The header for a message exchange that is either requesting or responding to an action. The reference(s) that are the subject of the action as well as other information related to the action are typically transmitted in a bundle in which the MessageHeader resource instance is the first resource in the bundle.

Many implementations are not prepared to use REST and need a messaging based infrastructure.

Code that identifies the event this message represents and connects it with its definition. Events defined as part of the FHIR specification have the system value "http://hl7.org/fhir/message-events".

Drives the behavior associated with this message.

Information about The destination application which the message that this message is a response to. Only present if this message is a response. intended for.

Indicates where message is to be sent for routing purposes. Allows verification of "am I the intended recipient".

There SHOULD be at least one destination, but in some circumstances, the source system is unaware of any particular destination system.

The id of Human-readable name for the message that this message is a response to. target system.

Allows receiver May be used for routing of response and/or to know what message is being responded to. support audit.

Code that identifies Identifies the type of response to target end system in situations where the initial message - whether it was successful or not, and whether it should be resent or not. transmission is to an intermediary system.

Supports multi-hop routing.

Indicates where the message should be routed to.

Allows the sender of the acknowledge message Identifies where to know if route the request was successful or if action is needed. message.

This is The id may be a generic response to the request message. Specific data non-resolvable URI for the response will be found in MessageHeader.data. systems that do not use standard network-based addresses.

Full details of any issues found in the message. Allows data conveyed by a message to be addressed to a particular person or department when routing to a specific application isn't sufficient.

Allows routing beyond just the sender of the message to determine what the specific issues are. application level.

The source application from which this message originated. Identifies the sending system to allow the use of a trust relationship.

Allows replies, supports audit. routing beyond just the application level.

Use case is for where a (trusted) sending system is responsible for multiple organizations, and therefore cannot differentiate based on source endpoint / authentication alone.

Human-readable name for The time that the source system. message was sent.

May be used to support Allows limited detection of out-of-order and delayed transmission. Also supports audit.

May include configuration The person or device that performed the data entry leading to this message. When there is more than one candidate, pick the most proximal to the message. Can provide other information useful enterers in debugging. extensions.

Supports audit Need to know for audit/traceback requirements and possibly interface engine behavior. for authorization.

Usually only for the request, but can be used in a response.

Can convey versions The logical author of multiple systems in situations where a the message passes through multiple hands. Note This - the person or device that decided the described event should happen. When there is a business versionId, not a resource identifier (see discussion ) more than one candidate, pick the most proximal to the MessageHeader. Can provide other authors in extensions.

Supports audit Need to know for audit/traceback requirements and possibly interface engine behavior. for authorization.

Usually only for the request, but can be used in a response.

An e-mail, phone, website or other contact point to use to resolve issues with The source application from which this message communications. originated.

Allows escalation of technical issues. replies, supports audit.

Identifies Human-readable name for the routing target to send acknowledgements to. source system.

Identifies where May be used to send responses, may influence security permissions. support audit.

The destination application which the message is intended for. May include configuration or other information useful in debugging.

Supports audit and possibly interface engine behavior.

Human-readable name for the target system. Can convey versions of multiple systems in situations where a message passes through multiple hands.

May be used for routing of response and/or to support audit. Supports audit and possibly interface engine behavior.

Identifies the target end system in situations where the initial message transmission is An e-mail, phone, website or other contact point to an intermediary system. use to resolve issues with message communications.

Supports multi-hop routing. Allows escalation of technical issues.

Indicates where Identifies the message should be routed routing target to send acknowledgements to.

Identifies where to route the message. send responses, may influence security permissions.

The id may be a non-resolvable URI for systems that do not use standard network-based addresses.

The person or device organization that performed accepts overall responsibility for the contents of the data entry leading to this message. Where there The implication is more than one candidate, pick that the most proximal to message event happened under the message. Can provide other enterers in extensions. policies of the responsible party.

Need to know for audit/traceback requirements and possibly for authorization.

Usually only for the request, but can be used in a response.

The logical author Coded indication of the message cause for the event - indicates a reason for the person or device that decided occurrence of the described event should happen. Where there that is more than one candidate, pick the most proximal to the MessageHeader. Can provide other authors in extensions. a focus of this message.

Need to know for audit/traceback requirements be able to track why resources are being changed and possibly for report in the audit log/history of the resource. May affect authorization.

Usually only for Information about the request, but can be used in message that this message is a response to. Only present if this message is a response.

Allows data conveyed by a The MessageHeader.id of the message to be addressed to a particular person or department when routing to which this message is a specific application isn't sufficient. response.

Allows routing beyond just the application level. receiver to know what message is being responded to.

The person or organization Code that accepts overall responsibility for identifies the contents type of the message. The implication is that response to the message event happened under the policies of the responsible party. - whether it was successful or not, and whether it should be resent or not.

Need Allows the sender of the acknowledge message to know for audit/traceback requirements and possibly for authorization. if the request was successful or if action is needed.

Usually only This is a generic response to the request message. Specific data for the request, but can response will be used found in a response. MessageHeader.focus.

Coded indication of the cause for the event - indicates a reason for the occurrence Full details of any issues found in the event that is a focus of this message.

Need to be able to track why resources are being changed and report in Allows the audit log/history sender of the resource. May affect authorization. message to determine what the specific issues are.

This SHALL be contained in the bundle. If any of the issues are errors, the response code SHALL be an error.

The actual data of the message - a reference to the root/focus class of the event.

Every message event is about actual data, a single resource, that is identified in the definition of the event, and perhaps some or all linked resources.

The data is defined where the transaction type is defined. The transaction data is always included in the bundle that is the full message. Only the root resource is specified. The resources it references should be contained in the bundle but are not also listed here. Multiple repetitions are allowed to cater for merges and other situations with multiple focal targets.