*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æsnet, 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 samtykkeservicen 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æringSamtykkeService, 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: slags mht indhold og format. Eksempler er PDF, Word-dokument, men kan også være af typen dokument og XML. Et eksempel på et XML dokument er 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.

En vigtig egenskab ved CDA dokumenter er den fælles CDA header. Denne header indeholder information, der går igen henover alle typer af kliniske dokumenter, f.eks. hvilken patient drejer dokumentet sig om, hvilken organisation er ansvarlig (ejer) af dokumentet mm. CDA headeren er således en international standard (HL7), men der findes en dansk specialisering af denne (standardiseret i regi af Medcomden danske profilering af metadata). Denne er beskrevet her XDS Metadata for Document Sharing. Danish profile. Medcom vedligeholder Der er en tilhørende liste over tilladte værdi sæt for metadata, som findes her DK-IHE_Metadata-Common_Code_systems-Value_sets.

Der findes andre flere profiler, der er specialiseringer af CDA. Dvs. kliniske dokumenter, der har en struktur til bestemte formål. Medcom har leveret danske profileringer af følgende typer Hver af disse har deres egen kode værdi i metadata feltet typecode. Følgende er nogle af de danske profileringer (se evt. Medcoms oversigt over HL7 standarder):

• Appointment Document (APD) til aftaler
• Careplan (CPD)
• Personal Data Card/Stamkort (PDC)
• Personal Health Monitoring Report (PHMR) til hjemmemonitorering
• Questionnaire Form Definition Document (QFDD) og Questionnaire Response Document (QRD) til patientrapporterede oplysninger (PRO)
• Personal Health Attachment Document (PHAD) til psykiatriplaner
• Vandrejournal (PSCR), Svangerskabsjournal (PRF), Kliniske målinger (CMR) til graviditetsmappen
• Laboratoriesvar (LABSVAR)

Oprindelig var det aftaledokumenter (APD) som blev delt på NSP platformen. Men det har ændret sig, så også de andre dokumentprofiler er kommet i spil. Alle dokumenterne på NSP er CDA dokumenter for nuværende. Og de De skal alle overholde Medcoms 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:

• Document Repository: til persistering af dokumenter tilknyttet et unikt ID.
• Document Registry: til opbevaring og indeksering af metadata vedr. dokumenterne i et eller flere XDS repositories. Metadata kunne f.eks. være start- og sluttidspunkt dokumentet dækker over, eller dets forfatter (author) (oplysningerne stammer typisk fra CDA headeren)

Der er to typer varianter af CDA dokumenter, som deles i infraskturen (angives også i metadata feltet type). De har hver deres servicehåndtag, som det fremgår nedenfor.

...

Integrationen med XDS infrastrukturen sker vha. en række standardiserede SOAP webservices - ITI kald. Et overblik over en standard XDS infrastruktur og de forskellige services ses nedenfor:

Når data skal deles vha XDS er der følgende overordnede flows:

...

• 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 dokumentdelings infrastrukturen dokumentdelingsinfrastrukturen af følgende komponenter.:

• DROS (anvenderguide) anvendes til skrive aktiviteterne:
  • Oprettelse af nye dokumenter (ITI-41 Provide and Register Document Set) sker fra anvendersystemerne. DROS lagrer det oprettede dokument i det bagvedliggende nationale XDS Repository. I forbindelse med oprettelsen sørger det nationale XDS Repository for at få indexeret dokumentet og dets metadata i det nationale XDS Registry (ITI-42 Register Document Set). Tidligere har også DRS været anvendt til dette formål, men den udgår.
  • Oprettelse af et dokument, som en opdatering til et eksisterende dokument (ITI-41 Provide and Register Document Set). Her ugyldiggøres det eksisterende/gamle dokument.
  • Ugyldiggøre (deprecate)  et dokument eller opdatering af et dokument (ITI-57: Update Document Set)
  • Registrering af On-Demand dokumenter (ITI-61 Register On-Demand Document Entry)
  • Registrering af Stable dokumenter (ITI-42 Register Document Set). Dette anvendes, hvis man selv ejer et repository, men anvender det nationale registry til indeksering. Et eksempel på dette er KIH databasen, som indeholder hjemmemålinger (PHMR) og spørgeskemaer (QRD) .
• DokumentDelingsServicen (DDS registry) (anvenderguide) anvendes til fremsøgning af dokumenter (ITI-18 Registry Stored Query)  hvor der blandt andet kigges i
  • det Nationale XDS Registry
  • aftale adaptorer til region Nord og Region Midt. Disse delegere søgninger videre til de to Bookplan instanser i Region Nord hhv. Region Midt
  • FSK registry (vha bruger idkort)
  • Svareksponeringsservice XDS Registry Adapter. Der delegerer søgninger videre til Svareksponeringsservicen efter laboratoriesvar
• DokumentDelingsServicen (DDS repository) (anvenderguide) anvendes til at hente dokumenter (ITI-43 Retrieve Document Set) fra repositories som
  • det Nationale XDS Repositoryaftale adaptorer til Region Nord og Midt, som henter Bookplan dokumenter i Region Nord hhv. Region Midt
  • Svareksponeringsservice XDS Repository Adapter. Der delegerer hentning af laboratoriesvar videre til Svareksponeringsservicen
  • KIH databasen
  • Graviditetsmappe On-Demand repositoryFSK (vha bruger idkort)
• Søgning af Fælles StamKort (SFSK) (anvenderguide) er til at fremsøge (ITI-18 Registry Stored Query) og hente (ITI-43 Retrieve Document Set) Fælles Stamkort vha system idkort . Dette er on-demand dokumenter, som skabes ud fra en række bagvedliggende stamdata services.
• Læse servicene i DDS registry/ DDS repository og SFSK gør brug at hjælpe komponenterne SamtykkeService, BehandlerRelationsService , MinSpærring og MinLog2 for at sikre borgerens rettigheder. Se evt. DDS anvenderguide for mere beskrivelse.
• Læse servicene i SFSK gør brug at hjælpe komponenterne BehandlerRelationsService og MinLog2 for at sikre borgerens rettigheder.

Ovenstående  infrastruktur findes i flere versioner/miljøer. Eksempelvis findes miljøerne test1, test2, prodtest og produktion. Og f.eks. findes DROS i versionerne "Aftaler" og "Graviditetsmappe".

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"

Det er op til anvenderen/udvikleren selv at vælge platform og frameworks, der passer til resten af dennes løsning. Fra et udvikler perspektiv kan man enten vælge selv at generere stubkode ud fra de standardiserede WSDL filer eller at anvende et tredjepartsprodukt. Nedenfor gives et forslag til, hvordan det kan gribes an med tredjepartsproduktet IPF Open eHealth Integration Platform, som forudsætter man arbejder på en java platform. Andre platforme kan have tilsvarende værktøjer og muligheder.

De metadata, man registrerer om dokumentet, skal ligesom CDA headeren, overholde Medcoms standarder de danske standarder XDS Metadata for Document Sharing. Danish profile og DK-IHE_Metadata-Common_Code_systems-Value_sets.

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.

...

Et eksempel på, hvordan forskellen mellem core model og RIM format kommer til udtryk, ses her for håndtering af confidentiality code og CPR nummer i forbindelse med oprettelse af et dokument.

...

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

...

• FindDocuments: Den traditionelle måde, hvor man opsætter en række søgekriterier som dato interval, dokument status, dokument type typekode mm.
• GetDocuments: her fremsøges dokumenterne efter entryuuid eller uniqueid

...

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

#Som søge funktionaliteten kunne/burde være#

På NSP er der 3 forskellige måder at lave en fremsøgning på:

• FindDocuments: Den traditionelle måde, hvor man opsætter en række søgekriterier som dato interval, dokument status, dokument type mm.
• FindDocumentsByReferenceId: her søge efter dokumentreferencer, man måtte have sat på da dokumentet blev oprettet kombineret med andre almindelige søgekriterier
• GetDocuments: her fremsøges dokumenterne efter entryuuid eller uniqueid

Når man laver en fremsøgning med ITI-18, kan man få to typer af objekter tilbage, baseret på den retur type man sætter i kaldet. 

• LeafClass: her returnes en liste af matchende documentEntry med fuld metadata
• ObjectRef: her returnes en liste af objekt referencer, som entryuuid

En måde at fremsøge meget store datamængder på, kan derfor laves med først en fremsøgning retur type ObjektRef og efterfølgende anvende disse værdier til at lave en GetDocuments med retur typen LeafClass.

TODO: Afklaring omkring der skal gøres noget at det bliver som "kunne være". Der gælder 2 ting:

• DDS'en tillader ikke FindDocumentsByReferenceId. Den findes i NXRG.
• DDS'en ser ikke ud til at tillade ObjectRef. Og hvordan skal den kunne håndtere spærringer på den baggrund? Er det nødvendigt at spærre for ID'er? ObjectRef findes i NXRG.

Eksempler på kald

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

Eksempler på kald

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

// Nyt kald/request 
ProvideAndRegisterDocumentSet provideAndRegisterDocumentSet = new ProvideAndRegisterDocumentSet();

// Opret documentEntry
DocumentEntry documentEntry = new DocumentEntry();
AssigningAuthority patientIdAssigningAuthority = new AssigningAuthority("1.2.208.176.1.2"); // OID for CPR registret
Identifiable patientIdentifiable = patientIdentifiable = new Identifiable("2512489996", patientIdAssigningAuthority);
documentEntry.setPatientId(patientIdentifiable);
... mere metadata, se CDA profilen

// Tilføj dokumentet til request
provideAndRegisterDocumentSet.getDocuments().add(new Document(documentEntry, new DataHandler(new ByteArrayDataSource(documentPayload.getBytes(), documentEntry.getMimeType()))));

// Opret SubmissionSet
provideAndRegisterDocumentSet.setSubmissionSet(createSubmissionSet(documentEntry.getPatientId(), contentTypeCode, submissionTime));

// Opret association mellem SubmissionSet og DocumentEntry
provideAndRegisterDocumentSet.getAssociations().add(createAssociation(submissionSet, documentEntry));

// Transformer request - dette laver core model om til RIM format
ProvideAndRegisterDocumentSetTransformer registerDocumentSetTransformer = new ProvideAndRegisterDocumentSetTransformer(ebXMLFactory);
EbXMLProvideAndRegisterDocumentSetRequest30 ebxmlRequest = (EbXMLProvideAndRegisterDocumentSetRequest30) registerDocumentSetTransformer.toEbXML(provideAndRegisterDocumentSet);
ProvideAndRegisterDocumentSetRequestType provideAndRegisterDocumentSetRequestType = ebxmlRequest.getInternal();

// Udfør kald
RegistryResponseType registryResponse = iti41PortType.documentRepositoryProvideAndRegisterDocumentSetB(provideAndRegisterDocumentSetRequestType);

// Transformer response - dette laver RIM format til core model
ResponseTransformer responseTransformer = new ResponseTransformer(ebXMLFactory);
Response response = responseTransformer.fromEbXML(new EbXMLRegistryResponse30(registryResponse));

// Aflæs kaldets svar
if (response.getStatus().equals(Status.SUCCESS)) {
	// Kaldet gik godt
} else
if (response.getStatus().equals(Status.PARTIAL_SUCCESS) || response.getStatus().equals(Status.FAILURE)) {
	// Der er warning eller fejl i kaldet, håndter dem
	for (ErrorInfo error : response.getErrors()) {
	}
}

...

Savnes inspiration til kodeeksempler, er også integrationstestene til f.eks. DROS og NXRG et godt sted at kigge.

Et eksempel på ITI-41 request og response ses nedenfor.

...

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:a573c596-6cc4-40e4-85c2-529d2fbf6914"/>
        <ns2:ObjectRef id="urn:uuid:4a68ec73-f9c1-4a32-8b50-1c8d585f6590"/>
      </ns2:RegistryObjectList>
    </ns6:AdhocQueryResponse>
  </soap:Body>
</soap:Envelope>="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 (typecode). Dette er endvidere i fin overensstemmelse med den domænebaserede målarkitektur, der baserer sig på IHE-XCA-profilen.

Da data i registry (SDS patientindex) og repository registreres via Dokument Registrerings- og Opdateringsservicen (DROS), skal der tilsvarende etableres en separat DROS tilknyttet hvert par af registry (SDS patientindex) og repository, så vi ender op med en separat trio DROS/registry/repository per dokumenttype.

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.

Krav til eksterne registries og repositories

Dokumentdelingsservicen anvendes til at fremsøge og hente dokumenter på NSP. Det sker ved, at servicen har en række registries og repositories konfigureret, den kalder med ITI-18 Registry Stored Query henholdsvis ITI-43 Retrieve Document Set. For at sikre godt samarbejde/ fejlhåndtering mellem dokumentdelingsservice og disse registries/ repositories, er der opstillet en række punkter, der skal overholdes, hvis man som registry/ repository ønsker at være en del af NSP's dokumentdeling. Disse findes her: registry og repository.

Hjælpeværktøjer og links

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

...