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.

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.

Messaging to retrieve data 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.

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.

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.