FHIR Messaging Overview

The Pan-Canadian eReferral-eConsult Messaging Interoperability Specification, enables a bi-directional exchange of information about referral requests, appointments, referral related tasks and communications between two trusted systems using FHIR messaging, and is the basis of integrations that connect systems participating in eReferral-eConsult related exchanges to one another.

In FHIR messaging, a message is sent from a source application to a destination application when an event happens. A message is a Bundle resource of type message, that conforms to specific rules.

For details, see HL7 FHIR Messaging documentation.

A popular way to transfer messages is using HTTP based $process-message FHIR operation, that includes RESTful interactions. For details, see $process-message operation definition.

CA:eReC Messaging Architectures

CA:eReC Messaging is meant to provide implementable technical specifications in support of real-world architectures for eReferral/eConsult message flows.

eReferral/eConsult data exchange architectures are of two main types:

• Point-to-point – where eReferral/eConsult messages are exchanged directly between the two main participants – eReC Source and eReC Target

• Central Intake – where eReferral/eConsult messages are first sent to a single intake point that directs the eReferral/eConsult requests from the eReC Source to one or multiple eReC Target destinations. The Central Intake dispatches the messages received from the original eReC Source using mechanisms for message Routing, Splitting and Chaining. For more information on Central Intake please see CA:eReC Central Intake.

CA:eReC Technical Actor Description

There are two types of actors that are defined in this IG to participate in CA:eReC Messaging:

• External facing – these actors are participating in data exchanges with external systems (sending or receiving) and require explicit specifications for integration points to allow for interoperability.

• Internal facing – these actors are internal to a particular system (e.g., Central Intake) and no explicit specifications for integration points are required for interoperability. However, there are internal capabilities that are required, as these have a direct impact on interoperability. Typically, the internal actors are grouped with external actors, that carry out the actual data exchange, after the internal actor finished their internal processing. Note that internal facing actors may potentially use or communicate with other external services that are not exposed or visible in the context defined in this implementation guide.

CA:eReC Messaging defines the following actors:

¹ Note: Real world systems MAY receive and send referrals using other modalities in addition to FHIR messaging (e.g. HL7 v2, fax, etc.) The eReC Dispatcher MAY have the ability to transform referrals between different modalities.

CA:eReC Actor Mappings

Real-world Systems, when they are participating in use cases, act as actors that assume distinct roles, where the same real-world system can perform one role or multiple roles. The chart below shows examples on how Use Case Actors can map to real-world Healthcare Systems (e.g. EMR/HIS), and to the Technical Actors that are performing specific transactions, that are referenced in this specification. Please refer to Participants for definitions of use case actors.

Note: The mapping below illustrates examples for basic eReferral/eConsult scenarios where messages are exchanged directly between the participants, without a Central Intake.

CA:eReC Actors and Transactions

The following diagrams illustrate the actors and transactions in scope for the CA:eReC Messaging Interoperability Specification.

CA:eReC Messaging Exchange Details

The actors and transactions details below are generally applicable to any type of eReC message exchanges, that includes both Point-to-Point and Central Intake architectures (external facing). The actors that are specific to Central Intake are not included.

CA:eReC Messaging Exchange with Central Intake

The diagram below illustrates the message exchanges applicable to CA:eReC messaging, with focus on the actors and transactions that participate in Central Intake. For more information on Central Intake, please see CA:eReC Central Intake.

CA:eReC Messaging Compliance

The table below lists the transactions for each actor directly involved in CA:eReC Messaging. To claim compliance with CA:eReC Messaging, an actor SHALL support all required transactions (labeled “R”).

¹ The transactions defined for the eReC Dispatcher Actor are internal to the Central Intake system, however they have a direct impact on interoperability. To exchange messages with external systems, the internal actor (eReC Dispatcher) is grouped with external actors (eReC Sender and eReC Receiver).

CA:eReC Actor Options

The table below lists the options that may be selected for each actor. Dependencies between options when applicable are specified in notes.

If no option is specified, the default capabilities are required for that actor. Otherwise, the capabilities for the specific option are required.

CA:eReC Actor Groupings

An actor from this profile (Column 1) SHALL implement all the required transactions and/or content modules in this profile in addition to all of the transactions required for the grouped actor (Column 2).

CA:eReC Transaction Detail

This section describes the transactions that are exchanged between the CA:eReC actors.

Note: The resources in focus illustrated are not exhaustive – in the tables below the most common focus is shown for each transaction.

For eReferral the Task.code is 'process-request' and for eConsult, it is 'process-request-consult'.

eReC Sender

The table below lists the outgoing transactions for the eReC Sender actor, along with the message details.

Trigger Event Mappings to Event Codes

The table below illustrates the most common real-life trigger events that are translating into the specific event codes within the FHIR message. This list is not exhaustive and there could be additional trigger events that are not represented here.

eReC Receiver

The table below lists the outgoing transactions for the eReC Receiver actor, along with the message details.

¹ Transaction is not applicable for eConsult.

Trigger Event Mappings to Event Codes

The table below illustrates the most common real-life trigger events that are translating into the specific event codes within the FHIR message. This list is not exhaustive and there could be additional trigger events that are not represented here.

eReC Dispatcher

¹ The transactions defined for the eReC Dispatcher Actor are internal to the Central Intake system, however they have a direct impact on interoperability. To exchange messages with external systems, the internal actor (eReC Dispatcher) is grouped with external actors (eReC Sender and eReC Receiver).

Constructing Messages

Transmission of information between two systems using FHIR messaging involves the exchange of a message payload that consists of several parts:

• A Message Bundle: A Bundle Resource ("type" : "message") is used to package together a collection of FHIR Resource instances that will be sent from one system to another. The Bundle SHALL have an entry for each of the FHIR Resources required to convey information about the business event, starting with the MessageHeader which SHALL always be first.

• A Message Header: A MessageHeader Resource with eventCoding identifying the trigger event and other message related metadata including an id, source.endpoint, destination.endpoint is used to convey the purpose of the message and to support message routing.

• The Focus of the Message: MessageHeader.focus SHALL point to the ServiceRequest, Task, Appointment or Communication Resource that is being acted upon.

• Other referenced entities and supporting information: The MessageHeader and Focus SHALL reference other resources to convey information about the Patient who is the subject of the referral request (ServiceRequest.subject), the PractitionerRole of the requester (ServiceRequest.requester, MessageHeader.author), supporting information (ServiceRequest.supportingInfo), etc.

• Identifiers & Timestamps: Bundles and MessageHeaders SHALL have appropriate Identifiers & Timestamps as defined in the FHIR messaging requirements. Each Bundle.entry element SHALL have a unique fullUrl and resource so systems that receive messages can resolve references within the bundle.

The Event (MessageHeader.event) and Focus of the Message (MessageHeader.focus) determines the content and structure of the Bundle of information (FHIR Resources) exchanged between the eReC Source and the eReC Target.

Example: ServiceRequest Message Bundle

As illustrated below, a message event that focuses on a ServiceRequest will include a Bundle of resoruces that, minimally, SHALL include:

• a MessageHeader
• the ServiceRequest referenced in MessageHeader.focus
• the Patient who is the subject of the ServiceRequest (ServiceRequest.subject)
• PractitionerRole(s) referenced in MessageHeader.author, ServiceRequest.requester, the requested ServiceRequest.performer where, each SHALL reference an Organization, Location and/or Practitioner
• references to other ServiceRequest.supportingInfo where needed (see below)

Illustration: ServiceRequest Message Bundle

Specifications:

Message Bundles corresponding to different Focus resource are specified on the following pages:

• Message Bundle: ServiceRequest
• Message Bundle: Task
• Message Bundle: Appointment
• Message Bundle: Communication

Notes:

• To enable conformance testing against the requirements of this IG, the requirements summarized above are formally specified as contraints within FHIR Profiles published in this IG. Implementers are strongly encouraged to become familiar with these formal specifications and to rely on them as the source of truth.

• Messages with multiple resources in MessageHeader.focus will have additional requirements that are not represented in the requirements above.

State Machines

The information flows defined above are used to transmit information about ServiceRequests, Appointments and related Communications between systems as well as to convey information about the status of a ServiceRequest. Within FHIR Messages, staus is conveyed using a combination of the event code in MessageHeader.event and the .status element(s) of the Task ('process-request') or ServiceRequest in MessageHeader.focus.

The person who initiated the Referral request (i.e. the Requester) is owner of the ServiceRequest and the system where a request was created, the eReC Source, SHALL be considered the source of truth for the content of the request.

Once a ServiceRequest has been created and sent to the eReC Target, the eReC Target that receives the request (and its users) SHALL be responsible for processing the request. Therefore, the eReC Target SHALL be considered the source of truth for all information about actions performed in response to the Request and the status of the request. The eReC Target SHOULD use the 'process-request' Task resource (and associated messages) to convey status information back to the eReC Source and Requester.

Requester State Machine

A ServiceRequest will pass through several states over its lifecycle. State changes within an eReC Source MAY be the result of actions taken directly by users of the eReC Source or a response to messages received from an eReC Target.

The following table outlines the expected use of FHIR messaging and message elements to convey state changes within the eReC Source to the eReC Target:

Performer State Machine

The 'process-request' Task is used to track the state of a ServiceRequest on the eReC Target. State changes MAY result from actions taken within the eReC Target or based on messages the system receives from an eReC Source.

The following table illustrates the relationship between changes in the status of the 'process-request' Task and the messages exchanged between the eReC Source and eReC Target. It is expected that systems participating in integrations will have internal states that vary from below, therefore implementers SHALL anticipate the need to discuss workflow and state transitions with integration partners at the time of implementation and to map their internal states to the status codes used to exchange information between the eReC Source and eReC Target.

Furthermore to the above, the Task.businessStatus is a reflection of the internal business state of a task within an eReC Target. The Task.businessStatus MAY vary between eReC Target systems depending on internal workflow. An example of the relationship between the Task.businessStatus, Task.status, and ServiceRequest.status is depicted in the eConsult example below. Note: The below workflow event is only an example workflow step to demonstrate the relationship between various statuses.

¹ The status selected to depict the workflow event are not meant to be prescriptive. The code selection for Task.status and Task.businessStatus are up to the discretion of the participating systems.

Referral Outcome Information

Different referral requests and pathways will have different outcomes. As with other business flows, implementers SHALL anticipate the need to discuss expected outcomes of different ServiceRequests and any information to be shared when a ServiceRequest reaches a terminal state (i.e.: completed, cancelled, failed, or rejected).

Irrespective of the performer or requester a referral or consult request is completed when BOTH the sender and receiver mark it as completed.

Below are approaches in use:

Request completed by Performer

In the typical case where a ServiceRequest is accepted by and eReC Target and then completed by its users, an update to the 'process-request' Task SHOULD be used to share information with the requester about the ServiceRequest outcome, where:

• the MessageHeader.event SHALL be 'notify-update-process-request'
• the MessageHeader.focus SHALL be a reference to Task resources, where:
  • Task.code is 'process-request'
  • Task.status is 'completed'
• Task.output MAY reference one or more resources createdbasedOn the current ServiceRequest (e.g.: a Communication containing a plan of care)

Request completed by Requester

In some cases, the requester of a referral or consult may be required to confirm that the request has been completed.

Note : The task.code is used to differentiate between the eReferral compared to an eConsult request. For eConsult, task.code is 'process-request-consult' and for eReferral the task.code is 'process-request'

In case of an eConsult the workflow will be as follows:

Referral Forms and Supporting Information

This iGuide defines baseline messaging requirements for eReferral but not the forms or clinical data that must be sent with a ServiceRequest. Therefore, implementers SHALL anticipate the need to discuss and mutually agree on the approach that will be used to support different requests and referral pathways. This includes any forms that may be used to inititate the referral and the format of any required supporting information that must be attached.

This iGuide and the FHIR profiles within it provide a few different options for attaching supporting information to a ServiceRequest, including:

• Converting the information collected within a form into human-readable text and including it in the ServiceRequest.note.text element;
• Using one of several different FHIR resources that can be referenced in ServiceRequest.supportingInfo and then included in the message payload as a Bundle.entry:
  • QuestionnaireResponse to provide structured form data as a list of questions and responses. QuestionnaireResponse.text narrative field should be used to provide unstructured data such a copy-paste or summary of the Questionnaire response, or
  • DocumentReference to provide a binary attachment that's available to retrieve from a server using a url (recommended) or as base64 encoded data included in the resource.

Where there is a requirement to exchange structured clinical information supported by other FHIR resources implementers MAY engage and collaborate with the eReferral Interoperability Working Group to profile specific FHIR resources with the expectation of contributing them to a future version of this iGuide.