. Page versions: R5 R4B R4 R3 R2This page is part of the FHIR Specification (v0.01: Historical Archive Draft). 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: R5 R4B R4 R3 R2
This page describes how FHIR Resources can be used in a traditional messaging context, much like HL7 v2. Applications claiming conformance to this framework claim to be conformant to "FHIR messaging".
In FHIR messaging, a "request message" is sent from a source application to a destination application when an event happens. Events mostly correspond to things that happen in the real world. The request application consists of an aggregation of resources, with the first resource in the aggregation being a Message resource that identifies the nature of the request message and carries additional request metadata. The other resources in the aggregation depend on the request. The events supported in FHIR, along with the resources included in them, are defined below. The destination application processes the request, and returns one or more response messages which are also an aggregation of resources, with the first resource in the aggregation being a Message resource with a response section that reports the outcome of the transaction and any additional response resources required.
This specification assumes that content will be delivered from one application to another by some delivery mechanism, and then a response will be returned to the source application. The exact mechanism of transfer is irrelevant to this specification, but may include file transfer, http based transfer, LLP (HL7 minimal lower layer protocol), MQ series messaging, or anything else. The only requirement for the transfer layer is that requests are sent to a known location, and responses are returned to the source of the request. This specification considers the source and destination applications as logical entites, and the mapping from logical source and destination to implementation specific addresses is outside the scope of this specification.
In principle, source applications are not required to wait for a response to a transaction before issuing a new transaction. However in some case, the transactions in a given stream are dependent on each other, and must be sent in order. In addition, some transfer options may require sequential delivery of messages.
This specification ignores the existence of interface engines and message transfer agents that lie between the source and destination. Either they are transparent to the message/transaction content, and irrelevant to this specification, or they are actively involved in manipulating the message content. If these middleware agents are modifying the message content, then they become responsible for honoring the contract described below in both directions.
Some of the message delivery mechanisms mentioned above are reliable delivery systems - the message is always delivered, or an appropriate error is returned to the source. However in most implementations, reliable messaging cannot be assumed, and either the request or the response can get lost in transit. FHIR messaging describes a simple approach to handle this that applications must conform to, whether messaging appears to be reliable or not.
A message receiver must always check the incoming aggregation package ids, and check them against a store of previously received messages (going back a reasonable period in time). If it receives a duplicate message id that it has already responded to, it should assume that it's original response was lost, and resend the original response in a new aggregation package with Message.response.duplicate set to true. If the source application gets no response to it's request from the destination application, the source application should resend the same aggregation with the same aggregation package id.
A message is just an aggregation built using the Atom feed format. The first resource of a message is a Message resource. This resource identifies the message event and links to the additional focal resource associated with the message, if any. The list of additional resources which must be included in a given message is provided below. Other resources that are identified in the message resource or included resources may either be left as references that are located/resolved outside the scope of the aggregation, or they may also be included in the aggregation.
| Code | Description | Request | Response | Notes |
|---|---|---|---|---|
| admin-notify | Notification of a change to an administrative resource (either create or update). Note that there is no delete, though some administrative resources have status or period elements for this use | Person | -- | |
| Animal | -- | |||
| Organization | -- | |||
| Patient | -- | Patient Links cannot be updated using admin-notify. The links element must be empty | ||
| labreport-provide | Provide a lab report, or update a previously provided lab report | LabReport LabReport.patient LabReport.patient.person LabReport.patient.animal LabReport.admission LabReport.requestDetail.clinicalInfo LabReport.specimen LabReport.resultGroup.specimen | -- | |
| patient-link | Notification that two patient records actually identify the same patient | Patient,Patient | -- | Follow ups: patient-unlink? |
| patient-unlink | Notification that previous advice that two patient records concern the same patient is now considered incorrect | Patient,Patient | -- |
Applications claiming to be conformant to "FHIR messaging" may choose to publish a conformance statement that lists all the message events they support, either as sender or listener, and for each event, which resources are aggregated (sender), or are required to be aggregated (listener), and the conformance statements for the information content of the individual resources. The conformance statement is a resource with the name "MessageConformance".
This is an old version of FHIR retained for archive purposes. Do not use for anything else
Implementers are welcome to experiment with the content defined here, but should note that the contents are subject to change without prior notice.
© HL7.org 2011 - 2012. FHIR v0.01 generated on Mon, May 14, 2012 09:48+1000.