This page is part of the FHIR Specification (v0.5.0: DSTU 2 Ballot 2). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

2.4 Messaging using FHIR Resources

FHIR Resources can be used in a traditional messaging context, much like HL7 v2. Applications asserting conformance to this framework claim to be conformant to "FHIR messaging".

In FHIR messaging, a "request message" is sent from a source application to a destination application when an event happens. Events mostly correspond to things that happen in the real world. The request message consists of a Bundle identified by the type "message", with the first resource in the bundle being a MessageHeader resource. The MessageHeader resource has a code - the message event - that identifies the nature of the request message, and it also carries additional request metadata. The other resources in the bundle depend on the type of the request.

The events supported in FHIR, along with the resources that are included in them, are defined below.

The destination application processes the request and returns one or more response messages which are also a bundle of resources identified by the type "message", with the first resource in each bundle being a MessageHeader resource with a response section that reports the outcome of processing the message and any additional response resources required.

Example Request Message: TODO
Example Response Message: TODO

2.4.1 Basic Messaging Assumptions

This specification assumes that content will be delivered from one application to another by some delivery mechanism, and then one or more responses will be returned to the source application. The exact mechanism of transfer is irrelevant to this specification, but may include file transfer, http based transfer, MLLP (HL7 minimal lower layer protocol), MQ series messaging or anything else. The only requirement for the transfer layer is that requests are sent to a known location and responses are returned to the source of the request. This specification considers the source and destination applications as logical entities, and the mapping from logical source and destination to implementation specific addresses is outside the scope of this specification, though this specification does provide a direct delivery mechanism below.

The agreements around the content of the messages and the behavior of the two applications form the "contract" that describes the exchange. The contract will add regional and local agreements to the rules defined in this specification.

This specification ignores the existence of interface engines and message transfer agents that exist between the source and destination. Either they are transparent to the message/transaction content and irrelevant to this specification, or they are actively involved in manipulating the message content (in particular, the source and destination headers are often changed). If these middleware agents are modifying the message content, then they become responsible for honoring the contract that applies (including applicable profiles) in both directions.

A key aspect of a message is the impact of its content:

Consequence	The message represents/requests a change that should not be processed more than once. E.g. Making a booking for an appointment.
Currency	The message represents a response to query for current information. Retrospective processing is wrong and/or wasteful.
Notification	The content is not necessarily intended to be current, and it can be reprocessed, though there may be version issues created by processing old notifications.

Some Events defined by FHIR are assigned to one of these categories, but others are not able to be categorized in advance, and the category must be determined by the content, or the context.

2.4.1.1 Message Exchange Patterns

Each FHIR request message has one or more response messages. There must be at least one response message so that the sender can know that the message was properly received. Multiple response SHALL not be returned for messages of consequence, and SHOULD not be returned for notifications.

In principle, source applications are not required to wait for a response to a transaction before issuing a new transaction. However in many cases, the messages in a given stream are dependent on each other, and must be sent and processed in order. In addition, some transfer methods may require sequential delivery of messages.

For this reason, a synchronous exchange pattern - where the sender sends a message, and waits on the same channel for a single response, and then sends the next message - are the easiest to understand and manage. The mailbox described below works in this fashion.

However synchronous message exchange does not cater for multiple response messages, which may arise when processing queries, and also imposes through-put limitations which may become relevant at high volumes. Additionally, it may not be practical or appropriate to wait for response messages. In these cases, the asynchronous message pattern described below should be used.

2.4.1.2 MessageHeader.identifiers

An incoming message contains two identifiers: the Bundle.id and the MessageHeader.identifier. Each time a new message is created, it SHALL be assigned an identifier (MessageHeader.identifier) that is unique within that message stream. Note that since message streams are often merged with other streams, it is recommended that the identifier should be globally unique. This can be achieved by using a UUID or an OID. Each time a message is sent, the Bundle.id should be changed to a new value.

When a receiver receives and processes the message, it responds with a new message with a new identifier, wrapped in a bundle which also has a new id. The response message also quotes the request MessageHeader.identifier so that the source system can relate the response to its request.

2.4.1.3 Absence of Reliable Messaging

Some of the message delivery mechanisms mentioned above are reliable delivery systems - the message is always delivered, or an appropriate error is returned to the source. However most implementations use methods which do not provide reliable messaging, and either the request or the response can get lost in transit. FHIR messaging describes a simple approach that receivers SHOULD conform to in order to handle the absence of reliable messaging that maintains predictable functionality.

If the sender of the message implements reliable messaging, it SHALL do the following when it receives no response to a message within a configured timeout period:

Consequence

Resend the same message (with the same identifier) with the same Bundle.id

Currency

Resend the same message (with the same identifier) with a different Bundle.id

Notification

Resend the same message (with the same identifier) with a different Bundle.id

When a receiver implements reliable messaging, it SHALL check the incoming Bundle.id and MessageHeader.identifier against a cache of previously received messages. The correct action to take depends on what is received:

Both the Bundle.id and MessageHeader.identifier have not been received

This is the normal case, and the message should be processed

Both envelope and message already received

The original response has been lost (failed to return to the request issuer), and the original response SHALL be resent

The MessageHeader.identifier has already been received, but the Bundle.id is new

A previously seen message has been resubmitted for processing again. The server may either reprocess the message, or reject the message

The Bundle.id has already been received, but the MessageHeader.identifier is new

This is an error - Bundle.id values should never be reused

The duration period for caching does generally not need to be very long. At a minimum, it could be 1 minute longer than the timeout of the sending system, though it may need to be longer depending on the re-sending policies of the sending system.

Applications that implement reliable messaging declare their reliable cache period in their conformance statement.

2.4.1.3.1 Example: Consequence

In the first example, a Clinical EHR issues an order for a particular imaging examination to be performed on a patient. This is considered to be a message of Consequence: multiple orders should not be created (in practice there are usually human review processes that catch multiple orders, but repeat orders create entropy in the system that is harmful). The EHR sends a message where the Bundle.id is UUID 1 (72edc4e0-6708-42ab-9734-f56721882c10), with a MessageHeader.identifier of UUID 2 (dad53a57-dcb4-4f18-b066-7239eb4b5229).

The EHR system never receives a response to the message; it does not know whether the request message got lost, or the imaging management systems was unable to process the request, or whether it successfully processed the message and the response was lost. In this case, the EHR system resends the message with same two identifiers.

In this case, the imaging system successfully received the message, and processed it. Because it receives the resent order after 1 minute (which is within its 15 minute cache time), and the two UUIDs 1 and 2 match a message it has already processed, it knows that it already processed the order, and simply returns the previous response. In the case of additional resent queries, the application keeps sending the original response, though it may also alert system administrators that the same original message keeps being resent, since lost messages should be a rare occurrence.

When the EHR system finally receives the message, it knows how the imaging management system responded; it can be sure because the message id from the original request is echoed in the response portion of the returned message.

2.4.1.3.2 Example: Currency

In this second example, a Clinical EHR needs to know what appointment slots are available for a particular imaging procedure. This is a message of Currency: available slots are ever disappearing, and ordering a slot that has become unavailable is a waste of time for the humans and systems involved. The EHR sends a message where the Bundle.id is UUID 3 (4c7f5cb2-5964-4d42-b719-e0227461818c), with a MessageHeader.identifier is UUID 4 (63ed7d68-b2cc-421d-ba1c-a6c7785581f2).

In this case, the imaging system successfully received the message, and processed it. When it receives the resent order after 1 minute (which is within its 15 minute cache time), it sees that although the message id is the same, the Bundle.id has changed, and it reprocesses the message again, and sends a new response.

When the EHR system finally receives the message, it knows the current slot availability on the imaging management system responded.

Note that the existence of active intermediaries (or "middleware") creates the need for this protocol - the original sender matches the response to the request based on the MessageHeader.identifier, and so an active intermediary that choose the re-initiate a query that it previously relayed cannot change the MessageHeader.identifier. This protocol avoids the need for the MessageHeader.identifier to change, and only requires change to the Bundle.id which is never the basis for context linking outside the immediate message exchange protocol described here.

2.4.2 Conformance Statement

Applications may only assert conformance to "FHIR messaging" if they publish a conformance statement so the claim may be verified. A conformance statement lists all the message events supported (either as sender or receiver) and for each event, a profile that states which resources are bundled (sender), or are required to be bundled (receiver), and any rules about the information content of the individual resources. The conformance statement is a resource with the name "Conformance".

2.4.3 Mailbox: Synchronous Messaging

The mailbox is the standard name for a service hosted on a RESTful server that accepts messages and processes them in a synchronous fashion as transactions and returns a message response appropriate for the message received. The server is under no obligation to do anything particular with the resources except as required by the semantics of the event code in the message resource. e.g. In addition to processing the message event, a server may choose to retain all or some the resources and make them available on a RESTful interface, but is not required to do so.

When processing messages, a server may return a status code of 200 OK, or an process/error code (300+). If the server returns 200 OK, it SHALL return a bundle that is the message response. For any other response code, the message has not been processed. The server MAY return an OperationOutcome with additional information, and SHOULD do so if the response code is 400 or greater. The client SHALL interpret a 4xx response to indicate that there is no point resubmitting the unaltered message, and a 5xx response to indicate an unexpected error on the part of the server, which means that it is worth resubmitting (and doing so should not result in a duplicate message response). Repeated failures indicate either a fatal problem with the submission or a problem with the receiving application.

The following rules apply to the mailbox:

The mailbox only accepts POST transactions - any other HTTP method will result in an HTTP error
The request content type submitted is always a Bundle with type "message" containing a Message Header resource as the first resource
The response content type returned is always an HTTP error, or a Bundle with type "message" containing a Message Header resource as the first resource
If the response is an error, the body SHOULD be an Errors & Warning resource with full details
The URL never takes any parameters
The mailbox may be authenticated using standard HTTP authentication methods, including OAuth

This simple mailbox profile can be used by any HTTP end point that accepts FHIR messages, not just FHIR RESTful servers.

In order to ensure consistency of processing, the logical rules regarding processing of Bundle.id and message id described above SHALL be followed when messages are processed using the mailbox. Servers SHALL accept multiple concurrent message submissions and process them correctly.

2.4.4 Asynchronous Messaging

Asynchronous messaging may be implemented by using the RESTful interface and the Bundle End-point, by following this general pattern between "sender" and "receiver" systems, using a "MTA" (message transfer agent):

The sender constructs a bundle with type message, and a first entry which is a Message Header with a known MessageHeader.identifier ("src-id")
The sender creates this message on the MTA using its Bundle end-point
The receiver system is notified of the creation of the message. The receiver can do this by
- using the history operation to track new messages
- searching the Bundle end-point (e.g. GET [base]/Bundle?message.source.endpoint=http://acme.com/systems/pas to search for messages from the system at endpoint "http://acme.com/systems/pas")
- Subscribing to bundle updates using the Subscription resource
In the first 2 approaches, the receiver polls the MTA, and in the 3rd, the MTA pushes the event to the receiver
The receiver fetches the message, processes it as specified in the event.code, and builds one or more response messages
For each response message, the receiver constructs a bundle with type message, and a first entry which is a Message Header with the src-id in MessageHeader.response.identifier
When the receiver has finished processing the message, it marks it as processed using the tag ?? and the meta operation (POST to [base]/[type]/[id]/_meta where [id] is MTA id for the source message)
The source system can check on the status of messages and track responses using the same approaches as listed above for the receiver system. For the search mechanism, the operation would be GET [base]/Bundle?message.response-id=[src-id]

The MTA may either be hosted on the the sender, the receiver, or on a 3rd party server.

2.4.5 Relationship between Messaging and REST

As well as this messaging framework documented here, FHIR also defines a RESTful API. The messaging and RESTful frameworks are related in that both share the same set of resources on which they operate. In fact, the basic MessageHeader resource that the messaging framework is implemented is itself a resource that can treated in a RESTful approach.

The kinds of functionality that the RESTful API and the messaging framework offer are very similar; their primary difference is architectural in nature.

For instance, the messaging framework defines an event for notifying that a administration resource has been created or updated, as does the REST API. On the other hand, there are differences in the capabilities offered - while a patient merge can be implemented as a series of RESTful operations performed by the client that update all resources linked to the patient, when a message command to merge patient records is processed, the server will do all the work, and is also able to merge in areas not exposed on the RESTful API. The REST API, however, provides a set of basic operations on all resources that would need special definitions in the messaging framework - definitions that are not provided.

There is no expectation that RESTful systems will need to offer messaging support, or vice versa, though systems may find it useful to support both sets of functionality in order to satisfy a wider range of implementers.

As a resource that can be used with the RESTful framework, the MessageHeader resource has the normal resource end-point (/MessageHeader), which is used to manage a set of static message resources. This could be used to make an archive of past messages available. Creating or updating MessageHeader resources in this fashion does not represent the actual occurrence of any event, nor can it trigger any logic associated with the actual event. It is just for managing a set of message header resources.

In, addition, as described above, this specification defines the /Mailbox end-point so that RESTful servers can offer both messaging and RESTful services at once. Alternatively, messages can be transported between systems using any other method by which a stream of bytes (the message bundle) can be moved from one place to another. There is no requirement to use HTTP.

2.4.6 Event List

The message.code element carries a Coding that identifies the event that the message conveys. This table lists the message event codes defined in this specification (the system value for these is "http://hl7.org/fhir/message-events"):

Code	Category	Description	Request Resources	Response Resources	Notes
MedicationAdministration-Complete	Consequence	Change the status of a Medication Administration to show that it is complete.	MedicationAdministration	MedicationAdministration
MedicationAdministration-Nullification	Consequence	Someone wishes to record that the record of administration of a medication is in error and should be ignored.	MedicationAdministration	MedicationAdministration
MedicationAdministration-Recording	Consequence	Indicates that a medication has been recorded against the patient's record.	MedicationAdministration	MedicationAdministration
MedicationAdministration-Update	Consequence	Update a Medication Administration record.	MedicationAdministration	MedicationAdministration
admin-notify	Notification of a change to an administrative resource (either create or update). Note that there is no delete, though some administrative resources have status or period elements for this use.	Device	--
Device	--
Group	--
Location	--
--	Organization	(see Patient)
Patient	--
Practitioner	--
--	RelatedPerson
Person	--
diagnosticreport-provide	Notification	Provide a diagnostic report, or update a previously provided diagnostic report.	DiagnosticReport DiagnosticReport.patient DiagnosticReport.perfomer DiagnosticReport.results.specimen DiagnosticReport.results.result DiagnosticReport.image	--
observation-provide	Notification	Provide a simple observation or update a previously provided simple observation.	Observation Observation.subjectPatient Observation.subjectPatient.person Observation.subjectGroup Observation.subjectDevice Observation.subjectAnimal Observation.performerAgent Observation.performerAgent.person Observation.performerPatient Observation.performerPerson	--
patient-link	Notification	Notification that two patient records actually identify the same patient.	Patient,Patient	--	Follow ups: patient-unlink?
patient-unlink	Notification	Notification that previous advice that two patient records concern the same patient is now considered incorrect.	Patient,Patient	--
valueset-expand	Currency	The definition of a value set is used to create a simple collection of codes suitable for use for data entry or validation. An expanded value set will be returned, or an error message.	ValueSet	ValueSet

Code