DFT - The specification is currently in development and subject to change. For a full list of available versions, see the Directory of published versions

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 and reason 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.

• 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 and ServiceRequest.requester where each SHALL reference an Organization, Location, and/or Practitioner
• Either a PractitionerRole or HealthcareService resource referenced in ServiceRequest.performer
• references to other ServiceRequest.supportingInfo where needed (see below)

Illustration: ServiceRequest Message Bundle

Message Bundle 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)

Resource Profiles

• The requirements summarized above are formally specified as constraints within Resource 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.

Simplifying references to ServiceRequest from Target Systems in eReC Messages

A Point of Care system that participates in eReferral-eConsult workflows only in the role of Target System or Recipient System may lack the ability to store all information received in a ServiceRequest in a structured format. To support transmission of status updates, appointments and communications from these systems, implementers MAY choose to:

• store information received in a human readable form along with the official ServiceRequest.identifier (use = official, system and value) received from the Source System, and
• use the ServiceRequest.identifier received to generate conformant MessageBundle - Task (CA:eReC), MessageBundle - Appointment (CA:eReC) and MessageBundle - Communication (CA:eReC) without including the ServiceRequest and other resources referenced in the FHIR payload.

To support this, the eReC Messaging requires that:

• the eReC Requester and eReC Informer actors SHALL always send all Resources referenced within the message as Bundle entries when sending any of the following transactions:

  • Send new service request [eReCm-1]
  • Notify update service request [eReCm-3]
  • Revoke service request [eReCm-5]
  • Notify new service record [eReCm-2]
  • Notify update service record [eReCm-11]

• an eReC Performer sending messages:

  • SHALL always include the Resource referenced in MessageHeader.focus in the message as a Bundle.entry so it can be created or updated in the eReC Requester system
  • MAY reference a ServiceRequest using only a reference.identifier as long as the use, system and value elements are appropriately populated with the official ServiceRequest.identifier received
  • SHALL include every other Resource referenced in the message as a Bundle.entry

Use of HealthcareService vs PractitionerRole in eReC Messages

As described in the Use Cases, a first step in the referral workflows is for a Requester HCP to search for and select an appropriate service and/or service provider to send the referral to from a Care Service Directory. This will result in either:

• the selection of either be a service that is available at location (a HealthcareService), or
• the selection a specific clinician or group of clinicians working at an organization (a PractitionerRole).

When transmitting the referral using eReC Messaging, the eReC Requester SHALL include the HealthcareService or PractionerRole in the FHIR payload as a ServiceRequest.performer. Refer to MessageBundle - ServiceRequest (CA:eReC) for additional rules.

After receiving a message, an eReC Performer on the Target System (or Central System) will create a Task (process-request) to track the status of the eReferral. Refer to MessageBundle - Task (CA:eReC) for additional rules.