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 are defined as part of by codes, or by URIs that identify events, or by reference to EventDefinition or SubscriptionTopic resources that define the FHIR specification have event directly. This element is intentionally unbound, and the system value "http://terminology.hl7.org/CodeSystem/message-events". Alternatively uri selection of appropriate event codes is delegated to implementations and implementation guides. For codes, a good set of example codes is found in the EventDefinition. V2 event codes .

Drives the behavior associated with this message.

The time of the event will be found in the focus resource. The time of the message will be found in Bundle.timestamp .

The destination application which the message is 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.

May Indicates where the message should be used for routing of response and/or to support audit. routed.

Identifies where to route the message.

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

Allows data conveyed by a message to be addressed to a particular person or department when routing to a specific application isn't sufficient. Human-readable name for the target system.

Allows May be used for routing beyond just the application level. of response and/or to support audit.

Identifies the sending system Allows data conveyed by a message to be addressed to allow the use of a trust relationship. particular person or department when routing to a specific application isn't sufficient.

Allows routing beyond just the application level.

The person or device that performed the data entry leading to source application from which this message. When there is more than one candidate, pick the most proximal to the message. Can provide other enterers in extensions. message originated.

Need to know for audit/traceback requirements and possibly for authorization. Allows replies, supports audit.

The logical author of the message - the person or device that decided the described event should happen. When there is more than one candidate, pick Identifies the most proximal routing target to the MessageHeader. Can provide other authors in extensions. send acknowledgements to.

Need Identifies where to know for audit/traceback requirements and possibly for authorization. send responses, may influence security permissions.

Usually only for the request but can The url may be used in a response. non-resolvable URI for systems that do not use standard network-based addresses.

Human-readable name for the source system.

May be used to support audit.

May include configuration or other information useful in debugging.

Supports audit and possibly interface engine behavior.

Can convey versions of multiple systems in situations where a message passes through multiple hands.

Supports audit and possibly interface engine behavior.

An e-mail, phone, website or other contact point to use to resolve issues with message communications.

Allows escalation of technical issues.

Identifies where the sending entity to send responses, may influence security permissions. Summary true Comments The id may be a non-resolvable URI for systems that do not allow the use standard network-based addresses. of a trust relationship.

Need to know for audit/traceback requirements and possibly for authorization. Allows routing beyond just the application level.

Usually only Use case is for the request but can be used in where a response. (trusted) sending system is responsible for multiple organizations, and therefore cannot differentiate based on source endpoint / authentication alone. Proposing to remove and rely on Task to convey this information.

Coded indication of the cause for the event - indicates a reason for the occurrence of the event that is a focus of this message.

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

Information about the message that this message is a response to. Only present if this message is a response.

The MessageHeader.id Bundle.identifier of the message to which this message is a response.

Allows receiver to know what message is being responded to.

Code that identifies the type of response to the message - whether it was successful or not, and whether it should be resent or not.

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

This is a generic response to the request message. Specific data for the response will be found in MessageHeader.focus.

Full details of any issues found in the message.

Allows the sender of the 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. This is allowed to be a Parameters resource.

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.

Permanent link to the MessageDefinition for this message.

Allows sender to define the expected contents of the message.