...

*Dokumentationen af NSP services og komponenter på NSPOP omfatter udelukkende NSP produktionsmiljøet og ikke NSP’s øvrige miljøer. Det er muligt at få information og indblik i tilstanden på et af de øvrige miljøer via de gængse kommunikationsveje.

Indledning

Formål

Dokumentdeling gør det muligt for aktører i sundhedsvæsenet at dele relevante data om borgere og dermed skabe et overblik over den enkelte borgers situation for de aktører, som har brug for dette. Det kan være dem, som planlægger og gennemfører behandlingsforløb eller for borgeren selv og deres omsorgspersoner. Samtidig skal det være muligt for borgeren at bestemme, hvem han/hun vil dele disse data med gennem spærring samt se, hvem der har læst data via MinLog. Infrastrukturen på NSP, der muliggør deling af dokumenter på tværs af sundhedsaktører, er baseret på IHE XDS standarden

...

Der forventes et vist kendskab til CDA dokumenter - da fokus ikke er disse, ligesom kendskab til anvendelse af DGWS, NSP og SDN  forventes for implementeringen. Hjælpemoduler som MinSpærring, MinLog2 og andre komponenter, der er i spil i forbindelse med dokumentdeling berøres heller ikke andet overfladisk.

Hvad er dokumenter

Data i en XDS infrastruktur gemmes som dokumenter. Et dokument har et unikt id (documentId) og en række metadata, der beskriver, hvad dokumentet handler om. Dokumenter kan indholdsmæssigt være af flere forskellige typer: PDF, Word-dokument, men kan også være af typen CDA (Clinical Document Architecture). Et CDA dokument er egentlig bare et struktureret XML dokument, der følger en bestemt standard for kliniske dokumenter til udveksling (deling). Se f.eks. What is HL7 CDA? for en kort beskrivelse. Her kan man bl.a. se, at CDA findes på forskellige niveauer 1-3, hvor 3 har den højeste grad af struktur.

...

Oprindelig var det aftaledokumenter (APD), som blev delt på NSP platformen. Senere er flere dokumentprofiler kommet til. Alle dokumenterne på NSP er CDA dokumenter for nuværende. De skal alle overholde de danske profiler nævnt ovenfor. 

Hvad er dokumentdeling

XDS står for Cross-Enterprise Document Sharing og er en international standard udarbejdet af Integrating the Healthcare Enterprise (IHE) for udveksling af kliniske dokumenter. En XDS infrastruktur består (mindst) af følgende to komponenter:

...

• Start med at skabe et overblik over documententry, associations og submissionsest - f.eks. i "ITI TF-3 afsnit 4.1 Abstract Metadata Model". Det er de objekttyper, man primært taler om i standarden og datamodellen man bør forstå.
• Læs derefter omkring de forskellige kald nævnt ovenfor:
  • ITI-41 til oprettelse/ret af dokumenter - ITI TF-2 afsnit "3.41 Provide and Register Document Set-b [ITI-41]"
  • ITI-18 fremsøgning af dokumenter : ITI TF-2 afsnit "3.18 Registry Stored Query [ITI-18]"
  • ITI-43 hent af dokumenter: ITI TF-2 afsnit "3.43 Retrieve Document Set [ITI-43]"

NSP Arkitekturoversigt af komponenter

På NSP består dokumentdelingsinfrastrukturen af følgende komponenter:

...

Ovenstående  infrastruktur findes i flere versioner/miljøer. Eksempelvis test1, test2, prodtest og produktion.

Hvordan kommer man i gang

Komponenterne i dokumentdelings infrastrukturen kommunikerer med ITI kald, som er standardiserede SOAP services, der skal overholde IHE XDS specifikationen - i det såkaldte XML basererede "RIM format"

...

Da dokumentdelingen kører på NSP og sundhedsdatanettet (SDN) skal man anvende Den gode Web Service og have adgang til SDN for den del af miljøerne. Dette beskrives ikke yderligere her.

OpeneHealth biblioteket til Java

Man kan med fordel inkludere biblioteket IPF Commons IHE XDS i sin kodebase. Her findes både stubbe og en masse anvendelige utilities. Disse kan blandt andet mappe fra den IHE XDS standard specificerede RIM format, til en en "OpeneHealth core model", som er java klasser. Og gør det at udvikle ITI kald lettere at arbejde med.

...

<ns2:Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="urn:uuid:69d3b9f3-7919-40e0-8731-32fb339216c2" nodeRepresentation="N" id="urn:uuid:9068bc2b-1717-4337-abfb-027f303b20c6">
  <ns2:Slot name="codingScheme">
    <ns2:ValueList>
      <ns2:Value>2.16.840.1.113883.5.25</ns2:Value>
    </ns2:ValueList>
  </ns2:Slot>
  <ns2:Name>
    <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="N"/>
  </ns2:Name>
</ns2:Classification>

<ns2:ExternalIdentifier registryObject="urn:uuid:69d3b9f3-7919-40e0-8731-32fb339216c2" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="2512489996^^^&1.2.208.176.1.2&ISO" id="urn:uuid:6dc240d8-d871-4df1-b8c6-3414f1415022">
  <ns2:Name>
    <ns2:LocalizedString value="XDSDocumentEntry.patientId"/>
  </ns2:Name>
</ns2:ExternalIdentifier> 

Vigtige Objekter og id'er

Når man arbejder med OpeneHealth core model, er der nogle centrale klasser/objekter at beskæftige sig med. 3 af dem er SubmissionSet, DocumentEntry og Association:

...

• LeafClass: her returnes en liste af matchende documentEntry med fuld metadata indhold

Eksempler på kald

Det følgende er eksempelkode til at illustrere et ITI-41 kald til oprettelse af et dokument

...

ID: 2
Response-Code: 200
Encoding: UTF-8
Content-Type: application/soap+xml;charset=UTF-8
Headers: {connection=[keep-alive], content-type=[application/soap+xml;charset=UTF-8], Date=[Thu, 24 Feb 2022 14:12:50 GMT], transfer-encoding=[chunked]}
Payload: 
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
   .. soap headers fjernet for overskueligehed... 
  </soap:Header>
  <soap:Body>
    <ns6:AdhocQueryResponse xmlns:ns6="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns5="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns4="urn:ihe:iti:xds-b:2007" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" totalResultCount="2" status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success">
      <ns2:RegistryObjectList>
        <ns2:ObjectRef id="urn:uuid:a573c596-6cc4-40e4-85c2-529d2fbf6914"/>
        <ns2:ObjectRef id="urn:uuid:4a68ec73-f9c1-4a32-8b50-1c8d585f6590"/>
      </ns2:RegistryObjectList>
    </ns6:AdhocQueryResponse>
  </soap:Body>
</soap:Envelope>

 Dokumenttype-adskillelse i XDS-infrastrukturen

For at smidiggøre infrastrukturen ift. performance, vedligehold og sikkerhed er det besluttet, at vi fremadrettet etablerer separate registries (indexes) og repositories for hver dokumenttype. Dette er endvidere i fin overensstemmelse med den domænebaserede målarkitektur, der baserer sig på IHE-XCA-profilen.

...

Dette betyder, at der vil være et separat endpoint pr dokumenttype, som anvenderne skal anvende, når dokumenter registreres (og opdateres). Der vil til gengæld fortsat kun være behov for ét endpoint til dokumentdelingsservicen, når man skal fremsøge dokumenter.

Hjælpeværktøjer og links

De følgende links kan alle bidrage til at lette arbejdet med at implementere dokumentdeling.

...