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.

Actors and Transactions

Requester/Performer Integration

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

Informer/Recipient Integration

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

Messaging Compliance

Requester/Performer Integration: 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 transactions corresponding to the Maturity Level being claimed and lower, and
• appropriately handle error messages generated by less mature solutions that are unable to process messages sent.

Solutions MAY support a subset of transactions generally associated with solutions of higher maturity levels.

In other words:

• An actor conforming to Maturity Level 3 SHALL implement transactions from Maturity Level 3, Maturity Level 2 and Maturity Level 1
• An actor conforming to Maturity Level 2 SHALL implement transactions from Maturity Level 2 and Maturity Level 1 and MAY implement transactions from Maturity Level 3
• An actor conforming to Maturity Level 1 SHALL implement transactions from Maturity Level 1 and MAY implement transactions from Maturity Level 2 and Maturity Level 3

¹ Vendors claiming Level 3 compliance for the eReC Requester SHOULD demonstrate the actor's use with a compliant eReC Recipient (link).

² Vendors claiming Level 3 compliance for the eReC Performer SHOULD demonstrate the actor's use with a compliant eReC Informer (link).

Transaction Details

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 Requester

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

Example Trigger Events

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 Performer

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

Example Trigger Events

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 Informer

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

Example Trigger Events

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.

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: When there is an update to other resources in the notify-update-process-request , notify-update-service-request and notify-update-service-record events, the MessageHeader.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

Reducing message size

References between resources within a Message Bundle (illustrated as relationships in the diagram above) are managed using using the Reference element, specified below.

Reference

Reference.id

Reference.extension

Reference.reference

Reference.type

Reference.identifier

Reference.display

The structure supports references in either of two formats:

• a reference to a FHIR resource including within a Bundle.entry, or
• a shared business identifier for a Resource known to both systems

eReC Messaging requires that:

• when sending Send new service request [ eReCm-1 ] transaction all Resources referenced within the message SHALL be included in the message as Bundle entries and referenced from other resources using an absolute URL
• when sending messages for other transactions:
  • any Resource(s) referenced in MessageHeader.focus SHALL be included in the message as Bundle entries and referenced from other resources using an absolute URL
  • any Resource referenced within the message that does not include a previously shared business identifier SHALL be included in the message as a Bundle entry and referenced from other resources using an absolute URL
  • other Resources with a previously shared business identifier MAY be referenced using the reference.identifier element with both the system and value elements populated

Specifications:

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

• MessageBundle - ServiceRequest (CA:eReC)
• MessageBundle - Task (CA:eReC)
• MessageBundle - Appointment (CA:eReC)
• MessageBundle - Communication (CA:eReC)

Notes:

• To enable conformance testing against the requirements of this IG, the requirements summarized above are formally specified as constraints 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.

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).

A referral or consult request is completed when the Performer marks the Task as completed, although in some cases the Requester may have to mark the ServiceRequest as completed.

Below are approaches in use:

Request completed by Performer

In the typical case where a ServiceRequest is accepted by an eReC Performer 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 that are related to the action on 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.

Routing, Splitting, Chaining

The following sections address use of messaging for more advanced workflows. The diagrams in this section illustrate the use of messaging for service request routing and splitting. Systems illustrated have Level 3 capabilities.

Tracking eReferrals

Generally, when tracking eReferrals, the information is captured as of what happens to the eReferral throughout its lifetime – from the time the eReferral request is first submitted, until all the work and related work is complete. Along the way it is possible that the eReferral goes through multiple systems (e.g. Central Intake), organizations and/or providers and additional related referrals could be generated (as a result of routing, splitting and chaining activities. All this information is captured and linked back to the original eReferral request.

To track the eReferral and related information, there are specific attributes available in the ServiceRequest and Task FHIR resources, that are used specifically to identify the resources and capture the relationship between them, including but not limited to:

• ServiceRequest.identifier
• ServiceRequest.basedOn
• ServiceRequest.replaces
• ServiceRequest.requisition
• Task.basedOn
• Task.output

Please refer to L3: Advanced Workflows for a description on how each of these elements are used in the flows.

The diagrams below show how each of the attributes are used to track the information and link it back to the original eReferral.

Note: This section is not diving deeply into FHIR Resources, it rather aims to highlight specific information tailored to the topics described.

Tracking the eReferral when Routing

This section illustrates the message creation and the message interpretation on receipt, including the most important data elements that are used to track an eReferral when it is passed through the Routing mechanism.

Note:

• ServiceRequest 2 can have its own identifier, in addition to the ServiceRequest 1 identifier

Message Creation when Routing

1. An eReC Requester (Central System) SHALL create and send copies of a ServiceRequest when ServiceRequest.performer is changed, where:
   1. .replaces SHALL reference the original ServiceRequest received/copied
   2. an .id is local to each system where the resource is stored and MAY be different from the ServiceRequest.id received from the requester
   3. references in ServiceRequest.supportingInfo MAY be added to include additional information when needed SHALL be subject to the same constraints as the original ServiceRequest
   4. other elements of the parent ServiceRequest – including .requester and .identifier – SHALL be copied to the new child ServiceRequest
   5. the child ServiceRequest MAY add a new .identifier in addition to the parent .identifier
   6. the parent ServiceRequest information referenced in .replaces SHALL always be included in the message Bundle exchanged
2. After routing a referral, a Central System SHALL mirror any ServiceRequest updates received from the eReC Requester (Source System) in the child ServiceRequest and transmit to downstream recipients

Message Interpretation on Receipt when Routing

1. The eReC Recipient (Source System) can recognize that a previously sent referral has been routed by the receiver when it receives a notify-add-service-record message from the eReC Informer (Central System) where MessageHeader.focus includes a single (child) ServiceRequest with:
   1. an .identifier that already exists in the local system
   2. .replaces references an existing (parent) ServiceRequest with the same .identifier
   3. performer is different between the parent and child
2. The eReC Performer (Target System) processing a routed message MAY choose to ignore information in ServiceRequest.replaces when processing referrals as all information is in the ServiceRequest referenced in MessageHeader.focus

Tracking the eReferral when Splitting

This section illustrates the message creation and the message interpretation on receipt, including the most important data elements that are used to track an eReferral when it is passed through the Splitting mechanism.

Note:

• Status updates that are coming back from eReC performer to Recipient is the status of the original referral/ServiceRequest
• Status updates from the informer will reflect the status of the split referrals
• Implementaters may filter these based off what they are using and the workflow they are trying to achieve
• For additional information, please see Business Rules

Message Creation when Splitting

1. When splitting, an eReC System (Central Intake) SHALL create and send multiple ServiceRequest where:
   1. .replaces SHALL reference the original ServiceRequest received
   2. .requisitionSHALL be copied from an .identifier on the original ServiceRequest Note: multiple .identifiers with different systems may be present on the message, requiring a consistent rule to be defined by implementers.
   3. .id, .identifier SHALL be assigned by the system used to create the child ServiceRequest
   4. a parent ServiceRequest information referenced in .replaces SHALL always be included in the message Bundle exchanged
2. After routing a referral, a Central System SHALL mirror any ServiceRequest updates received from the eReC Requester (Source System) in the child ServiceRequest and SHOULD transmit to downstream recipients
3. After the ServiceRequest is replaced by splitting, the eReC Requester (Source System) can consider the original ServiceRequest status as closed.

Message Interpretation on Receipt when Splitting

1. An eReC Recipient (Source System) can recognize that a previously sent referral has been split by the receiver when it receives a notify-add-service-record message from the eReC Informer (Central System) where MessageHeader.focus includes multiple (child) ServiceRequests, each with:
   1. a .requisition that matches with an existing .identifier in the local system
   2. .replaces references an existing (parent) ServiceRequest

Tracking the eReferral when Chaining

This section illustrates the message creation and the message interpretation on receipt, including the most important data elements that are used to track an eReferral when it is passed through the Chaining mechanism.

The diagram below describes the generic chaining flow which includes both Point-to-Point and Central System integrations. i.e. Target Systems with Level 3 capability with the eReC Informer actor SHOULD be able to chain referrals.

Message Creation when Chaining

1. New ServiceRequests created as a result of services performed by the receiver SHALL only be shared with the requester using the chaining pattern where the downstream request is required to complete the requested service and the requester needs to know about downstream services or related events and information. In these cases:
   1. .basedOn SHALL reference the original ServiceRequest received
   2. .requester SHALL reference the person or organization that initiated the child ServiceRequest (not the initial requester)
   3. all identifiers including: .id, .identifier, .requisition should be assigned by the system used to create the child ServiceRequest
   4. a (parent) ServiceRequest is referenced in .basedOn SHALL always be included in the message Bundle exchanged
2. After sharing a ServiceRequest with downstream systems, an eReC System SHOULD also transmit ServiceRequest updates received from the eReC Requester (Source System) to downstream recipients

Message Interpretation on Receipt when Chaining

1. An eReC Recipient (Source System) can recognize that a previously sent referral has been chained by the receiver when it receives a notify-add-service-record message from an eReC Informer (Central System) where MessageHeader.focus includes a ServiceRequest with:
   1. .basedOn referencing an existing (parent) ServiceRequest with an unknown .identifier

Distinguishing between cases when receiving eReferrals

The eReC Recipient will need to recognize whether an eReferral has been Routed on to a new receiver, Split into multiple referrals or Chained to take appropriate action when processing a notification of a new service request received from eReC Informer. The following table summarizes the use of elements that can be used to distinguish between cases.