AO XDS Adaptere tilbyder en snitflade til fremsøgning og hentning af CDA aftaledokumenter.
Formålet med dette dokument er at beskrive systemarkitekturen for 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 |
AO XDS Adaptere skaber en read-only adgang til Bookplan aftaler i hhv Region Midt (RM) og Region Nord (RN).
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 sikkerhedsrelaterede opgaver til DDS. Det drejer sig f.eks. om:
AO XDS Adaptere er således en ren forretningskomponent, der har til ansvar at:
Dokumentanvendere tilgår ikke AO XDS Adaptere direkte, men vil anvende disse services indirekte gennem servicekald til DDS.
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 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.
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.