Written by Technical Team | Last updated 10.10.2025 | 12 minute read
If you are building a healthtech product for the English NHS, few architectural choices matter more than how you integrate with GP-held data. Two headline options often surface early in discovery: the Summary Care Record (SCR) FHIR API and GP Connect: Access Record – Structured (ARS). On the surface, both expose information that originates in GP systems and both speak FHIR. In reality, they serve different clinical moments, follow different governance paths, and present distinct technical patterns. Choosing the wrong one can saddle your team with avoidable rework or, worse, a solution that will not be assured for live use.
This deep-dive explains what each API is for, the data you can expect to receive, the consent and authorisation models that govern access, and the practicalities of going live. By the end, you’ll know which API to reach for first—and how to plan a roadmap that keeps clinical safety, legal basis, and delivery pragmatism squarely in view.
Although they draw from overlapping GP-sourced information, the two APIs target different problems in care delivery.
The Summary Care Record (SCR) FHIR API is about accessing a national summary that is specifically designed to support urgent and emergency care, and to provide a concise, high-signal view of a person’s critical information. It exists on the Spine and is populated from GP systems; historically this has been accessed via HL7 V3, and a FHIR-native interface is now available. The FHIR API’s explicit remit includes retrieving a patient’s SCR, uploading an updated SCR (for eligible systems), and managing consent-related operations (for example, updating a patient’s consent preference or raising a privacy alert in the narrow circumstances where dissent must be overridden). Importantly, a healthcare worker must be present and strongly authenticated, typically via an NHS Smartcard or a modern alternative, to use this API. At the time of writing, it is approved for GP (primary care) software rather than secondary care applications.
GP Connect: Access Record – Structured (ARS) is a Spine-brokered way for approved systems to retrieve a structured, coded slice of the registered GP practice record from the GP principal supplier (for example, EMIS, SystmOne). Rather than a single national summary document, ARS returns coded data by clinical area (medications, allergies, problems, consultations, investigations and more), in a format that consuming systems can import and process. It is designed for direct care and supports a wide range of care settings (acute, community, urgent care, shared care records and others). It currently runs over HSCN and is protected by the Spine Secure Proxy (SSP). Some areas—especially beyond medications and allergies—may still be in beta or vary by provider rollout, so product teams should plan for incremental data availability.
At a practical level, think of SCR FHIR as a nationally shared summary designed for fast, safe recognition of the most important facts—particularly in urgent or unscheduled settings—while GP Connect ARS provides richer, structured payloads directly from the GP system for broader care planning, medicines reconciliation, and longitudinal context. If your primary need is “What are this patient’s current meds, allergies and critical flags?” in a time-pressured context with a clinician present, SCR may be the better fit. If you need to process GP data at scale (for example to pre-populate a medicines reconciliation view, or surface problem lists and consultations inside an EPR), ARS is typically the better choice.
The first question product teams ask is, “What data do we actually get?” Here the APIs diverge in important ways.
SCR content and “additional information”. At its core, an SCR carries current medication, allergies, and bad reactions to medicines. This “core” payload is intentionally focused and unambiguous. However, a richer “additional information” (AI) set can be included with the patient’s consent (or under time-limited national arrangements), adding content such as significant history and procedures, immunisations, end-of-life preferences, anticipatory care information, and communication needs. During COVID-19, policy temporarily enabled broader inclusion of AI on an opt-out basis; that specific policy context ebbs, but the model demonstrates how AI can extend the SCR’s clinical value when legally justified. For app design, this means you should not treat SCR as a free-form record dump—it remains a summary, optimised for safety and speed.
GP Connect ARS clinical areas. ARS returns coded data from the registered practice record under distinct clinical groupings. Medications and allergies are fully in production; other areas—immunisations, problems, consultations, investigations, diary entries, outbound referrals and uncategorised items—are available with caveats (for example, provider support and version status), and programmatic differences exist between suppliers. Your integration should therefore be resilient to partial or evolving coverage per practice and supplier. In exchange, you get data you can ingest and compute on—ideal for features such as decision support, alerting, or automated form pre-population.
Document retrieval and HTML views. ARS focuses on structured data. If you need documents (attachments, letters) referenced in those records, you pair it with GP Connect: Access Document; if you need a rapidly embeddable, read-only view, GP Connect: Access Record – HTML is designed for that. This partitioning keeps the structured channel clean for computation, while still enabling retrieval of human-authored artefacts when required.
Upload vs read-only considerations. Another key difference: ARS is a read pathway for the structured record; there is no write-back to the GP record via ARS itself. Separate “Update Record” capabilities exist in the GP Connect family for specific write scenarios. By contrast, the SCR FHIR API includes upload operations (for eligible GP systems) to keep the national summary up to date, alongside retrieval. That can influence systems that act upstream of the summary—for example, GP EMR vendors.
At-a-glance data expectations:
Both APIs exist to support direct care and therefore enforce robust checks on who is asking, why they’re asking, and what they can see. But the mechanics differ in ways that matter for architecture and UX.
Identity and session assurance. The SCR FHIR API requires a healthcare worker to be present and strongly authenticated—historically with an NHS Smartcard, with modern alternatives available. That requirement shapes product design: every SCR interaction is bound to a present clinician with appropriate role-based authority, rather than a headless server-to-server process. Practically, this keeps SCR aligned with its clinical purpose: rapid, safe recognition of critical facts in time-sensitive care.
Spine Secure Proxy and JWTs for GP Connect. GP Connect ARS traffic is brokered through the Spine Secure Proxy (SSP), a forward HTTP proxy that centralises authentication and authorisation checks, audits, and data-sharing validations. Consuming systems send requests with a JSON Web Token that carries details about the user, organisation (ODS code), the system, and—where Smartcards are used—SDS identifiers. Local RBAC is required on the consumer side; national Smartcard use is not mandated by ARS (though some organisations may choose it). The SSP then verifies the request against data-sharing agreements and forwards it to the GP principal system. This pattern underpins ARS’s ability to operate reliably across multiple suppliers at national scale.
Consent and “additional information”. Consent in SCR is not a generic tick-box; it has specific meanings that change what appears in the summary. Patients can have a core SCR only, or a core SCR plus “additional information”, which significantly enriches the summary. There are also pathways for temporary policy changes (as during the COVID-19 COPI period), and mechanisms for recording dissent. The SCR FHIR API explicitly exposes endpoints to set or update consent preferences and to raise a privacy alert where it is lawful and necessary to override a recorded dissent. Teams must model these states clearly in their UI and logs.
Direct care purpose and legal basis. Both APIs require a lawful basis, routed through the direct care purpose; neither is a data exhaust for analytics or secondary uses. GP Connect ARS documentation explicitly constrains creation of patient-facing medical record views and reporting for secondary purposes via ARS alone; similarly, SCR is scoped to direct care with strong, per-access user assurances. Product managers should be precise in their use-case descriptions during onboarding, because assurance teams will validate that design and behaviour align with these constraints.
For teams on the clock, the differences in deployment pathways can be as decisive as the data model itself. Understanding network access, service levels, assurance and test strategies early saves rework later.
Network and availability posture. GP Connect ARS is currently available over HSCN and is classified as a silver service: run 24×7×365, supported in business hours. Internet enablement is on the roadmap, but HSCN remains the route at present. That carries practical implications—your hosting, connectivity and supplier arrangements must align with HSCN access (including potential use of managed HSCN providers).
FHIR style and operations. ARS is deliberately operation-based rather than a free-roaming REST browse of resources. You POST a FHIR Parameters payload indicating which clinical area(s) you want, and the provider system constructs a safe, clinically coherent response (for example, ensuring linked relationships are returned together). This choice favours clinical safety and consistent semantics over ad hoc resource traversal—a good trade-off in high-risk clinical contexts and a signal to design your client around well-formed “asks”.
Prerequisites and assurance for ARS. Before coding, confirm you can meet the technical, IG and clinical safety prerequisites. In practice that means aligning your platform and processes to national expectations and building a plan for test evidence.
Testing strategy for ARS. There are two parallel streams: technical testing (to prove your messages conform to the spec and that your integration with Spine/SSP is robust) and clinical testing (to demonstrate safe interpretation, processing and display of clinical data). NHS England provides clinical test data and guidance on hazards to mitigate as you design UI and workflows. Expect to iterate on edge cases—such as historical vs current meds, coded vs free-text entries, or handling of uncategorised items.
Onboarding and live gating. After submitting your use case and being approved, you’ll work through a structured consumer assurance process with gates that cover both test streams, evidence, and provider interoperability checks. Because ARS is a brokered model that touches every principal GP supplier, your go-live staging may be incremental by region or supplier availability. Maintain a provider-matrix and actively detect capability at runtime so you can gracefully degrade features in practices that have not yet enabled a given clinical area.
SCR FHIR integration footprint. The SCR FHIR page is intentionally lean on public details, but there are a few crucial signals for engineering: operations encompass getting an SCR identifier, retrieving the SCR, uploading the SCR (for eligible GP systems), updating consent, and raising a privacy alert on lawful override. Access is constrained to scenarios with a present and authenticated healthcare worker, and the current approval scope prioritises primary care software. For test planning, NHS England publishes a test data pack aligned to PDS FHIR so you can exercise the integration in the INT environment. The clinical safety posture is similar to ARS—direct care, strong identity, robust audit—but you should plan your consent flows and user journeys to reflect the meaningful state of consent (for example, “core only” vs “core + additional information”).
With the differences laid bare, how should a product or architecture team decide? Focus on clinical moment, data needs, and operational model.
If your users are clinicians who need a single, trusted, concise summary in urgent or unplanned care—especially where a Smartcard-presented session is natural—then SCR (FHIR) fits the moment. The content is intentionally conservative, the semantics are well understood, and the combined consent-and-privacy controls align with the seriousness of that use case. Where patients have given consent for “additional information” (or it is otherwise lawfully enabled), the SCR can carry enough context to inform decisions without overwhelming the clinician with the full record. Your design should emphasise recognition over analysis: present the essentials immediately and make any AI content clearly delineated.
If your aim is to compute on the GP record—populate a medicines reconciliation workflow, prefill clinical forms, surface problem lists, drive clinical decision support, or integrate longitudinal context into EPR or shared care portals—choose GP Connect ARS. You will do more engineering work to handle operation-based requests, supplier variability and edge cases, but the payoff is structured, coded data suitable for automation. Pair ARS with Access Document for attachments and letters when your UI needs narrative context, and consider Access Record – HTML when an embeddable, read-only view accelerates delivery while you mature your structured data features.
Finally, roadmap sequencing matters. Many teams start with Access Record – HTML for immediate read-only visibility, layer in ARS for computable use cases, and integrate SCR for urgent-care contexts where a national summary offers safety and speed. If you are a GP EMR vendor or a system collaborating closely with one, SCR FHIR upload endpoints may also feature in your plans to keep the national summary current. In all cases, bake in the governance work—HSCN connectivity, SSP integration, JWT construction, PDS alignment, local RBAC, clinical safety cases—early in discovery so the engineering work unfolds in parallel with assurance.
In summary: use SCR (FHIR) when you need a strong, clinician-presented summary that prioritises safety and recognition, with explicit consent semantics and national reach; use GP Connect ARS when you need structured, computable slices of the registered GP record for direct care features that benefit from machine-readable data. Both are vital parts of the NHS interoperability fabric—pick based on the clinical moment you serve, and plan your delivery to respect the security, consent and assurance patterns that make these APIs safe to use at national scale.
Is your team looking for help with NHS Summary Care Record API integration? Click the button below.
Get in touch