DK EHMI SBDH IG
0.91.0 - ci-build
DK EHMI SBDH IG
0.91.0 - ci-build
DK EHMI SBDH IG, published by MedCom. This guide is not an authorized publication; it is the continuous build for version 0.91.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 ehmiSBDHEnvelope follows the principles laid out in Reliable Messaging in general
The Reliable Messaging Model and how the flow is laid out using ehmiSBDHEnvelope 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: ehmiSBDHEnvelope/StandardBusinessDocumentHeader/BusinessScope/Scope/Type[EHMI-ReceiptAcknowledgement] and the Scope-InstanceIdentifier: ehmiSBDHEnvelope/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 ehmiSBDHEnvelopes. 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 ehmiSBDHEnvelope server may either reprocess the message, or reject the message |
| MessageIdentifier has already been received, but EnvelopeIdentifier is new | The original ehmiSBDHEnvelopeReceipt has been lost (failed to return to the request issuer) and thus the previously received Message in An ehmiSBDHEnvelope has been resubmitted with a new EnvelopeIdentifier for processing again. The original ehmiSBDHEnvelopeReceipt 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 ehmiSBDHEnvelopeReceipt |
This section provides a description of the different types of Reliable Messaging scenarios.
An unsolicited ehmiSBDHEnvelope is sent with a new request for a positive ehmiSBDHEnvelopeReceipt from the Sending MSH to a Receiving MSH.
The Receiving MSH SHALL always send a positive ehmiSBDHEnvelopeReceipt to the Sending MSH.
Duplication of an unchanged ehmiSBDHEnvelope can be done in one of the following ways:
The ehmiSBDHEnvelopes are completely identical and as a consequence, the ehmiSBDHEnvelope with request for positive ehmiSBDHEnvelopeReceipt arrives at the Receiving MSH more than once.
The Receiving MSH SHALL ignore the contents of the duplicate instances of the ehmiSBDHEnvelope but SHALL acknowledge a duplicate ehmiSBDHEnvelope in the same way as the original ehmiSBDHEnvelope.
A positive ehmiSBDHEnvelopeReceipt may not be sent first and then a negative ehmiSBDHEnvelopeReceipt or vice versa.
The Receiving MSH SHALL never display several instances of An ehmiSBDHEnvelope in An ehmiSBDHEnvelope overview, but SHALL log in a system log that reception of a duplicate ehmiSBDHEnvelope has taken place.
If the Sending MSH of the ehmiSBDHEnvelope has received ehmiSBDHEnvelopeReceipt already after the Receiving MSH's ehmiSBDHEnvelopeReceipt of An ehmiSBDHEnvelope's first instance, the Sending MSH SHALL similarly ignore the duplicate instances of the ehmiSBDHEnvelopeReceipt.
The Sending MSH SHALL never display multiple instances of the same ehmiSBDHEnvelopeReceipt in An ehmiSBDHEnvelope summary but SHALL log in a system log that ehmiSBDHEnvelopeReceipt of a duplicate has taken place.
Correct retransmission of message A.
The Sending MSH SHALL form a new ehmiSBDHEnvelope with a new ID and time of dispatch.
Since there has been no change in the Message content section, the rest of the ehmiSBDHEnvelope SHALL remain identical.
The ehmiSBDHEnvelope SHALL be sent and ehmiSBDHEnvelope-Acknowledged as a completely new ehmiSBDHEnvelope 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 ehmiSBDHEnvelope flow.
Like in Scenario #1, but where ehmiSBDHEnvelopeReceipt 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 ehmiSBDHEnvelope is considered a completely new ehmiSBDHEnvelope and consequently change of both EnvelopeIdentifier, MessageIdentifier and timestamp SHALL be made if relevant.
Resubmissions SHALL always be done manually.
An ehmiSBDHEnvelope's Reliable Messaging part can be found in the ehmiSBDHEnvelope/-element, which is shown in ehmiSBDHEnvelope's Reliable Messaging part
Reliable Messaging in ehmiSBDHEnvelope SHALL be the default mode but can explicitly be "turned off" by leaving out the Scope-element pointed out by the Scope-Type: ehmiSBDHEnvelope/StandardBusinessDocumentHeader/BusinessScope/Scope/Type[EHMI-ReceiptAcknowledgement] and the Scope-InstanceIdentifier: ehmiSBDHEnvelope/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 ehmiSBDHEnvelope SHALL send An ehmiSBDHEnvelopeReceipt return to the original Sender.
An ehmiSBDHEnvelopeReceipt consists of the following elements
MedComs desciption of Reliable Messaging in general in MedComs FHIR governance