Written by Technical Team | Last updated 10.10.2025 | 10 minute read
When clinicians meet patients for the first time—at 3am in urgent care, in a pharmacy consultation, or during a home visit—the riskiest moments are often the quiet ones: “What medicines do you take?” “Have you ever reacted badly to penicillin?” Silence, uncertainty, or an incomplete answer can turn into duplicated tests, delayed treatment, and medication errors. The Summary Care Record (SCR) exists to blunt that risk by providing an up-to-date clinical snapshot, created from the patient’s GP record and made available across care settings for direct care. The SCR FHIR API is the new, standards-based way for software to fetch, upload and manage that snapshot, embedding crucial context into the systems staff already use.
Unlike older, bespoke interfaces, the FHIR version of the SCR service lets integrators use modern, interoperable patterns to retrieve the latest SCR document and its pointer, check and set permission-to-view, and, for GP systems, upload updated summaries. That combination—authoritative data, near real-time updates from general practice and explicit governance—means safer, faster decisions, especially when a patient cannot speak for themselves.
At its core, the SCR FHIR API provides programmatic access to the patient’s Summary Care Record: an electronic record of important information such as medicines, allergies and adverse reactions, alongside richer “Additional Information” where appropriate. It exposes a standards-based interface to request, fetch and work with this record inside clinical software.
Crucially, the API’s scope is not just “read.” It also covers key operations that make the service clinically complete: applications can obtain the patient’s SCR identifier, download the current summary, upload a new GP summary (for authorised GP systems), update the patient’s consent to share with the Access Control Service (ACS), and raise a privacy alert when a break-glass override is needed. These capabilities lift SCR from a static viewer into an actionable, integrated safety tool.
The FHIR interface sits alongside the long-standing HL7 V3 route. That V3 service remains in production for creating and retrieving records and interacting with ACS; the FHIR approach is the easier, more modern path the programme has been building toward, aligning with UK Core FHIR profiles and current interoperability strategy.
One policy change that substantially increases the safety value of SCR is the ongoing inclusion of “Additional Information” by default for patients who have not previously expressed a preference. This means more clinically relevant context—significant medical history, immunisations, end-of-life information—travels with the patient across settings, while previous opt-outs and explicit choices are still respected. For integrators and clinical teams, that equates to fewer blind spots in emergencies and better continuity of care.
Technically, the SCR FHIR API follows familiar patterns. Two interactions matter most at the point of care: first, retrieving the pointer to the latest GP Summary via DocumentReference, and second, fetching the actual SCR document as a Bundle containing a Composition and supporting entries. In practice, the client asks for the latest DocumentReference of a particular type and then uses the link in that reference to request the document bundle for the specific patient.
The “type” in that DocumentReference is not arbitrary. It uses a SNOMED CT code to precisely identify the GP Summary concept, ensuring the client is asking for the right artefact. The query typically filters by patient NHS number and sorts for the most recent item, returning a single pointer that includes a URL to the Bundle endpoint. This small detail—using standard terminologies and consistent, typed pointers—improves reliability and makes integration deterministic.
Security is delivered the NHS way: the Spine Secure Proxy (SSP) acts as a broker and gatekeeper, providing a single point for authentication and authorisation and handling auditing and traffic control. Rather than each provider system exposing itself to the internet, consumer systems connect via SSP, which enforces policy, checks data-sharing agreements and keeps a robust audit trail. That architecture reduces surface area and standardises trust, crucial in a complex ecosystem.
The identity and audit model builds on access tokens and structured provenance. After authorisation, clients pass a JSON Web Token that captures the end-user context; the token is used both to confirm the request is properly authorised and to record who did what, when and why. GP Connect’s security guidance complements this with clear requirements for traceability headers and the broader audit envelope. In short: every access is attributable, every transaction auditable.
In frontline workflows, the person behind the keyboard matters. Access to SCR for direct care requires a healthcare worker to be present and authenticated—typically via an NHS smartcard or a modern alternative through CIS2. That ties each call to a real clinician in a real organisation, keeping the API anchored in legitimate relationships and minimum-necessary use.
The safety promise of the SCR API is inseparable from its governance model. Consent to share and “permission to view” (PTV) are not box-ticking exercises—they are the controls that ensure data flows only for direct care, with patient preferences honoured. FHIR makes these controls explicit. For example, the API includes an operation to set a patient’s permission status (Yes, No, Ask), and it works in concert with the Access Control Service behind the scenes.
How permission and break-glass work in practice: a GP system can update the PTV flag for a patient; a system can raise a central alert when an override (access in the public interest) is used; and patient preferences about the inclusion of Additional Information continue to be respected even as default inclusion remains in place for those who have not expressed a preference. These controls ensure access is both clinically responsive and accountable.
Good process still matters. Organisations viewing SCRs are expected to seek permission to view at an appropriate point in the patient’s pathway, explain the purpose plainly, define the scope of consent and record it. This isn’t bureaucracy for its own sake; it is what preserves patient trust and ensures a defensible audit trail when data is accessed under pressure.
The service remains purpose-bound to direct care. That means staff must be involved in the patient’s care, operating under a legitimate relationship, and using the information only to support diagnosis, medication safety, and treatment decisions. Clinical systems that integrate the API need to reflect those constraints in their user experience, access controls and logging.
Medication safety is the most visible benefit. With the SCR readily available inside clinical systems, clinicians can confirm the current list of medicines and check allergy and adverse reaction history before prescribing or administering. That context reduces omission errors, helps avoid contraindications and improves reconciliation during admissions and transfers. The SCR has been designed from day one with these use cases in mind.
The service shines in out-of-hours and urgent care. When a person cannot communicate or records are scattered across multiple systems, the SCR quickly answers “what do we know for sure?” Pharmacists, ambulance staff, 111 clinicians and urgent care teams can see core information, and, where included, richer context that helps them make safer decisions under time pressure. With very high population coverage, the odds are good that a relevant record is available when it matters.
End-of-life preferences and anticipatory care plans are another safety frontier. Additional Information can include EoL details (from the national dataset), significant medical history and reasons for medication. Surfacing these inside frontline clinical software avoids repeat conversations, aligns care with patient wishes and supports safer de-escalation where appropriate. It also helps identify risks—for example, steroid-dependent patients or those with complex comorbidities—early in an emergency presentation.
Finally, the way the SCR is generated contributes to reliability. Because it is created from the GP “source record” and synchronised when that record changes, the API generally returns a near-current snapshot rather than a stale PDF hidden in a shared drive. That timeliness, plus explicit permission-to-view and auditing, turns the SCR into a practical risk-reduction tool rather than a theoretical repository.
If you are planning an integration, treat the SCR API as both a technical and a clinical safety project. NHS England uses a digital onboarding route for the SCR FHIR API, and suppliers are expected to provide a hazard log and a risk log that show how you have identified and mitigated foreseeable harms. Evidence-based testing of those mitigations is part of the path to live. These artefacts exist to protect patients—and your users—when your software is under stress.
A build-time checklist that pays off in safety and speed:
From a developer-experience perspective, start with the interactive documentation/OAS file to generate clients and stub out requests, then wire in authentication and SSP routing. The onboarding portal provides the templates and submission routes for safety logs; plan time to complete them well and to demonstrate your mitigations with evidence. Quality here reduces back-and-forth and accelerates your path to production.
Eligibility matters. At the time of writing, this API is approved for use in primary care software—specifically GP systems—with a roadmap intent to broaden availability in future. If you sit outside that scope, engage early to validate your use case and understand the assurance path, rather than building on assumptions.
Go-live is not the finish line; it’s where safety is proven thousands of times a day. Monitor your audit events for patterns (e.g., frequent overrides at certain sites), build prompts that help clinicians seek permission at the right moment, and keep your consent and permission UI unambiguous. The safest integration is the one clinicians barely notice because it simply works the way they work.
Pulling it together, the SCR FHIR API is not just another data feed. It is a mature, governed, standards-based capability that lets you put the essentials—medicines, allergies, adverse reactions and clinically significant context—right where decisions are made. By combining authoritative data from general practice with FHIR patterns, SSP-mediated security, permission-to-view controls and explicit auditing, the API helps reduce the most common and dangerous failure mode in clinical care: acting without the full picture. Done well, that’s what safer care looks like in software.
If you are building for the NHS, start small with the pointer and document retrieval flows, wire in clear PTV prompts and auditing, then iterate toward uploads and consent management where appropriate. The result won’t be a flashy dashboard; it will be a quieter ward round, a safer prescribing moment, and a patient who doesn’t have to remember every detail at the worst possible time. That is a worthy definition of “digital transformation.”
Is your team looking for help with NHS Summary Care Record API integration? Click the button below.
Get in touch