HL7 v2 Events and Ad Hoc FHIR RESTful Events

The mappings to FHIR are indicative and would follow FHIR Workflow Ad Hoc Communication - Option A: Simple RESTful POST or PUT

See also NHS England Interoperability Handbook - Message Broker

In HL7 v2, the message broker is normally called a Trust Integration Engine (TIE)

NHS England specifications for HL7 v2 ADT

• NHS England HL7 V2 ADT Message Specifications

NHS England specifications for HL7 FHIR RESTful Ad Hoc

• Electronic Referral System (eRS)

Admission, Discharge and Transder (ADT)

Other

HL7 FHIR Message and Documents, HL7 v3 and CDA

NHS England standards for FHIR Message API's are:

Events

• National Event Management System (FHIR Message STU3)
• Transfer of Care FHIR Message and Document STU3
• Digital Medicine FHIR Message and Document STU3 depreceated

Request

• Bookings and Referrals (BARS) (FHIR Message R4)
• Electronic Prescription Service (EPS) (HL7 FHIR Message R4)

Will normally follow FHIR Workflow Ad Hoc Communication - Option A: Simple RESTful POST or PUT using either MESH or an operation ($process-message)

See also NHS England Interoperability Handbook - Message Broker

Will often focus on either the request part of a workflow or the result outcome - the event. Events are not tied to the Request and will often be generated at key trigger points such as patient admitted or discharged.

Store and Notify

See also NHS England Interoperability Handbook - Store and Notify

Store and Notify is principally a modernistion of the

In both cases an event notification is sent to the consumer, who can retrieve the data if required.

This also applies to HL7 v2 Events and Ad Hoc FHIR RESTful Events with the clinical data being shared using Query API and/or Shared Clinical Documents

Workflow Events

Although some workflow interactions are structured/digital particularly the initial request (referral, test request, etc). The subsequent events and sub tasks are predominantly SMS and Email based with the recipient manually updating their computer systems.

Workflow Events replace the email/SMS interaction with simple structured interactions which is centred around the practitioner/patient requirements to communicate around workflow.

This is roughly the same as Resource, Message and Document notifications discussed previously. The terminology has changed to reflect patient and practitioner focus:

• Resource / Document Source has become Placer, who is the person making the request.
• Resource / Document Consumer has become filler, who is the person fulfilling the request.

In FHIR Workflow these notifications use the FHIR Task resource. Email/SMS are/can still present and they will supplement the structured Placer and Filler interactions.

TODO Add in more details on FHIR Task

FHIR Task and Coding State Changes

Both the SNOMED CT coding and FHIR Task involve the communication of state changes between providers. The FHIR Workflow diagram illustrates a high-level view of the state changes.

From a technical perspective FHIR Task is being used here as a both a Request and an Event

FHIR Workflow

Ad Hoc Workflow Patterns

The simplest form of FHIR Workflow involves the POST of a Request, Events relating to the request are posted back.

For Lab Results or Referrals this would be a POST /ServiceRequest for the request and POST /DiagnosticReport for the response.

For more details see FHIR Ad-Hoc Workflow Communication Patterns

Supporting information for the ServiceRequest or Observations relating to the DiagnosticReport would be shared via a Query API framework.

Standards in this guide to be used with this pattern are:

• HL7 v2 Events and Ad Hoc FHIR RESTful Events
• Command 'pagelink' could not render: Page not found.

Workflow Management Patterns

Ad Hoc workflow Patterns lack support for clinical coordination and communication (see also Workflow Events. Workflow Management Patterns do and this includes direct activities relating to a referral such as rejection or referral acceptance, sub tasks such as booking an appointment relating to a referral.

For more details see FHIR Workflow Mangement Patterns

The following is an extract of the complete set of options.

Task Exchanges between Placer and Filler

• Option F: Creation of Task on placer's system
• Option G: POST of Task to fulfiller's system

FOR Care Coordination elaboration (No broker)

Task Exchanges via a Workflow Broker

• Option H: POST of Task to a workflow broker

NHS England Systems which follow this pattern are:

• Electronic Prescription Service (EPS) (HL7 FHIR Message R4)
• Electronic Referral System (eRS)

Notifications Events

Standards for notification events can include:

• Multicast Notification Service API Publish and receive patient-related state changes from a single centralised system.
• FHIR Cast FHIRcast synchronizes healthcare applications in real time to ensure the user acts on the same clinical information across these applications.
• FHIR Subscription Topic-Based Subscriptions Framework (Note this is a FHIR R5 description which is more mature than FHIR R4, options exist to apply this concept to earlier versions.)

Event Data Mapping

For backwards compatibility it is recommended that the HL7 v2 Event Trigger types v2.0003 is supported for type.