Introduktion

...

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 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 I skrivende stund er der tale om en simpel validering, der som tjekker, om at det indkommende request er lovligt i henhold til standarden IHE XDS.

...

Kalderen vil således altid få 0 eller flere Document Entry tilbage fra DROS, hvis der spørges på et lovligt CPR nummer og man ikke vha. søgekriterier har udeholdt formatcode og typecode. 

Til valideringen skal der opsættes en CPR validering, der anvender CPRExists service til verficering af CPR-numre. CPR valideringen kan køre i følgende tre modes:

• OFF: Der foretages ikke yderligere verifikation af CPRnummeret udover den simple validering beskrevet ovenfor. CPRExists kaldes ikke
• WARNING: CPRExists service kaldes. Hvis denne service svarer, at CPR nummeret ikke findes, så audit logges denne information. Der gives en warning tilbage til anvenderen (sammen med svaret i øvrigt).
• REJECT: CPRExists service kaldes. Svaret fra denne er en hård validering dvs kaldet til DROS, hvis CPRExist service ikke kender CPR nummeret.

...

Der er udviklet et bibliotek til validering af XDS dokumenter, XdsValidation. DROS kan konfigureres til at anvende dette bibliotek til at validere requests, inden de videresendes til det bagvedliggende registry (se Driftsvejledning for detaljer om hvordan dette gøres). Valideringen kan køre i tre 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.

...