A private healthcare provider can connect to NHS APIs, but only when the work it does supports the delivery of health and care for the NHS in England, because the NHS API platform is restricted to that purpose. The route you qualify for decides everything that follows. The relevant APIs are the Personal Demographics Service, GP Connect, the e-Referral Service, the Summary Care Record, the National Record Locator and MESH. Data flows in FHIR R4 using UK Core, SNOMED CT and dm+d. Before you go live you must clear DTAC, complete the Data Security and Protection Toolkit, satisfy DCB0129 and DCB0160 clinical safety standards, and respect the National Data Opt-out. Plan for roughly 8 to 16 weeks of assurance on top of your core build, total budgets from £45,000 to £180,000, and 9 to 18 months end to end for regulated apps.
Last updated: June 2026
Yes, but conditionally, and the condition catches more providers out than any technical detail. The NHS England API platform exists to support the delivery of health and care for the NHS in England. If your service is purely private, with no NHS-commissioned activity and no patient who is being treated under an NHS pathway, you will struggle to justify access to the more sensitive APIs. The platform team assesses purpose, not just capability. So the first question is never "can our software connect" but "does the work this software supports count as NHS care".
In practice, private providers fall into a few buckets, and the bucket you sit in determines the route. A private hospital group that also delivers NHS-funded elective procedures has a clear NHS purpose for those patients. A private GP practice doing a small amount of NHS work has a partial purpose. A pure wellness clinic with no NHS contract has almost no purpose and should expect to be limited to the open, unrestricted APIs only.
Our honest view: do not start a build assuming you will get GP Connect or Summary Care Record access. Start by mapping your eligibility, because retrofitting an architecture after you discover you only qualify for demographics is expensive and demoralising. The decision tree below is the one we walk every clinic through before a single line of code is written.
| Provider type | NHS purpose? | Likely API access | Realistic route |
|---|---|---|---|
| Private hospital delivering NHS-funded electives | Yes, for those patients | PDS, e-RS, GP Connect (case-dependent) | Full assurance via commissioner sponsorship |
| Private GP with partial NHS list | Partial | PDS, e-RS, possibly SCR | Standard onboarding, scoped to NHS activity |
| Health-tech vendor selling to NHS trusts | Yes, on behalf of trust | Depends on product; PDS common | Onboard per deploying organisation (ODS code) |
| Pure private clinic, no NHS contract | No | Open APIs only (ODS lookup, reference data) | Self-serve, no clinical-record access |
| Wellness or cosmetic provider | No | None of the restricted set | Build a private record system instead |
If you land in the bottom two rows, the right answer is usually a well-built private system, not an NHS integration. We design those too, and a clean custom CRM and patient-record system often serves a private clinic better than a constrained NHS connection ever would. Decide eligibility first, then choose the architecture.
The NHS publishes dozens of APIs, but for private providers a short list does almost all the useful work. The single most common starting point is the Personal Demographics Service, because almost every clinical workflow needs to confirm who the patient is, find their NHS number, and verify their registered GP. From there, the API you need depends on whether you are reading records, sending referrals, or moving documents.
The platform runs a "bring your own backend" model on Apigee. NHS England exposes the gateway and the auth; you build the system behind it. That keeps your architecture under your control but means the burden of resilience, logging and error handling sits with you, not the NHS.
Our stance: begin with PDS and ODS. PDS proves your auth, your FHIR handling and your governance under real conditions, and ODS lets you build and test without touching patient-identifiable data. Treat GP Connect and SCR as phase two, because they carry the heaviest assurance load and you want a working, audited pipeline before you ask for them.
| API | Primary use | Data sensitivity | Typical assurance weight |
|---|---|---|---|
| ODS | Organisation and practitioner lookup | Open data | Low |
| PDS | Patient trace and NHS number | Identifiable | Medium |
| e-RS | NHS referral booking | Identifiable, clinical | Medium to high |
| SCR | Meds, allergies, reactions | Sensitive clinical | High |
| GP Connect | Full GP record access | Highly sensitive | Very high |
| MESH | Document and bulk transfer | Varies by payload | Medium |
NHS integration uses two separate identity worlds and you must pick the right one for each journey: NHS login for citizens, and CIS2 for clinicians and health professionals. Both sit on OpenID Connect and OAuth 2.0, but they answer different questions. NHS login proves "this is the patient". CIS2 proves "this is an authorised member of staff". Confusing the two is one of the most common early design errors we see.
For patient-facing journeys, such as a private app letting a patient view a result or confirm their details, NHS login is the route. Its strength is identity assurance, measured in Vectors of Trust. Levels run from P0, where no verification has happened, through P5, to P9, the highest verification suitable for accessing sensitive health data. The level you need depends on what the patient can see or do. Showing a generic leaflet needs little; revealing clinical data needs high.
For staff-facing access to clinical records, CIS2 (the NHS Care Identity Service) carries the authentication, usually backed by a smartcard or a modern FIDO2 credential. Your application federates to CIS2 over OIDC, receives the clinician's verified identity and role, and you enforce role-based access on top.
The honest rule on auth: build it once, properly, and reuse it. The token handling, JWT signing and rotation logic is the same backbone whether you eventually add e-RS, SCR or GP Connect. If you are also building patient-facing automation such as an NHS-aware patient chatbot or an AI voice agent for appointment handling, the same NHS login layer should serve both, rather than bolting on a second auth stack later.
You must speak FHIR R4 as the primary standard, profiled to UK Core, with SNOMED CT for clinical terms and dm+d for medicines. Some older interfaces still use FHIR STU3, so a mature integration handles both. If your team has only ever built REST APIs against JSON of its own design, this is the steepest part of the learning curve, because FHIR is opinionated and the NHS profiles tighten it further.
FHIR (Fast Healthcare Interoperability Resources) models everything as Resources: a Patient, a MedicationStatement, an AllergyIntolerance, an Encounter. UK Core is the set of national constraints that tells you exactly how a UK Patient resource should look, which fields are mandatory, and which extensions apply. You do not get to improvise the shape of the data; you conform to the profile or the call is rejected.
Terminology is where many builds quietly go wrong. A medication is not a free-text string; it is a dm+d concept. A diagnosis is a SNOMED CT code, not your internal label. If you store free text and try to map it later, you inherit a permanent reconciliation problem. Capture the codes at source.
| Standard | What it governs | Where it bites |
|---|---|---|
| FHIR R4 | Resource structure and exchange | Strict validation; malformed resources are rejected |
| FHIR STU3 | Legacy interfaces still in use | You may need to support both versions |
| UK Core | UK-specific FHIR profiles | Mandatory fields and extensions you cannot skip |
| SNOMED CT | Clinical terminology | Diagnoses, problems, procedures must be coded |
| dm+d | Medicines and devices dictionary | Prescriptions and medication lists |
Our view on tooling: use an established FHIR library rather than hand-rolling validation. The HL7 reference implementations and well-maintained server libraries save months and remove a whole category of certification failures. The cost of getting terminology wrong is not a bug ticket; it is a failed clinical safety review. We treat the FHIR and terminology layer as a first-class component of any healthcare software build, never an afterthought bolted onto the end.
The governance load is larger than the engineering load, and underestimating it is the single biggest reason NHS integration projects slip. Before you connect anything that touches patient data you must satisfy DTAC, complete the Data Security and Protection Toolkit, meet the DCB0129 and DCB0160 clinical safety standards, establish a lawful basis under UK GDPR, and honour the National Data Opt-out. None of these are optional, and most must be evidenced, not merely claimed.
DTAC, the Digital Technology Assessment Criteria, is the NHS framework for evaluating digital health tools. It rolls clinical safety, data protection, technical security, interoperability and usability into one assessment that commissioners use to decide whether your product is fit to deploy. Treat DTAC as the umbrella; the items below are the supporting evidence it expects.
Here is the figure that should change how you plan: retrofitting compliance after the fact costs roughly 30 to 50 percent more than building it in from the start. A Clinical Safety Officer who joins at design time prevents architectural decisions that later have to be unpicked. One who joins at the end finds problems that are now expensive to fix. Be sceptical of any developer who treats DTAC and clinical safety as paperwork to handle "near launch". It is design input, and it belongs at the front.
| Requirement | Owner | Evidence produced | When to start |
|---|---|---|---|
| DTAC | Product and clinical lead | Completed assessment pack | Discovery |
| DSPT | Data protection lead | Published annual submission | Discovery |
| DCB0129 | Clinical Safety Officer | Safety case, hazard log | Design |
| DCB0160 | Deploying organisation CSO | Deployment safety case | Pre-deployment |
| DPIA (UK GDPR) | DPO | Signed-off DPIA | Design |
| National Data Opt-out | Engineering and DPO | Opt-out check in workflow | Build |
Onboarding moves through three environments, sandbox, integration and production, and you earn your way forward by passing assurance at each gate. The sandbox lets you build against synthetic data with no real-world risk. The integration environment tests your application against realistic, controlled conditions. Production is granted only once you have evidenced that you meet the integration criteria for the specific API. The e-RS journey is a good worked example, because its integration criteria are published as discrete stages you complete and submit.
The mistake to avoid is treating assurance as a single submission at the end. It is iterative. You demonstrate capability, the NHS reviews, you remediate, and you repeat until each criterion is signed off. Building a clean evidence trail as you go, rather than reconstructing it in a panic, is what separates a 10-week assurance from a 20-week one.
On the horizon, and worth designing toward, is the route for regulated private providers to plug into the NHS App through secure APIs. This is not yet live, so do not build a business case that depends on it, but it signals direction of travel: approved, well-governed private providers becoming first-class participants in NHS digital channels. If you build your auth, FHIR and governance layers cleanly now, you are positioned to adopt that route when it arrives rather than rebuilding for it.
One architectural caution: the NHS enforces rate limits and expects resilient clients. Design for token rotation, exponential backoff and graceful degradation from day one. A pipeline that falls over when a token expires will not pass assurance, and it will embarrass you in production. This resilience thinking is exactly what we bake into any healthcare process automation that touches NHS endpoints.
Budget 9 to 18 months and £45,000 to £180,000 for a regulated app that needs NHS integration, clinical safety sign-off and, where relevant, MHRA considerations. The assurance and governance work alone adds 8 to 16 weeks on top of your core engineering. These are realistic 2026 UK figures for a competent build, and they vary mainly by how many restricted APIs you need and whether you are also a medical device under MHRA rules.
The honest breakdown matters more than the headline. A demographics-only integration, PDS plus ODS, is a fraction of a full GP Connect and SCR build. The cost is not in the HTTP calls; it is in the FHIR conformance, the clinical safety case, the security evidence and the iterative assurance. Below is how we typically scope projects, and where the money actually goes.
| Project scope | Indicative cost | Timeline | Main cost drivers |
|---|---|---|---|
| Open APIs only (ODS, reference data) | £8,000 to £18,000 | 3 to 6 weeks | FHIR setup, no clinical safety |
| PDS demographics integration | £25,000 to £45,000 | 8 to 14 weeks | Auth, DSPT, basic DTAC |
| e-RS referral integration | £45,000 to £80,000 | 4 to 7 months | Integration criteria stages, clinical safety |
| GP Connect / SCR record access | £70,000 to £130,000 | 6 to 12 months | Heavy assurance, governance, DCB0129 |
| Full regulated app (multi-API + MHRA) | £90,000 to £180,000 | 9 to 18 months | Everything above plus device regulation |
Two figures are worth burning into your plan. First, the 8 to 16 weeks of assurance is sequential to much of the build, not parallel, so it lengthens the critical path. Second, retrofitting compliance costs 30 to 50 percent more than building it in, which means the cheapest path is also the most disciplined one. Our stance: do not chase a lower headline quote from a team that has never been through NHS assurance. The cheap build that fails clinical safety review is the most expensive build there is, because you pay twice and lose months.
Where can you safely save money? Phase the work. Ship PDS first, prove the pipeline, then add restricted APIs once you have a deployed, audited foundation. And reuse the auth and FHIR layer across products rather than rebuilding it per app. A clinic that wants demographics today and record access next year should architect for both now, then build incrementally. That is how we keep a multi-year NHS roadmap affordable rather than letting each phase reinvent the wheel.
Softomate runs NHS integration as a five-stage, fixed-quote engagement, so you know the price and the milestones before we start coding. We are a London-based software and automation agency in Stanmore (HA7), and we approach healthcare integration governance-first: eligibility and clinical safety are scoped in discovery, not discovered at launch. You get a single accountable team across engineering, FHIR conformance and assurance, rather than a developer who hands you a half-built integration and wishes you luck with the NHS.
Our process is deliberately front-loaded on the hard parts. We confirm your NHS purpose and the exact APIs you qualify for in week one, because that decision shapes everything. We bring clinical safety thinking in at design time, where it prevents rework, rather than bolting a hazard log on at the end. And we phase delivery so you get a working, audited PDS integration early, then layer on restricted APIs from a proven base.
| Stage | What happens | Typical duration |
|---|---|---|
| 1. Discovery and eligibility | Confirm NHS purpose, map APIs, scope DTAC and DSPT, fix the quote | 1 to 2 weeks |
| 2. Architecture and safety design | FHIR data model, auth pattern, DCB0129 hazard log started, DPIA drafted | 2 to 3 weeks |
| 3. Sandbox build | Develop against synthetic data, prove auth and FHIR conformance | 4 to 8 weeks |
| 4. Integration and assurance | Integration environment testing, evidence the integration criteria, security review | 4 to 8 weeks |
| 5. Production go-live and support | Production credentials, go-live checks, monitoring, annual DSPT upkeep | 2 weeks, then ongoing |
Pricing is fixed-quote after discovery, so you are never billed for surprises we should have foreseen. Demographics-led NHS integration projects start at £25,000, e-RS referral integrations from £45,000, and full record-access builds are quoted individually because the assurance scope drives the number. Every engagement includes the FHIR and auth backbone built once and reusable across your future products, which is where multi-phase clients save the most. If you want a patient-facing layer on top, our AI automation and web application teams build on the same secured foundation.
Most importantly, we will tell you honestly if you should not integrate at all. If your service has no NHS purpose, we will say so and design you a clean private system instead, rather than selling you an assurance process you cannot pass. That candour at the start is worth more than any feature list.
Only with a clear NHS purpose and full assurance. GP Connect access is among the most tightly governed APIs and requires strong clinical justification, a completed DSPT, DCB0129 clinical safety evidence and DTAC sign-off. A purely private clinic with no NHS-commissioned activity will not normally qualify and should plan for a private record system instead.
NHS login authenticates citizens and patients, proving who the patient is, with identity assurance measured in Vectors of Trust from P0 to P9. CIS2 authenticates clinicians and staff, usually via smartcard or FIDO2 credential. Both run on OpenID Connect and OAuth 2.0, but you choose NHS login for patient journeys and CIS2 for professional record access.
Yes. FHIR R4, profiled to UK Core, is the primary standard, with some legacy interfaces still on STU3. Clinical terms use SNOMED CT and medicines use dm+d. You conform to the profiles rather than designing your own data shapes, and malformed resources are rejected, so a proper FHIR library is strongly advised.
DTAC, the Digital Technology Assessment Criteria, is the NHS framework for evaluating digital health tools across clinical safety, data protection, security, interoperability and usability. It is not law, but NHS commissioners use it to decide whether to deploy your product, so in practice it is mandatory for any tool you want a trust to adopt.
Plan for roughly 8 to 16 weeks of assurance on top of your core build, and 9 to 18 months end to end for a regulated app. The assurance work is largely sequential, not parallel, so it extends the critical path. Building a clean evidence trail as you go keeps it at the lower end of that range.
The National Data Opt-out lets patients choose that their confidential information is not used beyond their direct care. Where it applies to your processing, you must check and honour that choice in your workflow. It does not block direct care uses, but you must build the opt-out check in rather than treating it as an afterthought.
Only to the open, unrestricted APIs such as ODS and reference data. The restricted APIs that handle patient-identifiable or clinical data require an NHS purpose, meaning your service supports the delivery of NHS care in England. Without that purpose, expect to be limited to open data and to build a private record system for everything else.
The e-Referral Service API books and manages referrals into NHS services. It supports XML, JSON, HTTP and OAuth, and its Clinical Referral Information API is live across several providers. Integration follows published integration criteria stages that you evidence and submit, making e-RS one of the more structured assurance journeys to plan around.
A Personal Demographics Service integration typically costs £25,000 to £45,000 and takes 8 to 14 weeks, covering auth, DSPT, basic DTAC and FHIR conformance. PDS is the usual starting point because almost every workflow needs to confirm the patient and their NHS number, and it proves your pipeline before you add heavier restricted APIs.
A route for regulated private providers to plug into the NHS App through secure APIs is on the roadmap but not yet live. Do not build a business case that depends on it. However, if you build your auth, FHIR and governance layers cleanly now, you will be positioned to adopt that route when it arrives without a costly rebuild.
NHS API integration is achievable for private providers, but only when your service supports the delivery of NHS care, and that eligibility decision must come before any code. Start with PDS and ODS to prove your FHIR R4, UK Core and OAuth 2.0 foundations, then phase in e-RS, SCR or GP Connect from an audited base. Budget 8 to 16 weeks of assurance on top of the build, total costs of £45,000 to £180,000, and 9 to 18 months for a regulated app. Remember that retrofitting compliance costs 30 to 50 percent more than building it in, so bring DTAC, DSPT and DCB0129 clinical safety to the front of the project. Respect the National Data Opt-out, choose NHS login or CIS2 deliberately, and design for rate limits and token rotation from day one. Get the governance right early and the engineering becomes the easy part.
If you are a private healthcare provider weighing up NHS connectivity, talk to our team about a fixed-quote discovery through our London healthcare software development service or get in touch to map your eligibility before you commit a budget.
Written by Deen Dayal Yadav, Founder of Softomate Solutions, a London-based software development and AI automation agency in Stanmore (HA7). With over 12 years building software and automation systems for UK businesses, including healthcare data integrations and FHIR-based pipelines, Deen leads a team that treats clinical safety and governance as design inputs, not afterthoughts. Softomate Solutions is registered at Companies House and delivers fixed-quote engagements for clinics, hospital groups and health-tech vendors. Learn more about Softomate Solutions.
We protect the real names of all clients featured in examples and case studies. Every testimonial is from a real client.
More from the blog
Work with us
Book a free 30-minute discovery call with DD and get a personalised automation roadmap.
Softomate Solutions Limited
Deen Dayal Yadav
Online
We use essential cookies to keep the site running. With your permission, we also use analytics cookies to understand how visitors use our site so we can improve it. No data is sold. Privacy Policy
