Introduktion

Formål

Formålet med dette dokument er at beskrive systemarkitekturen for DROS.

Læsevejledning

Nærværende dokument er tiltænkt udviklere og IT-arkitekter med interesse i DROS og dens opbygning.

Definitioner og referencer

Overblik over DROS

Dokumentregistrings- og opdateringsservice (DROS) håndterer oprettelsen af nye dokumenter. Servicen tager såldees imod registreringer til repository. Efterfølgende sørger det centrale XDS repository for at meta-data afleveres til registry, så dokumenterne kan fremsøges vha. Dokumentdelingsservice (DDS)

<iframe src="https://archi.nspop.dk/NSP/570928ca/views/id-6a5cebb5-c103-4f88-bfc3-0e96ed8049b4.html" name="test" height="450" width="800">You need a Frames Capable browser to view this content.</iframe>   

* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.

Løsningens afhængigheder

DROS betjener sig af tredjeparts biblioteker fra IPF Open eHealth Integration Platform til implementations- og hjælpeklasser, der har med XDS IHE at gøre.

DROS anvender NSP libraries:

• audit-api
• security-api

Løsningens opbygning

Nedenstående diagram viser opbygningen af DROS.

I designet er der lagt vægt på at definere en fornuftig struktur, hvor hver af DROS services er opbygget på en ensartet måde.

Ovenstående diagram viser, hvorledes en DROS ITI-X service er opbygget.

Selve service interface og implementation er placeret i pakkerne dk.nsp.dros.service(.impl). Klasserne i disse pakker er ansvarlige for at modtage requests fra anvenderne på de for DROS definerede snitflader. Ved at anvende klasser i pakken dk.nsp.dros.security valideres det, at den indkommende sikkerhedsbillet er valid og overholder de for DROS definerede krav (se evt. DROS - Driftsvejledning for muligheder for opsætning).

Klasserne i pakkerne dk.nsp.dros.service.validation(.impl) indeholder funktionalitet der har til formål at:

• Validere det indkommende request (se afsnit nedenfor vedr. validering)
• Konvertere de indkommende requests til domæneklasser (som defineret i biblioteket openehealth) til brug for videre validering (se afsnit nedenfor vedr. validering).

Hvis valideringerne i DROS ikke er overholdt, så returnerer DROS passende fejlbesked til den kaldende anvender.

Hvis valideringerne er overholdt, så anvender DROS klasser i pakkerne dk.nsp.dros.backend(.impl) til at kalde den bagvedliggende XDS infrastruktur.

Validering i DROS

DROS validerer de indkommende requests.

Whitelisting

DROS har sin egen whitelistingtabel, hvor cvr eller UUID for det kaldende certifikat skal være whitelistet. Se DROS - Driftsvejledning for detaljer.

Håndterede type koder (type codes)

DROS kan konfigureres med en liste af type codes, sådan at en instans håndtere en eller flere type koder. Dette resulterer i følgende opførsel, hvis der kaldes med en ikke håndteret type:

• ITI-41 Provide and Register document:  hvis typecode indgår i dokumentets metadata (documententry) og den ikke håndteres afvises kaldet med en fejl.
• ITI-42 Register document set: hvis typecode indgår i dokumentets metadata (documententry) og den ikke håndteres afvises kaldet med en fejl.
• ITI-61 Register on demand document:  hvis typecode indgår i dokumentets metadata (documententry) og den ikke håndteres afvises kaldet med en fejl.
• ITI-57 Update metadata:  hvis typecode indgår i dokumentets metadata (documententry) og den ikke håndteres afvises kaldet med en fejl.
• ITI-57 Deprecate: forventes at blive afvist af bagvedliggende registry, da target dokument forventes ikke at være tilgængeligt.

IHE validering

I det anvendte openhealth bibliotek findes en standard XDS validering. Dette anvendes til en simpel validering, som tjekker, at det indkommende request er lovligt i henhold til standarden IHE XDS.

Valideringspakkerne er struktureret, så disse senere kan udvides med NSP specifikke valideringer.

Validering af requests vha. standard valideringsbibliotek

Der er udviklet et bibliotek til validering af XDS dokumenter, XdsValidation.

DROS er konfigureret til at anvende dette bibliotek til at validere requests, inden de videresendes til det bagvedliggende registry. Der er en række konfigurationer, som sættes op til valideringsbiblioteket, sådan at DROS har mulighed for at påvirke valideringen. I dets nuværende form drejer det sig hovedsagligt om en række lister af gyldige koder. F.eks. hvilke typecodes, formatcodes, eventscodes etc metadata og dokument må indeholde.

Se driftsvejledning for detaljer om muligheder og konfiguration. Validering gennem validerings bibliotek kan køre i fire modes:

• OFF: Validering foretages ikke.
• LOG: Validering foretages, men requestet videresendes alligevel. Eventuelle valideringsfejl bliver auditlogget (se driftsvejledning for detaljer om dette). Anvenderen ser ikke resultatet af validering.
• WARNING: Validering foretages, men requestet videresendes alligevel. Eventuelle valideringsfejl bliver auditlogget (se driftsvejledning for detaljer om dette), og sendes tilbage til anvenderen som warnings.
• REJECT: Validering foretages, og requestet afvises hvis valideringen mislykkes.

 Validering af request vha. DROS' udvidede valideringsbiblitoek

DROS har implementeret egen validering vha. valideringsbiblioteket framework. Det drejer sig om validering af Cpr numre vha. PatientInformation samt Sor koder vha. Sores.

Der findes i DROS en enricher og 2 validatorer. Se dokumentationen til valideringsbiblioteket for en bedre forståelse af koncepterne.

Ovenstående figur visualiseres hvordan DROS' lokale validerings træ er struktureret. 

DocumentEntryPatientIdExistsValidator kalder PatientInformation i forbindelse med validering.

DocumentEntryAuthorInstitutionSorEnricher kalder Sores i forbindelse med enrichment.

For flere detaljer omkring den enkelte validator, se DROS anvender guide.