---
type: "doc"
source: "source/exchanging-messaging.html"
---
\[%settitle Exchanging with Messaging%\] \[%file newheader%\] \[%file newnavbar%\]

## Exchanging with Messaging

| Responsible Owner: [\[%wgt fhir%\]]([%wg fhir%]) Work Group | [Standards Status](versions#std-process):[Informative](versions#std-process) |
| --- | --- |

[Messaging](messaging) involves transmitting FHIR Bundles of resources from one system to another with a [MessageHeader](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](exchanging-operation) are described [here](exchanging#message). 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](#query) and [Messaging-based notifications](#notify). As well, messaging can have two different behavior flows - [synchronous](#sync) or [asynchronous](#async). 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.

### 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](#sync) or [asynchronous](#async)

As with operations, the payload of a message that solicits data from a _data source_ **could** be a resource such as [CommunicationRequest](communicationrequest) or [Task](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](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#searchset) [Bundle](bundle) or even a [Parameters](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.

### 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](workflow-management#optionj).)

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](#sync).

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

\[%file message-sync.svg %\]

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

\[%file message-async.svg %\]

\[%file newfooter%\]