...

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 skal alle overholde Medcoms profiler nævnt ovenfor. 

Der er to typer af CDA dokumenter (angives også i metadata feltet type) .

• "Stable document" som bliver skabt og gemt en gang for alle
• "On-demand" som først skabes på det tidspunkt, det faktisk efterspørges

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:

• XDS Document Repository: til persistering af dokumenter tilknyttet et unikt ID.
• XDS 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 af CDA dokumenter, som deles i infraskturen (angives også i metadata feltet type). De har hver deres servicehåndtag, som det fremgår nedenfor.

• "Stable document" som bliver skabt og gemt en gang for alle
• "On-demand" som først skabes på det tidspunkt, det faktisk efterspørges

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

...

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

1. Oprettelse af dokumenter:
   1. Dokumenter afleveres af dokumentkilden (Document Source) til XDS repository via servicehåndtaget ITI-41 Provide and Register Document Set. Herefter sørger XDS repository for at registrere dokumentet i XDS registry via servicehåndtaget ITI-42 Register Document Set.
   2. Hvis der er tale om et on-demand dokument registreres det af dokumentkilden (On Demand Document Source) direkte i XDS registry via servicehåndtaget ITI-61 Register On Demand Document Entry,  da der ikke er et faktisk CDA dokument at gemme.
2. Fremsøgning og hentning af dokumenter
   1. Dokumentaftager (Document Consumer) fremsøger dokumenter i XDS registry via servicehåndtaget ITI-18 Registry Stored Query. Svaret på denne query kan være en liste af metadata for de dokumenter, som matcher  søgningen. Et af felterne er repositoryId, der fortæller, hvor dokumentet kan findes.
   2. Dokumentaftager (Document Consumer) henter dokument i XDS repository via servicehåndtaget ITI-43 Retrieve Document Set
3. Dokumentadministrator (Document Administrator) kan opdatere metadata (heriblandt slet (deprecate)) i XDS registry via servicehåndtaget ITI-57 Update Document Set.
4. (Patient Identify Source , som fremgår af figuren, anvendes ikke på NSP, men er med i figuren da den indgår i standarden)

IHE XDS standarden er specificeret i en række dokumenter:. Disse er listet i nedenstående tabel med links og en beskrivelse af, hvordan man med fordel kan navigere i dem. 

...

• Start med at skabe et overblik over documententry, associations og submissionsest - f.eks. i "ITI TF-3 afsnit 4.1 Abstract Metadata Model"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]"
  Og læs derefter omkring
  • ITI-18 fremsøgning af dokumenter : ITI TF-2 afsnit "3.18 Registry Stored Query [ITI-18]"
  Og herefter om
  • ITI-43 hent af dokumenter: ITI TF-2 afsnit "3.43 Retrieve Document Set [ITI-43]"

Arkitekturoversigt af 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).
  • Sletning (deprecate) af  et dokument  eller opdatering af et dokument (ITI-57: Update Document Set)
  • Registrering af On-Demand dokumenter (ITI-61Register 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 indekserering. Et eksempel på dette er KIH databasen.
• DokumentDelingsServicen (DDS) registry (anvenderguide) anvendes til fremsøgning af dokumenter (ITI-18 Registry Stored Query)  hvor der 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
• DokumentDelingsServicen (DDS) repository (anvenderguide) repository anvendes til at hente dokumenter (ITI-43 Retrieve Document Set) fra
  • det Nationiolale XDS Repository
  • aftale adaptorer til region Nord og Midt, som henter Bookplan dokumenter i Region Nord hhv. Region Midt
• 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. 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 komponterne BehandlerRelationService, MinSpærring og MinLog2 for at sikre borgerens rettigheder.

...

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

Hvordan kommer man igang

...

OpeneHealth biblioteket til Java

Man behøver ikke at basere alting på Camel, men kan med fordel nøjes med at 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.

...

1. Opret kald i OpeneHealth core model
   1. For ITI41 kald indebærer det blandt andet opret/indlæs af dokument samt opret af metadata til documententrysenere fremsøgning
   2. For ITI42, 57 og 61 indebærer det oprettelse registrering og indeksering af metadata
   3. For ITI18 skal søge kriterierne sættes opsøgekriterierne angives
   4. For ITI43 skal dokumentid'erne sættes opangives
2. Udfør kald - det transformeres til RIM format på vej ud, og tilbage til core model ved returnering vha. openeHealth frameworket
3. Aflæs kaldets svar og håndter eventuelle fejl returneret. For ITI-18 og ITI-43 er der ligeledes metadata/dokument id'er henholdsvis dokumenter, der skal håndteres.

...

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

...

• For opret af dokumenter: source er submissionSet entryUuid og target er documentEntry entryUuid
• For ret; som for opret. Den ekstra "replace" association:  source er nye dokumentEntry entryUuid og target det gamle dokumentEntry entryUuid
• For slet (deprecate):  source er submissionSet entryUuid, og target er documentEntry entryUuid for det dokument, som skal slettes

TODO: Skal dele af ovenstående flyttes til DROS anvender guide? 

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

...

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:

...

Der er pt. ingen NSP erfaring med at udvikle dokumentdeling på .Net. Et produkt, der kunne se brugpart ud, som alternativ til Java platformens OpeneHelath er XdsObjects. Dette er dog kommercielt (med trial) og ser ikke ud til at være .NET standard kompatibel. Erfaringer med dette og andre .Net biblioteker er meget velkomne som input, til at få en mere uddybende dokumentation på området. 

TODO: Skal dette afsnit fjernes, så vi alene berøer .Net med bemærkningen "Andre platforme kan have tilsvarende værktøjer og muligheder." ovenfor i indledningen.

Hjælpeværktøjer og links

...

...