Guaranteed Delivery using Key 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. Further information can be found in the base FHIR specification here
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:
- The Bundle.identifier has not been received Process the message
- 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
Bundle Identifier and Timestamps
Readers must be familiar with the key identifiers, as described in the FHIR specification. The source information is found here
The FHIR specification identifies the importance of the Bundle.timestamp: the time the message was sent, and also the Bundle.identifier.
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.