Care Coordination and 360 Referrals (Proof of Concept) - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

NHS England Referral and Report Services

This page assesses the national NHS England services for referrals and reports against the 360X transactions. Test orders (pathology, genomics, imaging) are assessed on NHS England Diagnostic Order Services. Each covers part of the closed loop for particular settings; none covers all of it.

National standards are not all equal. eRS and EPS are mature, well-engineered services and are good references for their own scope (outpatient referral and triage; prescribing and dispensing) - their gaps are of scope, not design. BaRS under-specifies both data and process and is mapped onto the general pattern, not used as a model.

References

• NHS e-Referral Service (eRS) and eRS FHIR API
• Booking and Referral Standard (BaRS) and Booking and Referral FHIR API (versions 1.0.7 to 1.6.0 listed as in production, checked 2026-11-01)
• Transfer of Care
• Message Exchange for Social Care and Health (MESH) API
• National Record Locator (NRL) and Multicast Notification Service (MNS)
• PRSB standards - clinical headings for letters and discharge summaries
• NW GMSA - Genetic Referrals - analysis of the eRS FHIR resource model and BaRS
• GP Connect and GP Connect specifications (checked 2026-11-01)
• IM1 pairing integration
• Electronic Prescription Service (EPS), EPS FHIR API and Prescription Status Update API (checked 2026-11-01)
• IHE Pharmacy Medication Prescription and Delivery (MPD)

Coverage of the Closed Loop

The most common gap is the last row: the clinic letter or discharge summary that comes back to the GP does not identify the referral it answers, so the referrer's system cannot close the loop automatically. The national test ordering services do link the report to the request - see NHS England Diagnostic Order Services.

e-Referral Service (eRS)

eRS is the national service GP practices use to refer patients to consultant-led first outpatient appointments, with booking, Referral Assessment Services (RAS) for triage, and Advice and Guidance. Each referral has a Unique Booking Reference Number (UBRN).

eRS covers the input side only: clinical information and patient summaries attached to the referral (ServiceRequest.supportingInfo). The same kinds of document - a discharge report (HL7 Europe HDR) or patient summary (HL7 Europe EPS) - are also the output of a referral, which eRS does not carry. BaRS is the same - see BaRS.

The eRS FHIR API is mainly STU3 (ReferralRequest); an R4 ServiceRequest API is in development, with the UBRN in ServiceRequest.identifier (system https://fhir.nhs.uk/Id/UBRN) - see the NW GMSA eRS analysis. To confirm against the current eRS API.

Closing the loop with eRS. If the provider keeps the UBRN with the referral, its clinic letters can carry the UBRN as the referral identifier (Composition basedOn, or HL7 v2 ORC-2 / TXA), so the GP system can match the outcome to the referral it made.

Booking and Referral Standard (BaRS)

BaRS is a FHIR R4 standard for sending booking and referral information between NHS services, using FHIR Messaging ($process-message at both ends) through a national API that routes each request to the target service. Its Applications cover urgent and emergency care (NHS 111, integrated urgent care and ambulance services referring to and booking into emergency departments, urgent treatment centres and community services) and referrals into community pharmacy.

Assessment. BaRS covers most of the closed loop and has the same shape as 360X: asynchronous request and response messages between sender and receiver. The gaps are in how the messages are defined:

• payloads are loosely defined;
• workflow state is inferred from combinations of resource statuses rather than an explicit status;
• the BaRS CarePlan carries the sender's assessment;
• a patient without an NHS Number has only an untyped local identifier;
• parties are sent as full resources rather than identifier references.

The detailed review, with the evidence, is in the Booking and Referral Standard (BaRS) appendix. Where BaRS is the route, map it onto 360X and this guide's resources as described there.

Transfer of Care

Transfer of Care defines FHIR documents for information sent from hospital to the GP (and other providers): inpatient discharge, emergency care discharge, mental health discharge and outpatient letters, using the PRSB clinical headings. They are sent as ITK3 FHIR (STU3) messages over MESH.

Adoption of the Transfer of Care FHIR documents has been limited; most trusts send letters by MESH with Kettering XML (below). HL7 Europe HDR is the likely successor, see Referral Outcome Reports.

MESH and Kettering XML

MESH is the national store-and-forward service for sending messages and files between NHS organisations, addressed by mailbox. Most trusts send clinic letters and discharge summaries to GP practices through MESH in Kettering XML (the EDT / Docman format): a small XML envelope with patient demographics, document metadata and the letter as an attachment (usually PDF or RTF), which the GP workflow tool files into the GP record.

Kettering XML is a Document Messaging pattern: the letter is pushed and filed, and cannot be queried later. It is the MHD-style DocumentReference with a PDF attachment, which makes it straightforward to also publish to a Document Access Provider.

GP Connect

GP Connect is the national set of FHIR APIs and messaging specifications for GP practice systems. The GP practice is the most common Referral Initiator, and the usual recipient of outcomes even when it is not, so GP Connect appears at both ends of the loop. Capabilities as listed by NHS England (checked 2026-11-01):

Points for the closed loop:

• Pull versus push. 360X pushes the clinical information with the referral. With Access Record the Referral Recipient pulls it when it needs it, so the referral can carry less. The referral still SHALL carry the reason for referral and the referral question; the Recipient's view of the record is not a substitute.
• Send Document delivers a document (e.g. PDF) into the GP practice's document workflow over MESH - the same Document Messaging pattern as Kettering XML, but a national specification. To confirm whether its metadata can carry the Referral ID or UBRN, which is what closes the loop.
• Update Record is the nearest national example of a closed loop with a structured outcome: a patient referred to a community pharmacy (for example from NHS 111 or the GP practice) has the pharmacy consultation returned to the GP record as structured data. To confirm how the referral and the update are linked.
• Appointment Management makes the GP practice a Referral Recipient that other services can book into, i.e. the 360X Scheduling Option in the reverse direction.

GP Connect APIs are mostly FHIR STU3 and are reached through the Spine Secure Proxy; the messaging specifications use MESH - To confirm against each specification.

IM1 (Interface Mechanism 1)

IM1 is "the process that allows suppliers to integrate their system with any principal clinical system through an interface mechanism". The foundation suppliers, Optum (EMIS Web) and TPP (SystmOne), must offer interfaces that let third-party systems "read patient information", "extract information in bulk" and "enter data into the other system". Each consuming product is checked against each provider supplier's API and needs a Model Interface Licence with each one.

IM1 is how many third-party products used in primary care today (referral management, document workflow, remote monitoring and virtual ward platforms) read from and write to the GP record. Writing directly into another organisation's record is not the general pattern. The general pattern is that the producer sends a result or document (HL7 v2 ORU^R01 / MDM^T02, a CDA / FHIR Document, or a FHIR message) or makes it available through a REST API, and the consumer's own system imports and files it (360X Document Import Option). For this guide:

• IM1 interfaces are supplier-specific, not a national standard, so an IM1 integration is an implementation of a step in the loop (for example "file the Referral Outcome [PCC-57] into the GP record"), not an interface between the Referral Initiator and Referral Recipient.
• Where IM1 is used to file an outcome, the content SHOULD still be the documents and identifiers in this guide, so the same outcome can be sent by HL7 v2, FHIR Document or MESH without remapping, and IM1 can be replaced.
• IM1 read access is a supplier-specific form of the general REST query pattern (FHIR REST / IHE QEDm, MHD); GP Connect Access Record is the national equivalent.
• The virtual wards operational framework asks for "read/write functionality" across delivery partners. This guide does not follow that as written - see Virtual Wards.

Electronic Prescription Service (EPS)

EPS sends prescriptions electronically from prescribers to dispensers. NHS England describes it as "for prescribers and dispensers and is used in primary, secondary and community care"; "over 95% of all prescriptions in England" are now produced electronically, and increasing adoption in secondary care is a roadmap priority (service page, last edited 15 October 2026). EPS is workflow management, not clinical prescribing: the prescribing decision is made in the prescriber's system.

A prescription is the same order and report pattern as a referral: the prescriber places an order, a dispenser takes it, and the dispense is the report. IHE Medication Prescription and Delivery (MPD) defines it with Submit Medication Order [PHARM-5], Retrieve Medication Order [PHARM-7], Submit Medication Dispense [PHARM-8] and Retrieve Medication Dispense [PHARM-9] (1.0.0-comment-2, FHIR R5). HL7 Europe HDR depends on the R4 version of MPD (ihe.pharm.mpd.r4).

Points for this guide:

• The loop back to the prescriber. NHS England lists dispense notifications and claims as dispenser actions but does not say the dispense is returned to the prescriber; prescribers check status with the prescription tracker - To confirm. This is the same gap as letters that do not reference the referral: the order is electronic, the closing of the loop is a lookup.
• Prescriptions in referral outcomes. A Referral Outcome [PCC-57] often changes medication. The HDR discharge medications section (and the Consultation Note plan) says what the patient is on; EPS (in secondary and community care) or a request to the GP is how the change is actioned. The virtual wards framework asks for discharge medicines to be "shared with the patient's GP and community pharmacy".
• Referral to community pharmacy (for example from NHS 111 or a GP practice) is a referral, not a prescription: it uses PCC-55 (BaRS is used today on some routes) and returns the consultation to the GP through GP Connect Update Record [PCC-57]. The pharmacist may then issue or supply medicines.
• Virtual wards prescribe for patients at home. EPS in secondary and community care lets the virtual ward send prescriptions to a community pharmacy - To confirm how virtual wards prescribe today.

The EPS FHIR API (R4) and the older HL7 v3 messages carry the prescription, cancel, release, return and dispense notification - To confirm message and operation names against the specification. The Prescription Status Update API lets "dispensing suppliers" push status to patients "via the NHS App".

Other National Services