Logo

This specification conforms to FHIR®© R4

Reliable Messaging using MedCom FHIR Messaging

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.

reliable messaging fhir
Figure 1: Reliable Messaging - FHIR


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.

1 MedCom FHIR Reliable Messaging Model

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.

1.1 Different Reliable Messaging scenarios

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.

1.1.1 Scenario #1 - Normally successful unsolicidated message or request message flow with acknowledgement request

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.

1.1.2 Scenario #2 - Duplicate an unchanged message with a positive acknowledgement request

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.

1.1.3 Scenario #3 - (Re) Sending Unchanged Message

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.

1.1.4 Scenario #4 - Message is sent normally, acknowledgement is lost along the way

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.

1.1.5 Scenario #5 - (Re) Sending Modified Message

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



About

Support or contact

MedCom is responsible for this page. If you have any questions regarding this page, please contact fhir@medcom.dk or write to MedComs stream on Zulip.

Version of this documentation

The version of this documentation is: Version 1.0.8 You can finde the release note of the version here.



"FHIR® is the registered trademark of HL7 and is used with the permission of HL7. Use of the FHIR trademark does not constitute endorsement of this implementation guide by HL7, nor affirmation that this content is conformant to the various applicable standards"


Tilgængelighedserklæring