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

Exchange Options

360X sends every transaction as an IHE XDM package (ZIP over secure email) or, optionally, by XDR or MHD. NHS systems mostly do not have that infrastructure, so this guide defines the content of each interaction once and lets it travel by any of the options below. The content is always a small workflow message (order or status) and, for PCC-55, PCC-57 and PCC-59, a clinical document.

References

• IHE PCC 360X PCC TF-1 X.2.2 (transport options), X.3 (actor groupings)
• NW GMSA - Message Exchange, Document Exchange (MHD), API Security
• FHIR Messaging, FHIR Workflow Management
• MESH API
• EU Health Data API, IHE MHD

Options

All options SHALL carry the Referral ID and the patient identifier unchanged in every message, and SHALL acknowledge receipt (HL7 v2 ACK, MESH acknowledgement or FHIR response) separately from the business response (accept / decline).

HL7 v2

The 360X HL7 v2.5.1 messages, sent over MLLP (or HL7 over HTTP) through the Trust Integration Engine, using the NW GMSA HL7 v2 conventions for MSH, PID and PV1.

FHIR Message equivalents: Referral Order (O19) and Referral Order Status (O51); examples on PCC-55, PCC-57 and PCC-59.

Alternative: HL7 v2 REF_I12 (patient referral) and RRI_I12 (response) are the v2 referral messages some UK systems support - see Patient Referral [I12], with examples and FHIR Message equivalents; the NW GMSA Genetic Referrals page maps them. 360X uses the order messages instead, which match LTW and SWF.b.

Documents: the clinical document goes in the same message as an OBX of type ED (base64 PDF or FHIR Document) or RP (pointer), or as a separate MDM^T02 with the Referral ID - see Referral Outcome Reports.

MESH

MESH is store-and-forward between mailboxes. It replaces 360X's ZIP over email:

sequenceDiagram
    participant RI as Referral Initiator
    participant M as MESH
    participant RR as Referral Recipient
    RI ->> M: Send message (to recipient mailbox, workflow ID)
    RR ->> M: Check inbox, download
    RR ->> M: Acknowledge
    RR -->> RR: Process (accept / decline)
    RR ->> M: Send status update (to initiator mailbox)
    RI ->> M: Check inbox, download, acknowledge

The payload is an HL7 v2 message, a FHIR Message or a FHIR Document. MESH workflow IDs identify the kind of message - To confirm which workflow IDs exist for referrals and which would be needed. Kettering XML, used for most letters to GP practices today, carries the document only, without the referral status.

FHIR Messaging

Each interaction is a FHIR Message (Bundle type message), sent with $process-message or over MESH, following FHIR Messaging. BaRS also uses FHIR Messaging, but this guide's message contents and events follow 360X, not BaRS - see the BaRS assessment.

Message definitions: Referral Order (O19) (focus ServiceRequest) and Referral Order Status (O51) (focus Task) - the same FHIR Messages whether the HL7 v2 source is OMG^O19 / OSU^O51 or REF_I12 / RRI_I12.

MessageHeader.eventCoding is the HL7 v2 trigger event (v2-0003 O19, O51), as in the NW GMSA messages. Whether finer 360X events (accept, decline, interim, outcome) need their own codes, rather than the Task status, is Open; BaRS events would be mapped to these.

FHIR RESTful Task

Where both actors can reach the same FHIR server (a shared care record, a care coordination platform or a national API), the referral is a conversation on shared resources rather than messages - one of the FHIR Workflow Management Communication Patterns using Task.

sequenceDiagram
    participant RI as Referral Initiator
    participant S as FHIR Server
    participant RR as Referral Recipient
    RI ->> S: POST ServiceRequest, POST Task (status requested)
    S -->> RR: Notification (Subscription / MNS)
    RR ->> S: GET Task?owner=... &status=requested
    RR ->> S: PUT Task (accepted)
    S -->> RI: Notification
    RR ->> S: POST Appointment, PUT Task (businessStatus appointment-booked)
    RR ->> S: POST document, PUT Task (completed, output = document)
    S -->> RI: Notification
    RI ->> S: GET Task/{id}, GET document

The HL7 Physical Activity IG uses this pattern, including "light" recipients without their own FHIR server whose Tasks are held on the initiator's server.

Updates follow the DCP read-change-write rule with versioning (If-Match), see Dynamic Care Planning.

Document Sharing

See Document Sharing [MHD] and Query Existing Data [PCC-44]. Sharing data through an API is highly recommended - see EU Health Data API. Reports (and referral letters) are published to a Document Access Provider so other carers can find them, as described in Referral Outcome Reports. 360X's MHD Option groups the actors with MHD Document Source and Recipient; here they are the Health Data API Document Publisher and Document Access Provider. Publishing does not replace notifying the Referral Initiator.

XDM and XDR

360X's required XDM grouping (Portable Media Creator / Importer with ZIP over Email) and its XDR Option need XD* infrastructure that most NHS organisations do not have. They are optional in this guide. Where they are used, follow 360X as specified, with the content defined on the transaction pages.