This page is part of the FHIR Specification (v5.0.0: R5 - STU). This is the current published version in it's permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

3.1.6 Exchanging with Messaging

FHIR Infrastructure Work Group

Maturity Level: N/A

Standards Status: Informative

Messaging involves transmitting FHIR Bundles of resources from one system to another with a MessageHeader instance that defines the action (if any) the receiving system is expected to take. The characteristics that determine that messaging is a more appropriate choice than a FHIR operation are described here. Like operations, they are used only when other mechanisms cannot meet the use-case because messaging support tends to require more negotiation and custom development to support a use-case than more re-useable REST capabilities. Messaging is most found when back-end infrastructure is already organized in a messaging architecture or when routing is required to connect the data consumer and the data source.

There are two different mechanisms to exchange information using messaging - Messaging-based query and Messaging-based notifications. As well, messaging can have two different behavior flows - synchronous or asynchronous. Unlike operations, the data consumer cannot influence which behavior occurs (unless the data source uses different messaging events for different behavior). When a message is received, the data source determines whether it will respond synchronously or asynchronously.

3.1.6.1 Message-based Queries

In this scenario, a message is used to describe the information that is desired and is transmitted from data consumer to data source. The data source then (hopefully) assembles the desired information and sends a response message containing that information. These exchanges can either be synchronous or asynchronous

As with operations, the payload of a message that solicits data from a data source could be a resource such as CommunicationRequest or Task. It could also be any arbitrary resource or set of resources if the intended behavior were to 'match' characteristics of the specified resource(s). It can also be an instance of Parameters allowing passing arbitrary data elements. (If sending multiple resources, they will all need to be linked either through a direct reference from MessageHeader.focus or through relationships between each other.) With messaging, it is also possible to not have a payload at all, but instead to have the desired data implicitly defined in the MessageHeader event code. The response message containing the requested data could be a collection of resources (and resources with a relationship path to those resources), but could also be a bundled search-set Bundle or even a Parameters instance containing a single data element or an arbitrary operation-specific collection of data elements.

Also, like operations, message pairs to gather data can be very narrow in scope, tuned to ask a very specific question, or they can be very broad allowing a wide variety of parameters or even strings expressing queries in some formal language to be executed. Narrow definitions mean that each new type of data will require a new set of messages - and custom code written for all applications that support it. Broad definitions mean that the bar is relatively high to declare support for the message type - as there is no good way in FHIR to declare 'partial' support for a message.

3.1.6.2 Message-based Notifications

In this pattern, the data source packages up a set of information related to an event (e.g. a patient admission, an order creation, etc.) and pushes it to the data consumer. The consumer then acknowledges receipt and stores or processes the data as it sees fit. Some notifications might be logged and then ignored. Others might involve storing and or forwarding some of the information and discarding the rest. It is up to the recipient to determine what information it deems relevant. Typically there is no response message beyond a simple acknowledgement of receipt. (Note that messages can also be used to drive behavior rather than merely delivering information, but that is outside the scope of this section - further information on using messaging to drive workflow can be found here.)

The set of information conveyed is up to the design of the message. There could be a single focal resource or many, along with other related resources that may be relevant to the receiver. Quite often the same notification payload may be sent to a variety of systems, each of which may extract different sets of inforamtion. As with queries, notifications can be generic or specific. However, because the conformance expectations on receipt of a notification are light ("acknowledge receipt and do with the information as you will"), conformance implications for generic events are typically lower than for queries.

Because the response to notification messages is generally just an acknowledgement of receipt, notification mesage exchanges are typically synchronous.

3.1.6.3 Synchronous messaging

Synchronous messages are evaluated in 'real time', with the body of the initial 'acknowledgement' response containing the result of performing the message event. If the message is transmitted using HTTP, the response message will be in the body of the HTTP response. Typically, this means a response time on the order of milliseconds or seconds, though the specific response time expectations will be driven by the messaging technology and partner agreement. It is possible that routing can occur for synchronous messaging, but there would be limits to the number of hops achievable while still falling within timing constraints.

3.1.6.4 Asynchronous messaging

With asynchronous, the data consumer transmits the request message to the data source, which optionally acknowledges it. At some later point, the data source transmits a message to the data consumer containing the requested data. The response is linked to the request using MessageHeader.response.identifier. The data source could also support a 'status check' message event that allows a synchronous response indicating progress/timeline to response.