Release 5

This page is part of the FHIR Specification (v5.0.0: R5 - STU). This is the current published version. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

Infrastructure And Messaging icon Work GroupMaturity Level: 4 Trial UseSecurity Category: Not Classified Compartments: Device, Practitioner

Detailed Descriptions for the elements in the MessageHeader resource.

MessageHeader
Element IdMessageHeader
Definition

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.

Short DisplayA resource that describes a message that is exchanged between systems
Cardinality0..*
TypeDomainResource
Requirements

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

Summaryfalse
MessageHeader.event[x]
Element IdMessageHeader.event[x]
Definition

Code that identifies the event this message represents and connects it with its definition. Events defined as part of the FHIR specification are defined by the implementation. Alternatively a canonical uri to the EventDefinition.

Short DisplayEvent code or link to EventDefinition
Cardinality1..1
Terminology BindingMessageEvent:
TypeCoding|canonical(EventDefinition)
[x] NoteSee Choice of Datatypes for further information about how to use [x]
Requirements

Drives the behavior associated with this message.

Summarytrue
Comments

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

MessageHeader.destination
Element IdMessageHeader.destination
Definition

The destination application which the message is intended for.

Short DisplayMessage destination application(s)
Cardinality0..*
Requirements

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

Summarytrue
Comments

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

MessageHeader.destination.endpoint[x]
Element IdMessageHeader.destination.endpoint[x]
Definition

Indicates where the message should be routed.

Short DisplayActual destination address or Endpoint resource
Cardinality0..1
Typeurl|Reference(Endpoint)
[x] NoteSee Choice of Datatypes for further information about how to use [x]
Requirements

Identifies where to route the message.

Summarytrue
Comments

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

MessageHeader.destination.name
Element IdMessageHeader.destination.name
Definition

Human-readable name for the target system.

Short DisplayName of system
Cardinality0..1
Typestring
Requirements

May be used for routing of response and/or to support audit.

Summarytrue
MessageHeader.destination.target
Element IdMessageHeader.destination.target
Definition

Identifies the target end system in situations where the initial message transmission is to an intermediary system.

Short DisplayParticular delivery destination within the destination
Cardinality0..1
TypeReference(Device)
Requirements

Supports multi-hop routing.

Summarytrue
MessageHeader.destination.receiver
Element IdMessageHeader.destination.receiver
Definition

Allows data conveyed by a message to be addressed to a particular person or department when routing to a specific application isn't sufficient.

Short DisplayIntended "real-world" recipient for the data
Cardinality0..1
TypeReference(Practitioner | PractitionerRole | Organization)
Requirements

Allows routing beyond just the application level.

Summarytrue
MessageHeader.sender
Element IdMessageHeader.sender
Definition

Identifies the sending system to allow the use of a trust relationship.

Short DisplayReal world sender of the message
Cardinality0..1
TypeReference(Practitioner | PractitionerRole | Device | Organization)
Requirements

Allows routing beyond just the application level.

Summarytrue
Comments

Use case is for where a (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.

MessageHeader.author
Element IdMessageHeader.author
Definition

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

Short DisplayThe source of the decision
Cardinality0..1
TypeReference(Practitioner | PractitionerRole | Device | Organization)
Requirements

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

Summarytrue
Comments

Usually only for the request but can be used in a response.Proposing to remove and rely on Task to convey this information.

MessageHeader.source
Element IdMessageHeader.source
Definition

The source application from which this message originated.

Short DisplayMessage source application
Cardinality1..1
Requirements

Allows replies, supports audit.

Summarytrue
MessageHeader.source.endpoint[x]
Element IdMessageHeader.source.endpoint[x]
Definition

Identifies the routing target to send acknowledgements to.

Short DisplayActual source address or Endpoint resource
Cardinality0..1
Typeurl|Reference(Endpoint)
[x] NoteSee Choice of Datatypes for further information about how to use [x]
Requirements

Identifies where to send responses, may influence security permissions.

Summarytrue
Comments

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

MessageHeader.source.name
Element IdMessageHeader.source.name
Definition

Human-readable name for the source system.

Short DisplayName of system
Cardinality0..1
Typestring
Requirements

May be used to support audit.

Summarytrue
MessageHeader.source.software
Element IdMessageHeader.source.software
Definition

May include configuration or other information useful in debugging.

Short DisplayName of software running the system
Cardinality0..1
Typestring
Requirements

Supports audit and possibly interface engine behavior.

Summarytrue
MessageHeader.source.version
Element IdMessageHeader.source.version
Definition

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

Short DisplayVersion of software running
NoteThis is a business versionId, not a resource version id (see discussion)
Cardinality0..1
Typestring
Requirements

Supports audit and possibly interface engine behavior.

Summarytrue
MessageHeader.source.contact
Element IdMessageHeader.source.contact
Definition

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

Short DisplayHuman contact for problems
Cardinality0..1
TypeContactPoint
Requirements

Allows escalation of technical issues.

Summarytrue
MessageHeader.responsible
Element IdMessageHeader.responsible
Definition

The person or organization that accepts overall responsibility for the contents of the message. The implication is that the message event happened under the policies of the responsible party.

Short DisplayFinal responsibility for event
Cardinality0..1
TypeReference(Practitioner | PractitionerRole | Organization)
Requirements

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

Summarytrue
Comments

Usually only for the request but can be used in a response.Proposing to remove and rely on Task to convey this information.

MessageHeader.reason
Element IdMessageHeader.reason
Definition

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

Short DisplayCause of event
Cardinality0..1
Terminology BindingExample Message Reason Codes (Example)
TypeCodeableConcept
Requirements

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

Summarytrue
MessageHeader.response
Element IdMessageHeader.response
Definition

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

Short DisplayIf this is a reply to prior message
Cardinality0..1
Summarytrue
MessageHeader.response.identifier
Element IdMessageHeader.response.identifier
Definition

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

Short DisplayBundle.identifier of original message
NoteThis is a business identifier, not a resource identifier (see discussion)
Cardinality1..1
TypeIdentifier
Requirements

Allows receiver to know what message is being responded to.

Summarytrue
MessageHeader.response.code
Element IdMessageHeader.response.code
Definition

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

Short Displayok | transient-error | fatal-error
Cardinality1..1
Terminology BindingResponse Type (Required)
Typecode
Requirements

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

Summarytrue
Comments

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

MessageHeader.response.details
Element IdMessageHeader.response.details
Definition

Full details of any issues found in the message.

Short DisplaySpecific list of hints/warnings/errors
Cardinality0..1
TypeReference(OperationOutcome)
Requirements

Allows the sender of the message to determine what the specific issues are.

Summarytrue
Comments

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

MessageHeader.focus
Element IdMessageHeader.focus
Definition

The actual data of the message - a reference to the root/focus class of the event. This is allowed to be a Parameters resource.

Short DisplayThe actual content of the message
Cardinality0..*
TypeReference(Any)
Requirements

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.

Summarytrue
Comments

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.

MessageHeader.definition
Element IdMessageHeader.definition
Definition

Permanent link to the MessageDefinition for this message.

Short DisplayLink to the definition for this message
Cardinality0..1
Typecanonical(MessageDefinition)
Requirements

Allows sender to define the expected contents of the message.

Summarytrue