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

Booking and Referral Standard (BaRS)

A detailed review of the Booking and Referral Standard (BaRS) against IHE 360X and the general standards (HL7 v2, FHIR Workflow, FHIR Messaging). It replaces a summary judgement with evidence from the BaRS implementation guide and API specification. Each finding quotes the source; points not checked are marked To confirm.

References

• BaRS implementation guide - Guide v1.12.1, Core v1.6.0, Package v1.42.0 (checked 2026-11-02). The guide still says it "is currently under development"
• Booking and Referral FHIR API v1.0.7 - OpenAPI "Booking and Referral API" 1.0.0 (checked 2026-11-02)
• BaRS Core 1.6.0: Standard Pattern For Composites, Message Headers, Use Case Categories, Journey ID
• BaRS Applications (guide v1.12.1): 1 Bookings and Referrals into UEC, 4 Referral into UEC for Validation, 5 Referrals into Pharmacy
• FHIR Workflow - Request / Task / Event and FHIR Messaging
• HL7 Europe Hospital Discharge Report (HDR) 1.0.0 and HL7 Europe Patient Summary (EPS) 1.0.0-ballot (package hl7.fhir.eu.eps, 2026-06-06; CI build)
• PRSB standards - the requirements behind the BaRS data models
• Domain-Driven Design - Anti-Corruption Layer

Summary

What BaRS Does Well

• FHIR Messaging, both ways. "All implementers (senders or receivers) of BaRS must build a $process-message endpoint to be able to support the asynchronous workflows" (API v1.0.7). This is the same transport as this guide's FHIR route (Exchange Options).
• Service discovery and routing through a national Endpoint Catalogue and API proxy - something 360X leaves to the transport (Direct addresses in the US).
• Booking separated from referral: "A referral can be made independent of booking but, where a booking is made as part of the same workflow, they must be linked" (Application 1). This matches the 360X Scheduling Option and the Appointment Booking flow.
• Transactional integrity (retries, duplicate detection on X-Request-Id) and defined error responses (OperationOutcome).
• Clinically endorsed content for 111 to emergency department referrals - "PRSB have defined and endorsed an information model" (Application 1); see PRSB Standards.

Message Model Compared with 360X

A BaRS message is identified by MessageHeader.eventCoding (servicerequest-request, servicerequest-response, booking-request), MessageHeader.reason (new, update) and the MessageDefinition it claims. The MessageDefinitions in the API specification include bars-message-servicerequest-request-referral, -request-validation, -request-cancelled, -response-referral, -response-referral-short, -response-validation-interim, -response-validation-full, bars-message-booking-request and -booking-request-cancelled.

So BaRS does cover most of the closed loop, and is closer to 360X than this guide first said. The differences are in how it is defined, below.

1. Message Definitions Are Loose

The BaRS MessageDefinition example in the API specification (BARS Message Definition ServiceRequest - Request CaseTransfer) lists 15 entries in focus, each min 1, max 1: Bundle, MessageHeader, ServiceRequest, Patient, Encounter, Location, Organization, Practitioner, PractitionerRole, Observation, Flag, MedicationStatement, AllergyIntolerance, QuestionnaireResponse and Consent.

• In FHIR, MessageDefinition.focus identifies the resource(s) that are the subject of the event - the same as MessageHeader.focus - not every resource in the Bundle. Listing the Bundle and the MessageHeader as a focus is not meaningful, and max 1 for Observation or Flag does not fit a referral with several findings.
• BaRS says so itself: "payload conformance to MessageDefinitions is not checked as part of FHIR validation" and the check "is a manual, business logic, check and not something which is supported through standard FHIR validation of the payload" (Message Headers).
• Receivers may define their own: "The MessageDefinitions will principally be defined by BaRS, at a national level (although bespoke definitions can be used through BaRS)". A sender must "GET the message definition" for each receiver and service before sending.

In 360X each transaction is one HL7 v2 message structure with a fixed ORC-1 / ORC-5 pair. In this guide each event is a MessageDefinition with one focus (Referral Order (O19), Referral Order Status (O51)) and the contents are profiles that a validator can check.

2. ServiceRequest or Task

In Applications 1 and 4 there is no Task. The workflow state of a referral is spread over three resources: ServiceRequest.status (active, revoked, completed), the sender's and responder's Encounter.status (triaged, in-progress, finished, cancelled) and CarePlan.status. ServiceRequest.intent is fixed to plan.

In FHIR Workflow these are different things:

A 360X OMG^O19 both creates the order and asks a named recipient to act, so its FHIR equivalent is a ServiceRequest and a Task (status requested, focus the ServiceRequest). The HL7 Physical Activity IG does the same. Using Encounter.status to say whether a referral was accepted mixes the referral workflow with the recipient's own patient administration.

Application 5 does include a Task, but not in this role - see section 7.

This guide's Referral Order (O19) currently has the ServiceRequest as its focus and O51 the Task. Whether O19 should also carry the Task, so every message has the Task as its focus, is Open - see notes/research.md.

3. CarePlan Is the Assessment, Not a Plan

In Application 1 the BaRS CarePlan is the sender's triage result:

• CarePlan.status "MUST be populated with 'completed' - FIXED VALUE"; intent fixed plan;
• CarePlan.period.start is "the date/time the triage Disposition was identified";
• CarePlan.activity.outcomeCodeableConcept carries "the triage outcome codes" (NHS Pathways symptom group, symptom discriminator and disposition codes), and its text "MUST be populated with the clinical narrative" (the consultation summary);
• ServiceRequest.basedOn references the CarePlan.

This is the assessment that justifies the referral - in this guide, referral supporting information: the reason (ServiceRequest.reasonCode), the findings (Observation) and any form (Referral Forms, QuestionnaireResponse). FHIR R4 also has ClinicalImpression for an assessment. A CarePlan in Dynamic Care Planning and the Clinical Process says who is doing what, for an ongoing plan that several teams update - a different use. Receiving systems that file a BaRS CarePlan as a care plan would mislead users.

4. Patient Identification

BaRS Application 1 guidance for Patient.identifier:

• system https://fhir.nhs.uk/Id/nhs-number; value "MUST be populated with the NHS number when available. If no NHS number is available this SHOULD be populated with the Local patient identifier";
• the NHS Number is sent only with verification status "Number present and verified" or "Number present but not traced" - "else no NHS number MUST be sent";
• "The booking Receiver must accept potential patients who do not have a national validated identifier".

The guidance gives no system, identifier type or assigning organisation for the local identifier, and places it under an element whose system is the NHS Number. Without them, a receiver cannot tell whose number it is, so it cannot match the patient or send the identifier back. Urgent and emergency care is exactly where patients are often untraced.

General practice, and this guide (see Patient Administration):

Recommendation: when there is no verified NHS Number, send the sender's MRN (or other local identifier) with its type and assigning organisation, and return it in every response, as 360X requires for the patient identifier.

5. Payload Size and References

BaRS sends the parties as full resources: MessageHeader.sender and destination.receiver "MUST be populated with the full url to the Receiving Organisation resource", and that Organization "MUST" have an identifier (ODS code) and a name. Practitioner, PractitionerRole, Location and HealthcareService are also listed in the MessageDefinition, each with min 1.

Most standards identify organisations by code: HL7 v2 MSH-4 / MSH-6 (ODS code), FHIR Reference.identifier with a display, as in this guide's Referral Order message example and the NW GMSA messages. A resource adds nothing when it only repeats the ODS code and name, and every extra resource is something the receiver must validate and reconcile with its own directory (ODS). Send a resource only when it carries information the receiver cannot look up.

6. Hard to Tell What Each Message Contains

The receiver works out what it has been sent from a combination of values. The BaRS pseudo-code for $process-message (Standard Pattern For Composites) decides, for example:

• a new referral: eventCoding servicerequest-request, reason new, ServiceRequest.status active, category "Referral", CarePlan.status completed and Encounter.status triaged or finished;
• an interim validation response: servicerequest-response, reason new, ServiceRequest.status active, focus Encounter in-progress;
• a did-not-attend: servicerequest-response, category "Referral", ServiceRequest.status revoked, reason new.

revoked therefore means both "cancelled by the sender" and "the patient did not attend", told apart only by the event code. The payload also depends on the receiver's own MessageDefinitions, the use case category and the Application. This liberal approach is an anti-pattern for interoperability: every pair of systems has to agree the detail, which is the point-to-point integration that a standard is meant to remove.

360X and this guide make the event explicit: one order control code (ORC-1) and order status (ORC-5) per transaction in HL7 v2, and one Task.businessStatus from Referral Workflow Status in FHIR.

7. Application 5: Referral Mixed with the Consultation

Application 5 (Referrals into Pharmacy, v1.2.1; live use case Primary Care to Community Pharmacy - Pharmacy First) describes its payload as a narrative: "the assessment performed by the Sender (Encounter), identifying a 'problem' (Condition) which a plan of care (CarePlan) is established to address. The Sender is unable to support the plan of care so transitions responsibility, via a referral (ServiceRequest), while directing the next requested action (Task)." Against existing practice (HL7 v2 OMG^O19 / REF_I12, eRS, FHIR Workflow):

The SNOMED CT code above could not be checked on tx.fhir.org, whose UK Edition is older than the code - To confirm.

Task is misused. In FHIR Workflow a Task "fulfils" a request: Task.basedOn is "a higher-level authorization that triggered the creation of the task", such as a ServiceRequest. Application 5's Task instead carries the request itself (its code and timeframe), duplicating what ServiceRequest.code and occurrence are for, and is linked from a CarePlan rather than to the ServiceRequest.

The CarePlan is unnecessary. It only connects the Condition (why) to the Task (what); both belong on the ServiceRequest (reasonCode / reasonReference, code).

Referral, Clinical Document or Patient Summary?

Much of the confusion comes from putting the referral and the sender's consultation into one request. The Application 5 requirements ask the sender to include "medications administered or prescribed during the latest assessment and not available on existing records", "new allergies, established during the latest assessment", the patient's "Body Mass Index (BMI)", the blood pressure "service type", and current oral contraception for repeat supply. These are the record of the consultation that led to the referral, and of the patient's background - not the referral.

In existing practice the referral (ServiceRequest) stays small and points to the supporting information with ServiceRequest.supportingInfo. eRS works this way: the referral carries the clinical information and patient summaries as attachments (HL7 v3 or PDF) referenced from ServiceRequest.supportingInfo. The supporting information can be:

Suggested approach for this guide: the ServiceRequest carries the request (code, reasonCode, requester, encounter, occurrence); supportingInfo references a clinical document (HDR structure) for the episode, plus a patient summary (EPS) only where the receiver cannot query the record. Whether the clinical document or the patient summary should be the default for referrals to services without record access (such as community pharmacy) is Open.

The same two documents appear at both ends of a referral - as its input and as its output:

BaRS and eRS cover only the input side. Neither defines the outcome document, so both use clinical documents and patient summaries only as referral input, through ServiceRequest.supportingInfo (eRS attachments; BaRS resources in the message bundle). The output - the document that closes the loop - comes back by another route (Transfer of Care, MESH, GP Connect Send Document, HL7 v2 MDM^T02) and has to be linked to the referral by the receiver - see Referral Outcome [PCC-57].

Keeping the referral separate from its supporting documents is also future proof. NHS England shared care records - and the Single Patient Record - are expected to hold patient summaries and discharge reports. When they do, the referral does not change: supportingInfo references the published document (by DocumentReference or URL, see Document Sharing [MHD] and EU Health Data API) instead of carrying a copy. The receiver then retrieves the documents through an API when it needs them, so they no longer need to be in the message payload at all - the message carries only the workflow (the referral and its status). A payload that embeds the consultation in the referral bundle, as BaRS does, has to be redesigned for that.

PRSB Standards and FHIR Documents

The BaRS data models come from PRSB standards: Application 1 from the PRSB 111 referral work ("PRSB have defined and endorsed an information model"), Application 5 from "the Community Pharmacy Standard v3.0 as defined and endorsed by the Professional Records Standards Body (PRSB)". PRSB standards are headings for a document - what a clinician needs to read - so they map more naturally onto FHIR Documents than onto a BaRS message bundle:

See PRSB Standards for the full list and where each fits in the clinical process. The PRSB to HDR / EPS section mappings are To confirm.

Adopting BaRS: an Anti-Corruption Layer

A system that supports referrals generally - IHE 360X, IHE Dynamic Care Planning, IHE Dynamic Care Team Management (DCTM), HL7 v2, FHIR Workflow and FHIR Documents - should not let one national standard's model shape its core. The domain-driven design anti-corruption layer is the usual answer: a translation layer at the edge that converts between the external model (BaRS) and the system's own model, so BaRS concepts never enter the core.

flowchart LR
    subgraph EXT [External - BaRS]
        B1[BaRS $process-message<br/>ServiceRequest, Encounter,<br/>CarePlan, Task, Condition ...]
    end
    subgraph ACL [Anti-corruption layer]
        T1[Translate message<br/>to 360X event]
        T2[Map payload to<br/>general model]
        T3[Assemble BaRS<br/>responses]
    end
    subgraph CORE [Referral system - general model]
        C1[ServiceRequest + Task<br/>360X state]
        C2[FHIR Documents<br/>HDR, EPS]
        C3[Appointment, Encounter<br/>Patient Administration]
        C4[CarePlan, CareTeam<br/>DCP / DCTM]
    end
    B1 --> T1 --> C1
    B1 --> T2 --> C2
    T2 --> C3
    C1 --> T3 --> B1
    C2 --> T3

Tips for the layer:

• Keep it at the edge. Only the layer knows BaRS profiles, MessageDefinitions, use case categories and the Endpoint Catalogue. The core sees 360X events and the general resources.
• Translate both ways. Inbound BaRS messages become core events; core events (accept, decline, cancel, outcome) are turned into BaRS responses only for partners that use BaRS. Other partners get HL7 v2 or FHIR Messages from the same core events (Exchange Options).
• Keep the original. Store the received BaRS bundle unchanged for audit and re-processing; the translated resources reference it (Provenance).
• One layer per external standard. eRS, BaRS and HL7 v2 each get their own translator into the same core. This puts BaRS on the same footing as eRS, whose referral is a ServiceRequest with the clinical information and patient summary attached through supportingInfo.
• Documents by reference when they are shared. Store the clinical document and patient summary as documents in the core, so they can be published to a shared care record and referenced, rather than rebuilt from BaRS resources each time.
• Report gaps, don't absorb them. Where BaRS cannot carry something the core needs (a referral identifier, a typed patient identifier, the outcome document), the layer fills it from configuration or another route and records the gap, rather than changing the core model.

Using BaRS with This Guide

Using BaRS with This Guide

In summary, where BaRS is the route (for example NHS 111 to an emergency department):

• map each BaRS message to the 360X transaction in the table above and record the state as a Referral Task;
• carry the BaRS CarePlan, Condition, Observations, MedicationStatements and QuestionnaireResponses as referral supporting information, not as a care plan;
• take what is requested from Task.code (Application 5) into ServiceRequest.code, and the requesting practitioner and organisation into a PractitionerRole;
• keep a Referral ID and the sender's patient identifier (with type and assigning organisation) on both sides;
• send the outcome as a clinical document (HL7 Europe HDR, or a Composition with the HDR section codes for outpatient encounters) where BaRS has no equivalent;
• do all of this in an anti-corruption layer.