Table of contents
Reliable Messaging in MedCom FHIR Messaging follows the principles laid out in Reliable Messaging in general
The Reliable Messaging Model and how the flow is laid out using FHIR is shown in Figure 1.
When reliable messaging is implemented , the Receiver SHALL check the incoming Bundle.id and MessageHeader.id against a cache of previously received messages.
The correct action to take depends on what is received:
Case | Description |
---|---|
Both Bundle.id and MessageHeader.id have not been received | This is the normal case, and the message SHALL be processed |
Both Bundle.id and MessageHeader.id have already been received | The original response has been lost (failed to return to the request issuer), and the original response SHALL be resent |
MessageHeader.id has already been received, but Bundle.id is new | A previously seen message has been resubmitted for processing again. The server may either reprocess the message, or reject the message |
The Bundle.id has already been received, but the MessageHeader.id is new | This is an error - Bundle.id values MUST never be reused |
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.
Applications that implement reliable messaging declare their reliable cache period in their Capability Statement.
This ruleset is a generic ruleset governing the principles of Reliable Messaging:
A specific ruleset for respectively the MedCom FHIR Message and the VANSEnvelope will be explained later in this Governance.
This section provides a description of the different types of Reliable Messaging scenarios in generic terms. For specific handling of these scenarios for VANSEnvelope and FHIR Messages see the description in the detailed sections of the respective chapters for these subjects.
An unsolicidated message or request message is sent with a new request for a positive acknowledgement from the Sending System to a Receiving System. The Receiving System SHALL always send a positive acknowledgement to the Sending System.
Duplication of an unchanged message can be done in one of the following ways:
The messages are completely identical and as a consequence the message with request for positive acknowledgement arrives at the Receiving System more than once.
The Receiving System SHALL ignore the contents of the duplicate instances of the message, but SHALL acknowledge a duplicate message in the same way as the original message.
A positive acknowledgement may not be sent first and then a negative acknowledgement or vice versa.
The Receiving System SHALL never display several instances of a message in a message overview, but SHALL log in a system log that reception of a duplicate message has taken place.
If the Sending System of the message has received acknowledgement already after the Receiving System’s acknowledgement of a message’s first instance, the Sending System SHALL similarly ignore the duplicate instances of the acknowledgement.
The Sending System SHALL never display multiple instances of the same acknowledgement in a message summary, but SHALL log in a system log that acknowledgement of a duplicate has taken place.
Correct retransmission of a message.
The Sending System SHALL form a new envelope with a new ID and time of dispatch. Since there has been no change in the letter section, the rest of the message remains identical.
The message is sent and acknowledged as a completely new message according to Scenario #1 or # 1b.
Re-dispatches are always done manually and should be in accordance with the normal response time for the specific message flow.
As Scenario #1, but where acknowledgement is lost along the way from the Sending System to the Receiving System.
The shipping pattern is like Scenario #3.
If the content of the letter part is changed, the message is considered a completely new message with the consequent change of both EnvelopeId, LetterId and timestamp, where relevant.
Resubmissions are always done manually.
Links for Reliable Messaging |
---|
Reliable Messaging in general |
Reliable Messaging in VANSEnvelope |