This page is part of the FHIR Specification (v0.0.82: DSTU 1). 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: R5R4BR4R3R2
The header for a message exchange that is either requesting or responding to an action. The resource(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.
6.9.1 Scope and Usage
The MessageHeader resource is defined in order to support Messaging using FHIR resources.
The principle usage of the MessageHeader resource is when messages are exchanged. However, as a
resource that can be used with the RESTful framework, the MessageHeader
resource has the normal resource end-point ([base-url]/Message), which is
used to manage a set of static messages resources. This could be used to
make an archive of past messages available. Creating or updating Message 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 resources.
The resources referenced by the enterer, author and responsible elements may
all be included in the message bundle or left out on the basis that the recipient (and any intermediaries) are able to locate/resolve the resources
independently. The former would be suitable for loosely coupled systems, and the latter for tightly coupled systems. The messaging conformance
statement for an application may reference a profile that describes how the bundling occurs
The actual content of the data resource is specified for each message event (see the list on the messaging page).
Any resources referenced in the data element are always included in the bundle
If MessageHeader.source.endpoint and MessageHeader.destination.endpoint, are literal URLs, then they SHOULD identify
the addresses to which messages can be be delivered. If they are logical URIs (i.e. non-dereferenceable),
message delivery intermediaries must know how to deliver the message to the destination application.
The author and the receiver are not the actual technical systems - these are the human or organizations that make use of the technical systems
A receiver is not obligated to reject messages which do not explicitly identify it as receiver (e.g. a tracker will get messages that are destined for some other system)
6.9.4 Search Parameters
Search parameters for this resource. The standard parameters also apply. See Searching for more information about searching in REST, messaging, and services.