Nærværende dokument beskriver design og arkitektur af de såkaldte AO XDS Adaptere (IHE XDS proxy’er) fra interimløsningen.
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.
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).
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 |
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 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:
Arkitekturen er afbilledet i følgende diagram:
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 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 (Bookplan RM) for at fremsøge relevante aftaler. Disse bookplan-aftaler mappes til CDA dokumenter (APD version 2.0.1, ud fra 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.
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.
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.
En installation af AO XDS Adaptere udstiller netop een type dokumenter. Dvs konfigurationer afgør, hvorledes de resulterende dokumenter ser ud:
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.