Guaranteed Delivery & Key Message Identifiers

One important aspect of the FHIR standard is the adherence to the guaranteed delivery mechanism. This approach will go a long way in reducing the number of discrepancies. anne to add a link https://build.fhir.org/messaging.html#reliable

Mandatory Rules for Adjudicators/ Message Processors

When a receiver implements reliable messaging, it SHALL check the incoming Bundle.identifier against a cache of previously received messages. The correct action to take depends on what is received:

1. The Bundle.identifier has not been received Process the message
2. The Bundle.identifier has already been received, The original response has been lost (failed to return to the request issuer), and the original response SHALL be resent

Message Identifiers and Timestamps, FHIR Excerpt

Readers must be familiar with the key identifiers, as described in the FHIR specificaiton.
https://build.fhir.org/messaging.html#3.5.1.4 (Anne to update)

The FHIR specification states:

A message has 2 important timestamps:

1. Bundle.timestamp: the time the message was sent
2. Bundle.meta.lastUpdated: the last time the message was updated (either by storing, or by modification)
   
   

In addition, the message may have additional timestamps in additional resources in the message, either .meta.lastUpdated or others throughout the resources. The meaning of these will depend on the message event.

An incoming message contains exactly one Bundle.identifier which identifies the message. Each time a new message is created, it SHALL be assigned an identifier (Bundle.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. Each time a message is sent, the Bundle.identifier 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, contained in the Bundle.identifier element of the wrapping bundle. The response message also quotes the request Bundle.identifier in MessageHeader.response.identifier so that the source system can relate the response to its request.

Note that Bundle.id and MessageHeader.id also must be present, according to the rules of the underlying Resource.id definition, which allows the potential additional or complementary use of these resources using the FHIR RESTful API.