Written by Technical Team | Last updated 10.10.2025 | 11 minute read
The Summary Care Record (SCR) is a national electronic snapshot of essential clinical information taken from a person’s GP record. At its core, the NHS Summary Care Record FHIR API is the standards-based route to retrieve and, in appropriate contexts, update this information from accredited systems. It exists to make timely, clinically relevant information available at the point of care, in a way that’s consistent, secure and auditable for frontline services. By exposing a FHIR-conformant interface, it aligns to modern interoperability patterns while remaining anchored in NHS safeguarding and governance requirements.
An important practical nuance for product teams is eligibility: at the time of writing, access to the SCR FHIR API is primarily aimed at GP (primary care) systems, with a pathway envisaged for other settings over time. That positioning matters because it influences your onboarding route, your technical dependencies (such as identity, access and endpoint configuration), and your conformance evidence. If you’re building for secondary care or a cross-setting tool, you should still prepare your architectural runway now—identity, data handling and auditing are consistent themes—while tracking the evolving access scope.
From a capability point of view, the API is designed for direct care use by authenticated healthcare professionals within the NHS trust/organisation context. It supports reading an SCR for a patient and, depending on your role and approval, functions related to patient preferences and governance events (for example, recording consent changes or a privacy alert when emergency access is justified and mandated). Those workflows are tightly bound to user authentication and role-based access controls, so thinking about how your user journeys surface reason codes, consent state and auditing details is not just a UX concern; it’s a safety and compliance requirement.
Finally, because this is a FHIR-based interface, your design must be comfortable with FHIR resource structures, clinical coding, and document-style payloads. Whether your product stores clinical content, proxies it transiently, or renders it read-only, your data model and error handling should respect FHIR semantics, including how you treat identifiers, code systems, and immutable vs. mutable resources. This is less about “using FHIR” as a buzzword, and more about designing the smallest, safest surface area that cleanly maps to your clinical use case.
The legal basis for using SCR content is direct care. That simple statement carries several obligations: your application must only enable access to SCR where a legitimate clinical relationship exists, where the user is properly authenticated, and where access can be justified and audited. In practice, that means designing user flows that prompt for (and record) the “permission to view”, that honour patient preferences, and that log relevant details—who accessed what, when, why—so your Privacy Officer (or equivalent governance role) can review.
It is also essential to understand what the SCR contains and how consent influences scope. The core record includes current medications and allergies, and may include additional information (for example, significant medical history and care preferences) depending on patient choice and policy. Your UI should make that scope clear to clinicians, and your system should avoid any hidden “pre-fetch” that exceeds the minimum necessary. Build in the ability to surface consent state, explain what will be retrieved, and—where applicable—handle emergency access with the correct privacy alert mechanics and audit annotations.
Before a single line of integration code is written, there are foundational identifiers and identity patterns you must line up. First is user identity. User-restricted NHS APIs (which the SCR FHIR API is) use NHS Care Identity Service 2 (CIS2) for healthcare worker authentication, coordinated through the NHS API Platform’s OAuth 2.0 authorisation service. In real terms, your app registers on the platform, integrates an authorisation code or combined pattern, and exchanges tokens that include the user’s authenticated identity and role claims. For production traffic, tokens are obtained from the NHS API Platform token endpoint; for pre-production, equivalent integration endpoints are available. Treat token lifetimes, refresh behaviour and audience claims carefully and test them early.
Next, understand organisational identity and system accreditation. Every NHS organisation has an ODS code—a canonical identifier used across national systems for setup, reporting and access control. Your customer’s ODS code often gates which services and endpoints they are permitted to call, and it can drive aspects of role mapping, logging and tenancy. If you’re shipping a product across multiple NHS sites, your provisioning flow should capture ODS codes as first-class configuration and link them to deployment artefacts and audit partitions.
Alongside ODS, any system that connects to Spine has an Accredited System Identifier (ASID)—assigned per system per organisation. That means the same product installed in three trusts might have three distinct ASIDs. This is particularly relevant to routing and authorisation in Spine-mediated workflows, as well as for runtime lookups in the Spine Directory Service (SDS). Your deployment automation should therefore plan for ASID registration, per-site configuration, and robust runtime verification to ensure calls originate from the right ASID/organisation context.
A third building block is endpoint discovery and directory lookups. While you may not need to integrate directly with SDS for basic SCR FHIR consumption, understanding SDS concepts will make your life easier when troubleshooting. SDS is where accredited systems and endpoints are recorded; the FHIR-based SDS API and legacy interfaces expose ASID and message handling details that influence how calls are permitted or proxied. If your architecture involves intermediary components (for example, a proxy, gateway, or shared platform), ensure SDS-related metadata is correct and updated as part of your release pipeline.
Finally, align your environment strategy with NHS platform conventions. The NHS API Platform distinguishes sandbox/integration environments and production, with distinct base URLs and keys. Pay attention to the practicalities: separate API keys, separate identity apps/clients, and separate callback URLs for OAuth flows. This separation is not just tidiness; it’s a compliance and safety measure that prevents test traffic from leaking into live systems and vice-versa, and ensures you can reproduce authentication flows (including smartcard sign-in) in a controlled test setting before you onboard a live site.
Pre-integration essentials you should have in place:
Model the minimum viable surface area. With clinical safety and data minimisation in mind, only implement the endpoints and data elements you actually need. For many scenarios a read-only presentation of the core SCR is enough; for others, you may need to surface patient consent state or support specific governance actions. Design your UI to make those distinctions explicit to clinicians, and provide clear, copyable reason codes or justification fields when a privacy alert (emergency override) is necessary. Not only does this reduce risk, it will also shorten your assurance cycle by avoiding unnecessary scope creep.
Engineer for identity first. Development friction with CIS2 rarely comes from the protocol itself and more from lifecycle edges—token expiry, clock skew, missing or mis-scoped claims, and incorrect audience settings. Set up a dedicated “identity harness” in your codebase that can be executed in isolation from the clinical features. Include automated tests that request tokens, verify JWT signatures and claims, exercise refresh flows, and simulate invalid/expired tokens. For smartcard-backed paths, plan how your testers will access HSCN-connected devices or a virtualised alternative, and how you’ll replicate that experience in pre-prod.
Treat ODS and ASIDs as deploy-time, not just build-time, concerns. Because ASIDs are per system per organisation, you should not bake them into binaries. Instead, externalise ASID and organisation configuration and gate it behind a deployment step that validates against directory sources. Give your support team a one-page “ASID readiness” checklist: after installation at a new site, verify the ASID record, confirm the right FHIR endpoints are reachable, and perform a smoke test that exercises your permission-to-view flow end-to-end. The payoff is operational: fewer mysterious 403s and faster triage when something is mis-registered.
Design your audit spine. SCR access will be scrutinised. Build a single, consistent audit trail across user actions (authentication, privilege elevation, consent checks), clinical data retrieval (patient identifiers, SCR retrieval events), and governance events (privacy alerts, consent changes). Ensure every audit event is timestamped, linked to the user’s authenticated identity, and carries enough context to stand on its own. Provide a tamper-evident store and an export that your customers’ governance teams can review. Where possible, allow privacy officers to subscribe to a daily digest of SCR access in your application, filtered by site. This is as much a product feature as it is a compliance control.
Secure the transport, keys and code paths. The API Platform enforces TLS and OAuth 2.0, but your application still controls a lot of attack surface. Lock down redirect URIs. Rotate keys and client assertions frequently. Validate all JWTs before they reach business logic. Rate-limit calls to SCR endpoints to match real clinical patterns (for example, do not blast multiple read requests for the same patient without user action). For browser-based flows, implement CSRF protection around your OAuth redirects and use PKCE where appropriate. For native clients, prevent token exfiltration through mobile logs or crash reporters and store secrets in the operating system’s secure enclave/keystore.
The path to production involves more than “it works on my machine”. NHS England has well-defined onboarding routes, and you must align your evidence to the right one. Depending on the product and API, you’ll follow a digital onboarding flow or established assurance such as the Supplier Conformance Assessment List (SCAL), the Target Operating Model (TOM) or the Common Assurance Process (CAP). Read those pages early; they dictate the artefacts you’ll need—clinical safety case, DPIA, penetration test evidence, user help and incident playbooks—and the sequencing of your approvals.
Run a rehearsal of your go-live on a “near-live” customer site. Confirm that the production API Platform app is configured, that CIS2 sign-in flows work on clinical workstations (smartcard and non-smartcard routes), and that your deployment captured the correct ODS code and ASID. Have your Privacy Officer (or customer equivalent) review the first day’s access logs and sign off that the audit trail is complete and readable. If your product supports consent updates or privacy alerts, verify those paths with a small cohort of superusers and ensure the operational policy (who can do what, when, and how it is reviewed) is signed and stored centrally.
Operational go-live checklist you can adopt:
If you distil the work above into a single mindset, it’s this: treat SCR FHIR integration as a governed clinical feature, not just a technical one. The product choices you make—how you authenticate users, how you present consent and emergency access, how you log access—are proxies for the trust the NHS places in national services. Build a smallest-possible surface area that is role-aware, auditable and friendly to governance, and you will not only streamline your assurance path but also give clinicians the confidence to rely on your application when it matters.
From an engineering perspective, your early wins come from rehearsing identity, partitioning configuration by site, and baking in audit from day one. From a delivery perspective, your wins come from reading NHS onboarding guidance early and mapping evidence to your sprint cadences. And from a clinical safety perspective, your wins come from clarity: show clinicians what they are looking at, why they’re allowed to see it, and what will be recorded when they do.
That is the real checklist behind the checklist—an approach that keeps you quick on delivery, exacting on security, and respectful of the patient at the centre of it all.
Is your team looking for help with NHS Summary Care Record API integration? Click the button below.
Get in touch