1. Introduktion

Nærværende dokument beskriver design og arkitektur af de såkaldte AO XDS Adaptere (IHE XDS proxy’er) fra interimløsningen.

1.1. Formål

Formålet med dette dokument er at beskrive systemarkitekturen for AO XDS Adaptere.

Derudover inderholder dokumentet en beslutningslog for design og arkitekturen af AO XDS Adaptere.

1.2. Læsevejledning

Nærværende dokument er tiltænkt udviklere og IT-arkitekter med interesse i anvendelsen af AO XDS Adaptere.

Herunder hører naturligvis personer involveret i konkrete dokument-kildesystemers brug af aftaler (indirekte gennem DDS).

1.3. Definitioner og referencer

Formålet med denne sektion er at give et overblik over definitioner og dokumenter, der benyttes i dette dokument.

Definition

Beskrivelse

NSP

Den Nationale Service Platform (inden for sundheds-IT)

DDS


Dokumentdelingsservice
XDS

Cross Domain Document Sharing 

2. Overblik over løsningens arkitektur

Patienters aftaler med pleje- og sundhedsvæsenet gøres tilgængelige gennem Dokumentdelingsservices (DDS) på den Nationale Service Platform (NSP).

AO XDS Adaptere udstilles ikke direkte på NSP'en men kaldes via DDS - som et bagvedliggende XDS Registry og XDS Repository.

AO XDS Adaptere overlader derfor flere lovgivningsmæssige og sikkerhedsrelaterede opgaver til DDS. Det drejer sig f.eks. om:

  • DDS adgangskontrol: Adgang under hensyntagen til DGWS (AO XDS Adaptere implementerer ikke selv sikkerhed)
  • Opfølgning i forhold til behandlingsrelation: DDS bestiller opfølgning ved dataadgang - herunder også data fremskaffet via AO XDS Adaptere
  • Spærringer: DDS udleverer data i overensstemmelse med borgerens registreringer i MinSpærring
  • Logning i MinLog: DDS logger udleverede data til MinLog
  • AuditLogning af udleverede informationer

DDS henter dokumentmetadata og aftaledokumenter ved at kalde Aftaleoversigt XDS Registry Adapter hhv. Aftaleoversigt XDS Repository Adapter, samlet kendt som Aftaleoversigt XDS-adaptere.

Indholdet i de konkrete aftaledokumenter samt metadata entries for disse skabes af AO XDS Registry Adapter ved processering af returværdier fra kald til Bookplans REST-ful aftaleservice.

AO XDS Adaptere er således rene forretningskomponent, der har til ansvar at:

  • Understøtte queries til fremsøgning af dokumentmetadata via DDS Registry (ITI-18 Registry Stored Query)
  • Understøtte forespørgsler efter dokumentindhold via DDS Repository (ITI-43 Retrieve Document Set)

Arkitekturen er afbilledet i følgende diagram:

aoxdsadapter-arkitektur

2.1. Fremsøgning af dokument(ers metadata)

DDS Registry udbyder en service til søgning (ITI-18) for anvenderne.

Ved modtagelse af en søgning, vil DDS Registry sende søgningen videre til alle bagvedliggende registries - herunder AO XDS Registry RN og AO XDS Registry RM.

AO XDS Registry tager de indgående søge parametre og beslutter, om det er en query, som den skal behandle (hvis det er en søgning, der ikke inkluderer aftaledokumenter, så vil AO XDS Registry returnere et tomt svar. Se i øvrigt AO XDS Adapter - Guide til Anvendere.

AO XDS Registry kalder den bagvedliggende Bookplan web service (hhv. Bookplan RN og Bookplan RM) for at fremsøge relevante aftaler. Disse bookplan-aftaler mappes til CDA dokumenter (enten APD version 1.1 eller APD version 2.0.1 udfra konfigurationen).

Da bookplan-aftaler ikke har et unikt ID, så vil AO XDS Registry Adapter generere et dokument-id (og et dokument) for hvert resultat, som fremsøgningen giver anledning til. Samtidig med at resultatlisten for kaldet til ITI-18 kaldet laves, så genereres selve aftaledokumentet og lagres i AO XDS DB Cache.

2.2. Hentning af dokumenter

Ved hentning af dokument via DDS Repositorys service ITI-43 delegeres kaldet videre til AO XDS Repository. Det er op til AO XDS Repository at hente aftaledokumentet ud af AO XDS DB Cache.

Da der genereres et sæt dokumenter ved hver forspørgsel vil der hurtigt komme mange dokumenter i AO XDS DB Cache. Der er lavet oprydningsservice, der kan kaldes fra driften (f.eks. natlig oprydning), der fjerne dokumenter med en vis alder fra databasen. Se i øvrigt AO XDS Adaptere - Driftsvejledning for detaljer.

3. Designmålsætninger og -beslutninger

3.1. Designmålsætninger

Designet af AO XDS Adaptere er holdt som en minimal løsning. AO XDS Adaptere er således udelukkende ansvarlig for at implementere fremsøgningsservice (ITI-18) og dokumentafhenting (ITI-43) for CDA dokumenter af typen aftale. Al autentifikation og autorisation samt audit logning overlades til den foranliggende DDS.

3.2. Designbeslutninger

3.2.1. Antal dokumenttyper

En installation af AO XDS Adaptere udstiller netop een type dokumenter. Dvs konfigurationer afgør, hvorledes de resulterende dokumenter ser ud:

  • Metadataopsætning: En konfigurationsfil afgør, hvordan metadata ser ud for dokumenterne. Det gør det f.eks. muligt at lave konfigurationer for RN hhv RM, så indholdet af organisationsoplysningerne er forskellige for de to deployments.
  • Dokumentindhold: Konfigurationen afgør, hvordan de resulterende dokumenter ser ud f.eks. hvorvidt der er tale om version 1.1 eller 2.0 af APD profilen. Hvis det er nødvendigt at udstille to forskellige versioner vil det være nødvendigt at deploye to sæt AO XDS Adaptere med hver deres konfiguration.

3.2.1.1. Anvendelse af IPF Open eHealth Integration Platform

AO XDS Adaptere er omlagt til at anvende komponenter fra IPF Open eHealth Integration Platform https://oehf.github.io/ipf/ipf-platform-camel-ihe/index.html 

Herunder specielt standard WSDL for servicen ITI-18 og ITI-43 samt Java klasser til model.

  • No labels