Understanding the NHS Summary Care Record API: How It Works, and How to Integrate It Securely

What the Summary Care Record is — and why the FHIR API matters

The Summary Care Record (SCR) is a national dataset that surfaces vital GP-sourced information such as current medication, allergies, and adverse reactions. It exists to help clinicians who don’t have access to the full GP record make safer, faster decisions at the point of care. Rather than replacing local clinical systems, SCR augments them: a clinician in urgent care, a community setting, or a pharmacy can view a succinct, authoritative snapshot created from the GP record and synchronised to national infrastructure (Spine).

NHS England has published a modern, FHIR-based interface for the Summary Care Record. This SCR FHIR API sits alongside the legacy HL7 v3 route and enables approved software to programmatically access or update a patient’s SCR, using contemporary web standards and a clear OpenAPI description. For many suppliers, this is the simplest path to integrate with SCR while aligning with broader UK Core FHIR patterns.

It’s important to understand the current scope: as of late 2025, NHS England indicates that SCR FHIR API access is currently approved for GP (primary care) software. Secondary care availability is on the roadmap, and organisations outside the approved settings should plan for the NCRS (National Care Records Service) user interface or the HL7 v3 route in the interim. This distinction matters for product planning, resourcing, and timelines.

How the SCR FHIR API works: resources, interactions and data flow

At its core, the SCR FHIR API is an R4-based service built on UK Core patterns. Conceptually, there are two halves to understand:

• Read flows, where an authorised system retrieves the latest SCR for a patient; and
• Write flows, where a GP system publishes an updated summary document to Spine and, where permitted, signals changes to a patient’s consent for sharing. Both are represented using FHIR artefacts mapped from underlying Spine concepts.

On the read side, the API exposes a bundle representing the patient’s current SCR. The implementation guide describes a retrieval pattern that queries by the GP summary’s identifier (mapped from Spine) and the patient’s NHS number. In idiomatic FHIR terms, the client requests a Bundle containing a Composition (the clinical summary) and related entries. A typical search looks like “get me the GP Summary with this identifier for the patient with this NHS number.” This model preserves the SCR’s nature as an immutable clinical document with well-defined context and authorship.

On the write side, GP foundation systems publish updates as a new, immutable clinical document. Each upload results in a fresh summary stored in Spine clinicals; consumers always retrieve the latest “normal” SCR for a given patient. The implementation guide explicitly frames the MVP around two methods: (1) Send GP Summary Upload and (2) Update ACS consent status for SCR. The upload is modelled as a Composition aligned to UK Core; consent status interacts with the national Access Control Service (ACS), ensuring that sharing rules are respected.

Some implementations also rely on indexing and discovery through DocumentReference, particularly where documents are proxied or referenced by other national repositories. While the SCR retrieval pattern focuses on Bundle/Composition, developers should be familiar with DocumentReference semantics because other NHS APIs (for example, NDR and BaRS/NRL patterns) use it extensively to catalogue and fetch clinical documents. Understanding how DocumentReference and Binary relate to one another will pay dividends if your product needs to broker documents across services.

From a practical standpoint, you can treat the SCR FHIR API like a typical RESTful FHIR service secured with OAuth 2.0: you authenticate, obtain a token, and call FHIR endpoints over TLS. What’s different is the NHS-specific governance and the expectation that your client enforces clinical context (who’s the user? do they have a legitimate relationship? have they asked the patient’s permission to view?). Those guardrails are not just technical niceties — they’re mandatory features you must design into your product.

Key building blocks you’ll encounter

• FHIR version and artefacts. The guide targets FHIR R4 with a Composition representing the GP summary, delivered within a Bundle. You may also see AuditEvent where access logging or alerting is involved.
• Retrieval pattern. Query for the latest SCR by composition identifier and patient NHS number, returning a document bundle suitable for direct rendering or transformation.
• Publishing model. Each GP upload creates an immutable, versioned document on Spine. The FHIR upload aligns with UK Core; consent updates route to ACS.
• Adjacent document patterns. DocumentReference/Binary remain relevant across national services and are worth understanding for wider document workflows.

Access control, assurance and onboarding: CIS2, RBAC and “legitimate relationship”

Security is the defining characteristic of NHS platform integrations. The SCR FHIR API is user-restricted: you must authenticate both your application and the healthcare worker who is present at the point of care. NHS England’s standard patterns provide two options built on Care Identity Service 2 (CIS2) — combined and separate authentication/authorisation models. In both cases, the user proves their identity using an NHS Smartcard or a modern alternative, and your application obtains an OAuth 2.0 access token to call the API.

In the combined model, your app delegates end-user authentication to CIS2 “under the covers” of the API Platform’s OAuth server, keeping your integration simpler: you register only with the API Platform and receive tokens after the user signs in. In the separate model, you integrate directly with CIS2 for user authentication (for example, to retrieve richer identity claims) and request authorisation from the API Platform when you need to call a protected endpoint. Choose the pattern that aligns with your product’s risk profile and user experience; both land you with a standards-compliant OAuth bearer token for FHIR requests.

Authorisation is not solely technical. The National Role-Based Access Control (RBAC) model determines whether a given user — doctor, nurse, pharmacist, etc. — is allowed to perform a particular action (for example, “view SCR” or “upload GP summary”). Your software must enforce RBAC locally and propagate the right context in each call. Moreover, access must meet the “legitimate relationship” standard: the user is directly involved in the patient’s care and, where possible, has asked permission to view unless operating in best interests (for example, when the patient cannot consent). These duties are baked into SCR policy and must show up in your clinical safety case.

Finally, there’s onboarding and assurance. NHS England uses a digital onboarding process for SCR FHIR. You’ll submit a hazard log (using a provided template) and a risk log describing mitigations; the test team will seek evidence that your mitigations work in practice. Treat these as part of your design process rather than an after-the-fact exercise — they will shape user journeys (consent prompts, break-glass flows) and technical architecture (audit trails, token handling, privacy alerts).

Building and testing your integration: environments, test data and practical tips

NHS England’s developer guidance maps out a straightforward journey: understand the API, create a developer account, confirm your use case, design and build, test, undergo assurance, and go live. For the SCR FHIR API specifically, you’ll rely on the integration test environment, the downloadable test data pack, and the OpenAPI (OAS) file to generate SDKs and clients. Treat the OAS as your source of truth for endpoints, payloads, and error shapes; it’s maintained as the canonical API contract.

A dedicated read-only test data pack is available for SCR FHIR. It aligns with the PDS FHIR test packs (reusing NHS numbers) so you can exercise SCR and PDS together with coherent test patients — very useful when you need to validate identity flows end-to-end. The pack includes an XLSX index of test patients and XML exemplars of the two SCR types used in testing. Load these into your test harness and automate regression checks against them.

Your retrieval flow should be resilient and auditable. When you call the SCR FHIR API to fetch the latest summary for a given NHS number, design for idempotency and repeatability: cache etags or last-updated metadata if permitted, and expect that the “latest” document might change if the GP record has been updated. When rendering, preserve the SCR’s context (authors, dates, sections) and clearly label it as a summary, not the full GP record. Where your use case requires audit, align your logging with FHIR AuditEvent semantics; even if you don’t POST AuditEvent to Spine, a FHIR-literate audit trail makes clinical safety reviews simpler and aligns with NHS expectations.

For write scenarios in GP settings, integrate the summary upload pathway as a first-class feature that triggers on well-defined clinical events (for example, medicines or allergies updated). Respect the “immutable document” concept: an upload replaces the previous document with a new version in Spine, rather than patching an existing one. Where the clinical workflow requires changes to consent status (for example, enabling Additional Information), your client must use the designated route to update ACS and ensure that the UI communicates consent changes clearly to clinicians and, where applicable, to patients.

Integration checklist to de-risk your build:

• Accounts and access – Register a developer account on the API Platform and request SCR FHIR access for the correct environment(s). Verify your organisation and named contacts for assurance communications.
• Security architecture – Choose CIS2 combined or separate pattern; complete key registration; implement OAuth 2.0 token acquisition, validation, rotation, and revocation. Confirm RBAC mapping for each user role that will touch SCR.
• Test strategy – Import the SCR FHIR test data pack; create automated tests that fetch bundles for each patient and verify content against the supplied XML exemplars. Use the same NHS numbers to exercise PDS lookups where relevant.
• Clinical safety – Populate the hazard log and risk log templates early, then iteratively evidence each mitigation (for example, break-glass prompts, consent dialogues, audit visibility). Keep screenshots and test artefacts ready for evidence testing.
• Operational readiness – Implement robust error handling (timeouts, 4xx/5xx mapping to user feedback), observability (trace IDs, rate-limit metrics), and a clear support runbook for frontline services.

Common pitfalls and how to avoid them

• Treating SCR as a free-text blob. The SCR is a structured clinical document with crucial metadata. Surface sections clearly and avoid “flattening” context in your UI; this is essential for safe use.
• Skipping the permission-to-view moment. Build a clean, repeatable permission flow. If the patient can consent, ask. If they cannot, record the reason for best-interests access in your audit trail.
• Over-caching. Caching can improve performance, but never risk serving stale content where safety is at stake. Align cache lifetimes with clinical expectations and provide “refresh” controls for clinicians.
• Under-scoped RBAC. Map precisely which roles can view, upload or change consent — and test those paths under both CIS2 patterns to ensure least privilege is maintained.

Security by design: protecting patient data and staying compliant

The single best way to accelerate assurance is to build security into your product from day one. For SCR FHIR, that starts with CIS2-based user authentication and OAuth 2.0 for API calls. Your token client must validate signatures and claims, enforce expiries, and rotate credentials safely. Use short-lived tokens whenever possible and avoid persisting ID tokens; treat them as sensitive ephemeral artefacts. On the wire, enforce TLS 1.2+ and strict certificate validation; at rest, encrypt cached data (if any) and consider application-level encryption for particularly sensitive artefacts such as locally generated PDFs.

Design your UX for privacy and accountability. Present a clear permission-to-view step. If a clinician must “break glass” (override dissent) in a genuine emergency, make that explicit with warnings, capture a reason, and ensure your system triggers any mandated privacy alert workflow. Surface who accessed what and when directly to clinical governance teams via reports or dashboards. Finally, align with NHS England’s digital onboarding artefacts: maintain a living hazard log and risk log and keep them in step with your evolving product. Doing so doesn’t just get you through go-live — it makes your software safer in real-world use.

Conclusion: a pragmatic blueprint for teams

If you’re starting from scratch, adopt a practical sequence. First, confirm your use case and scope: is it GP software (eligible for SCR FHIR), or do you need NCRS UI integration now while you prepare for future API access? Then create your developer account, review the OAS, and scaffold a client with your preferred language and FHIR SDKs. Use the integration test environment with the SCR test data pack to stabilise retrieval and rendering. As your flows firm up, begin your CIS2 integration in the pattern you’ve chosen and wire in local RBAC checks. Build structured logging from day one and shape those logs into a FHIR-literate audit narrative.

Next, shift left on assurance: populate your hazard log, design explicit permission-to-view and break-glass experiences, and test them with clinicians. Avoid bespoke interpretations of national rules; follow the SCR service guidance on legitimate relationships and consent. Keep your product’s language human and consistent — clinicians should never be guessing whether they’re looking at a live GP system, a national summary, or a cached copy. If you implement write flows, remember that an upload creates a new immutable document; don’t mislead users with “update” metaphors in your UI.

Finally, plan for operations: define service-level expectations with your customers, document rate-limit behaviour, design graceful degradation (for example, clear messaging when SCR is temporarily unavailable), and provide a feedback loop to your team when clinicians encounter edge cases. As your product matures, keep an eye on NHS England’s roadmap — in particular, any expansion of SCR FHIR access beyond GP settings and enhancements to adjacent document services. Today’s well-designed integration will set you up to consume the next wave of national APIs with minimal rework.