DK EHMI SBDH IG
1.0.0 - release
DK EHMI SBDH IG
1.0.0 - release
DK EHMI SBDH IG, published by MedCom. This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/medcomdk/dk-ehmi-sbdh/ and changes regularly. See the Directory of published versions
Reliable Messaging in ehmiSBDH Envelope follows the principles laid out in Reliable Messaging in general
The Reliable Messaging Model and how the flow is laid out using ehmiSBDH Envelope is shown in Figure 1
In EHMI Reliable Messaging SHALL be "turned on" by adding the Scope structure pointed out by the Scope-Type element: ehmiSBDH Envelope/StandardBusinessDocumentHeader/BusinessScope/Scope/Type[EHMI-ReceiptAcknowledgement] and the Scope-InstanceIdentifier: ehmiSBDH Envelope/StandardBusinessDocumentHeader/BusinessScope/Scope/InstanceIdentifier[Request]
This is defined as the default mode of Reliable Messaging in EHMI.
When Reliable Messaging is implemented, the Receiver SHALL check the incoming StandardBusinessDocumentHeader/DocumentInformation/Identifier (hereafter EnvelopeIdentifier) and the StandardBusinessDocumentHeader/BusinessScope/Scope[Type:DOCUMENTID]/InstanceIdentifier (hereafter MessageIdentifier) against a cache of previously received ehmiSBDH Envelopes. The correct action to take depends on what is received:
| Case | Description |
|---|---|
| Both EnvelopeIdentifier and MessageIdentifier have not been received | This is the normal case, and the message SHALL be processed |
| Both EnvelopeIdentifier and MessageIdentifier have already been received | The original ehmiSBDH Envelope server may either reprocess the message, or reject the message |
| MessageIdentifier has already been received, but EnvelopeIdentifier is new | The original ehmiSBDH-EnvelopeReceipt has been lost (failed to return to the request issuer) and thus the previously received Message in An ehmiSBDH Envelope has been resubmitted with a new EnvelopeIdentifier for processing again. The original ehmiSBDH-EnvelopeReceipt SHALL be resent |
| The EnvelopeIdentifier has already been received, but the MessageIdentifier is new | This is an error - EnvelopeIdentifier values SHALL never be reused. Receiver MAY return a Negative ehmiSBDH-EnvelopeReceipt |
This section provides a description of the different types of Reliable Messaging scenarios.
An unsolicited ehmiSBDH Envelope is sent with a new request for a positive ehmiSBDH-EnvelopeReceipt from the Sending MSH to a Receiving MSH.
The Receiving MSH SHALL always send a positive ehmiSBDH-EnvelopeReceipt to the Sending MSH.
Duplication of an unchanged ehmiSBDH Envelope can be done in one of the following ways:
The ehmiSBDH Envelopes are completely identical and as a consequence, the ehmiSBDH Envelope with request for positive ehmiSBDH-EnvelopeReceipt arrives at the Receiving MSH more than once.
The Receiving MSH SHALL ignore the contents of the duplicate instances of the ehmiSBDH Envelope but SHALL acknowledge a duplicate ehmiSBDH Envelope in the same way as the original ehmiSBDH Envelope.
A positive ehmiSBDH-EnvelopeReceipt may not be sent first and then a negative ehmiSBDH-EnvelopeReceipt or vice versa.
The Receiving MSH SHALL never display several instances of An ehmiSBDH Envelope in An ehmiSBDH Envelope overview, but SHALL log in a system log that reception of a duplicate ehmiSBDH Envelope has taken place.
If the Sending MSH of the ehmiSBDH Envelope has received ehmiSBDH-EnvelopeReceipt already after the Receiving MSH's ehmiSBDH-EnvelopeReceipt of An ehmiSBDH Envelope's first instance, the Sending MSH SHALL similarly ignore the duplicate instances of the ehmiSBDH-EnvelopeReceipt.
The Sending MSH SHALL never display multiple instances of the same ehmiSBDH-EnvelopeReceipt in An ehmiSBDH Envelope summary but SHALL log in a system log that ehmiSBDH-EnvelopeReceipt of a duplicate has taken place.
Correct retransmission of message A.
The Sending MSH SHALL form a new ehmiSBDH Envelope with a new ID and time of dispatch.
Since there has been no change in the Message content section, the rest of the ehmiSBDH Envelope SHALL remain identical.
The ehmiSBDH Envelope SHALL be sent and ehmiSBDH Envelope-Acknowledged as a completely new ehmiSBDH Envelope according to Scenario #1 or # 1b.
Re-dispatches SHALL always be done manually and SHOULD be in accordance with the normal response time for the specific ehmiSBDH Envelope flow.
Like in Scenario #1, but where ehmiSBDH-EnvelopeReceipt is lost along the way from the Sending MSH to the Receiving MSH.
The shipping pattern is like Scenario #3.
If the content of the Message content part is changed, the ehmiSBDH Envelope is considered a completely new ehmiSBDH Envelope and consequently change of both EnvelopeIdentifier, MessageIdentifier and timestamp SHALL be made if relevant.
Resubmissions SHALL always be done manually.
An ehmiSBDH Envelope's Reliable Messaging part can be found in the ehmiSBDH Envelope/-element, which is shown in ehmiSBDH Envelope's Reliable Messaging part
Reliable Messaging in ehmiSBDH Envelope SHALL be the default mode but can explicitly be "turned off" by leaving out the Scope-element pointed out by the Scope-Type: ehmiSBDH Envelope/StandardBusinessDocumentHeader/BusinessScope/Scope/Type[EHMI-ReceiptAcknowledgement] and the Scope-InstanceIdentifier: ehmiSBDH Envelope/StandardBusinessDocumentHeader/BusinessScope/Scope/InstanceIdentifier[Request]
In EHMI Messaging, these elements SHALL be present together with the underlying structure-parts.
When "reliable", the receiver of the ehmiSBDH Envelope SHALL send An ehmiSBDH-EnvelopeReceipt return to the original Sender.
An ehmiSBDH-EnvelopeReceipt consists of the following elements
MedComs desciption of Reliable Messaging in general in MedComs FHIR governance