UK Core and NHS APIs: PDS, EPS, e-RS, BaRS and MESH are not one FHIR server
FHIR UK Core is the four-nation R4 profile baseline. NHS England catalogue APIs — PDS, EPS, e-Referral, BaRS and MESH/ITK3 — are separate products. Care Connect STU3 is deprecated.
Ala Ben Aicha
Direct answer
FHIR UK Core is the four-nation R4 baseline. PDS, EPS, e-RS, BaRS and MESH are separate NHS catalogue APIs, not one UK Core endpoint. Care Connect STU3 is deprecated in favour of UK Core R4.
UK Core: the profile pack, not the national spine
FHIR UK Core is the HL7 UK / NHS England baseline for FHIR R4 across the four nations. NHS England’s standard page: FHIR UK Core (DAPB4020 governance). STU1 (1.0.0) is the first balloted release; the STU2 sequence (2.0.0) is the current Standard for Trial Use recommended for implementation (Simplifier STU2). STU3 is a development sequence, not a reason to skip STU2 in a 2026 build.
Canonical for the Patient profile: https://fhir.hl7.org.uk/StructureDefinition/UKCore-Patient. UK Core does not, by itself, give you a production NHS API. It constrains resources so that other IGs and catalogue APIs can share Patient, Practitioner and terminology.
Country-specific identifier: NHS number, system https://fhir.nhs.uk/Id/nhs-number, with the UK Core NHS-number verification-status extension. Ten digits plus modulus-11 in the NHS Data Dictionary. Do not publish a real NHS number. Verify numbers through PDS; do not invent a local checksum service and call it PDS.
Care Connect STU3 is deprecated
NHS England’s catalogue entry Care Connect FHIR API standards states that Care Connect FHIR API standards have been deprecated. FHIR standards work continues as FHIR UK Core on R4 for England, Scotland, Wales and Northern Ireland. Booking-related Care Connect work is pointed at BaRS. New work should not start on Care Connect STU3 profiles.
NHS catalogue APIs are separate products
Look up each API in the NHS England API and integration catalogue. They have different onboarding forms, auth (often CIS2), environments and payloads. UK Core compatibility of a Patient resource does not enrol you in any of them.
| Use case | Catalogue API | What to remember |
|---|---|---|
| Trace, match and retrieve demographics; NHS number | Personal Demographics Service — FHIR | PDS FHIR is the national Patient spine. UK Core Patient is the profile shape; PDS is the service. |
| Send / dispense community prescriptions | EPS FHIR Prescribing and EPS FHIR Dispensing | EPS is its own R4 product (prescribing and dispensing split). Not a generic MedicationRequest CRUD on your server. |
| Create and manage referrals and slots | e-Referral Service — FHIR | e-RS is a national referral service. The HSCN-only predecessor is in production but deprecated; new integrations should use the current catalogue item. |
| Booking and referral between providers (including UEC) | Booking and Referral — FHIR (BaRS) | BaRS replaces Care Connect booking standards. Separate assurance from e-RS. |
| Fire-and-forget clinical messages, including ITK3 payloads | MESH / Interoperability Toolkit | MESH is a transport. ITK3 is a message specification that often rides MESH. Neither is a REST FHIR server. Transfer of Care FHIR messages are a MESH workflow, not PDS. |
Do not invent NHS England assurance durations. Each API’s catalogue page states its status (in production, beta, deprecated) and points to the onboarding process. Assurance clocks are on those pages and in the supplier contracts, not in this article.
What a UK build actually looks like
- Profile layer: UK Core R4 (STU2 unless the buyer names another sequence) for Patient, Practitioner, Organization, and the clinical resources you persist.
- Identity service: PDS FHIR for NHS number trace and retrieval. Telehealth and patient-facing apps that need a verified NHS number still go through PDS, not through a home-grown MPI alone. The telehealth platform article is about product architecture; it is not a PDS substitute.
- Workflow services: EPS, e-RS or BaRS if that workflow is in the contract — each with its own OAS, sandbox and CIS2 app registration.
- Messaging: MESH/ITK3 when the receiver is a mailbox, not a FHIR REST endpoint.
- Generic FHIR REST: the HL7 FHIR R4 guide for your own resource server. That server is not on the spine until a catalogue API says it is.
What this is not
This page is not NHS assurance, not a connection agreement, not an ODS code allocation, and not legal advice. Implementing UK Core profiles does not mean NHS England has assured the product. I do not quote onboarding weeks or “typical DSPT timelines” because those are not mine to invent. Nothing here is clinical advice.
Related reading
For UK Core mapping and catalogue-API integration design, use HL7 FHIR integration.