medcomdk · ovi-medcom · Nov 19, 2024 · Jun 24, 2024 · Jun 24, 2024 · Jun 28, 2024
diff --git a/docs/_config.yml b/docs/_config.yml
@@ -21,8 +21,6 @@ menutxt_item5: EHMI Endpoint Register*
 menuurl_item6: https://medcomdk.github.io/ehmi/assets/documents/egov/
 menutxt_item6: EHMI Governance*
 menuurl_item7: https://medcomdk.github.io/ehmi/assets/documents/security/
-menutxt_item7: EHMI Security
+menutxt_item7: EHMI Security*
 menuurl_item8: https://medcomdk.github.io/ehmi/assets/documents/glossary/
 menutxt_item8: EHMI Glossary
-menuurl_item9: https://medcomdk.github.io/ehmi/assets/ehmi_ecosystem.html
-menutxt_item9: EHMI Ecosystem
diff --git a/docs/assets/documents/eDelivery/index.md b/docs/assets/documents/eDelivery/index.md
@@ -0,0 +1,12 @@
+# eDelivery for EHMI
+
+**Table of contents**
+
+- [Standard Business Document Header (SBDH)](/SBDH-envelope/index.md)
+- [Exchange Header Envelope (XHE)](/XHE/index.md)
+- [Service Metadata Publisher (SMP)](/SMP/index.md)
+- [Forsendelsesstatus](/forsendelsesstatus/index.md)
+
+## EHMI Meddelelsesforsendelse og dokumentdeling
+
+![EHMI Meddelelsesforsendelse og dokumentdeling](/ehmi/assets/images/1_EHMI_Meddelelsesforsendelse_og_dokumentdeling_1315x563.png)
diff --git a/docs/assets/documents/eas/index.md b/docs/assets/documents/eas/index.md
@@ -3,32 +3,22 @@
 ***
     **Disclaimer** 
 
-    **To be specified in Q2 2024 and through working groups 2024-2026**
-
-    ***Shifts of languages between English and Danish will occur in this version - that will change completely to English in the next upcoming version***
-
+    **The menu items above marked with a star are yet not specified**
+
 <br/> 
 
-When a user of EHMI wants to send a message, the correct recipient of the message needs to be found somehow unless the user happens to know it by heart. Such a search function already exists to varying degrees in the various user systems, and to make these searches easier, EAS provides useful standardized search services based on relevant authoritative sources (like for example the national register of organizations within the health domain).
+When a user of EHMI wants to send a message, the correct recipient of the message needs to be found somehow unless the user happens to know it by heart. Such a search function already exists to varying degrees in the various user systems, and to make these searches easier, EAS provides useful standardized search services based on relevant authoritative sources (like for example the national register of organizations within the health domain (SOR)).
 
-When EAS receives a search request from a user system it in turn calls the relevant authoritative sources responsible for the information needed for the particular type of search request, and based on this EAS constructs the response for the user system. In this way EAS decouples the user systems from the authoritative sources and the, sometimes cumbersome, logic to be implemented to support searches for recipients in various different situations only needs to be implemented and maintained in EAS.
+When EAS receives a search request from a user system EAS in turn calls the relevant authoritative sources responsible for the information needed for the particular type of search request, and based on this EAS constructs the response for the user system. In this way EAS decouples the user systems from the authoritative sources and the, sometimes cumbersome, logic to be implemented to support searches for recipients in various different situations only needs to be implemented and maintained in EAS.
 
-Examples of search services EAS support include:
-•	Search for a patient’s general practitioner.
-•	Search for general practitioners in a delimited geographical area (relevant for patients with no fixed general practitioner).
-•	Search for recipients capable of receiving specific types of messages – not just the overall message type (including version), but also more detailed searches concerning specific aspects of the message to be sent (relevant, e.g., in relation to referrals for X-ray examinations that require special equipment not offered by all X-ray departments.
+Examples of search services EAS support include: 
+* Search for a patient’s general practitioner.
+* Search for general practitioners in a delimited geographical area (relevant for patients with no fixed general practitioner).
+* Search for recipients capable of receiving specific types of messages – not just the overall message type (including version), but also more detailed searches concerning specific aspects of the message to be sent (relevant, e.g., in relation to referrals for X-ray examinations that require special equipment not offered by all X-ray departments).
 
-[TBT] EHMI anvender en komponent til at håndtere Sundhedsadressering.
-
-[TBT] En skitse over komponenterne i EHMI netværkets anvendelse af komponenten kan ses her:
+An outline of the components in the EHMI network's use of the EHMI Adressing Service can be seen here:
+<img src="https://medcomdk.github.io/ehmi/assets/images/EHMI%20Pixi%20-%20Addressing%20Service.png" alt="EHMI Addressing Service (EAS) (DA)" width="100%">
 
 **The whole specification for EHMI Addressing Service (EAS) can be found** 
 <a href="https://build.fhir.org/ig/medcomdk/dk-ehmi-eas/" target="_blank">here</a>
 
-<br/> 
-
-## An outline of the components of the EHMI Delivery Status can be seen here:
-
-<br/> 
-
-![EHMI Addressing Service (EAS)](/ehmi/assets/images/3_EHMI_Sundhedsadresseringsservice_1315x551.png)
diff --git a/docs/assets/documents/ecore/ehmiSBDH/Reliable_Messaging-SBDH.md b/docs/assets/documents/ecore/ehmiSBDH/Reliable_Messaging-SBDH.md
@@ -0,0 +1,135 @@
+# Reliable Messaging using ehmiSBDHEnvelope
+
+**Table of contents**
+* [1 Different Reliable Messaging scenarios using ehmiSBDHEnvelope](#1-different-reliable-messaging-scenarios-using-vansenvelope)
+    * [1.1 Scenario #1 - Normally successful unsolicited ehmiSBDHEnvelope or request ehmiSBDHEnvelope flow with ehmiSBDHEnvelopeAcknowledgement request ](#11-scenario-1---normally-successful-unsolicited-vansenvelope-or-request-vansenvelope-flow-with-vansenvelopeacknowledgement-request)
+    * [1.2 Scenario #2 - Duplicate of an unchanged ehmiSBDHEnvelope with a positive ehmiSBDHEnvelopeAcknowledgement request ](#12-scenario-2---duplicate-of-an-unchanged-vansenvelope-with-a-positive-vansenvelopeacknowledgement-request)
+    * [1.3 Scenario #3 - (Re) Sending Unchanged ehmiSBDHEnvelope ](#13-scenario-3---re-sending-unchanged-vansenvelope)
+    * [1.4 Scenario #4 - ehmiSBDHEnvelope is sent normally, but ehmiSBDHEnvelopeAcknowledgement is lost along the way](#14-scenario-4---vansenvelope-is-sent-normally-but-vansenvelopeacknowledgement-is-lost-along-the-way)
+    * [1.5 Scenario #5 - (Re-) Sending Modified Message ](#15-scenario-5---re--sending-modified-message)
+* [2 VansEnvelope Reliable Messaging Elements](#2-vansenvelope-reliable-messaging-elements)
+    * [2.2 VansEnvelope Reliable Messaging Message Elements](#22-vansenvelope-reliable-messaging-message-elements)
+    * [2.3 VansEnvelope ehmiSBDHEnvelopeAcknowledgement Reliable Messaging Elements](#23-vansenvelope-vansenvelopeacknowledgement-reliable-messaging-elements)
+<br><br>
+
+
+
+
+Reliable Messaging in ehmiSBDHEnvelope follows the principles laid out in [Reliable Messaging in general](/assets/documents/020_Governance-for-Reliable-Messaging-in-general.md)
+
+The Reliable Messaging Model and how the flow is laid out using ehmiSBDHEnvelope is shown in <a href="#Fig1">Figure 1</a>. 
+
+<figure style="margin-left: 0px; margin-right: 0px; width: 100%;">
+<a href="../images/reliable-messaging-vansenvelope_1160x625.png" target="_blank"> <img src="../images/reliable-messaging-vansenvelope_1160x625.png" alt="reliable messaging principle" style="width:auto; margin-left:0px; margin-right:0px;" id="Fig1"></a>
+<figcaption text-align="left"><b>Figure 1: Reliable Messaging - ehmiSBDHEnvelope </b></figcaption>
+</figure>
+<br>
+
+When Reliable Messaging is implemented, the Receiver **SHALL** check the incoming EnvelopeIdentifier and Message/MetaInformation/Identifier (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 ehmiSBDHEnvelopeAcknowledgement has been lost (failed to return to the request issuer) and thus the previously received Message in a ehmiSBDHEnvelope has been resubmitted with a new EnvelopeIdentifier for processing again. The original ehmiSBDHEnvelopeAcknowledgement **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 ehmiSBDHEnvelopeAcknowledgement|
+
+## 1 Different Reliable Messaging scenarios using ehmiSBDHEnvelope
+
+This section provides a description of the different types of Reliable Messaging scenarios.
+
+- Scenario #1 - Normally successful unsolicited  ehmiSBDHEnvelope or request message flow with ehmiSBDHEnvelopeAcknowledgement request
+- Scenario #2 - Duplicate of an unchanged ehmiSBDHEnvelope with a positive ehmiSBDHEnvelopeAcknowledgement request
+- Scenario #3 - (Re-)Sending Unchanged ehmiSBDHEnvelope
+- Scenario #4 - ehmiSBDHEnvelope is sent normally, ehmiSBDHEnvelopeAcknowledgement is lost along the way
+- Scenario #5 - (Re-)Sending Modified ehmiSBDHEnvelope
+
+### 1.1 Scenario #1 - Normally successful unsolicited ehmiSBDHEnvelope or request ehmiSBDHEnvelope flow with ehmiSBDHEnvelopeAcknowledgement request 
+
+An unsolicited  ehmiSBDHEnvelope is sent with a new request for a positive ehmiSBDHEnvelopeAcknowledgement from the Sending System to a Receiving System.
+
+The Receiving System **SHALL** always send a positive ehmiSBDHEnvelopeAcknowledgement to the Sending System.
+
+### 1.2 Scenario #2 - Duplicate of an unchanged ehmiSBDHEnvelope with a positive ehmiSBDHEnvelopeAcknowledgement request 
+
+Duplication of an unchanged ehmiSBDHEnvelope can be done in one of the following ways:
+
+- An error may have occurred in the flow from the Sending System to the Receiving System with subsequent duplication of a ehmiSBDHEnvelope in scenario 1a.
+- The Sending System may inadvertently send a duplicate of ehmiSBDHEnvelope
+
+The ehmiSBDHEnvelopes are completely identical and as a consequence, the ehmiSBDHEnvelope with request for positive ehmiSBDHEnvelopeAcknowledgement arrives at the Receiving System more than once.
+
+The Receiving System **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 ehmiSBDHEnvelopeAcknowledgement may not be sent first and then a negative ehmiSBDHEnvelopeAcknowledgement or vice versa.
+
+The Receiving System **SHALL** never display several instances of a ehmiSBDHEnvelope in a ehmiSBDHEnvelope overview, but **SHALL** log in a system log that reception of a duplicate ehmiSBDHEnvelope has taken place.
+
+If the Sending System of the ehmiSBDHEnvelope has received ehmiSBDHEnvelopeAcknowledgement already after the Receiving System's ehmiSBDHEnvelopeAcknowledgement of a ehmiSBDHEnvelope's first instance, the Sending System **SHALL** similarly ignore the duplicate instances of the ehmiSBDHEnvelopeAcknowledgement.
+
+The Sending System **SHALL** never display multiple instances of the same ehmiSBDHEnvelopeAcknowledgement in a ehmiSBDHEnvelope summary but **SHALL** log in a system log that ehmiSBDHEnvelopeAcknowledgement of a duplicate has taken place.
+
+### 1.3 Scenario #3 - (Re) Sending Unchanged ehmiSBDHEnvelope 
+
+Correct retransmission of message A.
+
+The Sending System **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 ehmiSBDHEnvelopeAcknowledged 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.
+
+### 1.4 Scenario #4 - ehmiSBDHEnvelope is sent normally, but ehmiSBDHEnvelopeAcknowledgement is lost along the way 
+
+Like in Scenario #1, but where ehmiSBDHEnvelopeAcknowledgement is lost along the way from the Sending System to the Receiving System.
+
+The shipping pattern is like Scenario #3.
+
+### 1.5 Scenario #5 - (Re-) Sending Modified Message 
+
+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.
+
+## 2 VansEnvelope Reliable Messaging Elements
+
+### 2.2 VansEnvelope Reliable Messaging Message Elements
+
+A VansEnvelope consists of the following elements (see <a href="#Fig2">Figure 2</a>.):
+
+<figure style="margin-left: 0px; margin-right: 0px; width: 100%;">
+<a href="../images/vansenvelope_schema-reliable.png" target="_blank"> <img src="../images/vansenvelope_schema-reliable.png" alt="vansenvelope_schema-reliable" style="width:auto; margin-left:0px; margin-right:0px;" id="Fig2"></a>
+<figcaption text-align="left"><b>Figure 2: Reliable Messaging - reliable ehmiSBDHEnvelope tables </b></figcaption>
+</figure>
+<br>
+
+A VansEnvelope's Reliable Messaging part can be found in the ehmiSBDHEnvelope/Message/MetaInformation/Transport/Type-element, which is shown in <a href="#Fig3">Figure 3</a>.:
+
+<figure style="margin-left: 0px; margin-right: 0px; width: 100%;">
+<a href="../images/vansenvelope_schema-reliable-type.png" target="_blank"> <img src="../images/vansenvelope_schema-reliable-type.png" alt="vansenvelope_schema-reliable" style="width:auto; margin-left:0px; margin-right:0px;" id="Fig3"></a>
+<figcaption text-align="left"><b>Figure 3: Reliable Messaging - reliable ehmiSBDHEnvelope type </b></figcaption>
+</figure>
+<br>
+
+Reliable Messaging in ehmiSBDHEnvelope is the default mode but can explicitly be turned on and off by setting the ehmiSBDHEnvelope/Message/MetaInformation/Transport/Type-element to "reliable" or "unreliable".
+
+In FHIR Messaging, this element **SHALL** be "reliable" or left in default mode.
+
+### 2.3 VansEnvelope ehmiSBDHEnvelopeAcknowledgement Reliable Messaging Elements
+
+When "reliable", the receiver of the ehmiSBDHEnvelope **SHALL** send a ehmiSBDHEnvelopeAcknowledgement return to the original Sender.
+
+A ehmiSBDHEnvelopeAcknowledgement consists of the following elements (see <a href="#Fig4">Figure 4</a>.):
+
+<figure style="margin-left: 0px; margin-right: 0px; width: 100%;">
+<a href="../images/vansenvelope_schema-acknowledgement.png" target="_blank"> <img src="../images/vansenvelope_schema-acknowledgement.png" alt="vansenvelope_schema-acknowledgement" style="width:auto; margin-left:0px; margin-right:0px;" id="Fig4"></a>
+<figcaption text-align="left"><b>Figure 4: Reliable Messaging - reliable ehmiSBDHEnvelope acknowledgement </b></figcaption>
+</figure>
+<br>
+
+| Links for Reliable Messaging|
+|:---|
+|[Reliable Messaging in general](020_Governance-for-Reliable-Messaging-in-general.md)|
+|[Reliable Messaging in MedCom FHIR Messaging](043_Reliable_Messaging-FHIR.md)|
diff --git a/docs/assets/documents/ecore/ehmiSBDH/index.md b/docs/assets/documents/ecore/ehmiSBDH/index.md
@@ -5,9 +5,7 @@
     **Disclaimer** 
 
     **The menu items above marked with a star are yet not specified**
-
-    ***Shifts of languages between English and Danish will occur in this version - that will change completely to English in the next upcoming version***
-
+
 <br/> 
 
 The EHMI Standard Business Document Header (ehmiSBDH) is a customized version of the PEPPOL SBDH.

diff --git a/docs/assets/documents/ecore/ehmiSMP/ehmiSMP_Registrations.md b/docs/assets/documents/ecore/ehmiSMP/ehmiSMP_Registrations.md
@@ -5,9 +5,7 @@
     **Disclaimer** 
 
     **The menu items above marked with a star are yet not specified**
-
-    ***Shifts of languages between English and Danish will occur in this version - that will change completely to English in the next upcoming version***
-
+
 <br/> 
 
 ## ehmiSMP

diff --git a/docs/assets/documents/ecore/ehmiSMP/index.md b/docs/assets/documents/ecore/ehmiSMP/index.md
@@ -5,9 +5,7 @@
     **Disclaimer** 
 
     **The menu items above marked with a star are yet not specified**
-
-    ***Shifts of languages between English and Danish will occur in this version - that will change completely to English in the next upcoming version***
-
+
 <br/> 
 
 ## ehmiSMP

diff --git a/docs/assets/documents/ecore/index.md b/docs/assets/documents/ecore/index.md
@@ -5,9 +5,7 @@
     **Disclaimer** 
 
     **The menu items above marked with a star are yet not specified**
-
-    ***Shifts of languages between English and Danish will occur in this version - that will change completely to English in the next upcoming version***
-
+
 <br/> 
 
 
@@ -63,7 +61,7 @@ In addition to the primary flow, ehmiEnvelopeReceipt will be sent from the Recei
 
 <br/> 
 
-![EHMI Core Message Delivery and Document Sharing](/ehmi/assets/images/1_EHMI_Meddelelsesforsendelse_og_dokumentdeling_1315x563.png)
+![EHMI Core Message Delivery and Document Sharing](https://medcomdk.github.io/ehmi/assets/images/EHMI%20Pixi%20-%20Message%20delivery.png)
 
 <br/> 
 

diff --git a/docs/assets/documents/eds/index.md b/docs/assets/documents/eds/index.md
@@ -5,9 +5,7 @@
     **Disclaimer** 
 
     **The menu items above marked with a star are yet not specified**
-
-    ***Shifts of languages between English and Danish will occur in this version - that will change completely to English in the next upcoming version***
-
+
 <br/> 
 
 ## EHMI Delivery Status is defined as 
@@ -18,7 +16,7 @@
 
 <br/> 
 
-The EDS Server and EDS Clients are expected to implement the user stories outlined [here:](./userstories/index.md)
+The EDS Server and EDS Clients are expected to implement the user stories outlined [here](./userstories/index.md)
 
 <br/> 
 

diff --git a/docs/assets/documents/eds/userstories/component.md b/docs/assets/documents/eds/userstories/component.md
@@ -5,9 +5,7 @@
     **Disclaimer** 
 
     **The menu items above marked with a star are yet not specified**
-
-    ***Shifts of languages between English and Danish will occur in this version - that will change completely to English in the next upcoming version***
-
+
 <br/> 
 
 # EHMI Delivery Status User stories

diff --git a/docs/assets/documents/eds/userstories/index.md b/docs/assets/documents/eds/userstories/index.md
@@ -5,9 +5,7 @@
     **Disclaimer** 
 
     **The menu items above marked with a star are yet not specified**
-
-    ***Shifts of languages between English and Danish will occur in this version - that will change completely to English in the next upcoming version***
-
+
 <br/> 
 
 # EHMI Delivery Status User stories

diff --git a/docs/assets/documents/eds/userstories/patient.md b/docs/assets/documents/eds/userstories/patient.md
@@ -5,9 +5,7 @@
     **Disclaimer** 
 
     **The menu items above marked with a star are yet not specified**
-
-    ***Shifts of languages between English and Danish will occur in this version - that will change completely to English in the next upcoming version***
-
+
 <br/> 
 
 # EHMI Delivery Status User stories

diff --git a/docs/assets/documents/eds/userstories/receiver.md b/docs/assets/documents/eds/userstories/receiver.md
@@ -5,9 +5,7 @@
     **Disclaimer** 
 
     **The menu items above marked with a star are yet not specified**
-
-    ***Shifts of languages between English and Danish will occur in this version - that will change completely to English in the next upcoming version***
-
+
 <br/> 
 
 # EHMI Delivery Status User stories

diff --git a/docs/assets/documents/eds/userstories/sender.md b/docs/assets/documents/eds/userstories/sender.md
@@ -5,9 +5,7 @@
     **Disclaimer** 
 
     **The menu items above marked with a star are yet not specified**
-
-    ***Shifts of languages between English and Danish will occur in this version - that will change completely to English in the next upcoming version***
-
+
 <br/> 
 
 # EHMI Delivery Status User stories