Written by Technical Team | Last updated 15.08.2025 | 21 minute read
If you’re building software for the NHS, “integration” is less a single decision and more a collection of carefully sequenced choices. The modern landscape is anchored by national services collectively referred to as the Spine, wrapped in robust identity and security controls, and increasingly expressed through open standards such as HL7 FHIR. Knowing which national service does what—and how they fit together—is the difference between an elegant go-live and months of avoidable rework.
At the heart of most national flows is NHS Spine integration. Think of Spine as the national backbone that verifies identities, moves messages, and coordinates transactions across organisations. Some APIs sit directly on Spine (for example, the Electronic Prescription Service), others rely on a Spine-managed gateway (notably GP Connect via the Spine Secure Proxy), and many use Spine adjuncts such as the Spine Directory Service to discover endpoints or certificates. Your application rarely talks “to the NHS” in the abstract; it talks to precisely defined services that together make up the national fabric.
Standards matter because they de-risk interoperability. FHIR resources and profiles now underpin a growing list of APIs—from GP Connect’s clinical record access to the Booking and Referral Standard (BaRS). Even when a service still transports payloads through older patterns (for example, asynchronous documents over MESH), the content itself is increasingly FHIR-profiled, enabling structured consumption and safer downstream automation. Investment in clean FHIR mapping early in your architecture pays compounding dividends: less custom code, clearer test cases, and easier evolution as NHS services iterate.
The most surprising reality for many teams is that technical connectivity is only half the job. Assurance, governance and information standards drive your timeline just as much as code. Clinical risk management (DCB 0129/0160), information governance, and role-based access (via CIS2 or NHS Login) must be baked in from sprint one. That’s not bureaucracy for its own sake; it’s how the NHS assures patient safety at national scale. The smoothest projects treat these controls as first-class product requirements, not post-hoc sign-off.
Finally, think in “workflows”, not just endpoints. APIs such as the Personal Demographics Service (PDS) and GP Connect don’t live in isolation; they are often chained. A typical pattern might be: authenticate a clinician with CIS2, find the patient and NHS number in PDS, pull context with GP Connect, and then continue the journey in EPS, e-RS or BaRS. Mapping these end-to-end workflows up front—where identities are proven, which consent applies, and how data is cached—will shape your API choices as much as any technical constraint.
Workforce and citizen access are separate worlds, each with distinct APIs and trust models. For staff-facing software, NHS Care Identity Service 2 (CIS2) provides modern authentication and authorisation. CIS2 replaces older, smartcard-only patterns with web-friendly flows, multi-factor options and role-based access that is auditable at a national level. It is your primary route to confidently knowing “who is this clinician, and what are they allowed to do?” down to specific activities such as prescribing or viewing sensitive records. Most national APIs expect you to present CIS2-derived identity and role claims when you act on behalf of a staff user.
For patient-facing applications, NHS Login is the standard way to verify a citizen’s identity and obtain consented access to their services. It’s an OpenID Connect–based flow with progressive levels of identity proofing, designed for mobile and web contexts, and the same underpinning service that powers the NHS App. A well-designed NHS Login integration does more than just sign-in: it becomes the core consent artefact for any subsequent data access on the patient’s behalf (for instance, fetching their demographic record from PDS or surfacing GP Connect information where permitted through citizen channels).
NHSmail, meanwhile, is not an identity provider for APIs in the same sense, but it often features in real-world solutions. Because it’s the standard, secure email ecosystem for NHS organisations, teams use NHSmail addresses and distribution lists for operational notifications, resilience fallbacks, and onboarding workflows. Integrations that send sensitive messages to clinical teams frequently need to interoperate with NHSmail to “meet users where they work”, especially in early rollout phases before in-product messaging is ubiquitous.
Robust identity integration is as much about product decisions as it is about tokens and claims. You’ll want to align your sign-in patterns to the user’s context (workforce vs citizen), capture explicit consent where required, and map clinical safety rules to roles. The rule of thumb is simple: let identity drive capabilities, not the other way around.
The Personal Demographics Service (PDS) is almost always your first clinical integration. It’s the national patient demographic index that resolves and validates NHS numbers and associated demographic details. In practice, that means you can search by demographics to find an NHS number (with robust trace and match logic), or—better—confirm a patient’s details when presented with an NHS number supplied by a trusted source. PDS’s value isn’t just identity quality; it’s also a safer patient-matching experience that reduces duplicate records and misfiled documents downstream. Used alongside CIS2 or NHS Login, PDS helps you enforce that the person you’re dealing with really is the person whose record you’re about to touch.
GP Connect is the primary route into general practice records and appointments. Access Record: HTML gives a safe, read-only longitudinal view that is human-friendly (think “what a clinician would see on screen”), while Access Record: Structured exposes computable FHIR resources—problems, allergies, medications, immunisations, observations and encounters—for algorithmic processing and decision support. Appointment Management allows permitted providers (for example, urgent care services) to book, amend or cancel slots in GP systems. All of this is brokered through the Spine Secure Proxy, which enforces both organisation-to-organisation trust and per-user access controls. For digital health teams, GP Connect is the bridge between national-scale identity/consent and real clinical context that powers everything from medicine reconciliation to safety alerts.
The Summary Care Record (SCR) API gives time-critical access to a condensed clinical summary—medications, allergies and adverse reactions—with additional data where the patient has consented. SCR is designed for direct care scenarios such as unscheduled or emergency care, where clinicians need a high-signal snapshot to make safe decisions. The access model is conservative by design: you will need to demonstrate a legitimate relationship, appropriate role-based access, and auditable justification. When you integrate SCR, design the UI around “need to know” access and evidence the clinical safety case for why this access reduces risk.
Referral and booking are increasingly standardised across the NHS, and two services sit at the centre of that change. The NHS e-Referral Service (e-RS) API powers searching for services, initiating referrals, triaging via Advice & Guidance, and managing bookings into secondary care. If your product helps clinicians or patients choose services and move care along a formal pathway, e-RS is the way you make that happen programmatically. The more recent Booking and Referral Standard (BaRS) aims to unify booking and referral channels, especially across 111/999, urgent care and community services, with consistent FHIR-based requests and responses. Where e-RS covers planned care journeys, BaRS addresses the wider system’s need to place people into the right service first time, regardless of entry point.
When people leave hospital or a clinic, the Transfer of Care API delivers structured documents—discharge summaries and clinic letters—back to general practice. Historically, these were PDFs or unstructured notes; the modern API encourages FHIR-aligned, computable content that can be filed to the correct patient and coded into the GP record. For teams building virtual wards, post-discharge monitoring or medicines optimisation tools, this feed is gold dust: it closes the loop after an acute episode with authoritative, timely data.
Finally, the NHS Patient Care Aggregator (PCA) API is emerging as a way to surface a citizen’s view of their care in one place, aggregating content from multiple national and local sources. While details evolve, the direction is consistent: give patients a coherent, secure, mobile-first experience that builds on the same underlying national datasets clinicians trust. If your product aims to extend the NHS App experience, or to personalise patient journeys with real data, tracking the PCA’s capabilities is a strategic bet worth making.
Together, these APIs turn identity into action. PDS tells you who the person is; GP Connect and SCR tell you what matters clinically right now; e-RS and BaRS determine where they should go next; Transfer of Care brings the story back to the GP; and PCA promises to give patients the same clarity clinicians enjoy. Design your data model around that narrative and your integration choices will largely make themselves.
For transactional medicine—orders that move, slots that fill, prescriptions that flow—you need robust patterns that cope with the realities of the NHS’s scale. The Electronic Prescription Service (EPS) is the standout example. In EPS, prescribers create electronic prescriptions and dispensers claim, dispense and report against them, with Spine acting as the orchestrator. It’s a high-throughput, safety-critical system where end-to-end integrity and audit are paramount. Integrating EPS is not just about sending payloads: you must implement deterministic state transitions (prescribed → signed → released → claimed → dispensed → completed), handle edge cases such as prescription cancellations and replacements, and reconcile with the national source of truth. Get this right, and you unlock genuinely paperless medicines workflows.
Booking and referral transactions are formalising around the BaRS specification. Technically, BaRS leans into FHIR for payload structure and supports both synchronous and asynchronous patterns, because not every receiving service can provide an instant answer. From a product perspective, BaRS’s promise is that you don’t have to maintain a zoo of one-off integrations with local urgent care and community providers. Instead, you adopt a national pattern that aligns with e-RS in spirit, but is optimised for first-contact and out-of-hospital flows where time and triage matter.
Integration with primary care systems outside national APIs typically happens through NHS IM1. The IM1 Pairing model allows accredited third-party applications to “pair” with GP system suppliers (EMIS, TPP, etc.) to perform assured capability sets—think appointment booking, record read/write, tasks and documents—against local GP systems. IM1 is invaluable when your use case is inherently within general practice and not fully covered by GP Connect. It does, however, require bilateral work with each GP system supplier and close attention to the assured capability you’re targeting. Treat IM1 not as a shortcut, but as a complementary route to fill gaps in national provision where necessary.
Messaging is the glue that binds asynchronous healthcare. The Message Exchange for Social Care and Health (MESH) is a resilient, file-based transport used widely for document flows such as pathology, screening and the “send document” capabilities of GP Connect and Transfer of Care. From an engineering lens, MESH feels different to REST: you prepare payloads, post to a mailbox, and poll for responses or acknowledgements. But its reliability in offline or bursty network conditions and its national scale make it a staple. When your workflow is tolerant of near-real-time rather than instant response, and the payload is a document or batch, MESH is a safe bet.
Two more services quietly underpin many integrations: the Spine Directory Service (SDS) and NHS Notify. SDS is the address book and trust store that allows systems to discover where to send traffic and how to secure it—endpoints, organisation codes, certificates and capability flags. If your app needs to find “which endpoint do I send GP Connect calls to for this practice?” or “what capability does this organisation advertise?”, SDS has the answer. NHS Notify, on the other hand, is your practical route to reaching people. Whether it’s appointment reminders, referral updates or prescription notifications, a scalable, templated notification service helps you reduce DNA rates, close loops with patients, and keep staff informed. Used judiciously alongside in-app messaging, it improves the reliability and reach of your service without reinventing messaging infrastructure.
Picking the right tool for the job is part art, part engineering discipline. The following rules of thumb help teams avoid common missteps and bake in resilience from day one:
In practice, most mature products implement all three patterns. An urgent care solution may call GP Connect for immediate clinical context, place a booking via BaRS, receive downstream documents via MESH, notify the patient via NHS Notify, and file the discharge summary back to the GP through Transfer of Care. The architectural elegance comes from making each of those steps explicitly idempotent, observable and testable, with Spine and SDS providing a stable backbone for routing and trust.
The fastest teams treat NHS integration as a product capability, not a sequence of tickets. Start with a clinical safety case that flows from your user journeys. That case will force clarity about which national APIs you truly need, which roles must access them, and what evidence of consent or legitimate relationship you will present. With that blueprint, build thin, isolated adapters for each national service—PDS, GP Connect, EPS, e-RS, SCR, Transfer of Care, BaRS, PCA, IM1, MESH—so you can test them independently, replay requests, and evolve versions without touching your core domain logic.
Testing should blend realistic data with rigorous failure injection. For synchronous FHIR calls, simulate timeouts, partial results and permission denials. For MESH, rehearse mailbox outages, duplicate deliveries and late acknowledgements. For EPS, walk every edge case (prescription cancellation, prescription replacement, dispensing partials) until your state machine is bulletproof. Observability is non-negotiable: log correlation IDs, persist request/response envelopes securely for replay in incident analysis, and emit metrics that encode clinical outcomes (for example, “percentage of referrals successfully booked within four minutes”).
Operationally, design for the NHS’s rhythms. Expect maintenance windows and regional variation in readiness. Build configurable “circuit breakers” so loss of one integration degrades gracefully rather than taking down your entire service. Provide staff with clear, audit-friendly ways to switch to fallback workflows—NHSmail notifications or manual booking escalation—without losing continuity or breaching privacy rules. When you add NHS Notify messaging, do so as an extension of your consent and comms preferences model, not as a bolt-on.
Assurance goes smoother when you show your working. Maintain a living integration dossier: sequence diagrams for each user journey across national APIs; data protection impact assessments that map fields to lawful bases; clinical safety hazards with mitigations tied to specific UI behaviours; and role mappings from CIS2/NHS Login claims to features in your app. When an assessor asks, “why do you need SCR here?” your dossier should make the clinical rationale and the technical control obvious. That confidence speeds approvals and builds trust with partner organisations.
Finally, keep one eye on the road ahead. The convergence around FHIR, the maturation of BaRS, the growth of the Patient Care Aggregator, and the steady migration of legacy transports to modern patterns all point to a simpler, more consistent future. Architect now for version churn: put feature flags around new capability sets, model payloads with strong typing, and never let a single national API’s quirks leak into the rest of your codebase. The future you—shipping a major upgrade in a week rather than a quarter—will thank you.
To bring everything together, here’s how each of the core NHS APIs most often features in real-world digital health products and platforms.
BaRS is aimed at standardising how the system books and refers across urgent, emergency and community services. It uses FHIR modelling so requesters and providers speak a common language, and it embraces both synchronous and asynchronous responses to reflect the realities of triage and capacity management. If you’re building a product that places patients into services from 111, 999, clinical hubs or community settings, BaRS is the path to repeatable, scalable integration rather than a web of one-off local feeds.
CIS2 underpins workforce identity. It provides a modern way to authenticate staff, assert their roles and permissions, and cryptographically sign actions where necessary. The big win is traceability: your app can prove, to national standard, who did what and with what authority. Implement it early; retrofitting role-based controls after you’ve built features is expensive and risks failed assurance.
e-RS enables referrals, bookings and Advice & Guidance into planned care. Through its APIs, your app can search for services, present options, create or update referrals, and manage appointments. A strong UX wraps these calls with clinically meaningful filters—by specialty, priority, clinic type—and handles the referral lifecycle end to end. When combined with PDS and GP Connect, e-RS lets you move seamlessly from identifying the patient, understanding their clinical context, and placing them into the right planned care slot.
EPS integration makes prescriptions flow safely without paper. Key responsibilities are accurate payload construction, state management across the prescription lifecycle, and reconciliation with Spine as the source of truth. In patient-facing apps, EPS-backed features power order tracking and reminders; in clinician-facing apps, they shorten the time from decision to dispensing. Strong error handling is essential: ensure that cancellations, replacements and nomination changes are transparent and auditable.
GP Connect comes in capability sets. Access Record: HTML supports safe, human-readable views used by clinicians across urgent and community care. Access Record: Structured gives computable FHIR resources for decision support, analytics and automation. Appointment Management lets authorised services book into general practice, which is crucial for 111 and urgent care pathways. Because GP Connect is brokered through the Spine Secure Proxy, you inherit consistent security and routing without managing a patchwork of practice-level connections.
IM1 is your route to deep, supplier-specific capability where national APIs don’t yet reach. It provides a formal pairing and assurance process to use a GP system supplier’s APIs for agreed functions—record writes, tasks, documents, appointments. It’s indispensable for products operating largely within general practice, but it requires careful planning: each supplier has nuances, and you’ll work through them one at a time. Build abstraction layers and feature flags so each capability can be rolled out per supplier without fracturing your codebase.
NHS Login provides a familiar, secure sign-in for citizens. It offers progressive identity proofing and clear consent flows, making it suitable for everything from viewing records to booking appointments and receiving messages. In your architecture, NHS Login tokens are the foundation for all subsequent citizen-initiated calls—whether that’s reading demographics from PDS, surfacing GP Connect content that’s permitted for citizen channels, or subscribing to notifications about referrals or prescriptions.
MESH is the workhorse for asynchronous document exchange across the NHS. You use it when you need guaranteed delivery, reliable acknowledgements and resilience to intermittent connectivity. Typical use cases include pathology results, screening programme messages, GP Connect “send document”, and Transfer of Care messages. MESH integration means mastering mailbox semantics, idempotent processing and robust monitoring. Treat it as a first-class integration with clear retry and deduplication logic.
Notifications reduce friction and missed care. Integrate a templated notification service to send emails, SMS and push messages for events such as appointment confirmations, referral updates, EPS prescription status, or post-discharge tasks. The trick is aligning notifications with your consent model and providing easy in-product controls for patients and staff. Done well, notify-style messaging lowers DNA rates and improves the perceived responsiveness of your service without overloading clinical inboxes.
The PCA’s goal is to provide a consolidated view of a patient’s care in one place, especially for citizen experiences. For integrated digital teams, that means a single, sanctioned route to surface a person’s care interactions across services rather than stitching together a dozen feeds. While capabilities continue to expand, designing with PCA in mind positions your app to dovetail with the NHS’s citizen-facing roadmap rather than running parallel to it.
PDS is your identity anchor: validate NHS numbers, resolve demographic details and reduce patient-matching risk. Build patient flows that bias towards confirmed NHS numbers (for example, by scanning barcodes on correspondence or using NHS Login–linked identities) and use PDS to verify changes rather than accept them blindly. Good PDS hygiene prevents downstream filing errors and underpins safe, automated workflows.
SDS is the directory and trust store for the ecosystem. Use it to discover endpoints, capabilities and certificates for secure communication between organisations. Avoid hard-coded assumptions and instead query SDS to determine where and how to send traffic. When things change—practice system migrations, new capability go-lives—you won’t need to redeploy your service.
Spine is the backbone, and many national services ride on it. Whether you’re transacting with EPS, brokering GP Connect via the Spine Secure Proxy, or relying on national identity and routing, your service will interact with Spine’s trust, audit and messaging layers. Architect all Spine-touching code with observability and clear separation so troubleshooting and assurance are straightforward.
SCR provides a concise clinical snapshot for direct care, including medications and allergies, with additional data when patients consent. Access is deliberately tightly controlled: you’ll need to present evidence of role, purpose and relationship. SCR works best when your UI emphasises clinical decision-making under time pressure and the audit trail is clear and reviewable.
Use Transfer of Care to send structured discharge and clinic documents to general practice. Embed it wherever your workflow reaches a “care episode complete” milestone, and design retries and reconciliations to assure nothing is lost. Because the content is structured, you can power automation such as medicine reconciliation prompts or follow-up task creation without brittle text parsing.
Even in a world of APIs, email remains part of the NHS operational toolkit. Integrate NHSmail for secure, auditable communications to clinical teams—especially for exception handling, fallback notifications and early rollout phases where not every partner is API-ready. Keep messages minimal, actionable and linked back to in-product detail to avoid “email becoming the product”.
A realistic patient journey might start with NHS Login to authenticate the citizen and present consent, call PDS to confirm demographics, pull a curated subset of GP Connect data to pre-populate a questionnaire, place a referral through e-RS with rich clinical context, notify the patient about their booking via NHS Notify, and later consume a Transfer of Care document back into the patient’s longitudinal record. If a clinician steps in, CIS2 governs what they can view or do; if the pathway is urgent, BaRS orchestrates bookings into appropriate services; if medicines are involved, EPS handles prescription flow with Spine safeguarding integrity. Along the way, SDS keeps endpoints discoverable, MESH moves documents reliably, and PCA offers the citizen a simple, consistent view. That’s the promise of NHS API integration done well: fewer gaps, faster decisions, and safer care.
Success here isn’t luck. It’s the deliberate result of designing for identity first, adopting national standards rather than inventing local ones, choosing the right transport for each job, and embracing assurance as a core product discipline. Do that, and these APIs stop being a maze and become the rails that carry your service from idea to impact—safely, at scale, across the NHS.
Is your team looking for help with NHS API integration? Click the button below.
Get in touch