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

Ehmi SBDH Dk

ehmiSBDH

ehmiSBDH

Indledning

The EHMI Standard Business Document Header (ehmiSBDH) is a customized version of the PEPPOL SBDH.

It is developed to

suit the direct messaging of clinical content in EHMI
handle reliable messaging at the eDelivery network level like VANSenvelope in the VANS network
handle the XDS Metadata that is needed when MedCom Messages are exchanged as “documents” in the XDS Framework
serve the ground for EHMI Delivery Status
serve the ground for EHMI Statistics of message exchange

[TBD]

ehmiSbdh– Generelle elementer

Generelt

StandardBusinessDocumentHeader (SBDH) er en konvolutspecifikation udstedt af GS1 og profileret til anvendelse i PEPPOL. Den understøttes af eDelivery's Access Points (AP) ift. AS4 protokollen. Vi følger i EHMI konventionerne, som er udlagt i PEPPOLs profilering, men udvider den også til at kunne passe på sundhedsområdet. ehmiSBDH er dog ingenting uden en omgivende container, kaldet StandardBusinessDocument (SBD).

StandardBusinessDocument

StandardBusinessDocument er som nævnt SBDHs omgivende container, og er en wrapper rundt om SBDH, og indeholder kun to elementer:

StandardBusinessDocumentHeader
BinaryContent (base64-encodet)

Selvom StandardBusinessDocument, som sådan er konvolutten, bruges termen ehmiSbdhgenerelt om hele konvolutten, da det er dette indhold som er særligt interessant i meddelelsesudvekslingen. BinaryContent er elementet som indeholder en base64-encodet meddelelse eller kvittering for en afsendt SBDH.

EHMI StandardBusinessDocument

Indholdet i ehmiSBDH er for en stor dels vedkommende bestemt af hvorledes

de samme informationer registreres i EER
de samme informationer registreres i SMP
sammenhængen er til DokumentDelingServicen DDS
sammenhængen er til ehmiSBDH EnvelopeReceipt
de samme informationer registreres i EDS

ehmiSBDH har en struktur, der overordnet er delt ind i følgende elementer:

HeaderVersion
Sender
Receiver
DocumentInformation
Manifest
BusinessScope

ehmiSBDH for en MedCom meddelelse og en MedCom kvittering

I en ehmiSBDH for en MedCom meddelelse og en MedCom kvittering kan følgende metadata indgå:

Generelle ehmiSBDH metadata
Metadata for eDelivery generel meddelelseskommunikation
Metadata for sundhedsmeddelelseskommunikation
XDS Metadata for Dokumentdeling
Metadata for Reliable messaging - BusinessService Request

ehmiSBDH for en ehmiSBDH EnvelopeReceipt

I en ehmiSBDH for en ehmiSBDH EnvelopeReceipt er der følgende metadata:

Generelle ehmiSBDH metadata
Metadata for eDelivery generel meddelelseskommunikation
Metadata for sundhedsmeddelelseskommunikation
Metadata for Reliable messaging - BusinessService Response

ehmiSbdh– Fast definerede generelle elementer

SBDH’s generelle elementer er illustreret i nedenstående figur.

EHMI StandardBusinessDocument

BusinessScope har dog fået sit eget kapitel, da det afviger markant fra de øvrige. I det følgende præsenteres de generelle ehmiSBDH-elementer for de foreløbigt 2 meddelelsestyper, som EHMI opererer med:

FHIR
ehmiSBDH EnvelopeReceipt

Hvor det er relevant, vil de generelle elementer være opdelt i underafsnit, der beskriver stien til værdien for det pågældende element i de respektive meddelelsestyper. Hvor de fleste elementer har almindeligt fokus på meddelelsesudveksling generelt og samspillet med SMP, giver særligt BusinessScope et sundhedsorienteret aftryk i specifikationen.

HeaderVersion

Altid

<HeaderVersion>1.0</HeaderVersion>

Sender

Sender indeholder i EHMI kun det mandatory element Identifier.

Identifier

Indeholder attributten Authority, som jf. [Policy_identifiers], POLICY 6 Numeric Codes for Issuing Agencies, altid har værdien: "iso6523-actorid-upis"

Identifier repræsenterer GLN for afsender, hvor

Værdien 0088: afspejler at typen er GLN.
Værdien efter 0088: afspejler GLN-nummeret.

<Sender>
    <Identifier Authority="iso6523-actorid-upis">    
        “0088:”+[GLN-nummer]
    </Identifier>
</Sender>

Hvis MedCom meddelelsen er af typen FHIR

Hvis MedCom meddelelsen er af typen FHIR, da altid på følgende form:

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

Sender eksempel

Uanset meddelelsestype vil det altid munde ud i følgende Sender/Identifier, hvor værdien efter 0088: selvfølgelig vil variere.

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

Receiver

Receiver indeholder i EHMI kun det mandatory element Identifier.

Identifier

Indeholder attributten Authority, som jf. [Policy_identifiers], POLICY 6 Numeric Codes for Issuing Agencies, altid har værdien: "iso6523-actorid-upis" Identifier repræsenterer GLN for modtager, hvor

Værdien 0088: afspejler at typen er GLN-typenummeret.
Værdien efter 0088: afspejler GLN-nummeret.

<Receiver>
    <Identifier Authority="iso6523-actorid-upis">    
        “0088:”+[GLN-nummer]
    </Identifier>
</Receiver>' 

Hvis MedCom meddelelsen er af typen FHIR

Hvis MedCom meddelelsen er af typen FHIR, da altid på følgende form:

<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 eksempel:

Uanset meddelelsestype vil det altid munde ud i følgende Receiver/Identifier, hvor værdien efter 0088: selvfølgelig vil variere.

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

DocumentInformation

Standard

Vi opererer med 4 type standarder, som har hvert sit prefix ifm. standarden

FHIR
ebxml
OIOXML (beskrives I en senere version af standarden)
Edifact (beskrives I en senere version af standarden)

Hvis MedCom meddelelsen er af typen FHIR

Hvis MedCom meddelelsen er en OIOXML, da altid på følgende form:

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

Meddelelseseksempel:

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

Hvis MedCom meddelelsen er af typen ehmiSBDH EnvelopeReceipt

Altid

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

SBDH-envelope eksempel:

<DocumentInformation>
    …
    <Standard>ebbp-signals</Standard>
    …
</DocumentInformation>

TypeVersion

Er den indeholdte meddelelses version på formen

<DocumentInformation>
    …
    <TypeVersion>[Sti til typeversionen]</TypeVersion>
    …
</DocumentInformation>

Hvis MedCom meddelelsen er af typen FHIR

Hvis MedCom meddelelsen er af typen FHIR, da altid på følgende form:

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

Meddelelseseksempel:

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

Hvis den indeholdte meddelelse er af typen ehmiSBDH EnvelopeReceipt

Altid

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

ehmiSBDH EnvelopeReceipt eksempel:

<DocumentInformation>
    …
    <Type>ebbp-signals-2.0</Type>
    …
</DocumentInformation>

InstanceIdentifier

InstanceIdentifier vil blive genereret af den afsendende MSH og er uanset om det er en meddelelse eller en ehmiSBDH EnvelopeReceipt genereret.

<InstanceIdentifier>[generated UUID]</InstanceIdentifier>

Eksempel:

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

Type

Meddelelse:

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

Hvis MedCom meddelelsen er af typen FHIR

Hvis MedCom meddelelsen er en FHIR, da altid på følgende form:

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

Meddelelseseksempel:

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

Hvis meddelelsen er af typen ehmiSBDH EnvelopeReceipt:

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

Kvitteringstype har følgende udfaldsrum: Udfaldsrum for disse ebXML Business Process Signals er:

ReceiptAcknowledgement
ReceiptException
AcceptanceAcknowledgement (OBS! bruges ikke i produktionspiloten)

Envelope Kvitteringseksempel:

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

MultipleType

Altid false:

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

CreationDateAndTime

Altid på formen: [YYYY-MM-DD]T[TT-MM-SS]+[offset-to-UTC]

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

Eksempel:

<DocumentInformation>
    …
    <CreationDateAndTime>2024-03-01T16-19-00+01:00</CreationDateAndTime>
    …
</DocumentInformation>

DocumentInformation samlet meddelelseseksempel

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

DocumentInformation samlet kvitteringseksempel

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

Manifest (bevidst udeladt i Produktionspilotversionen)

ehmiSbdhBusinessScopes

ehmiSbdhBusinessScopes er SBDH’s name-value pair konstruktion karakteriseret ved identifier. Name er udtrykt ved Type-elementet og value er udtrykt ved InstanceIdentifier. Disse to skifter for hvert scope, mens Identifieren i EHMI sammenhæng altid er den samme: dk-medcom-messaging I det følgende gennemgås de i de logiske sammenhænge, som de optræder i.

BusinessScope for generel eDelivery meddelelseskommunikation

Sammenhæng til SMP

I eDelivery kommunikationen udgør SBDH’ens Scope struktur med de to typer, DOCUMENTID og PROCESSID, den direkte sammenhæng til SMP’ens DOCUMENTID og PROCESSID. Ydermere inkluderer sammenhængen også de allerede gennemgåede elementer i afsnittet om Receiver. I det følgende beskrives netop disse to Type elementer i SBDH’ens overordnede BusinessScope struktur. Scopene DOCUMENTID og PROCESSID er i PEPPOL fast definerede scopes, som sikrer en unik relation til SMP. DOCUMENTID og PROCESSID anvendes i EHMI med samme præcision som i PEPPOL, så der sikres en ensartethed i, hvordan man udtrykker værdierne på tværs af PEPPOL og EHMI. DOCUMENTID og PROCESSID bruges af AP’erne sammen med modtagers Receiver/Identifier til at slå modtagers eDelivery adresse op i SMP med et unikt respons som resultat.

EHMI StandardBusinessDocument

DOCUMENTID

Værdien i InstanceIdentifier er identisk med den tilsvarende SMP-registrering. Værdierne hentes fra MedComs standardkatalog og er her repræsenteret ved de værdier, som angiver typen af meddelelsen. Se bogmærke: [DKEDEL_DT_CodeList]

DOCUMENTID for MedCom FHIR Meddelelser

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

MedCom FHIR Meddelelseseksempel

<Scope> 
    <Type>DOCUMENTID</Type> 
    <InstanceIdentifier>
        urn:dk:medcom:prod:messaging:fhir:structuredefinition:homecareobservation# urn:dk:medcom:fhir:homecareobservation:3.0
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

DOCUMENTID for ehmiSBDH EnvelopeReceipt

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

DOCUMENTID ehmiSBDH EnvelopeReceipt eksempel:

<Scope> 
    <Type>DOCUMENTID</Type> 
    <InstanceIdentifier>
       urn:dk:healthcare:prod:messaging:oasis:ebxml:schema:xsd:SBDHReceiptAcknowledgement
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

PROCESSID

Værdien i InstanceIdentifier er identisk med den tilsvarende ProcessId SMP-registrering . I 4-corner modellen sendes SDN-emergence-registreringen med til SMP, så afsenders AP kan slå endelig modtager, også kaldet finalreceipient op korrekt i SMP.

<Scope> 
    <Type>PROCESSID</Type> 
    <InstanceIdentifier>
        [Process Identifier value] 
    </InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

PROCESSID for SDN Eksempel

Altid

<Scope> 
    <Type>PROCESSID</Type> 
    <InstanceIdentifier>sdn-emergence</InstanceIdentifier>
    <Identifier>dk-medcom-messaging</Identifier>
</Scope>

ehmiSbdhBusinessScope – sundhedsmeddelelseskommunikation

Scope – message metadata - who

EHMI StandardBusinessDocument

PATIENTID

Patientens CPR nummer indgår som identifier til brug for EDS Forsendelsesstatus og 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 MedCom FHIR meddelelser - eksempel:

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

SENDERID

Afsenders SOR-identifier indgår til brug for EDS Forsendelsesstatus. SENDERID for MedCom FHIR meddelelser:

<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 MedCom FHIR meddelelser - eksempel:

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

RECEIVERID

Modtagers SOR-identifier indgår til brug for EDS Forsendelsesstatus. RECEIVERID for MedCom FHIR meddelelser:

<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 MedCom FHIR meddelelser - eksempel:

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

Scope – message metadata - what

EHMI StandardBusinessDocument

MESSAGEIDENTIFIER

MESSAGEIDENTIFIER er den indeholdte meddelelses MessageHeader.id, bl.a. til brug for forsendelsesstatus opsamling.

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

MESSAGEIDENTIFIER eksempel:

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

Hvis MedCom meddelelsen er af typen ehmiSBDH EnvelopeReceipt

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

MESSAGEIDENTIFIER eksempel:

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

MESSAGEENVELOPEIDENTIFIER

MESSAGEENVELOPEIDENTIFIER er den indeholdte meddelelses Bundle.id, bl.a. til brug for forsendelsesstatus opsamling.

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

MESSAGEENVELOPEIDENTIFIER eksempel:

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

ORIGINALMESSAGEIDENTIFIER

ORIGINALMESSAGEIDENTIFIER er den originale indeholdte meddelelses MESSAGEIDENTIFIER, bl.a. til brug for forsendelsesstatus opsamling.