This page is part of the FHIR Specification (v0.11: DSTU 1 Ballot 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions
Formal definitions for the elements in the message resource.
| Message | |
| Definition | The root for a transmission 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 of which the Message resource instance is the first resource in the bundle. |
| Control | 1..1 |
| Requirements | Many implementations are not prepared to use REST and need a message based infrastructure. |
| Message.identifier | |
| Definition | The identifier of this message. |
| Control | 1..1 |
| Type | id |
| Comments | This must be unique within the scope of this stream of messages. |
| Message.timestamp | |
| Definition | The time that the message was sent. |
| Control | 1..1 |
| Type | instant |
| Requirements | Allows limited detection of out-of-order and delayed transmission. Also supports audit. |
| Message.event | |
| Definition | Code that identifies the event this message represents and connects it with the event definition in the FHIR specification. |
| Control | 1..1 |
| Binding | MessageEvent : the Event List in the messaging framework |
| Type | code |
| Is Modifier | true |
| Requirements | Drives the behavior associated with this message. |
| To Do | Consider changing to Coding to support profile-defined events. |
| Message.response | |
| Definition | Information about the message that this message is a response to. Only present if this message is a response. |
| Control | 0..1 |
| Is Modifier | true |
| Message.response.identifier | |
| Definition | The id of the message that this a response to. |
| Control | 1..1 |
| Type | id |
| Requirements | Allows receiver to know what message is being responded to. |
| Message.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. |
| Control | 1..1 |
| Binding | ResponseCode : The kind of response to a message (see http://hl7.org/fhir/response-code for values) |
| Type | code |
| Is Modifier | true |
| Requirements | Allows the sender of the acknowledge message to know if the request was successful or if action is needed. |
| Comments | This is a generic response to the request Message. Specific data for the response will be found in Message.data. |
| Message.response.details | |
| Definition | Full details of any issues found in the message. |
| Control | 0..1 |
| Type | Resource(OperationOutcome) |
| Requirements | Allows the sender of the message to determine what the specific issues are. |
| Comments | This must be contained in the bundle. If any of the issues are errors, the response code must be an error. |
| Message.source | |
| Definition | The source application from which this message originated. |
| Control | 1..1 |
| Requirements | Allows replies, supports audit. |
| Message.source.name | |
| Definition | Human readable name for the target system. |
| Control | 0..1 |
| Type | string |
| Requirements | May be used to support audit. |
| Message.source.software | |
| Definition | May include configuration or other information useful in debugging. |
| Control | 1..1 |
| Type | string |
| Requirements | Supports audit and possibly interface engine behavior. |
| Message.source.version | |
| Definition | Can convey versions of multiple systems in situations where a message passes through multiple hands. |
| Control | 0..1 |
| Type | string |
| Requirements | Supports audit and possibly interface engine behavior. |
| Message.source.contact | |
| Definition | An e-mail, phone, website or other contact point to use to resolve issues with message communications. |
| Control | 0..1 |
| Type | Contact |
| Requirements | Allows escalation of technical issues. |
| Message.source.endpoint | |
| Definition | Identifies the routing target to send acknowledgements to. |
| Control | 1..1 |
| Type | uri |
| Requirements | Identifies where to send responses, may influence security permissions. |
| Comments | The id may be a non-resolvable URI for systems that do not use standard network-based addresses. |
| Message.destination | |
| Definition | The destination application which the message is intended for. |
| Control | 1..1 |
| Requirements | Indicates where message is to be sent to for routing purposes. Allows verification of "am I the intended recipient". |
| Message.destination.name | |
| Definition | Human readable name for the source system. |
| Control | 0..1 |
| Type | string |
| Requirements | May be used for routing of response and/or to support audit. |
| Message.destination.target | |
| Definition | Identifies the target end system in situations where the initial message transmission is to an intermediary system. |
| Control | 0..1 |
| Type | Resource(Device) |
| Requirements | Supports multi-hop routing. |
| Message.destination.endpoint | |
| Definition | Indicates where the message should be routed to. |
| Control | 1..1 |
| Type | uri |
| Requirements | Identifies where to route the message. |
| Comments | The id may be a non-resolvable URI for systems that do not use standard network-based addresses. |
| Message.enterer | |
| Definition | The person or device that performed the data entry leading to this message. Where there is more than one candidate, pick the most proximal to the message. Can provide other enterers in extensions. |
| Control | 0..1 |
| Type | Resource(Practitioner) |
| Requirements | Need to know for audit/traceback requirements and possibly for authorization. |
| Comments | Usually only for the request, but can be used in a response. |
| Message.author | |
| Definition | The logical author of the message - the person or device that decided the described event should happen. Where there is more than one candidate, pick the most proximal to the Message. Can provide other authors in extensions. |
| Control | 0..1 |
| Type | Resource(Practitioner) |
| Requirements | Need to know for audit/traceback requirements and possibly for authorization. |
| Comments | Usually only for the request, but can be used in a response. |
| Message.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. |
| Control | 0..1 |
| Type | Resource(Practitioner|Organization) |
| Requirements | Allows routing beyond just the application level. |
| Message.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. |
| Control | 0..1 |
| Type | Resource(Practitioner|Organization) |
| Requirements | Need to know for audit/traceback requirements and possibly for authorization. |
| Comments | Usually only for the request, but can be used in a response. |
| Message.effective | |
| Definition | The effective time - the real world time of the event that the message represents. Usually this is just a starting time, but some message events also have an end time (do x for period y). |
| Control | 0..1 |
| Type | Period |
| Requirements | Need to know for understanding the content of the message, may govern receiver's behavior. |
| Comments | Usually only for the request, but can be used in a response. |
| To Do | Grahame thinks this is not 80/20. Also, that it really should be domain modeled, not tucked away here. |
| Message.reason | |
| Definition | Coded indication of the cause for the event - indicates a reason for the occurance of the event that is a focus of this message. |
| Control | 0..1 |
| Binding | EventReason : (Value Set Definition) |
| Type | CodeableConcept |
| 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. |
| Message.data | |
| Definition | The actual data of the message - a reference to the root/focus class of the event. |
| Control | 0..* |
| Type | Resource(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. |
| 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. |