NHS API integration gives private healthcare providers access to the same national clinical data infrastructure used by NHS trusts - patient demographics, medications, referrals, shared care records, and more. For private clinics, specialist consultancies, and independent hospitals operating in London and across the UK, this connectivity is no longer a luxury. It is becoming a competitive and clinical necessity.
Patients move between NHS and private care. Their records should move with them. A private cardiologist who cannot access a patient's NHS prescriptions, previous diagnoses, or GP referral information makes clinical decisions with incomplete data. An independent clinic that cannot receive or send NHS e-Referrals loses referral volume to competitors who can. The NHS API programme exists to solve these problems, and private providers who understand how to use it are building a significant structural advantage.
This guide explains what NHS APIs are available, how they work technically, what governance is required to access them, and how private healthcare organisations in London should approach integration.
The NHS API programme - managed through NHS England's Digital Services - provides a catalogue of APIs that external organisations can use to connect to NHS data and services. The programme replaced the older N3 connectivity model with a cloud-friendly, internet-accessible API layer built on FHIR R4.
The NHS API platform, available at digital.nhs.uk/developer, lists every available API, its access model, its data scope, and its assurance requirements. Currently, over 60 APIs are available across clinical records, prescribing, referrals, demographics, and administrative services. Not all are open to private sector organisations, but a significant number are available with appropriate governance in place.
The key APIs for private healthcare providers are the Personal Demographics Service (PDS) API, the Electronic Prescription Service (EPS) API, the e-Referrals Service (eRS) API, and the Summary Care Record (SCR) API. Each serves a distinct clinical and operational purpose.
The PDS API provides access to NHS patient demographic data: NHS number, full name, date of birth, address, registered GP, and death notification status. For private providers, the NHS number is the single most important piece of data for patient record matching and cross-organisational continuity.
An NHS number lookup at registration allows a private clinic to link its patient record to the national patient identifier. This enables downstream interoperability - any subsequent NHS API call for that patient uses the NHS number as the key, ensuring that records retrieved are unambiguous matches for the correct patient.
PDS API access requires completing the NHS onboarding process, signing the appropriate data sharing agreement, and demonstrating that the use case is appropriate. The PDS API operates under Spine Mini Services Provider (SMSP) rules for some access modes and full Spine connectivity for others. Most private provider use cases are well-served by the FHIR-based PDS FHIR API, which does not require full Spine connectivity.
The EPS API allows prescribers in any setting to send electronic prescriptions to NHS-registered dispensers and allows pharmacies to retrieve and dispense them. For private providers, EPS integration matters in two ways.
First, private prescribers whose patients also hold NHS prescriptions can view what has been prescribed, avoiding dangerous duplication or interaction. Second, private providers operating any prescribing or dispensing function need EPS connectivity to participate in the national prescription tracking system. This is particularly relevant for private GP services and specialist clinics with in-house dispensing.
EPS integration is technically demanding. It requires Spine connectivity, an NHS smartcard infrastructure for prescriber authentication, and integration with the NHS BSA's prescription tracking systems. The timeline for EPS integration is typically 12 to 18 months from application to live operation.
The eRS API allows referrals to be made, received, and managed electronically within the NHS national referral system. Private providers who are commissioned to deliver NHS services - either through integrated care board contracts or the NHS Private Patient Unit - can receive NHS referrals electronically via eRS.
For private providers seeking NHS volume, eRS integration is essential. A clinic that can receive NHS e-Referrals directly into its booking system reduces administrative friction and demonstrates to commissioning bodies that it has the digital infrastructure expected of an NHS partner.
eRS access requires registration as an NHS service provider, completion of the NHS Directory of Services requirements, and technical assurance through the Path-to-Live environment. Private providers must ensure their patient administration system (PAS) can receive and process eRS referrals before beginning integration.
The SCR contains a patient's key NHS clinical information: current medications, allergies, adverse reactions, and - where patients have consented to additional information - diagnoses, immunisations, and care plans. Every GP-registered patient in England has an SCR. Private providers treating patients for whom NHS records are relevant can view the SCR with appropriate clinical justification and patient consent.
SCR access is the most clinically significant of the private provider APIs. A private anaesthetist reviewing a patient's medications and allergies before a procedure, or a private emergency service treating an unconscious patient, has a legitimate clinical basis for SCR access. The data retrieved can prevent adverse events that would be impossible to prevent without NHS record visibility.
SCR API access carries the highest governance requirements. Organisations must demonstrate clinical need, role-based access controls, audit logging that meets NHS Digital's access audit standards, and staff training on appropriate SCR use. The process is rigorous, and rightly so.
All current NHS APIs use FHIR R4 as their data exchange format. FHIR (Fast Healthcare Interoperability Resources) defines a set of data resources - Patient, Observation, MedicationRequest, Appointment, and so on - and a REST API pattern for querying and updating them.
A private provider system that wants to call NHS APIs must be able to send and receive FHIR R4 resources. This is not a configuration option; it is a hard technical requirement. Systems built on proprietary data formats need a FHIR translation layer before they can communicate with NHS APIs.
Our API development and system integration team builds FHIR R4-compliant integration layers that sit between a private provider's existing systems and NHS APIs. The translation layer handles authentication, FHIR resource mapping, error handling, and retry logic, leaving the clinical application free to consume NHS data without managing the integration complexity directly.
There is an important distinction between full NHS Spine connectivity and the newer FHIR-based NHS API access model. Full Spine connectivity - required for EPS, some SCR use cases, and older NHS systems - involves connecting to NHS Spine through Message Handling Service (MHS) infrastructure, typically via a Spine-connected software supplier or hosted service. This is complex, expensive, and slow to implement.
The newer NHS FHIR APIs, available through the NHS API platform, use standard internet connectivity with OAuth 2.0 authentication. They do not require Spine infrastructure. For private providers whose use cases are served by the FHIR API layer, this is a dramatically simpler integration path.
The practical guide: check the NHS API catalogue first. If the data or service you need is available via a FHIR API, use that route. Reserve full Spine connectivity for use cases that genuinely require it - primarily EPS and certain administrative transactions.
Two authentication mechanisms are relevant for private providers accessing NHS APIs. CIS2 (Care Identity Service 2) is the smartcard-based identity system used by clinical staff to authenticate to NHS systems. It replaced the older NHS smartcard model and provides role-based access to NHS Spine services.
NHS login is the patient-facing authentication service. Applications that allow patients to log in using their NHS credentials use NHS login, which provides a verified NHS number along with the authentication token.
Private provider systems that are staff-facing (clinician portals, admin systems) typically integrate CIS2 for staff authentication to NHS APIs. Patient-facing applications use NHS login. The right choice depends on who is making the API call and what data they are authorised to access.
No private provider accesses NHS APIs without completing a governance process. The core requirements are:
Data Security and Protection Toolkit (DSPT). Completion of the annual DSPT submission demonstrates that your organisation meets NHS Digital's minimum data security standards. This is a prerequisite for any NHS data sharing agreement and for connection to NHS APIs. First-time DSPT submissions typically take 3 to 6 months to complete properly.
Data sharing agreement. NHS Digital requires a signed legal agreement before granting access to patient data through NHS APIs. The agreement type varies by API and data sensitivity. Summary Care Record access requires an NHS Digital Data Sharing Agreement at the highest tier. PDS access requires a more straightforward agreement but still requires legal sign-off from the organisation's senior responsible officer.
Technical assurance. Before connecting to a production NHS API, organisations must complete technical assurance testing in the NHS Path-to-Live integration environment. This confirms that the integration behaves correctly, handles errors appropriately, and does not generate unexpected load on NHS infrastructure.
Clinical safety. Where NHS API integration supports clinical decision-making, DCB0129 (manufacturer) and DCB0160 (deploying organisation) clinical safety standards apply. These require a Clinical Safety Officer, a hazard log, and a clinical safety case before go-live.
Accessing NHS patient data through APIs does not transfer the data controller obligations of NHS organisations to the private provider. However, the private provider becomes a data processor (or joint controller, depending on the use case) and acquires its own obligations under UK GDPR.
Private providers must document their lawful basis for processing NHS-derived patient data under Article 9(2) of UK GDPR. They must complete a Data Protection Impact Assessment (DPIA) for high-risk processing. They must implement appropriate technical and organisational measures - encryption at rest and in transit, role-based access controls, audit logging, and incident response procedures.
The ICO expects that organisations handling health data have not just policies in place but evidence that those policies are followed. Access logs, training records, DPIA documentation, and incident logs all provide that evidence. An ICO audit of a private provider accessing NHS data will look for all of these.
The sequence matters. Teams that attempt NHS API integration before completing the governance steps waste months and face application rejection. The correct order is:
Our health and wellness software development team supports private providers through this entire process, from use case definition through to technical assurance completion.
The commercial case for NHS API integration in London private healthcare is compelling and increasingly measurable. Private providers with NHS referral pathways report that eRS integration increases referral volume by removing the friction of paper or fax-based referral processes. Providers with PDS integration report fewer patient identification errors and reduced administrative rework. Providers with SCR access report clinical efficiency gains from not having to chase GP practices for medication histories and allergy information before procedures.
The competitive dynamic is also shifting. NHS integrated care boards (ICBs) commission private providers for NHS services as part of the independent sector treatment centre programme and elective care recovery. ICBs increasingly expect digital maturity - including NHS API connectivity - as a procurement condition. Private providers without NHS integration capability are losing NHS-commissioned work to competitors who have invested in their digital infrastructure.
The investment in NHS API integration is therefore both a patient safety measure and a commercial strategy. Providers who make this investment are building infrastructure that enables NHS commissioning relationships, improves clinical outcomes, and differentiates their offering from competitors who remain disconnected from NHS systems. In London's competitive private healthcare market, that differentiation has direct revenue impact.
Yes, but with significant governance requirements. Private providers can access NHS patient demographics via the PDS API, view Summary Care Records with clinical justification and patient consent, receive NHS e-Referrals via the eRS API, and view prescription information via EPS. Each data source requires a separate data sharing agreement with NHS Digital, completion of the DSPT, and technical assurance testing. Access is not available without completing these steps, and attempting to access NHS data without the appropriate agreements in place is a serious breach of UK GDPR and NHS data governance rules.
The end-to-end timeline depends on which APIs are required. PDS-only integration can complete in 6 to 9 months including governance. eRS integration takes 12 to 18 months. SCR access typically takes 12 to 24 months given the higher governance burden. These timelines are dominated by governance and assurance processes, not technical development. Technical integration with a FHIR-capable system typically takes 4 to 12 weeks once access is approved. Starting governance processes early and in parallel with technical development is the most effective way to compress the total timeline.
NHS Spine is the national IT infrastructure that underpins many NHS digital services including PDS, EPS, and the SCR. Some NHS APIs require full Spine connectivity - which involves Message Handling Service infrastructure and is complex to implement. Others, including the FHIR-based PDS API and the newer FHIR APIs, operate over standard internet connectivity and do not require Spine infrastructure. Private providers should check whether their target APIs offer FHIR access before committing to full Spine connectivity, as the FHIR route is substantially simpler and faster to implement.
FHIR (Fast Healthcare Interoperability Resources) is the international standard for health data exchange, now mandated by NHS Digital for all new NHS integrations. NHS APIs expose health data as FHIR R4 resources - standardised data objects for patients, medications, appointments, observations, and so on. A system that wants to call NHS APIs must be able to send requests and process responses in FHIR R4 format. Systems built on proprietary data formats need a FHIR translation layer before they can communicate with NHS APIs. FHIR also enables interoperability beyond NHS systems, as the same standard is used internationally in the US, EU, and Australia.
When a private provider accesses NHS patient data through APIs, it becomes a data processor or joint controller under UK GDPR and acquires its own compliance obligations. Health data accessed via NHS APIs is special category data under Article 9, requiring an explicit lawful basis, a Data Protection Impact Assessment, and appropriate technical controls including encryption, audit logging, and role-based access. The ICO has indicated that organisations accessing NHS data are subject to the same scrutiny as NHS organisations themselves when it comes to data protection obligations. Private providers must treat NHS-derived patient data with the same rigour as data they collect directly.
More from the blog
Let us help
Talk to our London-based team about how we can build the AI software, automation, or bespoke development tailored to your needs.
Softomate Solutions Limited
Deen Dayal Yadav
Online
