...

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

TODO

<< 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, minSpærring (filter) og værdispring

Hvordan kommer man igang

Komponenterne i dokumentdelings infrastrukuren kommunikerer med ITI kald, som er standardiserede SOAP services, der skal overholde IHE XDS specifikationen. De er 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 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. Disse kan blandt andet mappe fra RIM formatet (specificeret af IHE XDS standarden), til en en "OpeneHealth core model", som er java klasser. Og gør det at udvikle ITI kald lettere at arbejde med.

Helt overordnet kan det at lave et ITI kald deles op i følgende trin

1. Opret kald i OpeneHealth coree model
   1. For ITI41 kald indebærer det blandt andet opret/indlæs af dokument samt opret af metadata til documententry
   2. For ITI42, 57 og 61 indebærer det oprettelse af metadata
   3. For ITI18 skal søge kriterierne sættes op
   4. For ITI43 skal dokumentiderne sættes op
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 dokument id'er henholdsvis dokumenter, der skal håndteres.

Dette kan illustreres ved følgende transformeringsdiagram, hvor man ser core modellen blive transformateret til RIM formatet og efterfølgende et ITI kald udført. Resultatet af ITI kaldet kommer tilbage i RIM format, og transformeres til core modellen:

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.

Først OpeneHealth core model, den kode man skriver i sit program:

• DROS 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 opatering 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 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 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) er til at fremsøge og hente 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

Komponenterne i dokumentdelings infrastrukuren kommunikerer med ITI kald, som er standardiserede SOAP services, der skal overholde IHE XDS specifikationen. De er 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 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. Disse kan blandt andet mappe fra RIM formatet (specificeret af IHE XDS standarden), til en en "OpeneHealth core model", som er java klasser. Og gør det at udvikle ITI kald lettere at arbejde med.

Helt overordnet kan det at lave et ITI kald deles op i følgende trin

1. Opret kald i OpeneHealth coree model
   1. For ITI41 kald indebærer det blandt andet opret/indlæs af dokument samt opret af metadata til documententry
   2. For ITI42, 57 og 61 indebærer det oprettelse af metadata
   3. For ITI18 skal søge kriterierne sættes op
   4. For ITI43 skal dokumentiderne sættes op
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 dokument id'er henholdsvis dokumenter, der skal håndteres.

Dette kan illustreres ved følgende transformeringsdiagram, hvor man ser core modellen blive transformateret til RIM formatet og efterfølgende et ITI kald udført. Resultatet af ITI kaldet kommer tilbage i RIM format, og transformeres til core modellen:

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.

Først OpeneHealth core model, den kode man skriver i sit program:

documentEntry.getConfidentialityCodes().

documentEntry.getConfidentialityCodes().add(new Code("N", new LocalizedString("N"), "2.16.840.1.113883.5.25"));

AssigningAuthority patientIdAssigningAuthority = new AssigningAuthority("1.2.208.176.1.2");
Code patientCode = new Code("2512489996", new LocalizedString("CPR"), "1.2.208.176.1.2");
documentEntry.setPatientId(new Identifiable(patientCode, patientIdAssigningAuthority));

...

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>

Biblioteker til .Net

...

</soap:Envelope>

Biblioteker til .Net

TODO: find noget

https://www.iheusa.org/sites/iheusa/files/IHE%20Profiles%20for%20Health%20Information%20Exchange.pdf

https://groups.google.com/g/ihe-north-america-connectathon-2007/c/dLNk8mWoMVY

Hjælpeværktøjer og links

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

...

...

...

...

...

...

https://groups.google.com/g/ihe-north-america-connectathon-2007/c/dLNk8mWoMVY

Hjælpeværktøjer og links

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

...