DK EHMI SBDH IG, published by MedCom. This guide is not an authorized publication; it is the continuous build for version 2.0.1 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

Ehmi SBDH

ehmiSbdhprofile of Standard Business Document Header

ehmiSbdhprofile of Standard Business Document Header

ehmiSbdh– General elements

The StandardBusinessDocumentHeader (SBDH) is an envelope specification issued by GS1 and profiled for use in PEPPOL. It is supported by eDelivery's Access Points (AP) according to the AS4 protocol. We follow the conventions, which are laid out in PEPPOL's profiling, but also we are extending it to be able to take care of the health area. However, ehmiSBDH is nothing without a surrounding container, called StandardBusinessDocument (SBD).

StandardBusinessDocument

StandardBusinessDocument is, as mentioned, SBDH's surrounding container, and is a wrapper around SBDH, and contains only two elements:

StandardBusinessDocumentHeader
BinaryContent (base64 encoded)

Although the StandardBusinessDocument, as such, is the envelope, the term ehmiSBDH is generally used for the entire envelope, since it is this content that is of particular interest in the message exchange. BinaryContent is the element that contains a base64-encoded message or Acknowledgement for a sent SBDH.

EHMI StandardBusinessDocument

The content of ehmiSBDH is largely determined by how

the same information is registered in EER
the same information is registered in SMP
the context is to NSP DokumentDelingService, DDS
the context is for ehmiSBDH EnvelopeReceipt
the same information is registered in EDS

ehmiSBDH has a structure that is generally divided into the following elements:

HeaderVersion
Sender
Receiver
DocumentInformation
Manifest
BusinessScope

ehmiSBDH for a MedcomMessagingMessage and a MedCom Acknowledgement

In an ehmiSBDH for a MedCom Message and a MedCom Acknowledgement, the following metadata can be included:

General ehmiSBDH metadata
Metadata for eDelivery general message communications
Health Message Communication Metadata
XDS Metadata for Document Sharing
Metadata for MedCom Statistics
Metadata for Reliable messaging - BusinessService Request

ehmiSBDH for an ehmiSBDH EnvelopeReceipt

In an ehmiSBDH for an ehmiSBDH EnvelopeReceipt there is the following metadata:

General ehmiSBDH metadata
Metadata for eDelivery general message communications
Health Message Communication Metadata
Metadata for MedCom Statistics
Metadata for Reliable messaging - BusinessService Response

ehmiSbdh– general fixed elements

SBDH's general elements are illustrated in the figure below.

EHMI StandardBusinessDocument

BusinessScope has, however, been given its own chapter, as it differs significantly from the others. In the following, the general ehmiSBDH-elements are presented for the provisionally 2 message types that EHMI operates with:

FHIR
ehmiSBDH EnvelopeReceipt

Where applicable, the general elements will be divided into subsections that describe the path to the value of that element in the respective message types. Where most elements have a general focus on message exchange in general and the interaction with SMP, BusinessScope in particular gives a health-oriented imprint in the specification.

HeaderVersion

Always

<HeaderVersion>1.0</HeaderVersion>

Sender

ehmiSbdhSender contains only the mandatory element Identifier.

Identifier

Contains the attribute Authority, which according to [Policy_identifiers], POLICY 6 Numeric Codes for Issuing Agencies, always has the value: "iso6523-actorid-upis"

Identifier represents GLN of sender where

The value 0088: reflects that the type is GLN.
The value after 0088: reflects the GLN number.
“0088:”+[GLN-number]

If the MedCom Message is of type FHIR

If the MedCom Message is of type FHIR, then always in the following format:

Bundle.entry[0].resource.sender.reference.resolve().identifier.where(system = 'https://www.gs1.org/gln').value

Sender example

Regardless of the message type, it will always result in the following Sender/Identifier, where the value after 0088: will of course vary.

<Sender>
    <Identifier Authority="iso6523-actorid-upis">
        0088:5790000121526
    </Identifier>
</Sender>

Receiver

ehmiSbdhReceiver contains only the mandatory element Identifier.

Identifier

Contains the attribute Authority, which according to [Policy_identifiers], POLICY 6 Numeric Codes for Issuing Agencies, always has the value: "iso6523-actorid-upis"

Identifier represents GLN of sender where

The value 0088: reflects that the type is GLN.
The value after 0088: reflects the GLN number.
“0088:”+[GLN-number]
'

If the MedCom Message is of type FHIR

If the MedCom Message is of type FHIR, then always in the following format:

<Receiver>
    <Identifier Authority="iso6523-actorid-upis">    
        “0088:”+[Bundle.entry[0].resource.destination.receiver.reference.resolve().identifier.where(system = 'https://www.gs1.org/gln').value]
    </Identifier>
</Receiver>

Receiver example:

Regardless of the message type, it will always result in the following Receiver/Identifier, where the value after 0088: will of course vary.

<Receiver>
    <Identifier Authority="iso6523-actorid-upis">0088:5790000201389    </Identifier>
</Receiver>

DocumentInformation

Standard

EHMI operates with 4 types of standards, each of which has its own prefix according to the standard

FHIR
eb
OIOXML (described in a later version of the standard)
Edifact (described in a later version of the standard)

If the MedCom Message is of type FHIR

If the MedCom Message is of type FHIR, then always in the following format:

<DocumentInformation>
    <Standard>
        [Bundle.entry[0].resource.event.as(Coding).code]
    </Standard>
</DocumentInformation>

Message example:

<DocumentInformation>
    <Standard>homecareobservation-message</Standard>
</DocumentInformation>

If the MedCom Message is of type ehmiSBDH EnvelopeReceipt

Always

<DocumentInformation>
    …
    <Standard>
        [bpssignal:ReceiptAcknowledgement@xmlns:bpssignal[standard]]
    </Standard>
    …
</DocumentInformation>

SBDH-envelope example:

<DocumentInformation>
    …
    <Standard>ehmisbdh-acknowledgement</Standard>
    …
</DocumentInformation>

TypeVersion

Is the contained message version on the form

<DocumentInformation>
    …
    <TypeVersion>[Path to the type version]</TypeVersion>
    …
</DocumentInformation>

If the MedCom Message is of type FHIR

If the MedCom Message is of type FHIR, then always in the following format:

<DocumentInformation>
    …
    <TypeVersion>
        [Bundle.entry[0].resource.MessageHeader.definition[versionssuffiks]]
    </TypeVersion>
    …
</DocumentInformation>

Message example:

<DocumentInformation>
    …
    <TypeVersion>1.0</TypeVersion>
    …
</DocumentInformation>

If the contained message is of type ehmiSBDH EnvelopeReceipt, always

<DocumentInformation>
    …
    <TypeVersion>
        [bpssignal:ReceiptAcknowledgement@xmlns:bpssignal[version]]
    </TypeVersion>
    …
</DocumentInformation>

ehmiSBDH EnvelopeReceipt example:

<DocumentInformation>
    …
    <Type>ReceiptAcknowledgement</Type>
    …
</DocumentInformation>

InstanceIdentifier

The InstanceIdentifier will be generated by the sending MSH and is regardless of whether a message or an ehmiSBDH EnvelopeReceipt is generated.

<InstanceIdentifier>[generated UUID]</InstanceIdentifier>

example:

<!-- [generated UUID] -->	
<DocumentInformation>
	…
    <InstanceIdentifier>b7faca8e-e908-47bb-b323-0eb8a854c558</InstanceIdentifier>
    …
</DocumentInformation>

Type

Message:

<DocumentInformation>
    …
    <Type>[Message-starttag]</Type>
    …
</DocumentInformation>

If the MedCom Message is of type FHIR

If the MedCom Message is of type FHIR, then always in the following format:

<DocumentInformation>
    …
    <Type>[Bundle]</Type>
    …
</DocumentInformation>

Message example:

<DocumentInformation>
    …
    <Type>Bundle</Type>
    …
</DocumentInformation>

If the message is of type ehmiSBDH EnvelopeReceipt:

<DocumentInformation>
    …
    <Type>[EnvelopeReceipt type]</Type>
    …
</DocumentInformation>

Receipt type has the following scope: Scope for these ebXML Business Process Signals is:

ReceiptAcknowledgement
ReceiptException
AcceptanceAcknowledgement (NOTE! not used in the production Production Pilot)

EnvelopeReceipt example:

<DocumentInformation>
    …
    <Type>ReceiptAcknowledgement</Type>
    …
</DocumentInformation>

MultipleType

Always false:

<DocumentInformation>
    …
    <MultipleType>false</MultipleType>
    …
</DocumentInformation>

CreationDateAndTime

Always in this format: [YYYY-MM-DD]T[TT-MM-SS]+[offset-to-UTC]

<DocumentInformation>
    …
    <CreationDateAndTime>
        [YYYY-MM-DD]T[TT-MM-SS]+[offset-to-UTC] 
    </CreationDateAndTime>
    …
</DocumentInformation>

example:

<DocumentInformation>
    …
    <CreationDateAndTime>2025-04-01T16-19-00+01:00</CreationDateAndTime>
    …
</DocumentInformation>

DocumentInformation - aggregate message example

<DocumentIdentification>
    <Standard>homecareobservation-message</Standard>
    <TypeVersion>1.2</TypeVersion>
    <InstanceIdentifier>9a6ff822-08de-5a6f-9670-9fa4b9d2f0dc</InstanceIdentifier>
    <Type>Bundle</Type>
    <MultipleType>false</MultipleType>
    <CreationDateAndTime>2025-04-01T16-19-00+01:00</CreationDateAndTime>
</DocumentIdentification>

DocumentInformation - aggregate EnvelopeReceipt example

<DocumentIdentification>
    <Standard>ehmisbdh-acknowledgement</Standard>
    <TypeVersion>ebbp-signals-2.0</TypeVersion>
    <InstanceIdentifier>9a6ff822-08de-5a6f-9670-9fa4b9d2f0dx</InstanceIdentifier>
    <Type>ReceiptAcknowledgement</Type>
    <MultipleType>false</MultipleType>
    <CreationDateAndTime>2025-04-01T16-19-00+01:00</CreationDateAndTime>
</DocumentIdentification>

Manifest (deliberately omitted in the Production Pilot version)

ehmiSbdhBusinessScopes

ehmiSbdhBusinessScopes is the SBDH's name-value pair construction characterized by an identifier. Name is expressed by the Type element and value is expressed by the InstanceIdentifier. These two change for each scope, while the Identifier in the EHMI context is always the same: dk-medcom-messaging. In the following, they are reviewed in the logical contexts in which they appear.

ehmiSbdhBusinessScope

eDelivery message communication

In context of SMP

In the eDelivery communication, the SBDH's Scope structure with the two types, DOCUMENTID and PROCESSID, is the direct relation to the SMP's DOCUMENTID and PROCESSID. Furthermore, the context also includes the elements already reviewed in the section on Receiver. In the following, precisely these two types of elements in the SBDH's overall BusinessScope structure are described. The scopes, DOCUMENTID and PROCESSID, are permanently defined scopes by PEPPOL, which ensure a unique relationship to SMP. DOCUMENTID and PROCESSID are used in EHMI with the same precision as in PEPPOL, so that consistency is ensured in how the values are expressed across PEPPOL and EHMI. DOCUMENTID and PROCESSID are used by the APs together with recipient's Receiver/Identifier to look up recipient's eDelivery address in SMP with a unique response as a result.

EHMI StandardBusinessDocument

DOCUMENTID

The value in InstanceIdentifier is identical to the corresponding SMP record. The values are taken from MedCom's standard catalog and are here represented by the values that indicate the type of message. See bookmark: [DKEDEL_DT_CodeList]

DOCUMENTID for MedCom Messaging Messages

<Scope> 
    <Type>DOCUMENTID</Type> 
    <InstanceIdentifier>
        urn:dk:healthcare:prod:messaging:medcom:fhir:structuredefinition::[Bundle/MessageHeader/eventCoding/code.value]##urn:dk:medcom:fhir:[Bundle/MessageHeader/eventCoding/code.value]::[Bundle/MessageHeader/definition/[value of MessageDefinition version-part]]
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

MedcomMessagingMessage example

<Scope> 
    <Type>DOCUMENTID</Type> 
    <InstanceIdentifier>
        urn:dk:healthcare:medcom:messaging:fhir:structuredefinition::homecareobservation-message##urn:dk:medcom:fhir:homecareobservation-message::1.2
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

MedcomMessagingMessage Acknowledgement example DOCUMENTID urn:dk:healthcare:medcom:messaging:fhir:structuredefinition::acknowledgement-message##urn:dk:medcom:fhir:acknowledgement-message::2.0 dk-medcom-messaging

DOCUMENTID for ehmiSBDH EnvelopeReceipt

<Scope> 
    <Type>DOCUMENTID</Type> 
    <InstanceIdentifier>
        urn:dk:healthcare:prod:messaging:oasis:ebxml:schema:xsd::[bpps-signaltype]##urn:dk:medcom:[bpps-signaltype]::[version]
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

DOCUMENTID ehmiSBDH EnvelopeReceipt example:

<Scope> 
    <Type>DOCUMENTID</Type> 
    <InstanceIdentifier>
       urn:dk:healthcare:messaging:oasis:ebxml:schema:xsd::ehmisbdh-acknowledgement##urn:dk:ehmi:sbdh:ehmisbdh-acknowledgement::1.0
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

PROCESSID

The value in InstanceIdentifier is identical to the corresponding ProcessId SMP record. In the 4-corner model, the SDN emergency registration is also sent to the SMP, so that the sender's AP can look up the final receiver, also called the final recipient, correctly in the SMP. PROCESSID [Process Identifier value] dk-medcom-messaging

PROCESSID for SDN example

sdn-emergence is the InstanceIdentifier used to relate a message's emergence on SDN, SundhedsDataNettet.

Always PROCESSID urn:ehmi:sdn-emergence dk-medcom-messaging

Health message communication

Scope – message metadata - who

EHMI StandardBusinessDocument

PATIENTID

The patient's Civil Registration Number, CPR, is included as an identifier for use in EDS Shipment status and XDS metadata.

<Scope>
    <Type>PATIENTID</Type>
    <InstanceIdentifier>
        [Bundle.entry.resource.ofType(Patient).identifier.where(system=’urn:oid:1.2.208.176.1.2’).value]
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

PATIENTID for MedComMessagingMessages - example:

<Scope>
    <Type>PATIENTID</Type>
    <InstanceIdentifier>
        0101010227
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

SENDERID

Sender's SOR identifier is used for EDS Shipment status.

SENDERID for MedComMessagingMessages:

<Scope>
    <Type>SENDERID</Type> 
    <InstanceIdentifier>
        [Bundle.entry[0].resource.sender.reference.resolve().identifier.where(system = 'urn:oid:1.2.208.176.1.1').value]
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

SENDERID for MedComMessagingMessages - example:

<Scope>
    <Type>SENDERID</Type> 
    <InstanceIdentifier>1170101</InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

RECEIVERID

Recipient's SOR identifier is used for EDS Shipment status.

RECEIVERID for MedComMessagingMessages:

<Scope>
    <Type>RECEIVERID</Type> 
    <InstanceIdentifier>
        [Bundle.entry[0].resource.destination.receiver.reference.resolve().identifier.where(system = 'urn:oid:1.2.208.176.1.1').value]
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

RECEIVERID for MedComMessagingMessages - example:

<Scope>
    <Type>RECEIVERID</Type> 
        <InstanceIdentifier>1170102</InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

Scope – message metadata - what

EHMI StandardBusinessDocument

MESSAGEIDENTIFIER

MESSAGEIDENTIFIER is the MessageHeader.id of the contained message, i.a. for use in collection of EDS shipping status.

<Scope>
    <Type>MESSAGEIDENTIFIER</Type> 
    <InstanceIdentifier>
        [Bundle.entry[0].resource.id]
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

MESSAGEIDENTIFIER example:

<Scope>
    <Type>MESSAGEIDENTIFIER</Type> 
    <InstanceIdentifier>f06c1ac8-6096-5178-a380-2831d2456986</InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

If the MedCom Message is of type ehmiSBDH EnvelopeReceipt

<Scope>
    <Type>MESSAGEIDENTIFIER</Type> 
    <InstanceIdentifier>
        [generated]
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

MESSAGEIDENTIFIER example:

<Scope>
    <Type>MESSAGEIDENTIFIER</Type> 
    <InstanceIdentifier>
        f06c1ac8-6096-5178-a380-2831d2456986 
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

MESSAGEENVELOPEIDENTIFIER

MESSAGEENVELOPEIDENTIFIER is the contained message's Bundle.id, i.a. for use in collection of EDS shipping status.

<Scope>
    <Type>MESSAGEENVELOPEIDENTIFIER</Type> 
    <InstanceIdentifier>
        [Bundle.id]
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

MESSAGEENVELOPEIDENTIFIER example:

<Scope>
    <Type>MESSAGEENVELOPEIDENTIFIER</Type> 
    <InstanceIdentifier>
        f06c1ac8-6096-5178-a380-2831d2456986
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

ORIGINALMESSAGEIDENTIFIER

ORIGINAL MESSAGE IDENTIFIER is the MESSAGE IDENTIFIER of the original contained message, i.a. for use in collection of EDS shipping status.

Is only relevant when SBD/SBDH/DocumentInformation/Standard.value = “ebbp-signals” and SBD/SBDH/DocumentInformation/Standard.value = "acknowledgement-message"

<Scope>
    <Type>ORIGINALMESSAGEIDENTIFIER</Type> 
    <InstanceIdentifier>
    Den originale meddelelses InstanceIdentifier
    [SBD/SBDH/BusinessScope/Scope[MESSAGEIDENTIFIER]/InstanceIdentifier.value]
    </InstanceIdentifier>
     <Identifier>dk-medcom-messaging</Identifier>
</Scope>

ORIGINALMESSAGEIDENTIFIER example:

<Scope>
    <Type>ORIGINALMESSAGEIDENTIFIER</Type> 
    <InstanceIdentifier>
        f06c1ac8-6096-5178-a380-2831d2456986
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

ORIGINALMESSAGEENVELOPEIDENTIFIER

The ORIGINAL MESSAGEENVELOPEIDENTIFIER is the contained message's Bundle.id, i.a. for use in collection of EDS shipping status.

Is only relevant when SBD/SBDH/DocumentInformation/Standard.value = “ebbp-signals” and SBD/SBDH/DocumentInformation/Standard.value = "acknowledgement-message"

<Scope>
    <Type>ORIGINALMESSAGEENVELOPEIDENTIFIER</Type> 
    <InstanceIdentifier>
        [Bundle.id]
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

ORIGINALMESSAGEENVELOPEIDENTIFIER example:

<Scope>
    <Type>ORIGINALMESSAGEENVELOPEIDENTIFIER</Type> 
    <InstanceIdentifier>
        f06c1ac8-6096-5178-a380-2831d2456986
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

ORIGINALMESSAGESTANDARD

ORIGINAL MESSAGE STANDARD is the original contained message standard, i.a. for use in collection of EDS shipping status.

Is only relevant when SBD/SBDH/DocumentInformation/Standard.value = “ebbp-signals” or SBD/SBDH/DocumentInformation/Standard.value = "acknowledgement-message"

<Scope>
    <Type>ORIGINALMESSAGESTANDARD</Type> 
    <InstanceIdentifier>
        The original message standard [SBD/SBDH/DocumentInformation/Standard.value] 
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

ORIGINALMESSAGESTANDARD example for “ebbp-signals”:

<Scope>
    <Type>ORIGINALMESSAGESTANDARD</Type> 
    <InstanceIdentifier>homecareobservation-message</InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

ORIGINALMESSAGESTANDARD example for "acknowledgement-message":

<Scope>
    <Type>ORIGINALMESSAGESTANDARD</Type> 
    <InstanceIdentifier>unknown</InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

ORIGINALMESSAGEVERSION

ORIGINAL MESSAGE VERSION is the version of the original contained message, i.a. for use in collection of EDS shipping status.

Is only relevant when SBD/SBDH/DocumentInformation/Standard.value = “ebbp-signals” or SBD/SBDH/DocumentInformation/Standard.value = "acknowledgement-message"

<Scope>
    <Type>ORIGINALMESSAGEVERSION</Type> 
    <InstanceIdentifier>
        [SBD/SBDH/DocumentInformation/TypeVersion.value]
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

ORIGINALMESSAGEVERSION example for “ebbp-signals”:

<Scope>
    <Type>ORIGINALMESSAGEVERSION</Type> 
    <InstanceIdentifier>1.2</InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

ORIGINALMESSAGEVERSION example for "acknowledgement-message":

<Scope>
    <Type>ORIGINALMESSAGEVERSION</Type> 
    <InstanceIdentifier>unknown</InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

ORIGINALENVELOPEIDENTIFIER

The ORIGINALENVELOPEIDENTIFIER is the original ehmiSBDH-envelopes InstanceIdentifier, i.a. for use in collection of EDS shipping status.

Is only relevant when SBD/SBDH/DocumentInformation/Standard.value = “ebbp-signals”

<Scope>
    <Type>ORIGINALENVELOPEIDENTIFIER</Type> 
    <InstanceIdentifier>
        [SBD/SBDH/DocumentInformation/InstanceIdentifier.value]
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

ORIGINALENVELOPEIDENTIFIER example:

<Scope>
    <Type>ORIGINALMESSAGEIDENTIFIER</Type> 
    <InstanceIdentifier>
        f06c1ac8-6096-5178-a380-2831d2456986
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

MedCom Statistics

StatisticalInformation

The StatisticalInformation is the designated elements of a MedCom Message that has to be gathered for MedCom to monitoring which messages are sent over the EHMI Network.

The designated elements of a concrete MedcomMessagingMessage can be found here

<Scope>
    <Type>StatisticalInformation</Type> 
    <InstanceIdentifier>
        "MCM:"+[SBD/SBDH/DocumentInformation/Standard]+(if designated postfix-value has been made for this message standard, then "#"+[designated postfix-values from a concrete message] else N/A)
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

StatisticalInformation example 1:

<Scope>
    <Type>StatisticalInformation</Type> 
    <InstanceIdentifier>
        MCM:homecareobservation-message
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

StatisticalInformation example 2:

<Scope>
    <Type>StatisticalInformation</Type> 
    <InstanceIdentifier>
        MCM:carecommunication-message#carecoordination
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

XDS-Metadata

EHMI StandardBusinessDocument

The following reflects the DokumentDelingsServicen on NSP's needs for XDS metadata. This scope type is set on the exchange with the document sharing services.

This scope only applies to MedCom Messages, not MedCom receipts, as they are not shared via the Document Sharing Service.

This scope does not apply to the primary exchange between Sender and Receiver.

ehmiSbdhBusinessScope/Scope for XDS-Metadata

Always FHIR DocumentReference for the relevant message type with associated variables to be able to identify e.g. patient and organization

<Scope>
    <Type>XDS-METADATA</Type> 
        <InstanceIdentifier>
            <[CDATA: <DocumentReference> [DocumentReference-structure] </DocumentReference>]>
        </InstanceIdentifier>
    <Identifier>dk-medcom-DocumentReference</Identifier>
</Scope>

XDS-Metadata (example på encoded value)

<Scope>
    <Type>XDS-METADATA</Type> 
        <InstanceIdentifier>
            <[CDATA: [DocumentReference-structure*]]>
        </InstanceIdentifier>
    <Identifier>dk-medcom-DocumentReference</Identifier>
</Scope>

As [DocumentReference-structure] can't be referenced in the above xml-snippet, you can find the example of the structure to be included here: [DocumentReference-structure]

Reliable messaging

Reliable messaging is triggered by a request for the degree of reliable messaging desired from the sender, which is done using SBDH's BusinessService in the BusinessScope element.

When the sender has made a request for Reliable messaging and thus the use of ehmiSBDH EnvelopeReceipts, these are handled using ebXML Business Process Signals (ebBP Signals 2.0.4).

Outcome spaces for these ebXML Business Process Signals are:

ReceiptAcknowledgement
ReceiptException
AcceptanceAcknowledgement (currently not used in the Production Pilot)

Two structures are used

Reliable messaging - Business Service request
Reliable messaging - BusinessService response

Both are built around SBDH's BusinessScope/Scope element.

In connection with requirements related to on Reliable messaging, the structure in BusinessScope called BusinessService is used to design which type of ehmiSbdhtransactions the recipient of the original ehmiSBDH-envelope must fulfill.

CorrelationInformation is used to tie a message and its receipt together. All elements of CorrelationInformation are generated by the sending SBDH-MSH. Recipient of ehmiSBDH and sender of EHMI ReceiptAcknowledgement must acknowledge the elements RequestingDocumentCreationDateTime and RequestingDocumentInstanceIdentifier by indicating the CorrelationInformation. An ehmiSBDH EnvelopeReceipt is never acknowledged.

ehmiSbdhBusinessScope Complex

Reliable messaging - BusinessService Request

ehmiSBDH_ReceiptAckowledgementRequest

The following, is how the setup is desired in the Production Pilot.

EHMI-ReceiptAcknowledgement- - Request

In an EHMI-ReceiptAcknowledgement - Request, the scope is always like this:

<Scope>
    <Type>EHMI-ReceiptAcknowledgement</Type>
    <InstanceIdentifier>Request</InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

CorrelationInformation -

Reliable messaging uses the SBDH's CorrelationInformation to tie the original ehmiSBDH and the ehmiSBDH EnvelopeReceipt together. The RequestingDocument InstanceIdentifier is specifically used here.

CorrelationInformation - RequestingDocumentCreationDateTime

RequestingDocumentCreationDateTime is the time of original message sending = DocumentIdentification/CreationDateAndTime

<CorrelationInformation>
    <RequestingDocumentCreationDateTime>
        [YYYY-MM-DD]T[TT-MM-SS]+[offset to UTC]
    </RequestingDocumentCreationDateTime>
    …
<CorrelationInformation>

example:

<CorrelationInformation>
    <RequestingDocumentCreationDateTime>
        2021-02-17T09:30:10+01:00
    </RequestingDocumentCreationDateTime>
    …
<CorrelationInformation>

CorrelationInformation - RequestingDocumentInstanceIdentifier

RequestingDocumentInstanceIdentifier is the original envelope's identifier = DocumentIdentification/InstanceIdentifier

<CorrelationInformation>
    …
    <RequestingDocumentInstanceIdentifier>
        RequestingSBDH/DocumentIdentification/InstanceIdentifier
    </RequestingDocumentInstanceIdentifier>
    …
<CorrelationInformation>

example:

<CorrelationInformation>
    …
	<RequestingDocumentInstanceIdentifier>
        9a6ff82208de-5a6f-9670-9fa4b9d2f0dh
    </RequestingDocumentInstanceIdentifier>
    …
<CorrelationInformation>

CorrelationInformation - ExpectedResponseDateTime

ExpectedResponseDateTime expresses the expected maximum time until an ehmiSbdhresponse is received. In the Production Pilot this is a 10 min response time, i.e. RequestingDocumentCreationDateTime + 10 min

<CorrelationInformation>
    …
    <ExpectedResponseDateTime>
        [YYYY-MM-DD]T[TT-MM-SS]+[offset to UTC]
    </ExpectedResponseDateTime>
<CorrelationInformation>

example:

<CorrelationInformation>
    …
    <ExpectedResponseDateTime>
        2021-02-17T09:40:10+01:00
    </ExpectedResponseDateTime>
<CorrelationInformation>

CorrelationInformation - samlet example

<CorrelationInformation>
    <RequestingDocumentCreationDateTime>
        2021-02-17T09:30:10+01:00
    </RequestingDocumentCreationDateTime>
    <RequestingDocumentInstanceIdentifier>
        9a6ff82208de-5a6f-9670-9fa4b9d2f0dh
    </RequestingDocumentInstanceIdentifier>
    <ExpectedResponseDateTime>
        2021-02-17T09:40:10+01:00
    </ExpectedResponseDateTime>
</CorrelationInformation>

ehmiSbdhBusinessServices - Request

BusinessServiceName

Always

<BusinessServiceName>
    EHMI-ReceiptAcknowledgement-Request
</BusinessServiceName>

ServiceTransaction – TypeOfServiceTransaction

TypeOfServiceTransaction=”RequestingServiceTransaction”

ServiceTransaction – IsNonRepudiationRequired

IsNonRepudiationRequired=”false”

ServiceTransaction – IsAuthenticationRequired

IsAuthenticationRequired=”false”

ServiceTransaction – IsNonRepudiationOfReceiptRequired

IsNonRepudiationOfReceiptRequired=”false”

ServiceTransaction – IsIntelligibleCheckRequired

IsIntelligibleCheckRequired=”false”

ServiceTransaction – IsApplicationErrorResponseRequested

IsApplicationErrorResponseRequested=”false”

ServiceTransaction – TimeToAcknowledgeReceipt

TimeToAcknowledgeReceipt=”600000” (ms)

ServiceTransaction – TimeToAcknowledgeAcceptance

TimeToAcknowledgeAcceptance=”0” (= is not currently used)

0 ServiceTransaction – TimeToPerform

TimeToPerform=”0” (=is not currently used)

ServiceTransaction – Recurrence

Recurrence=”0” (=is not currently used)

ehmiSbdhBusinessServices - Request example

<BusinessService>
    <BusinessServiceName>
        EHMI-ReceiptAcknowledgement-Request
    </BusinessServiceName>
    <ServiceTransaction 
        TypeOfServiceTransaction=”RequestingServiceTransaction”, 
        IsNonRepudiationRequired=”false”, 
        IsAuthenticationRequired=”false”, 
        IsNonRepudiationOfReceiptRequired=”false”, 
        IsIntelligibleCheckRequired=”false”, 
        IsApplicationErrorResponseRequested=”false”, 
        TimeToAcknowledgeReceipt=”600000”, 
        TimeToAcknowledgeAcceptance=”0”, 
        TimeToPerform=”0”, 
        Recurrence=”0”/>
</BusinessService>

Reliable messaging - BusinessService Request samlet example

<BusinessScope>
    <Scope>
        <Type>EHMI-ReceiptAcknowledgement</Type>
        <InstanceIdentifier>Request</InstanceIdentifier>
        <Identifier>dk-medcom-messaging</Identifier>
        <CorrelationInformation>
            <RequestingDocumentCreationDateTime>
                2021-02-17T09:30:10+01:00
            </RequestingDocumentCreationDateTime>
            <RequestingDocumentInstanceIdentifier>
                9a6ff82208de-5a6f-9670-9fa4b9d2f0dh
            </RequestingDocumentInstanceIdentifier>
            <ExpectedResponseDateTime>
                2021-02-17T09:40:10+01:00
            </ExpectedResponseDateTime>
        </CorrelationInformation>
        <BusinessService>
            <BusinessServiceName>
                EHMI-ReceiptAcknowledgement-Request
            </BusinessServiceName>
            <ServiceTransaction 
                TypeOfServiceTransaction=”RequestingServiceTransaction”, 
                IsNonRepudiationRequired=”false”, 
                IsAuthenticationRequired=”false”, 
                IsNonRepudiationOfReceiptRequired=”false”, 
                IsIntelligibleCheckRequired=”false”, 
                IsApplicationErrorResponseRequested=”false”, 
                TimeToAcknowledgeReceipt=”300000”, 
                TimeToAcknowledgeAcceptance=”0”, 
                TimeToPerform=”0”, 
                Recurrence=”0”/>
        </BusinessService>
    </Scope>
    …
</BusinessScope>  

Reliable messaging - BusinessService Response

ehmiSBDH_ReceiptAckowledgementResponse

The following is the setup desired in the Production Pilot.

EHMI-ReceiptAcknowledgement - Response

In an EHMI-ReceiptAcknowledgement - Response scope is always like this:

<Scope>
    <Type>EHMI-ReceiptAcknowledgement</Type>
    <InstanceIdentifier>Response</InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

CorrelationInformation -

Reliable messaging uses the SBDH’s CorrelationInformation to tie the original ehmiSBDH and the Acknowledgement ehmiSbdh together. The RequestingDocumentInstanceIdentifier is specifically used here

CorrelationInformation - RequestingDocumentCreationDateTime

RequestingDocumentCreationDateTime is the disptach time of original envelope = RequestingSBDH/RequestingDocumentCreationDateTime

<CorrelationInformation>
	<RequestingDocumentCreationDateTime>
        [YYYY-MM-DD]T[TT-MM-SS]+[offset to UTC]
    </RequestingDocumentCreationDateTime>
…
<CorrelationInformation>

RequestingDocumentCreationDateTime example

<CorrelationInformation>
	<RequestingDocumentCreationDateTime>
        2021-02-17T09:30:10+01:00
    </RequestingDocumentCreationDateTime>
    …
<CorrelationInformation>

CorrelationInformation - RequestingDocumentInstanceIdentifier

RequestingDocumentInstanceIdentifier is the original envelope's identifier = RequestingSBDH/RequestingDocumentInstanceIdentifier

<CorrelationInformation>
    …
    <RequestingDocumentInstanceIdentifier>
        RequestingSBDH/RequestingDocumentInstanceIdentifier
    </RequestingDocumentInstanceIdentifier>
    …
<CorrelationInformation>

RequestingDocumentInstanceIdentifier example

<CorrelationInformation>
    …
    <RequestingDocumentInstanceIdentifier>
        9a6ff82208de-5a6f-9670-9fa4b9d2f0dh
    </RequestingDocumentInstanceIdentifier>
    …
<CorrelationInformation>

CorrelationInformation - ExpectedResponseDateTime

ExpectedResponseDateTime is omitted in an EHMI ReceiptAcknowledgement

CorrelationInformation - samlet example

<CorrelationInformation>
    <RequestingDocumentCreationDateTime>
        2021-02-17T09:30:10+01:00
    </RequestingDocumentCreationDateTime>
    <RequestingDocumentInstanceIdentifier>
        9a6ff82208de-5a6f-9670-9fa4b9d2f0dh
    </RequestingDocumentInstanceIdentifier>
</CorrelationInformation>

ehmiSbdhBusinessServices - Response

BusinessServiceName

Always

<BusinessServiceName>
    EHMI-ReceiptAcknowledgement-Response
</BusinessServiceName>

ServiceTransaction – TypeOfServiceTransaction

Always

TypeOfServiceTransaction=”RespondingServiceTransaction”

ServiceTransaction – IsNonRepudiationRequired

Always

IsNonRepudiationRequired=”false”

ServiceTransaction – IsAuthenticationRequired

Always

IsAuthenticationRequired=”false”

ServiceTransaction – IsNonRepudiationOfReceiptRequired

Always

IsNonRepudiationOfReceiptRequired=”false”

ServiceTransaction – IsIntelligibleCheckRequired

Always

IsIntelligibleCheckRequired=”false”

ServiceTransaction – IsApplicationErrorResponseRequested

Always

IsApplicationErrorResponseRequested=”false”

ServiceTransaction – TimeToAcknowledgeReceipt

Always

TimeToAcknowledgeReceipt=”0” (ms)

ServiceTransaction – TimeToAcknowledgeAcceptance

Always

TimeToAcknowledgeAcceptance=”0” (=is not currently used)

0 ServiceTransaction – TimeToPerform

Always

TimeToPerform=”0” (=is not currently used)

ServiceTransaction - Recurrence

Always

Recurrence=”0” (=is not currently used)

ehmiSbdhBusinessServices - Response example

<BusinessService>
    <BusinessServiceName>
        EHMI-ReceiptAcknowledgement-Response
    </BusinessServiceName>
    <ServiceTransaction 
        TypeOfServiceTransaction=”RequestingServiceTransaction”, IsNonRepudiationRequired=”false”, 
        IsAuthenticationRequired=”false”, IsNonRepudiationOfReceiptRequired=”false”, IsIntelligibleCheckRequired=”false”, IsApplicationErrorResponseRequested=”false”, TimeToAcknowledgeReceipt=”600000 ”, 
        TimeToAcknowledgeAcceptance=”0”, 
        TimeToPerform=”0”, 
        Recurrence=”0”/>
</BusinessService>

Reliable messaging - BusinessService Response overall example

<BusinessScope>
    <Scope>
        <Type>EHMI-ReceiptAcknowledgement</Type>
        <InstanceIdentifier>Response</InstanceIdentifier>
        <Identifier>dk-medcom-messaging</Identifier>
    <CorrelationInformation>
        <RequestingDocumentCreationDateTime>
            2021-02-17T09:30:10+01:00
        </RequestingDocumentCreationDateTime>
        <RequestingDocumentInstanceIdentifier>
            9a6ff82208de-5a6f-9670-9fa4b9d2f0dh
        </RequestingDocumentInstanceIdentifier>
    </CorrelationInformation>
    <BusinessService>
        <BusinessServiceName>
            EHMI-ReceiptAcknowledgement-Response
        </BusinessServiceName>
        <ServiceTransaction 
            TypeOfServiceTransaction=”RespondingServiceTransaction”, IsNonRepudiationRequired=”false”, 
            IsAuthenticationRequired=”false”, IsNonRepudiationOfReceiptRequired=”false”, IsIntelligibleCheckRequired=”false”, IsApplicationErrorResponseRequested=”false”, TimeToAcknowledgeReceipt=”0”, 
            TimeToAcknowledgeAcceptance=”0”, 
            TimeToPerform=”0”, 
            Recurrence=”0”/>
        </BusinessService>
        </Scope>
    …
</BusinessScope>

ehmiSbdhBinaryContent – the contained message

BinaryContent is an ehmiSbdh1.2 extension that allows to wrap specific content in ehmiSBDH and base64-encode it. MimeType clarifies the content and what the recipient can expect from the base64 decoding.

Outcome space for mimeType is:

text/xml
text/edi
fhir/xml

fhir/json

<BinaryContent xmlns="http://peppol.eu/xsd/ticc/envelope/1.0" mimeType=[mimeType] encoding=[encoding]>
    [base64-encoded indhold]
<BinaryContent>

Encoding in the pilot will be the following for all the MedComMessagingMessages:

"UTF-8"

Encoding will have the following outcome space for ReceiptAcknowledgement and ReceiptException in the pilot:

"UTF-8"

ehmiSBDH xsd-schemas

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)

Ehmi SBDH

ehmiSbdhprofile of Standard Business Document Header

ehmiSbdh– General elements

StandardBusinessDocument

ehmiSBDH for a MedcomMessagingMessage and a MedCom Acknowledgement

ehmiSBDH for an ehmiSBDH EnvelopeReceipt

ehmiSbdh– general fixed elements

HeaderVersion

Sender

Identifier

If the MedCom Message is of type FHIR

Sender example

Receiver

Identifier

If the MedCom Message is of type FHIR

Receiver example:

DocumentInformation

Standard

If the MedCom Message is of type FHIR

If the MedCom Message is of type ehmiSBDH EnvelopeReceipt

TypeVersion

If the MedCom Message is of type FHIR

InstanceIdentifier

Type

If the MedCom Message is of type FHIR

If the message is of type ehmiSBDH EnvelopeReceipt:

MultipleType

CreationDateAndTime

DocumentInformation - aggregate message example

DocumentInformation - aggregate EnvelopeReceipt example

Manifest (deliberately omitted in the Production Pilot version)

ehmiSbdhBusinessScopes

eDelivery message communication

In context of SMP

DOCUMENTID

DOCUMENTID for MedCom Messaging Messages

DOCUMENTID for ehmiSBDH EnvelopeReceipt

PROCESSID

Health message communication

Scope – message metadata - who

PATIENTID

SENDERID

RECEIVERID

Scope – message metadata - what

MESSAGEIDENTIFIER

If the MedCom Message is of type ehmiSBDH EnvelopeReceipt

MESSAGEENVELOPEIDENTIFIER

ORIGINALMESSAGEIDENTIFIER

ORIGINALMESSAGEENVELOPEIDENTIFIER

ORIGINALMESSAGESTANDARD

ORIGINALMESSAGEVERSION

ORIGINALENVELOPEIDENTIFIER

MedCom Statistics

StatisticalInformation

XDS-Metadata

Document sharing XDS-Metadata

ehmiSbdhBusinessScope/Scope for XDS-Metadata

XDS-Metadata (example på encoded value)

Reliable messaging

Reliable messaging - BusinessService Request

EHMI-ReceiptAcknowledgement- - Request

CorrelationInformation -

CorrelationInformation - RequestingDocumentCreationDateTime

CorrelationInformation - RequestingDocumentInstanceIdentifier

CorrelationInformation - ExpectedResponseDateTime

CorrelationInformation - samlet example

ehmiSbdhBusinessServices - Request

BusinessServiceName

ServiceTransaction – TypeOfServiceTransaction

ServiceTransaction – IsNonRepudiationRequired

ServiceTransaction – IsAuthenticationRequired

ServiceTransaction – IsNonRepudiationOfReceiptRequired

ServiceTransaction – IsIntelligibleCheckRequired

ServiceTransaction – IsApplicationErrorResponseRequested

ServiceTransaction – TimeToAcknowledgeReceipt

ServiceTransaction – TimeToAcknowledgeAcceptance

0 ServiceTransaction – TimeToPerform

ServiceTransaction – Recurrence

ehmiSbdhBusinessServices - Request example

Reliable messaging - BusinessService Request samlet example