Patient Care Coordination (PCC) Implementation Guide - Local Development build (v0.1.1-current) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Patient Referral and Consultation Note [360X]

References

• IHE 360 Exchange Closed Loop Referral(360X)
• AU eRequesting Implementation Guide
• HL7 Europe Hospital Discharge Report

Actors and Transactions

Actor	Definition
Referral Initiator	The provider asking for a referral or advice/guidance
Referral Recipient	The provider or specialist receiving and managing the referral.
Care Directory Serivce	Details on services provided by providers, i.e. eRS Healthcare Service, UEC Directory of Services, NHS Service Finder

Transaction & Archetype Maps

The different options include the use of the following archetypes. The differing formats are generally compatible with each other.

Message (IHE 360X CDA/FHIR Document)	HL7 v2	HL7 FHIR Message	HL7 FHIR Resource
Referral Request [PCC-55]	REF_I12 Patient referral	Patient Referral I12	ServiceRequest
Consultation Note [PCC-59]	ADT_A04 Register a patient	Consultation Note A04	Encounter
Discharge Report [PCC-57]	ADT_A03 Discharge/end visit	Discharge A03	Encounter
Referral Decline [PCC-56]	REF_I15 Request patient referral status		Task

Process Flow

eReferral and eDischarge Process

1. Referral Initiator
   • Start Event – The process begins.
   • Complete Referral Form – The initiator fills out a referral form, possibly attaching a Referral Letter document.
   • Submit Referral Request [PCC-55]– The referral is sent electronically.
2. Referral Recipient
   • Receive Referral – The recipient receives and acknowledges the referral.
   • Triage Referral – The referral is reviewed for appropriateness.
   • ​Decision: Accept or Reject Tasking Conversation
     • If rejected, a Reject message is sent back to the initiator and the process ends for the recipient.
     • If accepted, the process continues.
3. Care Delivery
   • Perform Procedure, Care and Advice – The referred care is delivered.
   • A Consultation Note is generated.
   • Send Consultation Note [PCC-59] – The note is sent back to the referral initiator.
   • Decision: Discharge?
     • If no, the cycle continues with further care and documentation.
     • If yes:
       • Prepare Discharge Report – A report is created.
       • Send Discharge Report [PCC-57] – The report is sent to the initiator.
       • Process Discharge Report – The initiator processes the discharge information.
4. End Event
   • The process concludes when the discharge report is processed.

Options

Traditional Messaging Option

eReferral and eDischarge Sequence Diagram

With this option the requests are sent between the referral initiator and recipients.

Pros and Cons

• Follows International standards.
  • The FHIR Messages mentioned above are not part of an international standard.
• Makes use of Messaging Patterns and so in secondary care has considerable middleware via Trust Integration Engines (TIE).
• The HL7 v2 ADT interactions are common in secondary but not so in other care settings.
  • ADT is often used for event notifications with no clinical content. The clinical content is often shared via clinical documents (see next option)
• Is an entry point standard which replaces email + pdf
• The referral acceptance/rejection (REF_I15) is often not implemented.
• The referral request, consultation note and discharge report are not shared with other care providers.
• Would likely make use of old pipe+hat and XML formats which can cause implementation difficulties.
• Data semantics around workflow are at present weak (all message formats), in particular this includes:
  • use of business identifiers
  • use of clinical coding
• This is not supported in UK HL7 standards (including UKCore).

Notes

1. The Referral Request is similar to:
   1. NHS England Booking and Referral Standard FHIR Message
2. Consultation Note and Discharge Report are similar to:
   1. NHS England GP Connect and IM1 Send Document, Update Record, and IM1 Write back operations.
   2. NHS England Transfer of Care FHIR Document
   3. NHS England Digital Medicines FHIR Document

Event Notifications and Enterprise Shared Data/Document Repositories Option

Both the referral initiator and recipient share the referral letter, consultation note and discharge report using API's. Instead of transferring data they communicate via event notifications.

Message Exchange Flow

1. Referral Request (PCC-55)
   • The Referral Initiator sends a referral document (PCC-55) to the Enterprise Document/Data Sharing system.
2. REF_I12 Command Message
   • A control message (based on HL7 v2 or FHIR message standards) is sent to notify the system about the new document or data.
3. Retrieve Referral Request (PCC-55)
   • The Referral Recipient then pulls or retrieves the actual Referral Request (PCC-55) from the Enterprise Document/Data Sharing system.

Pros and Cons

• The command/document message is reused from the traditional messaging approach but without the clinical detail which simplifies the conversations.
• Data or Document Sharing Options
  • When sharing via documents, a central EDMS system such as IHE XDS or EDMS with standard API's such as IHE MHD (note: IHE XDS can be used with MHD).
    • The format of the documents may be PDF, CDA or FHIR Document
  • When sharing data, the referral initiator and recipient should share the content via standard API's such as IHE QEDm/FHIR REST Query API.
• The method of sharing the data/document will vary, modern EPR suppliers are likely to favour IHE QEDm/FHIR REST. Many NHS Trusts are now sharing documents internally using EDMS, these are most often PDF documents.
• The referral acceptance/rejection (REF_I15) is often not implemented.

Notes

1. This is similar to the approach used in NHS England e-Referral Service - FHIR API

Shared Repositories and FHIR Workflow Option

Pros and Cons

• This gives EHR/EPR full control of the data they create and so reduces data duplication. Access controls can be applied locally.
  • This level is sharing using FHIR REST Query API is already supported by several EPRs.
• The workflow interactions follow conversation patterns which allow for more natural business communication.
• FHIR Worfklow interactions can be replaced HL7 v2 messages; it is anticipated a mixed economy will be required.
• EHR/EPR without sharing capabilites can make use of an Enterprise Clinical Data Repository or off-the-shelf Clinical Data Repositories (FHIR-based or openEHR with FHIR REST API)
• The uptake of FHIR Workflow by existing vendors is likely to be low as they will often have equivalent alternatives.
• A modern alternative to a traditional message, which supports modern transport and payload standards.
• This is considerably different to common technical patterns which may not be understood by a non-technical audience, which imply a level of technical debt around the delivery of this.
• The FHIR Task and Encounter can be delivered via FHIR Subscription which is likely to be the preferred method (not FHIR RESTful in enterprise interactions due to scaling issues).