EHMI Delivery Status (EDS)
1.0.0 - release Denmark flag

EHMI Delivery Status (EDS), 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-eds/ and changes regularly. See the Directory of published versions

Home

Official URL: http://medcomehmi.dk/ig/eds/ImplementationGuide/dk.ehmi.eds Version: 1.0.0
Active as of 2025-02-10 Computable Name: EHMIEDSIG

EHMI Delivery Status (EDS)


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.

EHMI Delivery Status (EDS)


EDS is using some basic abbreviations throughout the specification, the most common are:

  • EUA = End User Application
  • MSH = Message Service Handler
  • AP = Access Point (eDelivery)

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:

EHMI Delivery Status (EDS) - 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.

  • "Raw IG view" is as explained above the raw IG manner look of an example
  • "Raw server view" opens a call to a HAPI FHIR server, which produces the get operation on the server for that particular instance
  • "Graphical view" opens an application called vhewer.com, which produces a raw graphical context for the example. In the background it runs the same call as the "Raw server view" does, just producing a more human friendly view to the user

1. Scenarios for the primary MedCom message and the corresponding MedCom Acknowledgement message in EHMI


2. Scenarios for the ehmiSBDH Acknowledgement in EHMI


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.

Security for the calls to EDS

The calls for EDS are always produced in a security context.

The calls for EDS are described here