diff --git a/docs/_config.yml b/docs/_config.yml
index 33eeda3..988fc28 100644
--- 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
new file mode 100644
index 0000000..7c0858d
--- /dev/null
+++ 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
+
+
diff --git a/docs/assets/documents/eas/index.md b/docs/assets/documents/eas/index.md
index 0e36df8..441b162 100644
--- 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**
+
-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:
+
**The whole specification for EHMI Addressing Service (EAS) can be found**
here
-
-
-## An outline of the components of the EHMI Delivery Status can be seen here:
-
-
-
-
diff --git a/docs/assets/documents/ecore/ehmiSBDH/Reliable_Messaging-SBDH.md b/docs/assets/documents/ecore/ehmiSBDH/Reliable_Messaging-SBDH.md
new file mode 100644
index 0000000..5fee41b
--- /dev/null
+++ 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)
+
+
+
+
+
+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 Figure 1.
+
+
+
+Figure 1: Reliable Messaging - ehmiSBDHEnvelope
+
+
+
+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 Figure 2.):
+
+
+
+Figure 2: Reliable Messaging - reliable ehmiSBDHEnvelope tables
+
+
+
+A VansEnvelope's Reliable Messaging part can be found in the ehmiSBDHEnvelope/Message/MetaInformation/Transport/Type-element, which is shown in Figure 3.:
+
+
+
+Figure 3: Reliable Messaging - reliable ehmiSBDHEnvelope type
+
+
+
+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 Figure 4.):
+
+
+
+Figure 4: Reliable Messaging - reliable ehmiSBDHEnvelope acknowledgement
+
+
+
+| 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)|
\ No newline at end of file
diff --git a/docs/assets/documents/ecore/ehmiSBDH/index.md b/docs/assets/documents/ecore/ehmiSBDH/index.md
index ab60036..aaeb397 100644
--- 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***
-
+
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
index e0f7005..aed5d3d 100644
--- 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***
-
+
## ehmiSMP
diff --git a/docs/assets/documents/ecore/ehmiSMP/index.md b/docs/assets/documents/ecore/ehmiSMP/index.md
index 98d4904..4a4c426 100644
--- 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***
-
+
## ehmiSMP
diff --git a/docs/assets/documents/ecore/index.md b/docs/assets/documents/ecore/index.md
index 447882b..7c5abfb 100644
--- 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***
-
+
@@ -63,7 +61,7 @@ In addition to the primary flow, ehmiEnvelopeReceipt will be sent from the Recei
-
+
diff --git a/docs/assets/documents/eds/index.md b/docs/assets/documents/eds/index.md
index eabe23a..467b6e4 100644
--- 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***
-
+
## EHMI Delivery Status is defined as
@@ -18,7 +16,7 @@
-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)
diff --git a/docs/assets/documents/eds/userstories/component.md b/docs/assets/documents/eds/userstories/component.md
index 77874a3..0819628 100644
--- 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***
-
+
# EHMI Delivery Status User stories
diff --git a/docs/assets/documents/eds/userstories/index.md b/docs/assets/documents/eds/userstories/index.md
index ec546e5..177a91f 100644
--- 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***
-
+
# EHMI Delivery Status User stories
diff --git a/docs/assets/documents/eds/userstories/patient.md b/docs/assets/documents/eds/userstories/patient.md
index 3e62bad..349d84a 100644
--- 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***
-
+
# EHMI Delivery Status User stories
diff --git a/docs/assets/documents/eds/userstories/receiver.md b/docs/assets/documents/eds/userstories/receiver.md
index a60bd25..def2252 100644
--- 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***
-
+
# EHMI Delivery Status User stories
diff --git a/docs/assets/documents/eds/userstories/sender.md b/docs/assets/documents/eds/userstories/sender.md
index 98d651e..8c2aa2d 100644
--- 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***
-
+
# EHMI Delivery Status User stories
diff --git a/docs/assets/documents/eer/index.md b/docs/assets/documents/eer/index.md
index 2a4d682..000c705 100644
--- a/docs/assets/documents/eer/index.md
+++ b/docs/assets/documents/eer/index.md
@@ -7,3 +7,37 @@
**To be specified in Q2 2024**
+
+The EHMI Endpoint Register (EER) is an organizational register of Endpoints related to the public SOR.
+
+As SOR will be developed to host only the regular physical locations of an organizational unit, EER will take over the role of SOR-EDI, which hosts the GLN number of a SOR unit and its supported messagetypes. GLN is the actual foreign key to SOR in SOR-EDI. In EER the foreign key to SOR will be the SORID. Thereby the SOR Unit will be able to have more Endpoints expressed by GLN. Util the transition of SOR to be able to handle this, EER will be limited to have only one GLN per SOR unit.
+
+EER will in the first version serve the following purposes:
+
+- EER will be the authoritative register for FHIR messaging endpoints
+- EER will be the authoritative register for FHIR document sharing endpoints for FHIR messages
+- EER will be the master register for SMP registrations (EHMI Core) for the above
+- EER will serve EHMI Addressing Service (EAS) in EAS's effort to deliver the correct receiverdata for a messaging sender.
+
+**As expressed in "Elaborated Vision for Message Communication in the Health Sector" (slightly reformulated):**
+
+Information about an organizational unit’s mailbox is available in SMP, which opens an important distinction. On one hand, a mailbox is related to the organizational unit it receives messages for and, on the other, a mailbox is also related to the message infrastructure itself through which the messages are sent.
+
+SMP is part of the latter, but today the mailbox information is located in SOR, that is, very closely coupled to the former. In order to accommodate both, and to make the existing coupling to SOR less tight as well as to allow for the one-to-many relation between an organizational unit and its mailboxes, it is decided to move the mailbox information to an independent register of mailboxes outside SOR.
+
+In this way, the three distinct business-related concepts of organizational unit, mailbox, and message types are separated into three separate but related registers SOR, EER, and SMP.
+
+**_As expressed in "Elaborated Vision for Message Communication in the Health Sector" a decision on which IHE directory service should be followed, it is decided to follow the mCSD profile, while being pragmatic to this approach and develop it as needed in versions_**
+
+
+
+**The whole specification for EHMI Endpoint Register (EER) can be found**
+here
+
+
+
+## An outline of the components of the EHMI Endpoint Register (EER) can be seen here:
+
+
+
+
diff --git a/docs/assets/documents/egov/index.md b/docs/assets/documents/egov/index.md
index 1d864c1..7ebdb1c 100644
--- a/docs/assets/documents/egov/index.md
+++ b/docs/assets/documents/egov/index.md
@@ -6,6 +6,6 @@
**Minimal Viable Governance (MVG) to be specified in 2024 and final Governance in a broader sence 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**
+ ***
diff --git a/docs/assets/documents/egov/index2.md b/docs/assets/documents/egov/index2.md
index 76c0d08..c25134f 100644
--- a/docs/assets/documents/egov/index2.md
+++ b/docs/assets/documents/egov/index2.md
@@ -6,8 +6,8 @@
**Minimal Viable Governance (MVG) to be specified in 2024 and final Governance in a broader sence 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**
+ ***
diff --git a/docs/assets/documents/glossary/index.md b/docs/assets/documents/glossary/index.md
index caa5ea1..07d3eb1 100644
--- a/docs/assets/documents/glossary/index.md
+++ b/docs/assets/documents/glossary/index.md
@@ -1,33 +1,36 @@
-# Acronyms
+# Acronyms and glossary
***
**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***
-
+
-| Acronym | Acronym for | Description | Domain |
-| --- | --- | --- | --- |
-| AP | Access Point | The eDelivery component responsible for exchanging data between Corner 2 and 3 in the 4 Corner model | eDelivery |
-| EDS | EHMI Delivery Status | [TBD] | EHMI |
-| EER | EHMI Endpoint Register | [TBD] | EHMI |
-| ehmiAck | EHMI Envelope Receipt | [TBD] | EHMI |
-| ehmiSBDH | The EHMI Profile of Standard Business Document Header | [TBD] | EHMI |
-| EUA | End User Application | [TBD] | EHMI |
-| GS1 | Originally "EAN International" now just GS1 | The organisation responsible for GLN numbers and the original SBDH specification. [Website](https://www.gs1.org/) | GS1 |
-| IHE | Integrating the Healthcare Enterprise | International organization which creates interoperability in health care systems | EHMI |
-| MSH | Message Service Handler | The functionality who is responsible for wrapping messages into the ehmiSBDH. Can be a module in an EUA or AP, or it can be a stand-alone application | EHMI |
-| OASIS | [TBD] | The Standardisation Organisation responsible for the specifications of AS4, SML, SMP, ebXML [Website](https://www.oasis-open.org/) | EHMI |
-| PEPPOL | [TBD] | [TBD] | PEPPOL |
-| SBD | Standard Business Document | The wrapper around the SBDH and the Binary content of ehmiSBDH | PEPPOL |
-| SBDH | Standard Business Document Header | [TBD] | PEPPOL |
-| SMP | Service Metadata Provider | [TBD] | eDelivery |
-| SML | Service Metadata Locator | [TBD] | eDelivery |
-| 4-corner-model | eDelivery 4-corner-model | 1. Sender system Corner 1 sends a message through a Service Handler to Access Point Corner 2. 2. Access Point Corner 2 looks up in SML/DNS to find the address of the SMP in which the receiving system's Corner 4 receiver-capabilities are registered. 3. Access Point Corner 2 looks up in SMP to test whether the receiver system Corner 4 has receiver-capabilities corresponding to what is to be sent, as well as to find the address of the Access Point Corner 3 to which the message is to be sent. 4. Access Point Corner 2 sends the message to Access Point Corner 3. 5. Access Point Corner 3 sends the message through the Service Handler to the receiver system Corner 4. | eDelivery |
-
+
+| Acronym | Acronym for | Description | Domain | Relevate links |
+| --- | --- | --- | --- | --- |
+| AP | Access Point | The eDelivery component responsible for exchanging data between Corner 2 and 3 in the 4 Corner model | eDelivery | [TBD] |
+| *DDS* | *Document Sharing Service* | *A national infrastructure for document sharing with an underlying repository structure based on IHE-XDS already exists on the national service platform for the healthcare sector. Document sharing of sent messages is realized through the collection of sent messages from the senders AP to the DDS, where DDS expose the same messsages in the national infrastructure for both healthcare professionals and citizens.* | *NSP* | [TBD] |
+| *EAS* | *EHMI Addressing Service* | *A health addressing service is developed to solve the wellknown challenges for a sender to find the right recipient. The service will draw necessary information from the proper authoritative sources and present this information to the sender of the message, thereby assisting the sender in finding the proper recipient.* | *EHMI* | [EHMI EAS (IG)]*(https://build.fhir.org/ig/medcomdk/dk-ehmi-eas/)* |
+| EDS | *EHMI Delivery Status (Track’n’Trace)* | *The delivery status component collects the delivery status of a sent message at selected points along the delivery path and subsequently exposing the delivery status via a service to both healthcare professionals and citizens, allowing them to follow the status of a message in close to real-time to the benefit of the citizens/patients’ safety.* | EHMI | [TBD] |
+| EER | EHMI Endpoint Register | [TBD] | EHMI | *[EER (IG)](https://build.fhir.org/ig/medcomdk/dk-ehmi-eer/)* |
+| ehmiAck | EHMI Envelope Receipt | [TBD] | EHMI | [TBD] |
+| ehmiSBDH | The EHMI Profile of Standard Business Document Header | *SBDH 'Standard Business Document Header’ is an envelope that can be used in relation to eDelivery and can contain different general message format types, such as EDIFACT, OIO-XML and FHIR. The ehmiSBDH is a customized version of the PEPPOL SBDH. ehmiSBDH is the envelope that is used between the MSHs and ensures the message communication in the EHMI network, so that the EHMI network nodes do not have to deal with anything else than a generic envelope.* | EHMI | *[ehmiSBDH (IG)](https://build.fhir.org/ig/medcomdk/dk-ehmi-sbdh/index.html)* |
+| *ehmiSMP* | *Service Metadata Provider* | [TBD] | *EHMI* | [TBD] |
+| EUA | End User Application | *A message is created in the EUA by the end user/health professional. A message will be sent from the Sender’s EUA to the Receiver’s EUA, and FHIR Acknowledgements will be sent from the Receiver’s EUA to the Original Sender’s EUA. The EUA can be built and hosted together with MSH and AP in various ways.* | EHMI | [TBD] |
+| GS1 | Originally "EAN International" now just GS1 | The organisation responsible for GLN numbers and the original SBDH specification. | GS1 | [Website](https://www.gs1.org/) |
+| IHE | Integrating the Healthcare Enterprise | International organization which creates interoperability in health care systems | EHMI | [TBD] |
+| MSH | Message Service Handler | The functionality who is responsible for wrapping messages into the ehmiSBDH. Can be a module in an EUA or AP, or it can be a stand-alone application | EHMI | [TBD] |
+| OASIS | [TBD] | The Standardisation Organisation responsible for the specifications of AS4, SML, SMP, ebXML | EHMI | [Website](https://www.oasis-open.org/) |
+| PEPPOL | [TBD] | [TBD] | PEPPOL | [TBD] |
+| SBD | Standard Business Document | The wrapper around the SBDH and the Binary content of ehmiSBDH | PEPPOL | [TBD] |
+| SBDH | Standard Business Document Header | *PEPPOL SBDH is an envelope that can be used in relation to eDelivery and can contain different general message format types, such as EDIFACT, OIO-XML and FHIR.* | PEPPOL | [TBD] |
+| SMP | Service Metadata Provider | [TBD] | eDelivery | [TBD] |
+| SML | Service Metadata Locator | [TBD] | eDelivery | [TBD] |
+| 4-corner-model | eDelivery 4-corner-model | 1. Sender system Corner 1 sends a message through a Service Handler to Access Point Corner 2. 2. Access Point Corner 2 looks up in SML/DNS to find the address of the SMP in which the receiving system's Corner 4 receiver-capabilities are registered. 3. Access Point Corner 2 looks up in SMP to test whether the receiver system Corner 4 has receiver-capabilities corresponding to what is to be sent, as well as to find the address of the Access Point Corner 3 to which the message is to be sent. 4. Access Point Corner 2 sends the message to Access Point Corner 3. 5. Access Point Corner 3 sends the message through the Service Handler to the receiver system Corner 4. | eDelivery | [TBD] |
+
+
diff --git a/docs/assets/documents/production-pilot/index.md b/docs/assets/documents/production-pilot/index.md
index 43648a3..e541a13 100644
--- a/docs/assets/documents/production-pilot/index.md
+++ b/docs/assets/documents/production-pilot/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***
-
+
## EHMI Production Pilot Description
@@ -17,20 +15,23 @@
### Introduction
-In MedCom13, MedCom has a joint testing project ’Kommunale prøvesvar på ny infrastruktur’('HomeCareObservations on new infrastructure'), where MedCom's two central modernization tracks are connected: FHIR and EHMI, where both the message communication and the infrastructure are modernized. The modernization is due to the need to improve the quality of e.g. security, transparency, robustness and efficient, international digital message communication. Overall the EHMI Production Pilot is described in the Project Description as part of MedCom13 here
-
-In the project, a test will be carried out in operation in parts of Q1 and Q2 2026.
+*The production pilot for EHMI involves a new FHIR standard for municipal test responses, HomeCareObservation, which is sent via the new underlying EHMI infrastructure on the Health Data Network (DA: Sundhedsdatanettet, SDN). In the production pilot, a test will be carried out in operation in parts of Q1 and Q2 2026 with a limited set of participants, where the HomeCareObservation will be sent from municipal emergency services (EOJ) to general medical practice (LPS) via EHMI. The HomeCareObservation is based on MedCom's existing standard for laboratory responses, and aims to ensure digital and structured exchange of municipal test responses.*
-In the test, the new FHIR standard for municipal test responses, HomeCareObservation, will be sent from municipal emergency services (EOJ) to general medical practice (LPS) via EHMI.
+*In the production pilot, the following EHMI functionalities and services (and more) will be tested:*
+- *document sharing of sent messages and subsequent exposure of the messages in the national infrastructure for both healthcare professionals and citizens for the benefit of the citizens/patients safety.*
+- *collecting delivery status of messages (Track’n’Trace) at selected points along the delivery path and subsequently exposing the delivery status via a service to both healthcare professionals and citizens, allowing them to follow the status of a message in close to real-time.*
+- *addressing via the EHMI Addressing Service*
+- *the EHMI Endpoint Register, a central and independent organizational register of endpoints related to the national SOR*
-The dispatch of the standard must be done via the new underlying eDelivery infrastructure, which is carried out on the *Health Data Network*, **Sundhedsdatanettet**, and there must also be a test of EHMI functionalities such as document sharing and Delivery status (Track'n'Trace).
+*The testing of the EHMI architecture and configuration of the involved components with various message flows will be carried out in operation in parts of Q1 and Q2 2026.*
+Overall the EHMI Production Pilot is described in the Project Description as part of MedCom13 here.
The project has a number of deliverables of specifications, which can be seen below in [EHMI Production Pilot specification schema](#ehmi-production-pilot-specification-schema)
-**Table of contents**
+**Table of content**
- [Project Time schedule](#project-time-schedule)
- [EHMI Core Description](#ehmi-core-description)
@@ -39,14 +40,14 @@ The project has a number of deliverables of specifications, which can be seen be
- [EHMI Delivery Status Security Description](#ehmi-delivery-status-security-description)
- [EHMI Production Pilot specification schema](#ehmi-production-pilot-specification-schema)
- [Changes that EHMI causes on MedCom FHIR IGs and FHIR Profiles (by 2024.04.01)](#changes-that-ehmi-causes-on-medcom-fhir-igs-and-fhir-profiles-by-20240401)
-- [Relevante Links](#relevante-links)
+- [Relevant Links](#relevant-links)
### Project Time schedule
-
+
@@ -65,7 +66,7 @@ EHMI Core is defined as
- eDelivery Access Points (AP)
- eDelivery SML and SMP
-EHMI Core is further described [here](../ecore/index.md)
+EHMI Core specification is further described [here](../ecore/index.md)
@@ -139,11 +140,11 @@ EHMI Delivery Status Security is defined as
Note! All links opens in a new window.
-- Dansk:
+- Danish:
- MedCom: MedCom13 projektbesksrivelse af ’Kommunale prøvesvar på ny infrastruktur’
- SDS: Målbillede for meddelelseskommunikation på sundhedsområdet
- MedCom: Sundhedsdatanettet (SDN)
-- Engelsk:
+- English:
-
- Digital Europe, eDelivery eDelivery
- Digital Europe, eDelivery AP specifikationer
diff --git a/docs/assets/documents/security/index.md b/docs/assets/documents/security/index.md
index 2f656ac..a9a92ba 100644
--- a/docs/assets/documents/security/index.md
+++ b/docs/assets/documents/security/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***
-
+
## EHMI Core Security Description
diff --git a/docs/assets/documents/security/security-specification-of-ehmi-core.md b/docs/assets/documents/security/security-specification-of-ehmi-core.md
index 304b013..c69e130 100644
--- a/docs/assets/documents/security/security-specification-of-ehmi-core.md
+++ b/docs/assets/documents/security/security-specification-of-ehmi-core.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***
-
+
@@ -18,11 +16,11 @@
- [General information about security for components in EHMI](#general-information-about-security-for-components-in-ehmi)
-- [Specifications – security regarding message communication](#specifications---security-regarding-message-communication)
+- [Specifications - security regarding message communication](#specifications---security-regarding-message-communication)
- [Decentralized regarding security](#decentralized-regarding-security)
-- [All components stand-alone – implemented on different servers](#all-components-stand-alone---implemented-on-different-servers)
+- [All components stand-alone - implemented on different servers](#all-components-stand-alone---implemented-on-different-servers)
- [All components stand-alone - grouped together on the same server](#all-components-stand-alone---grouped-together-on-the-same-server)
@@ -34,13 +32,13 @@
- [Sending system stand-alone - MSH/AP build together - all grouped together on the same server](#sending-system-stand-alone---mshap-build-together---all-grouped-together-on-the-same-server)
-- [Sending system/MSH build together – AP stand-alone - implemented on different servers](#sending-systemmsh-build-together---ap-stand-alone---implemented-on-different-servers)
+- [Sending system/MSH build together - AP stand-alone - implemented on different servers](#sending-systemmsh-build-together---ap-stand-alone---implemented-on-different-servers)
-- [Sending system/MSH build together – AP stand-alone - all grouped together on the same server](#sending-systemmsh-build-together---ap-stand-alone---all-grouped-on-the-same-server)
+- [Sending system/MSH build together - AP stand-alone - all grouped together on the same server](#sending-systemmsh-build-together---ap-stand-alone---all-grouped-together-on-the-same-server)
-- [Sending system/MSH build together – MSH/AP build together - implemented on different servers](#sending-systemmsh-build-together---mshap-build-together---implemented-on-different-servers)
+- [Sending system/MSH build together - MSH/AP build together - implemented on different servers](#sending-systemmsh-build-together---mshap-build-together---implemented-on-different-servers)
-- [Sending system/MSH build together – MSH/AP build together - all grouped together on the same server](#sending-systemmsh-build-together---mshap-build-together---all-grouped-on-the-same-server)
+- [Sending system/MSH build together - MSH/AP build together - all grouped together on the same server](#sending-systemmsh-build-together---mshap-build-together---all-grouped-together-on-the-same-server)
- [All components build together](#all-components-build-together)
@@ -74,7 +72,7 @@ A strong authentication of users must take place (according to NIST niveau 3-4 o
-## Specifications – security regarding message communication
+## Specifications - security regarding message communication
First, the general guidelines regarding security in the message flow in EHMI are described. Secondly, it is described for the different scenarios of **interconnections** and **grouping**, cf. [General security definitions regarding components in the delivery chain](#general-security-definitions-regarding-components-in-the-delivery-chain) how the guidelines is implemented in the individual scenarios.
@@ -111,7 +109,7 @@ The following table illustrates in general, how the guidelines are regarding sec
-### All components stand-alone – implemented on different servers
+### All components stand-alone - implemented on different servers
@@ -197,9 +195,9 @@ The following table illustrates in general, how the guidelines are regarding sec
-### Sending system stand-alone - MSH/AP build together – all grouped together on the same server
+### Sending system stand-alone - MSH/AP build together - all grouped together on the same server
-
+
| **EHMI components** | **Subtask** | **Who** |
|-----------------------------------|------------------------------------------------------------------------|----------------------|
@@ -209,7 +207,7 @@ The following table illustrates in general, how the guidelines are regarding sec
-### Sending system/MSH build together – AP stand-alone – implemented on different servers
+### Sending system/MSH build together - AP stand-alone - implemented on different servers
@@ -223,7 +221,7 @@ The following table illustrates in general, how the guidelines are regarding sec
-### Sending system/MSH build together – AP stand-alone – all grouped together on the same server
+### Sending system/MSH build together - AP stand-alone - all grouped together on the same server
@@ -236,7 +234,7 @@ The following table illustrates in general, how the guidelines are regarding sec
-### Sending system/MSH build together – MSH/AP build together - implemented on different servers
+### Sending system/MSH build together - MSH/AP build together - implemented on different servers
Through dialog with the participating parties, we have learned that this scenario is possible. In that case, it is important, that parties with this kind of setup agree on which MSH is the primary with fulfilling the MSH obligations, and which MSH simply forwards information to the next link in the chain. Once this is in place , the following security instructions will apply.
@@ -252,7 +250,7 @@ Through dialog with the participating parties, we have learned that this scenari
-### Sending system/MSH build together – MSH/AP build together – all grouped together on the same server
+### Sending system/MSH build together - MSH/AP build together - all grouped together on the same server
diff --git a/docs/assets/documents/security/security-specification-of-ehmi-eds.md b/docs/assets/documents/security/security-specification-of-ehmi-eds.md
index 7210d51..6237202 100644
--- a/docs/assets/documents/security/security-specification-of-ehmi-eds.md
+++ b/docs/assets/documents/security/security-specification-of-ehmi-eds.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***
-
+
diff --git a/docs/assets/ehmi_ecosystem.md b/docs/assets/ehmi_ecosystem.md
index afc7e1f..877ae6f 100644
--- a/docs/assets/ehmi_ecosystem.md
+++ b/docs/assets/ehmi_ecosystem.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***
-
+
## EHMI Ecosystem sites
diff --git a/docs/assets/images/EHMI Adressing Service.jpg b/docs/assets/images/EHMI Adressing Service.jpg
new file mode 100644
index 0000000..003064f
Binary files /dev/null and b/docs/assets/images/EHMI Adressing Service.jpg differ
diff --git a/docs/assets/images/EHMI Pixi - Addressing Service.png b/docs/assets/images/EHMI Pixi - Addressing Service.png
new file mode 100644
index 0000000..1703ef2
Binary files /dev/null and b/docs/assets/images/EHMI Pixi - Addressing Service.png differ
diff --git a/docs/assets/images/EHMI Pixi - Message delivery.png b/docs/assets/images/EHMI Pixi - Message delivery.png
new file mode 100644
index 0000000..6bb65b0
Binary files /dev/null and b/docs/assets/images/EHMI Pixi - Message delivery.png differ
diff --git a/docs/assets/images/EHMI Pixi - tidslinje.png b/docs/assets/images/EHMI Pixi - tidslinje.png
new file mode 100644
index 0000000..89c34dd
Binary files /dev/null and b/docs/assets/images/EHMI Pixi - tidslinje.png differ
diff --git a/docs/assets/images/ehmi-eas-and-eer.png b/docs/assets/images/ehmi-eas-and-eer.png
new file mode 100644
index 0000000..dae5f36
Binary files /dev/null and b/docs/assets/images/ehmi-eas-and-eer.png differ
diff --git a/docs/assets/images/reliable-messaging-vansenvelope_1160x625.png b/docs/assets/images/reliable-messaging-vansenvelope_1160x625.png
new file mode 100644
index 0000000..4f85628
Binary files /dev/null and b/docs/assets/images/reliable-messaging-vansenvelope_1160x625.png differ
diff --git a/docs/index.md b/docs/index.md
index d0ff6d5..468208d 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -5,38 +5,52 @@
**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***
-
+
+
+
+
+This is the homepage of the entire technical description and all the specifications of EHMI. Some may be described here, while others will be linked to from here. For instance, all HL7 FHIR Specifications is to be found in their respective Implementation Guides (IG) following the standard for publishing by HL7. Other specifications may be shared with our partners in the Danish Health Data Authority and therefore have a format that suits them as well.
+
+To learn about the EHMI project as seen from a project perspective in Danish, please visit Kommunale prøvesvar på ny infrastruktur (opens in a new window)
+
+*In MedCom13, MedCom has a joint testing project ’Kommunale prøvesvar på ny infrastruktur’('HomeCareObservations on new infrastructure'), where MedCom's two central modernization tracks; FHIR and EHMI, are connected and both the message communication and the infrastructure are modernized and tested in interaction. The modernization is due to the need to improve the quality of e.g. security, transparency, robustness and efficient, international digital message communication. The MedCom modernization is described further in MedCom13 here.*
+
+
-This is the homepage of the entire description and all the specifications of EHMI. Some may be described here, while others will be linked to from here. For instance, all HL7 FHIR Specifications is to be found in their respective Implementation Guides (IG) following the standard for publishing by HL7. Other specifications may be shared with our partners in the Danish Health Data Authority and therefore have a format that suits them as well.
+*EHMI (Enhanced Healthcare Messaging Infrastructure) is built on eDelivery, which is the core of future message communication. But EHMI involves several additional elements and services compared to eDelivery, such as support of message sharing, improved handling of addressing via a health addressing service (EHMI Addressing Service, EAS) and delivery status (EHMI Delivery Status, EDS) (also called Track'n'Trace). 'The Architectural Vision' (DA: Målbilledet for meddelelseskommunikation på sundhedsområdet) forms the framework and guideline for testing EHMI. 'The Architectural Vision' can be read here.*
-**For now, specifications published here at 01-04-2024 will focus on the Production pilot for EHMI and are therefore narrowed down to show only what is currently ready. By the end of Q2 2024 several more specifications and descriptions will be released on these sites and make the documentation more comprehensive.**
+**For now, specifications published here at 01-04-2024 will focus on the Production pilot for EHMI and are therefore narrowed down to show only what is currently ready. Later in 2024 several more specifications and descriptions will be released on these sites and make the documentation more comprehensive.**
**Table of content for Production pilot for EHMI**
+- EHMI Production Pilot Description
+ - EHMI Core Description
+ - EHMI Core Security Description
+ - EHMI Delivery Status Description
+ - EHMI Delivery Status Security Description
+
+**Table of content for EHMI Specifications (published April 1, 2024)**
+- EHMI Core
+ - ehmiSBDH
+ - ehmiSMP
+- EHMI Delivery Status
+ - EHMI Delivery Status
+- EHMI Addressing Service*
+- EHMI Endpoint Register*
+- EHMI Governance*
+- EHMI Security
+- EHMI Glossary
+- EHMI Ecosystem
+
+
+
-- [EHMI Production Pilot Description](/assets/documents/production-pilot/index.md)
- - [EHMI Core Description](/assets/documents/production-pilot/index.md#ehmi-core-description)
- - [EHMI Core Security Description](/assets/documents/production-pilot/index.md#ehmi-core-security-description)
- - [EHMI Delivery Status Description](/assets/documents/production-pilot/index.md#ehmi-delivery-status-description)
- - [EHMI Delivery Status Security Description](/assets/documents/production-pilot/index.md#ehmi-delivery-status-security-description)
-
-- EHMI Specifications (published April 1, 2024)
- - EHMI Core
- - [EHMI Core](/assets/documents/ecore/index.md)
- - [ehmiSBDH](/assets/documents/ecore/ehmiSBDH/index.md)
- - [ehmiSMP](/assets/documents/ecore/ehmiSMP/index.md)
- - EHMI Delivery Status (EDS)
- - [EHMI Delivery Status (EDS)](/assets/documents/eds/index.md)
- - EHMI Security
- - [EHMI Security](/assets/documents/security/index.md)
diff --git a/docs/index2.md b/docs/index2.md
deleted file mode 100644
index 2d3e0b9..0000000
--- a/docs/index2.md
+++ /dev/null
@@ -1,14 +0,0 @@
-# Welcome to EHMI - MedCom's Enhanced Healthcare Messaging Infrastructure
-
-**Table of contents for stable documentation**
-
-- EHMI Core
- - [EHMI Message sending (eDelivery) and sharing (XDS)](/assets/documents/ecore/index.md)
-- EHMI enhanced
- - [EHMI Delivery Status (EDS)](/assets/documents/eds/index.md)
- - [EHMI Endpoint register (EER)](/assets/documents/eer/index.md)
- - [EHMI Healthcare adressing (EAS)](/assets/documents/eas/index.md)
-- EHMI Security
- - [EHMI Security](/assets/documents/security/index.md)
-- EHMI Governance
- - [EHMI Governance](/assets/documents/egov/index.md)
+
**The whole specification for EHMI Addressing Service (EAS) can be found**
here
-
+
+
+