...

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

TODO: Lav korrekt tegning

Når data skal deles vha XDS sker følgende:

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 et et faktisk CDA dokument at gemme.
3. Dokumentaftager (Document Consumer) fremsøger dokumenter i XDS registry via servicehåndtaget ITI-18 Registry Stored Query. Svaret på denne query er en liste af documentIds og repositoryIds, der fortæller, hvilke dokumenter der lever op til søgekriterierne, og hvor de findes (repositoryId)
4. Dokumentaftager (Document Consumer) henter dokument i XDS repository via servicehåndtaget ITI-43 Retrieve Document Set
5. Dokumentadministrator (Document Administrator) kan opdatere metadata (heriblandt deprecate) i XDS registry via servicehåndtaget ITI-57 Update Document Set.
6. (Patient Identify Source som fremgår af figuren anvendes ikke på NSP)

IHE XDS standarden er specificeret i en række dokumenter som findes her (revision og dato matcher versionen da link indsat):

TODO: mere læsevejledning til standarden?

Arkitekturoversigt af komponenter

På NSP består dokumentdelings infrastrukturen af følgende komponenter.

<< oversigtstegninger over komponenter og iti interaktioner - tag kopi fra aftaledeling: Aftaler - justser med (+SFSK og -backends)?? >> I den tegning for dokumentdeling er det DDS Repo+Registry+DRS+DROS+SFSK, der er relevante (diverse backends skal ikke dokumenteres her). Skrive "udløbsdato" for DRS.

<< liste og forklaring af tegning inkl links til anvender guide for de forskellige >>

husk at placere hjælpe moduler og nævne at det får man med 

nævne flere miljøer med denne konfig, og ref'e til test link nedenfor

Minlog, behandlingsrelationer, minSamtykke (filter) og værdispring

Hvordan kommer man igang

husk dgws

og adgang til nsp og sdn

andet? hvor meget kan der linkes til?

...

Komponenterne i dokumentdelings infrastrukuren kommunikerer med ITI kald, som er standardiserede SOAP services, der skal overholde IHE XDS specifikationen. 

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 udfra 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.

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

eksempler på brug af librariet (hvilke objekter og hvilke id'er skal man tage stillinger)

...

gode steder at kigge: integrationstestene  og anvender guides for komponenterne

Biblioteker til .Net

Hjælpeværktøjer

...

endpoints link

andre nsp sider

cda viewer

cda validator

...

og links

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