6.9 Message リソース

Home ＞ Infrastructure ＞ Message [message]

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.

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 message consists of a bundle of resources, with the first resource in the bundle being this Message resource. The Message resource has a code - the message event - that identifies the nature of the request message and carries additional request metadata. The other resources in the bundle depend on the type of the request.

The events supported in FHIR, along with the resources that are included in them, are defined below.

The destination application processes the request and returns one or more response messages which are also a bundle of resources, with the first resource in the bundle being a Message resource with a response section that reports the outcome of processing the message 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, MLLP (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 entities, 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 many cases, the messages in a given stream are dependent on each other, and must be sent and processed in order. In addition, some transfer methods may require sequential delivery of messages.

This specification ignores the existence of interface engines and message transfer agents that exist 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 that applies (including applicable profiles) in both directions.

An incoming message contains two identifiers: the envelope id (feed.id) and the message.identifier. Each time a new message is created, it must be assigned an identifier that is unique within that message stream. Note that since message streams are often merged with other streams, it is recommended that the identifier should be globally unique. This can be achieved by using a UUID or an OID or appropriately chosen URI with a serially incrementing number. Each time a message is sent, the bundle identifier (feed.id) should be changed to a new value.

When a receiver receives and processes the message, it responds with a new message with a new identifier, wrapped in a bundle which also has a new id. The response message also quotes the request message identifier so that the source system can relate the response to its request.

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 most implementations use methods which do not provide reliable messaging, and either the request or the response can get lost in transit. FHIR messaging describes a simple approach to handle this that receivers should conform to in order to maintain predictable functionality even when messaging is not reliable.

When considering the issue of reliable messaging, the source application should consider whether the message is a message of consequence, or a message of currency. A message of consequence is one where the message requests a change that should not be processed more than once, and where the sender needs the response that results from processing the message. A message of currency is where the correct response is the very latest information available. Typically, this is status information. Some messages fit into neither category - the response does not particularly matter. Usually these are notification messages.

In order to enable these processing rules, and to benefit from them, the original sender of the message SHALL do the following when it receives no response to a message within a configured timeout period:

When a receiver declares that it implements reliable answers, it SHALL check the incoming envelope id and message identifier against a cache of previously received messages. The correct action to take depends on what is received:

The duration period for caching does generally not need to be very long. At a minimum, it could be 1 minute longer than the timeout of the sending system, though it may need to be longer depending on the re-sending policies of the sending system.

TODO: describe some use cases

Applications may only claim to be conformant to "FHIR messaging" if they publish a conformance statement so the claim may be verified. A conformance statement lists all the message events they support (either as sender or receiver) and for each event, a profile that states which resources are bundled (sender), or are required to be bundled (receiver), and any rules about the information content of the individual resources. The conformance statement is a resource with the name "Conformance".

There are two end-points defined for a RESTful server that supports Messages:

• [baseurl]/message/: a normal RESTful end point for message resources
• [baseurl]/mailbox: an address at which messages can be delivered

The first end-point ([baseurl]/message/) is used for working within the message contents, for instance, for building messages piecemeal or for auditing received messages. Creating or updating Message resources to this end point 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 message resources.

The second end-point ([baseurl]/mailbox) is used for actually sending messages as bundles, to indicate that the event identified by the code has occurred. The end-point responds with a message response as defined for the particular event, or an error indicating that the attempt to process the message was unsuccessful. The functionality of this end-point is described below.

Note: While the end-points above are defined for use with message resources and for delivering messages to a RESTful server, it is not necessary to use them; messages may be transported between systems using any method desired.

Message (Resource)identifier : id 1..1timestamp : instant 1..1event : code 1..1 <<MessageEvent>>enterer : Resource(Practitioner) 0..1author : Resource(Practitioner) 0..1receiver : Resource(Practitioner|Organization) 0..1responsible : Resource(Practitioner|Organization) 0..1effective : Period 0..1reason : CodeableConcept 0..1 <<EventReason>>data : Resource(Any) 0..*Responseidentifier : id 1..1code : code 1..1 <<ResponseCode>>details : Resource(OperationOutcome) 0..1Sourcename : string 0..1software : string 1..1version : string 0..1contact : Contact 0..1endpoint : uri 1..1Destinationname : string 0..1target : Resource(Device) 0..1endpoint : uri 1..1response0..1source1..1destination1..1

Alternate definitions: Schema/Schematron, Resource Profile

• The resources referenced by the enterer, author and responsible elements may all be included in the 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. The data resource is always included in the bundle

The message.code element carries a simple code that identifies the even that the message conveys. This table lists the codes that are allowed to be used in a message event:

In this table, the request and response columns list the focus resource for the event, along with other resources that should also be carried in the message directly (if they exist). Open Issue for ballot: Does this list need to be extensible?

The mailbox is the standard name for a service hosted on a RESTful server that accepts messages and processes them as transactions and returns a message response appropriate for the message received. The server is under no obligation to do anything particular with the resources except as required by the semantics of the event code in the message resource. A server may choose to retain the resources and make them available on a RESTful interface, but is not required to do so. If the server returns 200 Ok, it must return a valid message that indicates what the outcome of the event processing is. An HTTP error indicates that the message was not processed successfully and that it should be resubmitted (and doing so should not result in a duplicate message response). Repeated failures indicate either a fatal problem with the message or a problem with the receiving application.

The mailbox can also be used to accept documents. In this case, the document is "accepted" (the server takes responsibility for custody of the received document) and an HTTP status of 204 No Content is returned, or an HTTP error is returned. The server is under no obligation to do anything with the document except as specific trading partner agreements dictate.

The following rules apply to the mailbox:

• The mailbox only accepts POST transactions - any other HTTP method will result in an HTTP error
• The request content type submitted is always a bundle containing a message or document resource as the first resource
• The response content type returned is always an HTTP error, a bundle containing a message as the first resource, or empty (if a document was received)
• If the response is an error, the body SHOULD be an Errors & Warning resource with full details
• The URL never takes any parameters
• The mailbox may be authenticated using standard HTTP authentication methods, including OAuth

This simple mailbox profile can be used by any HTTP end point that accepts FHIR messages or documents, not just FHIR RESTful servers.

In order to ensure consistency of processing, the logical rules regarding processing of envelope id and message id described above SHALL be followed when messages are processed using the mailbox. No such rules apply regarding documents - if the client receives no response, it should continue to submit the document until it does. Servers SHALL accept multiple document submissions and process them correctly.

Search Parameters for RESTful searches. The standard parameters also apply. See Searching for more information.