DK EHMI Delivery Status (EDS)
1.0.2-draft - draft
DK EHMI Delivery Status (EDS)
1.0.2-draft - draft
DK EHMI Delivery Status (EDS), published by MedCom. This guide is not an authorized publication; it is the continuous build for version 1.0.2-draft built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/medcomdk/dk-ehmi-eds/ and changes regularly. See the Directory of published versions
| Official URL: http://medcomehmi.dk/ig/eds/ImplementationGuide/dk.ehmi.eds | Version: 1.0.2-draft | |||
| Draft as of 2025-12-03 | Computable Name: EHMIEDSIG | |||
The EHMI Delivery Status (EDS) Implementation Guide is a Content Profile that defines some basic and reusable logging patterns based on the FHIR AuditEvent Resource, that is used between an EDS device client and the EDS server.
EDS is inspired by IHE Basic Audit Log Patterns (IHE BALP) Implementation Guide, which is a Content Profile that defines some basic and reusable AuditEvent patterns.
A focus is on enabling Privacy centric AuditEvent logs that hold well-formed indication of message communication around a Patient, when they are the subject of a messaging event being recorded on the EDS Server.
EDS is using some basic abbreviations throughout the specification, the most common are:
EDS is used in the EHMI messaging flow like above.
In a more technical outline of the above, it is presented here in a sequence diagram:
Calls to EDS are produced in different scenarios basically as shown graphically above and in example instances below.
For each scenario there are 2 examples which opens in a new window,"Graphical view" and "Raw server view". Please be aware that it can take a while to open, as it calls an external server to render the fhir examples. The last view, "Raw IG view" opens the page in this IG, where the example is shown in ordinary IG-manner.
| # | usecase | Graphical View | Raw view(server) | Raw View(IG) |
|---|---|---|---|---|
| 1.1 | When a message is created and sent in an EUA (The user has hit the "sent button") | EDS-PDS-01.1 | EDS-PDS-01.1 | EDS-PDS-01.1 |
| 2.1 | When the message is received by the sending MSH | EDS-PDS-02.1 | EDS-PDS-02.1 | EDS-PDS-02.1 |
| 2.2 | When the message is actually sent again by the sending MSH | EDS-PDS-02.2 | EDS-PDS-02.2 | EDS-PDS-02.2 |
| 3.1 | When the message is received by the sending AP | EDS-PDS-03.1 | EDS-PDS-03.1 | EDS-PDS-03.1 |
| 3.2 | When the message is actually sent again by the sending AP | EDS-PDS-03.2 | EDS-PDS-03.2 | EDS-PDS-03.2 |
| 4.1 | When the message is received by the receiving AP | EDS-PDS-04.1 | EDS-PDS-04.1 | EDS-PDS-04.1 |
| 4.2 | When the message is actually sent again by the receiving AP | EDS-PDS-04.2 | EDS-PDS-04.2 | EDS-PDS-04.2 |
| 5.1 | When the message is received by the receiving MSH | EDS-PDS-05.1 | EDS-PDS-05.1 | EDS-PDS-05.1 |
| 5.2 | When the message is actually sent again by the receiving MSH | EDS-PDS-05.2 | EDS-PDS-05.2 | EDS-PDS-05.2 |
| 6.1 | When the message is actually received and finalized by the receiving EUA | EDS-PDS-06.1 | EDS-PDS-06.1 | EDS-PDS-06.1 |
| # | usecase | Graphical View | Raw view(server) | Raw View(IG) |
|---|---|---|---|---|
| 7.1 | When the original ehmiSBDH envelope has been received in the original receiving MSH (at 5.1 in the above use case) and the original Receiving MSH creates and sends an ehmiSBDH Acknowledgement |
EDS-BDS-07.1 | EDS-BDS-07.1 | EDS-BDS-07.1 |
| 8.1 | When the ehmiSBDH Acknowledgement is received by the original Receiving AP | EDS-BDS-08.1 | EDS-BDS-08.1 | EDS-BDS-08.1 |
| 8.2 | When the ehmiSBDH Acknowledgement is actually sent again by the original Receiving AP | EDS-BDS-08.2 | EDS-BDS-08.2 | EDS-BDS-08.2 |
| 9.1 | When the ehmiSBDH Acknowledgement is received by the original Sending AP | EDS-BDS-09.1 | EDS-BDS-09.1 | EDS-BDS-09.1 |
| 9.2 | When the ehmiSBDH Acknowledgement is actually sent again by the original Sending AP | EDS-BDS-09.2 | EDS-BDS-09.2 | EDS-BDS-09.2 |
| 10.1 | When the ehmiSBDH Acknowledgement is received and finalized by the original Sending MSH | EDS-BDS-10.1 | EDS-BDS-10.1 | EDS-BDS-10.1 |
| # | usecase | Graphical View | Raw view(server) | Raw View(IG) |
|---|---|---|---|---|
| 11.1 | When an Acknowledgement message is created and sent in an EUA (Automatically) | EDS-BDS-11.1 | EDS-BDS-11.1 | EDS-BDS-11.1 |
| 12.1 | When the Acknowledgement message is received by the original Receiving MSH | EDS-BDS-12.1 | EDS-BDS-12.1 | EDS-BDS-12.1 |
| 12.2 | When the Acknowledgement message is actually sent again by the original Receiving MSH | EDS-BDS-12.2 | EDS-BDS-12.2 | EDS-BDS-12.2 |
| 13.1 | When the Acknowledgement message is received by the original Receiving AP | EDS-BDS-13.1 | EDS-BDS-13.1 | EDS-BDS-13.1 |
| 13.2 | When the Acknowledgement message is actually sent again by the original Receiving AP | EDS-BDS-13.2 | EDS-BDS-13.2 | EDS-BDS-13.2 |
| 14.1 | When the Acknowledgement message is received by the original Sending AP | EDS-BDS-14.1 | EDS-BDS-14.1 | EDS-BDS-14.1 |
| 14.2 | When the Acknowledgement message is actually sent again by the original Sending AP | EDS-BDS-14.2 | EDS-BDS-14.2 | EDS-BDS-14.2 |
| 15.1 | When the Acknowledgement message is received by the original Sending MSH | EDS-BDS-15.1 | EDS-BDS-15.1 | EDS-BDS-15.1 |
| 15.2 | When the Acknowledgement message is actually sent again by the original Sending MSH | EDS-BDS-15.2 | EDS-BDS-15.2 | EDS-BDS-15.2 |
| 16.1 | When the Acknowledgement message is actually received and finalized by the original Sending EUA | EDS-BDS-16.1 | EDS-BDS-16.1 | EDS-BDS-16.1 |
As the EUA, MSH and AP can be built and hosted together in various ways, this is just the maximum possible scenarios, and the real scenarios will most likely be less than shown here.
The calls for EDS are always produced in a security context.