Written by Technical Team | Last updated 05.09.2025 | 20 minute read
The NHS Summary Care Record (SCR) provides an at-a-glance view of essential clinical information to support safe, informed care when a person presents outside their usual setting. At its simplest, it contains current medications, allergies and adverse reactions. With explicit consent (or in an emergency where consent cannot be obtained), Additional Information may be included: significant medical history, care preferences, and other pertinent details that clinicians rely on for rapid, risk-aware decisions. Bringing this content into your application via a modern, standards-based interface is where the FHIR API comes in.
Fast Healthcare Interoperability Resources (FHIR) is the dominant healthcare interoperability standard globally, prized for its developer-friendly RESTful approach and consistent, machine-readable clinical models. In the NHS, SCR data is exposed using FHIR resources and UK-specific profiles that align with national terminologies like SNOMED CT and the dm+d medicines dictionary. Instead of wrestling with bespoke payloads or legacy message formats, implementers work with predictable resource shapes such as Patient, AllergyIntolerance, MedicationRequest or MedicationStatement, and document-style bundles that can be rendered for clinical viewing or mined for discrete data.
A common pattern for summaries is the FHIR “document paradigm”, which uses a Composition resource to act as the clinical table of contents and assembles related entries into a Bundle. This gives you a clinically coherent snapshot comprising sections for medication, allergies, problems and more, complete with authorship, attestation and timestamps. It is also routine to retrieve discrete resources via FHIR search endpoints when your application needs to drive decision support or reconcile the SCR with locally held records. Both approaches can coexist: a single document fetch to display a human-readable summary, and targeted queries for features like duplicate therapy detection or allergy cross-checks.
UK Core profiles are central to reliable integration. They constrain base FHIR to match NHS policy and practice (for example, UK-specific name structures, identifiers and extensions), and point to UK terminologies to support semantic interoperability. When you map your application models to UK Core, you dramatically reduce ambiguity and the likelihood of downstream surprises. For SCR, this typically means ensuring you correctly handle NHS Numbers as national identifiers, recognise SNOMED CT codes across clinical conditions and allergies, and parse dm+d-coded medication concepts for a consistent medicines experience.
SCR holds confidential patient information, so access is tightly governed. Integrators must design with security and clinical safety as first-class concerns from day one. At a minimum, you should plan for strong authentication, explicit authorisation, layered transport security, robust auditability and strict purpose-of-use controls that align to direct care. These controls are not optional “boltons”; they are foundational to gaining onboarding approval and to retaining trust in live service.
In NHS environments, authentication typically follows one of two patterns. For end-user-facing applications—think a clinician launching from an EPR or a web portal—user authentication leverages NHS Identity services (Care Identity Service 2), flowing via modern OAuth 2.0 and OpenID Connect. Tokens include claims describing the authenticated professional, their role-based access and the organisation they’re operating on behalf of. For system-to-system use cases—background services or server-side batch operations—mutual TLS and signed JWTs are commonly used for client authentication, with fine-grained scopes determining what the calling system may read. In both cases, access is constrained to the minimum necessary for direct care.
Traffic to national services often traverses the Spine Secure Proxy (SSP), which acts as a policy enforcement point and broker. When your requests route via the SSP, expect to supply standard headers to identify your accredited system, the target endpoint and the interaction you are attempting. This is part of the national trust fabric: it allows consistent audit, throttling, and policy checks at the edge. Your solution will be issued identifiers (such as an ASID) and will operate on behalf of organisations identified by ODS codes, giving the platform a clear view of “who is calling, on whose behalf, for what”.
Compliance goes beyond transport and identity. The NHS requires evidence of robust information governance and clinical safety. From an IG perspective, you will need to complete the Data Security and Protection Toolkit assessment appropriate to your organisation’s role, conduct Data Protection Impact Assessments, and embed the Caldicott Principles and the common law duty of confidentiality in your operating procedures. From a clinical safety angle, the standards DCB0129 (for manufacturers) and DCB0160 (for deploying organisations) require you to manage hazards systematically and assign a named Clinical Safety Officer who assures the design, risk controls and testing approach.
To turn these principles into an implementation plan, build your integration around the following security building blocks:
Integrating with SCR via FHIR is less about exotic endpoints and more about applying the core REST patterns effectively. Most solutions combine a patient identity confirmation step, a summary retrieval step and optional resource-level queries for workflow-specific features. The details will vary with your clinical context, but the patterns are consistent and lend themselves to clean, testable designs.
Everything begins with the patient identifier. The NHS Number is the canonical identifier for English care settings. Your UI should capture enough demographics to confirm identity—name, date of birth and postcode are commonplace—and your back end should verify the NHS Number format using the standard modulus 11 check before making any clinical calls. It is also good practice to reconcile the number against a demographics service to catch transpositions or stale identifiers. Once you have a confidently matched NHS Number, you use it to drive your SCR queries: either as a direct Patient/{id} read (where the system exposes a deterministic mapping) or as a search on Patient?identifier= followed by linked resource retrieval.
For a clinician-friendly view, the document approach is powerful. A typical call uses a Composition-oriented endpoint that returns a Bundle representing the person’s summary. Your application renders the HTML narrative for immediate safety—ensuring that medications, allergies and adverse reactions are always visible in a human-readable format—and also iterates entries to populate structured models for downstream features. Because summaries are inherently time-sensitive, make sure you surface “as at” timestamps, authorship and any caveats about completeness. If Additional Information is present, signpost it clearly and ensure your consent capture aligns with policy.
Targeted resource searches unlock richer behaviours. For example, reconciling a medicines list against local prescribing requires access to the underlying medicine resources using dm+d codes. Cross-checking allergy status during an admission may need a fresh AllergyIntolerance?patient= search to ensure you are not relying on stale cache. Clinical decision support rules often pivot on Condition (active problem list), potentially Observation (e.g. vaccination status or key vitals) and Procedure entries that signal significant interventions such as cardiac devices or implants. The FHIR _include and _revinclude parameters are helpful when you need to resolve references (for example, to pull Medication alongside MedicationRequest) in a single round-trip.
Caching and conditional requests matter. The SCR is a shared national asset; your design should be polite to upstream services without compromising clinical freshness. Use entity tags (ETag) and If-None-Match or If-Modified-Since headers to avoid downloading an unchanged summary repeatedly. Persist small, time-bound caches—minutes, not hours—for non-critical views, and always provide a manual refresh in clinical screens to respect professional judgement. When you cache, store the identifiers and version IDs of individual resources: it simplifies later reconciliation and enables you to implement lightweight “resource changed?” checks.
To help your team map SCR content to FHIR, the following resource-level view is a practical starting point:
A successful SCR integration follows a predictable delivery arc. It starts with discovery and onboarding, where you register your organisation and system, document your intended use cases, and secure the necessary technical details: endpoints, environment URLs, authentication setup, scopes, and any required proxy configuration. You will be assigned or request identifiers for your system and test organisations, and you’ll provision certificates and secrets for lower environments. Treat this as a first-class engineering task—store everything in your secrets manager, script your environment configuration, and put guardrails in place so developers cannot accidentally point at production.
Your path to production should pass through a dedicated test environment with rich, realistic data sets. Populate automated tests that exercise the full journey: authentication flows, patient lookup, summary retrieval, error handling, and audit logging. Where the upstream supplies sandboxes with synthetic patients and pre-canned SCR payloads, build scenario tests that cover the edge cases you absolutely do not want to discover in clinic: patients with no SCR; patients with allergies but no medications; patients with long medication lists; records containing Additional Information; and records where certain sections are withheld or marked as sensitive. Formal integration and assurance checkpoints will expect evidence of these tests, traceable to your hazard log and clinical safety case.
Once live, your obligations shift from “can we integrate?” to “are we operating safely, reliably and respectfully at scale?”. Performance must be predictable under load and degradation must fail safe. Timeouts, retries and circuit breakers protect your users from intermittent upstream issues, while making your platform a good citizen of the shared service. Implement exponential back-off with jitter on retriable HTTP responses, and treat non-retriable codes (like 403 and 404) as terminal, surfacing clear messages in your UI to prevent clinicians repeating the same failing action.
Resilience sits alongside performance. Design for transient network faults, certificate rollovers and token endpoint slowdowns. Monitor every step with metrics that actually matter: authentication latency, token acquisition failures, success rates for summary fetches, cache hit ratios, median and tail latencies per endpoint and per calling feature, and user-visible error rates. Wire these into alerts that route to on-call engineers and clinical safety contacts. Where your system supports “break-glass” access, monitor and audit it separately with heightened scrutiny; out-of-pattern use is both a safety signal and a potential IG incident.
Clinical safety never stops at go-live. Your hazard log should evolve with the product: new features, updated upstream behaviour, and user feedback all drive review cycles. Carry out regular safety audits of the SCR rendering components to ensure that changes in profile constraints or terminology do not accidentally hide or misrepresent critical information. Keep your Clinical Safety Officer engaged in routine change processes and incident post-mortems. When you update your FHIR client library or alter caching behaviour, run targeted regression tests against edge-case summaries and document the clinical impact assessment.
Terminology and profile drift are living realities. Schedule routine updates of SNOMED CT and dm+d within your platform and rehearse the operational steps: downloading reference sets, reindexing lookups, regenerating code systems in your decision support rules, and testing example SCR payloads that reference new or deprecated concepts. Do the same for UK Core profile changes: when the upstream tightens a cardinality or introduces a new extension, your validation logic and parsers may need updates. Fail validation errors noisily in non-production and fail gracefully in production with explicit user messaging and error telemetry.
Finally, don’t neglect human-centred design. The safest SCR integration is one where clinicians can see and trust the essentials without hunting. Put allergies and adverse reactions above the fold; show current medications with dosage and status; and present provenance so that a clinician knows when and by whom the summary was last compiled. Offer clear affordances for consent and break-glass, and make the “no SCR available” state friendly but unmissable. It is better to return a fast, honest message that a summary cannot be retrieved than to leave a clinician guessing behind a spinning loader.
Even experienced teams benefit from a few pragmatic guardrails when they first integrate with a national FHIR service. Focus on testability from the outset. Encapsulate authentication, request construction and response parsing behind a narrow service interface in your codebase and inject it wherever your application needs SCR data. This lets you stand up fake servers or replay fixtures for unit tests, proving that your user experience and clinical logic respond correctly to every scenario you can imagine. Keep a library of real-world-like SCR payloads—sanitised and synthetic—that cover wide variation in data quality and completeness.
Invest in robust error handling and user messaging. FHIR servers will communicate error conditions via OperationOutcome resources; don’t discard them. Parse the structure to extract human-meaningful details. Distinguish between “not found”, “access denied”, “patient is sensitive/restricted”, and “temporary service issue”. Map each to a design system component with the right copy and next steps. In a ward round, an ambiguous error forces clinicians to repeat actions or, worse, guess—a recipe for frustration and risk. In your telemetry, tag errors with a stable taxonomy so you can spot trends across sites and versions.
Keep your FHIR client flexible. Differences in profile constraints, optional elements and extension usage are inevitable between environments. Treat the UK Core profiles as your baseline, validate server responses against them in non-prod to catch drift early, and relax validation in production to prioritise clinical safety. When you do encounter an unexpected element or a constrained field, log it with context and a copy of the offending fragment under strict PHI handling controls. These breadcrumbs are invaluable when liaising with upstream teams to resolve inconsistencies.
On the front end, render the document narrative as your primary display, but never as your only safety net. The narrative ensures a clinically authored view is visible even if your structured parsing misses something edge-case. At the same time, structured rendering—lists of allergies with reaction severity, medicines grouped by status, explicit flags for “no known allergies”—helps clinicians scan and act more quickly. Combine the two: show the narrative, tally structured counts and surface attention-grabbing exceptions (e.g., severe anaphylaxis) as chips or callouts.
Wherever possible, avoid reinventing wheels. Reuse well-maintained FHIR libraries for your language, choose a mature OAuth/OIDC client for token management, and adopt tested HTTP clients with built-in retry and circuit breaker support. Standardise on a small set of internal abstractions—HTTP client, auth provider, FHIR parser—and make them easy to swap. This pays off when you upgrade from one FHIR release to another, replace your OIDC library, or need to add an alternative identity flow for a new care setting.
Integrating with SCR is not just a technical exercise; it is stewardship of patient trust. Your workflows must respect consent and transparency. If you present Additional Information, indicate clearly that the broader view is being accessed and for what clinical purpose. Where policy requires it, record the clinician’s justification for break-glass access and display it back for confirmation. Build in a habit of showing patients what is being accessed about them when interactions occur in patient-facing contexts; this fosters trust and reduces the likelihood of misunderstandings or complaints.
Retention and minimisation principles apply to cached SCR data. Store the smallest amount of data for the shortest time necessary to deliver safe care. Avoid long-term replication of national data into your own stores unless there is a clear legal basis and a clinical necessity, and even then, architect for segregation and traceability. When you do cache or persist for audit, encrypt at rest with strong keys, segment access by role, and ensure your deletion workflows are tested and evidenced. Patients have rights to know how their data is used; your privacy notices and support processes should make it easy for them to understand and exercise those rights.
Be prepared for edge cases where a patient’s record is flagged as sensitive or restricted. Your UI should explicitly communicate that access is restricted and provide policy-appropriate next steps, rather than generic failures. In some scenarios, a restricted patient may still permit access to certain sections or metadata; design your parsing and display layers to handle partial documents gracefully, with prominent banners and a clear provenance trail so clinicians never mistake a partial view for a complete one.
Finally, embed a feedback loop with your clinical users. The best technical controls are undermined by poor usability, and the safest clinical designs evolve with real-world experience. Provide a simple route for clinicians to report unexpected SCR behaviours or data quality issues they repeatedly encounter. Treat such reports as both product backlog items and potential safety incidents, triaging accordingly. This partnership mindset turns your integration from a compliance project into a living, trusted capability.
Healthcare interoperability is dynamic. New UK Core versions are published, authentication capabilities evolve, and national programmes adjust policy. Your SCR integration should be built to change. Maintain a configuration registry that decouples environment URLs, scopes, headers and feature flags from code so you can respond quickly to upstream adjustments. Use semantic versioning and release notes internally for your FHIR client so other teams consuming it can anticipate breaking changes.
Observability is your early-warning system. Beyond raw metrics, invest in distributed tracing that follows a summary request from UI click through to token exchange, proxy hop and FHIR response. Tag traces with patient pseudonyms (never raw identifiers in logs), user roles and site codes to detect patterns: for example, slower responses when Additional Information is included, or higher error rates for a particular organisation due to firewall quirks. These insights help you work constructively with upstream operations teams and your own site IT departments.
When introducing changes, run canary releases for a subset of users or sites. Because clinical stakes are high, avoid “big bang” rollouts of authentication libraries or FHIR parsers. Pair canaries with feature flags to revert quickly if you encounter unexpected server behaviour or data shapes. Keep a formal “change impact on clinical safety” checklist for each release: list the components touched, the resources affected, the hazards re-assessed, and the test evidence you have gathered. Over time, this discipline reduces deployment stress and increases stakeholder confidence.
Looking ahead, design your data access layer with multiprofile capability. Although SCR has a clear scope, your platform may also integrate with GP Connect, the Personal Demographics Service or the National Record Locator—each with its own profiles and conventions. A pluggable validation and mapping layer lets you add or switch profiles without invasive rework. It also positions you to take advantage of future enhancements, such as richer provenance metadata, improved document rendering hints, or expanded consent signalling.
To integrate with the NHS Summary Care Record FHIR API successfully, think like a product team, a safety engineering team and an IG team at the same time. On the product side, focus on clear, clinician-centred displays and snappy performance. On the safety side, treat the SCR narrative as the ground truth for visibility, validate and parse structures carefully, and never hide uncertainty. On the IG side, be parsimonious with data, explicit with consent and auditable in everything you do. Wrap these with sound engineering practices—testable abstractions, resilient networking, secure key management and rich observability—and you have the foundations of a robust, approvable integration.
The payoff is real. A well-implemented SCR integration gives clinicians immediate access to medications, allergies and adverse reactions, reduces transcription errors, speeds triage and strengthens continuity of care across settings. It also builds public trust that sensitive health information is handled with the seriousness it deserves. By grounding your build in FHIR best practice, UK Core profiles, strong security and clinical safety standards, you create a capability that is both useful today and adaptable to tomorrow’s interoperability landscape.
That is the essence of a high-quality integration: not simply “connecting to an API”, but delivering a reliable, safe and respectful experience that earns its place in the clinical workflow, quietly helping professionals make better, faster decisions for the people they serve.
The NHS Summary Care Record FHIR API specifically provides access to essential patient summary data such as medications, allergies, and significant medical history. Other NHS FHIR APIs, like GP Connect or Personal Demographics Service APIs, expose different types of data. The SCR API is intended for rapid clinical decision-making, while others support broader workflows such as appointments, demographics verification, or full GP records.
Yes, third-party apps can integrate with the SCR FHIR API, but they must undergo a strict assurance process. This includes proving compliance with NHS interoperability standards, demonstrating robust security, and meeting information governance requirements. Without formal approval, apps cannot access live patient data.
There is no direct licensing cost for using the API itself. However, organisations should budget for development, security testing, assurance, and compliance processes. In some cases, there may also be costs for connectivity to NHS infrastructure, such as the Health and Social Care Network (HSCN).
Approval timelines vary depending on your readiness. Organisations with a mature security framework and a clear clinical use case may complete onboarding in a few months. However, more complex implementations can take longer if additional assurance steps, clinical safety case reviews, or extensive testing are required.
Direct patient access to their Summary Care Record is not supported through this API. It is designed for healthcare professionals delivering direct care. Patients can view their health information through NHS-approved channels, such as the NHS App, rather than via third-party integrations with the SCR API.
The API provides near real-time access to patient summary data, but it is not a continuous live feed. Each API call retrieves the most recent version of a patient’s record available at that point in time. If frequent updates are required, applications must request refreshed data using appropriate FHIR queries.
Eligibility is generally limited to NHS organisations and approved partners delivering direct care. This includes hospitals, GP practices, urgent care centres, and approved digital health suppliers. Commercial vendors must demonstrate a legitimate role in supporting NHS care delivery to gain access.
Developers can use sandbox environments, synthetic patient records, and automated test packs provided by NHS Digital to simulate real-world integration scenarios. These resources are essential for building confidence before applying for live service access.
The SCR API is designed for use within England’s NHS infrastructure and follows UK-specific profiles and terminologies. While based on global FHIR standards, it is not intended for international healthcare systems. Overseas organisations working with the NHS may integrate, but only if they meet NHS assurance and compliance requirements.
Is your team looking for help with NHS Summary Care Record API integration? Click the button below.
Get in touch