preBallot - The specification is currently in ballot review 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 anentryfor 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.endpointandreasonis 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, ServiceRequest.requester, the requestedServiceRequest.performerwhere, each SHALL reference an Organization, Location and/or Practitioner - references to other
ServiceRequest.supportingInfowhere 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)
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.
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,systemandvalue) received from the Source System, and - use the
ServiceRequest.identifierreceived to generate conformant MessageBundle - Task (CA:eReC), MessageBundle - Appointment (CA:eReC) and MessageBundle - Communication (CA:eReC) without including theServiceRequestand 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
Bundleentries 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.focusin the message as aBundle.entryso it can be created or updated in the eReC Requester system - SHALL also include all other Resources not received from the eReC Requester in the message as
Bundle.entry - MAY reference a
ServiceRequestand other resources received from the eReC Requester using areference.identifierif theuse,systemandvalueelements are appropriately populated with the officialServiceRequest.identifierreceived
- SHALL always include the Resource referenced in
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.
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. This Task will either be assigned to a:
- A health care provider (HCP) in a
PractitionerRole. In these cases, the eReC Performer on the Target System SHOULD send event based messages in response to actions taken with:- the assigned
PractitionerRoleinTask.owner - the
PractitionerRoleresponsible for the action that generated the message inMessageHeader.author
- the assigned
- A central intake service or similar entity performing a clerical function supporting a single entry model. In these cases, the eReC Performer on a Central System MAY send event based messages in response to actions taken with:
- the
HealthcareServiceperforming the clerical functionTask.owner MessageHeader.authorunpopulated.
- the