DK EHMI SBDH IG
1.0.0 - release
DK EHMI SBDH IG, 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-sbdh/ and changes regularly. See the Directory of published versions
Official URL: http://medcomehmi.dk/ig/dk-ehmi-sbdh/ImplementationGuide/dk-ehmi-sbdh | Version: 1.0.0 | |||
Active as of 2025-02-02 | Computable Name: DKEHMISBDHIG |
The EHMI Standard Business Document Header (ehmiSBDH) is a customized version of the PEPPOL SBDH, which again is an extension of the original GS1 SBDH.
It is developed to serve as an envelope in message and document exchanges, the version for PEPPOL especially for wrapping the message/document and handling the metadata related to it in an eDelivery environment.
In relation to EHMI Core:
In relation to EHMI Delivery Status:
ehmiSBDH is in EHMI called ehmiSBDH due to constraints EHMI lay on the GS1- and PEPPOL-specifications, none of which is breaking to a validation against the original specification with the PEPPOL extensions
ehmiSBDH can therefore be send and delivered through the eDelivery Network in EHMI Core in all use cases, where ehmiSbdhserves the entire EHMI ecosystem.
ehmiSBDH wraps the bidirectional message with clinical content between the Message Service Handlers (MSH) and serve as a neutral container for whatever MedCom Message, that is being send. If it is a FHIR, OIOXml or Edifact message, ehmiSBDH can wrap it and due to extensive extraction of metadata from the message also serve the ground for
An ehmiSBDH Acknowledgement is basically just a ehmiSBDH wrapping the ehmiSBDH EnvelopeReceipt like it would wrap any MedCom Message. The configuration of especially the BusinessScopes is a little different, but technically it is
All ehmiSBDH xsd-files can be found via the download-page, but an overview of what they most importantly contain can be seen here:
(all files open in new window)
This specification of ehmiSBDH covers what is needed to understand and work with for EHMI Core and its stations of MSHs. But there is still room for more service and it is planned to deliver more huidance on how to map from one format to another in the MSHs. FHIR StructureMappings delivers a useful tool to do that and as this IG lives over time more and more FHIR StructureMappings will find their way into this IG. FHIR StructureMappings are not limited to handle resources of FHIR profiles, but can handle practically all kinds of formats.
For a number of different mappings to and from ehmiSBDH and/or MedCom Messaging Message, there will be developed a number of FHIR StructureMappings in order for the suppliers to better understand and potentially automate some tasks around mappings.
There has already been developed one in its initial phase, which is:
The StructureMappings in the pipeline are: