Introduktion

Formål

DDS Registry og Repository er en national service til

1. Opslag på patienter i Dokumentdelingsservicens registry
2. Udtræk af dokumenter vha. Dokumentdelingsservicens repository baseret på opslag i registry.

Formålet med dette dokument er at beskrive systemarkitekturen for DDS Registry og Repository.

For et overblik over systemet henvises til afsnit Arkitekturdesign - overblik.

Læsevejledning

Nærværende dokument er tiltænkt udviklere og IT-arkitekter med interesse i anvendelsen af DDS Registry/Repository. Herunder hører naturligvis personer involveret i konkrete dokument-kildesystemers brug af DDS Repository.

I dokumentet bruges begreberne autorisation og autoriseret primært i en sikkerhedskontekst, dvs. i forståelsen at en person eller et system har tilladelse til at anvende en given ressource. Anvendes begreberne om sundhedspersoner med dansk autorisation opført i Sundhedsstyrelsens autorisationsregister vil dette fremgå eksplicit.

Definitioner og referencer

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

Introduktion til DDS

Baggrund for opslag i DDS Registry

Baggrunden for at tilbyde opslag gennem DDS Registry er:

”Formålet med NPI (Nationalt Patientindeks) er at tilvejebringe adgang til data om patienten fra forskellige datakilder via et indeks. Anvendersystemer (f.eks. Sundhedsjournalen) kan i indekset søge efter informationer om data på en given patient (metadata) og præsentere en oversigt over disse for sundhedsfaglige brugere og borgere. Såfremt en sundhedsfaglig bruger eller borger ønsker at få adgang til de bagvedliggende detaljerede patientdata, skal indekset levere tilstrækkelig information om, hvor og hvordan dette kan hentes. Hvis det system, der er kilde til data har etableret en standardiseret snitflade til at hente disse patientdata, vil den sundhedsfaglige bruger kunne hente disse, ligesom borgeren umiddelbart vil kunne hente data via sundhed.dk.

Indekset skal skabe adgang så:

• borgeren har muligheden for at se data fra de professionelle om sine undersøgelser og behandlinger

• sundhedspersoner får mulighed for at se metadata og derigennem få adgang til yderligere data om en specifik patient fra andre organisationer, og vist eget system (via Sundhedsjournalen), f.eks. ved modtagelse af patienter som er enten akut syge, ambulante med komplekse forløb eller i øvrigt ukendte for behandleren

…

NPI skal i passende omfang bygge på internationale standarder og profiler. IHE profilerne vinder stigende udbredelse internationalt ved indførelsen af IT i sundhedsvæsenet, og vil derfor være relevante at anvende i projektet. IHE profiler indgår i regionernes projekt vedrørende fællesregionalt billedindeks, og i EU projektet epSOS, hvor man skal kunne udveksle patientresuméer og elektroniske recepter på tværs af EU’s medlemsstater. NSI er derfor særligt interesserede i at få afdækket om IHE XDS og tilsvarende standarder (kost)effektivt kan understøtte en standardiseret og dynamisk indeksering af relevante sundhedsfaglige datakilder.”

Overblik over løsningen

Dokumentdelingsservice (DDS) består af to logiske services DDS Registry og DDS Repository, der tilsammen understøtter funktionerne

• Fremsøgning (DDS Registry)
  • Der etableres med løsningen en DDS Registry web service, som giver mulighed for opslag i DDS Registry for både sundhedspersoner og borgere.
  • Opslag gennemføres med operationen Reqistry Stored Query, der er IHE XDS.b’s operation til fremsøgning af metadata i et IHE registry. DDS Registry viderestiller fremsøgning af metadata til IHE Repository, der med produktet Healthshare er en implementation af netop IHE registry.
  • DDS understøtter pt følgende 3 query typer: FindDocuments, FindDocumentsByReferenceId, GetDocuments
• Hentning (DDS Repository)
  • Der etableres med løsningen en DDS Repository web service, som giver mulighed for både sundhedspersoner og borgere at udtrække dokumenter på baggrund af metadata registreret i dokumentdelingsservice.
  • DDS Repository benyttes som intelligent proxy for en eller flere dokumentkilder.
  • Udtræk gennemføres med operationen Retrieve Document Set, der er IHE XDS.b’s operation til udtræk af dokumenter fra et IHE repository.

Figur 1 Anvendelse af services og databaser fra DDS

Servicene gennemfører en række yderligere tjek, logninger og behandlinger af data:

• Logning i Min-log-servicen
• Igangsættelse af check af behandlingsrelation mellem borger og sundhedsfaglig
• Kontrol af samtykke herunder filtrering inden returnering af data
• Mulighed for værdispring
• For registry tjekkes om et givet registry er gældende matcher evt medsendt dokumenttype
• For repository også bestemmelse af dokumentkildes webservice-endpoint
• Se DDS guide til anvendere, afsnit søgning og hentning hvor denne logik er udførligt beskrevet for registry henholdsvis repository blandt andet for forskellige brugertyper.

Servicene er yderligere indpakket i headers, som ikke er en del af IHE standarden:

• overholder Den Gode Web Service 1.0.1 (med få undtagelser som beskrevet i snitfladerne)
  • OIO IDWS for borgeradgang
• kræver anvendersystem autentificeret af STS’en på NSP
• kræver anvendersystem autoriseret, hvilket kontrolleres vha. whiteliste
• kræver bruger/patient identificeret ved brug af attributter i en ekstra header, HSUID-headeren.
• returnerer SOAPFault ved autentifikations- og autorisationsfejl samt ved visse systemfejl.

Brugertyper og adgangsscenarier

DDS Registry understøtter en række brugertype og adgangsscenarier. Disse brugertyper stiller forskellige krav til autentifikations- og kaldkontekst. Derudover er anvendelsen af de eksterne services (samtykke, behandlingsrelation, minlog) forskellig for de forskellige adgangsscenarier.

Først beskrives, hvordan en given brugertype fremkommer ud fra modellen, der udstilles i Security API. Så gennemgåes de forskellige brugertyper og adgangsscenarier på et overordnet niveau (User Stories). Herefter beskrives, hvordan DDS Registry anvender eksterne services (samtykke, minlog og behandlerrelationservice) i forhold til de forskellige scenarier.

Endelig gennemgås adgangsscenarierne i forhold til den gældende sikkerhedsprotokol på DDS Registry: Den Gode Webservice (DGWS). Det gennemgåes, hvorledes adgangsscenarierne kan implementeres i autentifikations- og kaldkontekst for DGWS: Sosi Id-kort og HSUID header.

Brugertyper

DDS Registry understøtter følgende DDS brugertyper med følgende overordnede muligheder:

• Borger: Borgere kan tilgå egne data, eller data på andre borgere, som de har en passende relation til (børn, fuldmagt)
• Sundhedsfaglig: Sundhedsfaglie kan tilgå data på borgere, hvis der er hjemmel til dette (behandlingsrelation, ikke-negativt samtykke, værdispring)
• Ikke-autoriseret bruger: Myndighedspersoner uden lægefaglig autorisation, men som har brug for at tilgå data på borgere (f.eks. adgang til aftaler for kommunale medarbejdere)
• System bruger: er der kun således at systemer (i praksis sundhed.dk) kan anvende DDS og ved hjælp af en medsendt HSUID header kan opnå status som een rigtig brugertype.

De forskellige DDS brugertyper giver anledning til en række adgangsscenarier dvs. måder, hvorpå disse kan tilgå DDS Registry for fremsøgning af dokumenter for et givent CPR nummer. 

Bestemmelse og mapning til actor

De enkelte brugertyper bestemmes udfra modellen, der udstilles i Security API. Disse regler er opsummeret i tabellerne nedenfor.

Transformation af brugertyper

En systembruger giver ikke mening i sig selv, og skal mappes over til en anden brugertype. Andre brugertyper kan også mappes til andre typer på baggrund af hsuid header information. En borger kan mappes til en borger på vegne af ved hjælp af cprFromPayload (det vil sige det cprnummer, som der forespørges på).

Den følgende figur viser i venstre side, hvilke brugertypr man kan blive på baggrund af modellen i security api'et. I højre side viser de brugertyper, det er muligt at få tildelt i dokumentdelingsservicen. Pilene imellem venstre og højre side, viser de mulige transformationer, der kan ske mellem brugertyperne baseret på indhold af hsuid header/cprnr i payload. System brugeren er ikke en tilladt brugertype og returneres som en fejl.

De forskellige brugertyper bliver beriget med følgende:

• Sundhedsfaglig alm:
  • organisationIdtype fra hsuid
  • organisationId fra hsuid
  • titel bliver sat til at være educationCode
• Ikke-autoriseret bruger
  
  • organisationIdtype fra hsuid
  • organisationId fra hsuid
  • hvis ingen national rolle sættes rollen "ingen_idkort_rolle"
  • titel bliver sat til at være national rolle - ellers anvendes konfigurerbar default værd
• Sundhedsfaglig på vegne af:
  • organisationIdtype fra hsuid
  • organisationId fra hsuid
  • titel bliver sat til at være educationCode eller national rolle afhængig af den brugertype man arbejder på vegne af har
  • onbehalfof titel bliver sat til educationCode
• Borger
  • titel bliver sat med konfigurerbar default værdi (anvendes i forbindelse med MinLog)

Titel anvendes i forbindelse med MinLog, og bliver i forbindelse med berigelsen konverteret til en mere sigende tekst end educationCode/national rolle.

Brugertyperne bliver til sidst valideret for:

• Alle roller, hvis hsuid header medsendt:
  
  • hsuid rollen skal matche den på security context
  • hsuid acting user cpr skal matche den aktøren
• Borger på vegne af
  • Der skal være en relation
• Sundhedsfaglig og Sundhedsfaglig på vegne af
  • hsuid authorisationkode skal matche den på aktøren
  • hsuid OrganizationId valideres mod Sores, hvis organizationIdSource er SOR
• Ikke-autoriseret bruger
  
  • hsuid OrganizationId valideres mod Sores, hvis organizationIdSource er SOR
• Den endelige brugertype må ikke være af typen System

Brug af eksterne services ved adgangsscenarier

De forskellige adgangsscenarier giver anledning til forskellige anvendelser af eksterne services. Disse anvendelser er opsummerert i nedenstående skema:

Adgangsscenarier og tests

De ovenstående adgangsscenarier giver anledning til en række integrationstests.

Målene med integrationstestene er at udføre en række tests, der påviser at:

• Adgangsscenarierne er understøttet af DDS som beskrevet ovenfor: Dvs det er muligt at få data ud af DDS i de forskellige scenarier
• Negative tests: For hvert scenarie vil integrationstestene inkludere en række negative tests .. det tjekkes f.eks. at der ikke kan anvendes værdispring i scenarie IA-1

Integrationstestene er bygget op på følgende måde:

• Integrationstestene i DDS er delt ind i testklasser, der dækker de ovenstående scenarier. De er navngivet med scenariernes roller som prefix og en efterfølgende beskrivende tekst, så sammenhængen med dokumenationen bevares.
• Alle testcases i integrationstestene er implementeret som cucumber test, der i sin anvendelse forklarer intentionen med testen.
• Alle testcases er bygge op efter samme skabelon som klart definerer præconditions (Given), aktivering af funktion (When) og tjek af svar/postconditions (Then). Se f.eks. Martin Fowler: Given-When-Then

Således indeholder integrationstestsuiten følgende:

• B1: borger_soeg_egne.feature
• B2: borger_soeg_andre_fuldmagt.feature
• B2: borger_soeg_andre.feature
• B2: BORGER_SOEG_ANDRE_SRP_FORAELDREMYNDIGHED
• SF1: sf_soeg_aftaler.feature
• SF1: sf_soeg_alle_dokumenttyper.feature
• SF1: sf_soeg_alle_dokumenttyper_byreferenceid.feature
• SF1: sf_soeg_labsvar.feature
• SF3: Samme features som SF1
• IA1: ia_ingen_national_rolle.feature
• IA1: ia_laege_sekraetaer.feature
• IA1: ia_sundhedsassistent.feature

For afvikling af integrationstests henvises til dokumentet DDS - Testvejledning.

Fordeling af ansvar

Der er foretaget en fordeling i ansvar for gennemførelse af aktiviteter, der foregår ved udtræk. Ansvarsfordelingen er som følger:

• DDS forestår alle aktiviteter undtagen kontrol af dokumentspecifikke samtykker
• Kildesystemer forestår fremfinding af dokumenter samt kontrol af dokumentspecifikke samtykker.

Rationalet bag denne fordeling er beskrevet i afsnit 'Kontrol af data-specifikke samtykker foretages af kildesystem' under designbeslutninger.

Et samlet overblik for applikationen Dokumentdelingsservice er lavet i nedenstående model.

<iframe src="https://archi.nspop.dk/NSP/570928ca/views/f301b4a5-2e58-4c90-80d5-d5e3914448dd.html" name="test" height="640" 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.

Behandling af udtræk i DDS Repository

I DDS guide til anvendere, afsnit hentning er der i detaljer redegjort for, hvordan DDS repository udtrækker dokumenter. Nedenfor er udvalgte områder af denne logik uddybet.

Repository bestemmelse af kildesystem(er)

Udtræk sker ved anvendelse af operationen Retrieve Document Set, hvor der i request-beskeden indgår et eller flere DocumentRequest-elementer, hver med følgende indhold:

• repositoryUniqueId, en OID, der identificerer det kildesystem, hvorfra dokumentet kan udtrækkes
• documentUniqueId, en OID, der identificerer dokumentet
• homeCommunityId, en OID, der identificerer det Community, hvorfra dokumentet kan udtrækkes (bemærk, at der kun specificeres en værdi, når denne er anført i svaret fra en Registry Stored Query, fx i svaret fra et DDS Registry)

Som beskrevet i [ITI TF-2] afsnit 3.18.4.1.2.3.8 anvendes homeCommunityId til at bestemme webservice-endpoint for services, der giver adgang til data inden for et IHE-fællesskab.

I [ITI TF-2] afsnit 3.43.4.1.3 er det beskrevet, hvordan en XCA Initiating Gateway skal reagere på en Retrieve Document Set-request:

• homeCommunityId bruges til at bestemme webservice endpoint for Responding Gateways (altså repositories)
• hvis homeCommunityId identificerer det lokale IHE-fællesskab, anvendes repositoryUniqueId til at bestemme webservice endpoint for repositories

Denne adfærd ligger til grund for bestemmelsen af kildesystemer i DDS Repository beskrevet i det følgende.

Ved gennemløb af alle DocumentRequest-elementer i Retrieve Document Set-request’en skabes en mængde (Set) af webservice-endpoints og en mængde af id, der ikke kunne fremfindes:

1. Hvis homeCommunityId er anført i et DocumentRequest-element i Retrieve Document Set-request’en, da foretages opslag i konfiguration på det homeCommunityId
2. Fremfindes et eller flere webservice-endpoints, da tilføjes disse til mængden af webservice-endpoints (dermed fortsættes til næste DocumentRequest-element)
3. Der foretages opslag på repositoryUniqueId i DDS Repositorys konfiguration
4. Fremfindes et webservice-endpoint, da tilføjes dette til mængden af webservice-endpoints (dermed fortsættes til næste DocumentRequest-element)
5. Fremfindes ingen webservice-endpoints, da tilføjes repositoryUniqueId’et til mængden over id, der ikke kunne fremfindes. Disse forespørgsler resulterer i en fejl hver i det resulterende svar.
6. De webservice-endpoints der ikke kan kontaktes, resulterer i en fejl i det resulterende svar.

Denne mekanisme (i DDS Repositorys bestemmelse af kildesystemer) er helt ortogonal på hvorvidt kildesystemer anvender XCA. Fordelen er, at DDS Repository ikke skal kende alle repositoryUniqueId (transitivt), således at et kildesystem i et IHE-fællesskab kan skifte til og fra XCA uden at DDS Repository-konfigurationen skal ændres.

Som vist i Figur 2 kan yderligere kildesystemer via XCA knyttes til et IHE-fællesskab uden ændring i konfigurationen i DDS Repository, når homeCommunityId er kendt af DDS Repository.

Figur 2 Konfiguration af DDS Repository baseret på repositoryUniqueId og homeCommunityId tillader tilføjelse af nye dokumentkilder. Når DDS Repository kender til dokumentkilde C’s webservice endpoint gennem dens homeCommunityId (IHE-fællesskab XYZ), da kan der tilføjes en ny dokumentkilde, her Dokumentkilde F, til IHE-fællesskabet via XCA uden at DDS Repository skal omkonfigureres.

I Figur 2 er Dokumentkilde B kendt direkte ved dens repositoryUniqueId. Tilføjes endnu en dokumentkilde via XCA til Dokumentkilde B, da skal DDS Repository enten:

• Omkonfigureres til at kende den tilføjede dokumentkildes repositoryUniqueId og webservice endpoint, eller
• Omkonfigureres så Dokumentkilde B’s webservice endpoint kendes via dens homeCommunityId (og ikke dens repositoryUniqueId)

Forudsætningen for at mekanismen ikke falder tilbage til opslag på repositoryUniqueId, er at:

• homeCommunityId blev specificeret i metadata under registrering
• homeCommunityId blev returneret ved opslag (følger automatisk, hvis specificeret under registrering af metadata)
• homeCommunityId indgår i DDS Repositorys konfiguration (liste over kendte services)

Behandling af udtræk i kildesystem

Et kildesystem har følgende ansvar:

• Overholdelse af snitflade og adfærd for IHE XDS.b ITI-43
• Fremfindelse af dokument(er)
• Kontrol af data-specifikke samtykker (medmindre der er tale om værdispring)
• Frafiltrering af dokumenter/dokument-dele omfattet af data-specifikke samtykker (herunder indsættelse af advarsler i svaret ved frafiltrering grundet samtykker samt advarsel ved manglende evne til at kontrollere samtykker).

Datastrukturen i Dokumentdelingsservice er opsummeret i nedenstående model.

<iframe src="https://archi.nspop.dk/NSP/570928ca/views/e3bdeed3-50ba-460c-9c69-fb5062e908d1.html" name="test" height="330" 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.

I documentsource findes webservice-endpoint for kildesystemer, i form af mapning mellem angivet OID i udtræk, til aktuelt service endpoint for XDS dokument kilde. Kombinationen af OID og type skal være unik.

I documentregistry er der konfiguration af hvilke dokument-indeks som har Metadata for de registrede udstillede dokumenter. 

I Whitelist config indeholdes de CVR-numre, hvis systemer er whitelisted som anvendersystemer, på test- og produktionsmiljø.

Designmålsætninger og -beslutninger

Designmålsætninger

Systemet skal designes i overensstemmelse med de målsætninger og prioriteter, som er angivet i Tabel 1. Prioriteten af hver enkelt målsætning er angivet med 1 til 5 hvor 5 indikerer højest prioritet.

Tabel 1: Designmålsætninger og deres indbyrdes vigtighed

Designbeslutninger

I dette afsnit fastholdes væsentlige design beslutninger samt deres rationale. Hvis relevant, fastholdes også designs, som er afvist samt rationalet herfor.

Logning vha Log4j

Fejl- og debug-logning implementeres vha. log4j der konfigureres for hver enkelt service. Der oprettes som udgangspunkt en logfil pr. service.

I denne logges exceptions og stacktraces for evt. fejl, der kastes.

Logning af flowID

Hvis konfigurationen sættes til ’debug’-niveau, logges flowID fra SOAP-beskeders Medcom-header ved entry/exit af webservicemetoderne.

Logningen af flowID er implementeret for at muliggøre, i tilfælde af fejlsøgning, at man kan følge de kald, der har indgået i et forløb.

Brug af NSPUtil til Service Level Agreement (SLA) logning

SLA-logning understøttes ved hjælp af (SLA) logningsfunktionaliteten i NSPUtil.

SLA-logningen logger all kald til DDS og består bl.a. af: Tidspunkt for kald, navn på den kaldte metode, tidsmæssig længde på kaldet, id (MessageID) på den besked der behandles.

I DDS - Driftsvejledning er beskrevet en liste af XDS-fejl indlejret i svar fra XDS Registry/XDS Repository/XDS-infrastruktur, der giver anledning til SLA-logning som fejlet, udadgående kald, på trods af at kaldet til den eksterne XDS-komponent (Registry/Repository eller infrastruktur) er succesfuldt. Mens fejlen XDSMissingHomeCommunityId fortrinsvis kan bero på fejl fra dokumentanvenders side, så er den inkluderet fordi den også kan skyldes fejlkonfiguration i XDS-infrastrukturen. De øvrige fejl i listen er udtryk for server-side fejl eller fejl i XDS-infrastruktur. Fejlene, hvoraf nogle reflekterer situationer, der kan opstå transient i XDS-infrastrukturen, skal håndteres af dokumentanvendere, da de kan betyde, at ikke alle tilgængelige oplysninger returneres i svar.

Selvom fejlene ikke er udtryk for, at DDS ikke fungerer korrekt, så SLA-logges de af DDS som fejlet for at lette detektion og fejludbedring.

Auditlogning

Auditlogning i DDS Registry sker vha AuditAPI'et (introduceret i SDS-2506 - Auditlogging af DDS via AuditAPI ARKIVERET ).

ITI-18: foretag auditlogning af patient-id, bruger-id, på-vegne-af-id samt hsuid-header og for hver DocumentEntry (DE) i returneret svar (der kan være frafiltreret metadata pga. samtykker): DE.uniqueId, DE.repositoryUniqueId, DE.homeCommunityId, DE.typeCode.

ITI-43: foretag auditlogning af patient-id, bruger-id, på-vegne-af-id samt huisd-header og for hver DocumentResponse (DR) i returneret svar (der kan være frafiltreret metadata pga. samtykker): DR.uniqueId, DR.repositoryUniqueId, DR.homeCommunityId.

Statisk konfiguration i propertyfil

Servicekonfigurationen foretages i en properties-fil, der skal deployes på webserveren et sted i applikationens classpath.

Ændringer i konfigurationen skal ledsages af genstart af servicen, da konfigurationen indlæses og verificeres ved opstart af de enkelte services. Properties kontrolleres for tilstedeværelse i property-filen, ikke for anførte værdi.

For en beskrivelse af hvad der skal opsættes i konfigurationen, se DDS - Driftsvejledning.

Applikationskonfiguration konfigureres i filerne DDSRegistry.properties og DDSRepository.properties. Al konfiguration af sikkerhed og klientopsætning angives i denne fil. Derudover angives også placeringen af logkonfigurationsfilen.

Serviceklientkonfiguration, der omfatter konfiguration af DDS Registry’s og Repositories kald til andre services, udpeges i applikationskonfigurationen. Det er muligt at lade applikationskonfigurationen ”pege på sig selv” angive serviceklientkonfigurationsparametre i applikationskonfigurationen, men der kan også foretages serviceklientkonfiguration i separate filer.

Placeringen af serviceklientkonfiguration angives i applikationskonfigurationen.

Logkonfiguration udpeges i applikationskonfigurationen. I logkonfigurationsfilen angives logger-properties for:

• Generel DDS Registry/Repository fejl- og debug-logning. Den generelle logning konfigureres ved at angive en log4j-logger property med navn log4j.logger.dk.nsi.
• Værdispringsloggen konfigureres med en log4j-logger property med navn log4j.logger.consentoverride.
• Performanceloggen, der kan bruges til logning umiddelbart før og efter kald til andre services, konfigureres med en log4j-logger property med navn log4j.logger.performancelogger.

Dynamisk konfiguration i database

DDS skal have adgang til en datasource ved navn ’WhitelistDS’ for at kunne lave autorisation af anvendersystemer vha. whitelist.

Brug af datasources

DDS Registry og Repository skal have adgang til:

• en datasource med navn ’SORDS’, der har adgang til SOR-databasen til brug ved kald af behandlingsrelationsservicen
• en datasource med navn ’AuthDS’, der har adgang til autreg-databasen. Dette benyttes ved kontrol af autorisationskode
• en datasource med navn ’WhitelistDS’, der har adgang til whitelist databasen til brug ved autorisation af anvendersystemer

Derudover skal DDS Repository have adgang til:

• en datasource med navn ’DocumentSourcesDS’, der har adgang til documentsources databasen til brug ved opslag af IHE repository.

Implicitte headers i WSDL

For at DDS Registry og Repository kan eksponere et webservice-interface, der i videst muligt omfang implementerer Registry Stored Query i henhold til IHE-standarden, er det søgt at minimere ændringer. Derfor er DGWS-headerne og HSUID-headeren tilføjet som implicitte headere, dvs. tilføjet til bindings i DDS Registry/Repository WSDL, men ikke input/output-beskederne.

Kaldsemantik i header

Et generelt håndhævet princip for webservices er, at argumenter af betydning for semantikken i webservice-operationer skal være placeret i SOAP body og ikke i SOAP header.

Hensynet til overholdelse af IHE-standarden vejer dog tungere, hvorfor en parameter som angivelse af værdispring er fastholdt i HSUID-headeren, til trods for at parameteren har betydning for semantikken. Derved er SOAP body fastholdt som defineret af IHE-standarden.

Advarsler i svaret

For entydigt at kunne kommunikere, at samtykkebegrænsninger har bevirket fravær af metadata i svaret fra opslag på DDS Registry, er det valgt at benytte IHE-standardens mulighed for implementationsspecifikke fejlbeskrivelser.

Alternativt skulle et af IHE-standardens egne fejlkoder, som beskrevet i afsnit 4.2.4 i [ITI TF-3], være anvendt på bekostning af entydighed for så vidt angår årsagen til fejlen/advarslen.

I IHE standarden er beskrevet, hvordan implementationsspecifikke fejl/advarsler kan angives, herunder at errorCode skal sættes til "XDSRegistryError", mens codeContext skal indeholde detaljer om fejlsituationen.

Se [DDS Registry query snitflade] og [DDS Repository snitflade] for de konkrete anvendelser af implementationsspecifikke fejl/advarsler.

Beslutning vedrørende servicearkitektur

Da DDS ikke har behov for transaktionsstyring er den implementeret som almindelig web service og ikke som Java EE bean.

Asynkron involvering af kontrolservices

Kald til Samtykkeservice og Behandlingsrelationsservice udføres i parallel, hvert kald som synkront kald.

Anvendelse af thread local request context

Invokere i DDS for kald af MinLog, BRS, Samtykkeverifikationsservicen samt for XDS Registry benytter JAXWS klient-proxier.

Disse er tunge at skabe, da det involverer udstrakt grad af reflection. Dette er undgået ved at skabe klient-proxyerne en gang og genbruge dem ved hver forespørgsel.

En forudsætning for denne fremgangsmåde (når udstrakt brug af synchronized fravælges grundet ineffektivitet) er brug af trådsikker port.

Ifølge JAXWS specifikationen er klient-proxy porte ikke trådsikre.

Derfor anvendes en udvidelse i Apache CXF, der indgår i den underliggende platform i Wildfly, der sikrer trådsikker request context beskrevet i http://cxf.apache.org/faq.html#FAQ-AreJAX-WSclientproxiesthreadsafe?

DDS er i sine invokere afhængig af trådsikker request context stillet til rådighed af CXF-implementationen af JAXWS i Wildfly

Der er risiko for sammenblanding af patient-data/behandling af patient-data, hvis ikke CXF’s JAXWS-implementation anvendes.

Anvendelse af security API til validering af sikkerhedsbilletter

Valideringen af de indkommende sikkerhedsbilletter (OIO IDWS, SOSI Idkort) foretages udenfor selve komponenten vha det i security API.

Det er fortsat DDS egen opgave at validere, at den kaldende brugers kald er lovlige/giver mening og overholder de i DDS gældende forretningsregler.

Kontrol af data-specifikke samtykker foretages af kildesystem

Alternativer:

1. Kontrol fra DDS Repository via ekstra metadata om dokumenter/dokument-dele
2. Kontrol fra DDS Repository ved anvendelse af standardformat(er)

Betinget mapning til SOR-kode for sundhedspersons organisation

Når data-specifikke samtykker skal kontrolleres ved kald af Samtykkeverifikationsservicen skal sundhedspersonens organisation gives ved dennes kode i SOR-klassifikationen.

Ved kald af DDS Repository er der som beskrevet i [DDS Repository snitflade] mulighed for i HSUID-header at angive sundhedspersonens organisation ved:

• enten ydernummer, SHAK-kode eller SOR-kode
• enten a) ydernummer og tilhørende SOR-kode, eller b) SHAK-kode og tilhørende SOR-kode

Er SOR-koden ikke givet ved kaldet af DDS Repository, foretages mapning til SOR-kode ud fra organisation angivet HSUID-headeren. Den fremfundne SOR-kode tilføjes til HSUID-header brugt ved kaldet til kildesystemet, således at kildesystemet ikke skal foretage mapningen.

Anvendelse af SOAP 1.1 for DDS Repository webservices

Snitfladen for DDS Registry/Repository skal indeholde SOAP-headere fra DGWS 1.0.1 og SOAP-header samt SOAP-body med indhold specificeret af IHE XDS.

DGWS 1.0.1 specificerer anvendelse af SOAP 1.1, mens webservices for IHE XDS er baseret på SOAP 1.2.

Det er valgt, at DDS skal udstille services med SOAP 1.1-binding af hensyn til overholdelse af DGWS.

Konsekvensen af valget er, at MTOM-anvendelse sker med SOAP 1.1-binding [MTOM SOAP 1.1] og ikke [MTOM SOAP 1.2].

Angivelse af patient-identifikation i DDS Repository

Både DDS Repository og kildesystemet har behov for at kende identifikation af den borger, der udtrækkes dokumenter om (patient-id). DDS Repository har behovet i kraft af, at denne skal kalde Samtykkeverifikationsservicen, Behandlingsrelationsservicen og MinLogRegistreringsservicen, hvor patient-id er krævet information. Tilsvarende skal kildesystemet kende patient-id, når data-specifikke samtykker kontrolleres ved kald af Samtykkeverifikationsservicen.

Patient-id indgår ikke i den request-struktur, der anvendes ved ITI-43 RetrieveDocumentSet.

Det er valgt, at tilføje en attribut til et enkelt patient-id til HSUID-headeren. Det er dermed anvendersystemets ansvar at specificere det korrekte patient-id. Med RetrieveDocumentSet er det muligt at udtrække dokumenter for flere dokument-id. Support blot for et enkelt patient-id har den konsekvens, at kald af RetrieveDocumentSet kun må anvendes, når alle specificerede dokument-id gælder samme patient. Det påhviler anvendersystemet at sikre, at dette er tilfældet.

Alternative løsninger:

1. ITI-18 opslag på register (foretaget i DDS Repository) ved brug af query’en GetDocuments. Denne er fravalgt grundet øget latens og manglende garanti for succes.
2. Tilføjelse af patient-id til ekstra, specifik header
3. Ved undersøgelse af fremhentede dokument(er). Fravalgt da det ikke er givet, at patient-id kan fremfindes utvetydigt.

Supplerende løsninger til valgte løsning:

1. Kontrol af patient-id ved ITI-18 opslag på register. Fravalgt af samme grunde som ITI-18 opslag beskrevet ovenfor.

Ingen sikring af overensstemmelse mellem angivet patient-id og patient-id i dokumenter

Med RetrieveDocumentSet er det muligt at udtrække dokumenter for flere dokument-id. Som beskrevet i forrige afsnit angives et enkelt patient-id i HSUID-headeren.

Det er valgt, at der ikke foretages kontrol af overensstemmelse mellem patient-id angivet i HSUID-header og patient-id for de dokumenter, der ønskes udtræk af.

Det påhviler anvendersystemet at sikre, at der er overensstemmelse mellem angivne patient-id og patient-id for de dokumenter, der ønskes udtræk af.

Ingen sikring af udtræk for enkelt patient ad gangen

Med RetrieveDocumentSet er det teknisk muligt med et kald at udtrække dokumenter for flere forskellige patienter. Af hensyn til patient-sikkerhed må der dog kun udtrækkes dokumenter for samme patient.

Det er valgt, at der ikke foretages kontrol af, at alle dokumenter, der ønskes udtræk af, vedrører samme patient.

Det påhviler anvendersystemet at sikre, at der kun forespørges om udtræk for samme patient.

Filtrering af registry kald vha. dokumenttype

I praksis er følgende situationer opstået:

• Der kan returnerres fejlkoder for indekses/registries som ikke indeholder dokumenter på de forespurgte dokumenttyper
• Nedbrud i enkelte registries/repositories har indvirkning på alle forespørgsler uanset dokumenttype
• Lange svartider i enkelte registries har i dag indvirkning på alle forespørgsler uanset dokumenttype

For at forbedre disse punkter er det blevet lavet muligt at konfiguerere hvilke dokumenttyper et givet registry er interessant for. Når en iti-18 søgning (Registry Stored Query) indeholder dokumenttype, kan man hermed vidersende kaldet til et udvalg af registries istedet for alle. For opsætning af dette, se driftvejldningen.

Filtrering af registry kald vha. feature toggling

Da behovet for at undersøtte FindDocumentsByReferenceId query typen for iti-18  opstod blev DDS udvidet med denne mulighed. Desværre understøtter alle DDS'ens backends ikke denne mulighed. Så for at undgå at introducere en række fejlsvar fra disse backends, er det blevet gjort muligt at konfigure, hvilke query typer de forskellige registry backends understøtter. Database delen er lavet så generisk, at det istedet for "query typer" hedder "features" så man i fremtiden også kan anvende den til andre filtreringer på ting, som de forskellige registry backends understøtter eller ikke understøtter. For opsætning af dette, se driftvejldning.

Filtrering af dokumenter vha. typecode, eventcode og practicesettingcode

For at kunne differentiere på et højere niveau, end at man som sundhedfaglig har adgang til alle eller ingen dokumenter på en patient, er der oprettet muligheden for at lave et metadata filter. For et givet CVR nummer og systemnavn kan man angive vha. metadata, hvad den sundhedsfaglige må se.

Pt. er det muligt at filtrere på typecode (dokumenttype), eventcode og practicesettingcode. Som minimum skal et dokument matche en konfigureret typecode. Og er der for en konfiguration sat eventcode og practicesettingcodes på, skal disse også indgå i metdata for dokumtet for at de kommer med.

Der filtreres kun, hvis der ikke er valgt værdispring. Og filtreres dokumenter fra, giver det anledning til en fejltekst i svaret.

For opsætning se driftvejledningen.

Validering af Actor Query Parametre

Nogle actors har ikke love til at lave søgninger (ITI-18) på alle værdier i query parametrene.  Derfor kan man begrænse nogle actor/bruger typer på det parameter værdier de laver i søgningerne.

For nuværende drejer det sig om følgende brugertype:

• Borger på vegne af, med relationen fuldmagt, hvor fuldmagten kommer fra en fuldmagtstreng. Der skal være givet tilladelse til denne fuldmagtstreng for den anvendte typecode og formatcode værdi.
• Borger med forældremyndighed. Det skal være givet tilladelse til de anvendte typecode og formatcode værdier for denne brugertype.

For opsætning se driftvejledningen.

Arkitekturdesign

Dette afsnit beskriver statiske såvel som dynamiske aspekter af systemarkitekturen, herunder baggrunden for de enkelte designvalg.

Overblik

DDS Registry

Den generelle servicestruktur er at servicen implementeres som en webservice, der implementerer det webinterface, der er genereret fra DDS Registry WSDL. Webservicen DDSRegistryWS er en tynd skal, der for sin eneste weboperation til opslag i DDS Registry blot kalder den faktiske implementation DDSRegistryQueryImpl.

Figur 3a: Implementationen af webservice-interfaces

Der findes to alternative WSDL filer for operationen ITI-18 på DDS Registry og ITI-43 for DDS Repository, der gør de muligt at kalde DDS med en OIO IDWS billet. Forretningslogikken for disse snitflader er den samme som de klassiske DGWS snitflader.

Behandling af opslag

DDSRegistryQueryImpl forestår autentifikation og autorisation af anvendersystem vha. DGWSProvider. Som forberedelse til autentifikation og autorisation af bruger af webservicen foretager DDSRegistryImpl parsning og validering af SOAP-headerens HSUID-header vha. ValidatedHsuidAttributes.

Autentifikation og autorisation af bruger varetages af ServiceActorProvider, der som input tager den skabte instans af SecurityContext og ValidatedHsuidAttributes.  Der foretages en række check og valideringer, se ovenfor under afsnittet brugertyper.

Til behandling af opslaget kaldes DDSRegistryQueryLogic, som beskrevet i afsnit DDS Registry Query Logic.

DDSRegistryQueryImpl foretager fejlhåndtering ved at omdanne exceptions til SOAP fault med indhold som beskrevet i [DDS Registry query snitflade]. En undtagelse herfra er dog ved exception pga. negativt samtykke mod en sundhedsperson, hvor der dannes en advarsel i et tomt svar, også beskrevet i [DDS Registry query snitflade].

DDS Repository

Den generelle servicestruktur er at servicen implementeres som en webservice, der implementerer det webinterface, der er genereret fra DDS Repository WSDL [ITI-43++ SOAP 1.1 WSDL]. Webservicen er en tynd skal, der for sin eneste weboperation (til udtræk) blot kalder den faktiske implementation DDSRepository.

Figur 3b Implementationen af webservice-interfacet

DDSRepository forestår autentifikation og autorisation af anvendersystem vha. DGWSProvider.

Som forberedelse til autentifikation og autorisation af bruger af webservicen foretager DDSRepository parsning og validering af SOAP-headerens HSUID-header vha. ValidatedHsuidAttributes. Autentifikation og autorisation af bruger varetages af UserCheck, der som input tager den skabte instans af ValidatedHsuidAttributes. Er brugeren en sundhedsperson og er der anført ansvarlig sundhedsperson cpr- og autorisationsnummer (fra Sundhedsstyrelsen), foretager UserCheck desuden kontrol af sammenhængen mellem cpr- og autorisationsnummeret.

Til behandling af udtræk kaldes DDSRetrieveDocumentLogic, som beskrevet i afsnit 4.2.

DDSRepository foretager fejlhåndtering ved at omdanne exceptions til SOAP fault med indhold som beskrevet i [DDS Repository snitflade]. En undtagelse herfra er dog ved exception pga. negativt samtykke mod en sundhedsperson, hvor der dannes en advarsel i et tomt svar, også beskrevet i [DDS Repository snitflade].

Service business logik

DDS Registry

DDSRegistryQueryLogic implementerer den sekvens af kald af services og håndtering af fejlsituationer, der er beskrevet i afsnit 2.3.1.1. Dog håndteres autentificering og autorisation beskrevet i afsnittet af DDSRegistryQueryImpl som beskrevet ovenfor.

Figur 4a DDSRegistryQueryLogic får dependency injected et antal delegates, der varetager kald til de forskellige services.

DDSRegistryQueryLogic forestår orkestrering af kald til de forskellige services, hvor kaldene er pakket ind i ”invokere”:

• ConsentVerificationServiceInvoker indkapsler kald af ConsentUserCheck og ConsentDataCheck på samtykkeverifikationsservicen. Se [ConsentVerificationService ws] for beskrivelse af kaldte webservice-snitflade.
• DocumentRegistryInvoker forestår videresendelse af opslaget til IHE Registry-servicen. Dette sker gennem et webservice-interface beskrevet i [IHE WSDL] og [IHE XSD].
• MinLogRegistrationInvoker indkapsler kaldet til MinLogRegistration-servicen. Se [MinLogService ws] for beskrivelse af kaldte webservice-snitflade.
• TreatmentRelationInvoker laver kaldet til behandlingsrelationsservicen. Se [Behandlingsrelationsservice ws] for beskrivelse af kaldte webservice-snitflade.
• ConsentOverrideLoggingInvoker indkapsler den måde, logning af værdispring er implementeret.

Derudover gør DDSRegistryQueryLogic brug af ConsentFilter, der implementerer den betingede filtrering af metadata i resultatet fra opslaget på IHE Registry. ConsentFilter kommer kun i anvendelse, når en sundhedsperson laver opslag uden anvendelse af værdispring og når sundhedspersonen er omfattet af data-specifikke samtykker.

Figur 5a UML Sekvensdiagram for DDSRegistryQueryLogic

I Figur 5a er vist et sekvensdiagram for DDSRegistryQueryLogic ved opslag foretaget af en sundhedspersons uden anvendelse af værdispring, hvor: der ikke er personligt negativt samtykke mod sundhedspersonen eller den ansvarlige sundhedsperson; der er data-specifikt negativt samtykke.

DDS Repository

DDSRepository implementerer den sekvens af kald af services og håndtering af fejlsituationer, der er beskrevet i afsnit 2.1.1. Dog håndteres autentificering og autorisation af DDSRepository som beskrevet ovenfor. 

Figur 4b DDSRetrieveDocumentLogic får dependency injected et antal delegates, der varetager kald til de forskellige services.

DDSRepository forestår orkestrering af kald til de forskellige services, hvor kaldene er pakket ind i ”invokere”:

• ConsentVerificationServiceInvoker indkapsler kald af ConsentUserCheck på samtykkeverifikationsservicen. Se [ConsentVerificationService ws] for beskrivelse af kaldte webservice-snitflade.
• DocumentRetrieveInvoker forestår videresendelse af udtræk til et kildesystems ITI-43 snitflade. Dette sker gennem et webservice-interface beskrevet i [IHE Document Repository WSDL] og [ITI TF-2].
• MinLogRegistrationInvoker indkapsler kaldet til MinLogRegistration-servicen. Se [MinLogService ws] for beskrivelse af kaldte webservice-snitflade.
• TreatmentRelationInvoker laver kaldet til behandlingsrelationsservicen. Se [Behandlingsrelationsservice ws] for beskrivelse af kaldte webservice-snitflade.
• ConsentOverrideLoggingInvoker indkapsler den måde, logning af værdispring er implementeret.

I Figur 5b er vist et sekvensdiagram for DDSRepository.

Figur 5b Sekvensdiagram for DDSRetrieveDocumentLogic

Overblik over konfigurationsmuligheder for dokumentsøgning og hentning

Dette afsnit giver først, vha. en figur et helt overordnet overblik over, hvor der er muligheder for at påvirke det resultat, som en anvender fremsøger/henter af dokumenter. Efterfølgende er der i en tabel en mere detaljeret beskrivelse af disse. 

Overordnet overblik

I DDS registry og DDS repository, er der flere steder, hvor det er muligt at konfigurere opsætning, som påvirker, hvordan og hvad en anvender får tilbage af fremsøgning (iti-18 registry) og hentning (iti-43 repository).

I den følgende figur er dette illustreret for DDS registry henholdsvis DDS repository for de 2 går søjler: ITI-18 og ITI-43. Detaljer omkring de forksellige konfigurationer kan findes i afsnittet efter.

Figuren viser 4 logiske knudepunkter i DDS servicen og hvilke konfiguration der anvendes hvor:

• Validering af forespørgsel: valideres på vej ind i servicen og anvender får en fejl uden der faktisk foretaget søgning. Undtagelse: frabedelsescheck effektueres først efter fremsøgning.
• Opsæt af muligheder: fremfinding af det grundlag, som dokumenterne skal søges i
• Filtering af muligheder: filtrering/begrænsning af det datagrundlag, som søges i.
• Filtrering af dokumenter: når søgningen er foretaget, kan dokumenter, som ikke må returneres blive filtreret fra

Figur: konfigurationsoverblik

Detaljer omkring konfigurationerne

Nedenfor er hver konfiguration beskrevet.  Tabellen indeholder følgende kolonner:

Analysen er dokumenteret vha. en tabel med følgende kolonner:

• Id: id og navn som konfigurationen er kendt under
• Formål: formålet med konfigurationen.
• Brugertype: hvilke brugertyper gælder konfigurationen for. Der anvendes brugertyperne fra sourcekoden, som kan mappes som følger
  • Citizen - Borger
  • CitizenOnBehalfOf - BorgerPåVegneAf med undertyperne
    • proxyHolder - fuldmagtshaver
    • childCustodyHolder - forældremyndighedshaver
  • HealthCareProfessionalWithAuthorization - Sundshedsfaglig med authorisation
  • HealthCareProfessionalWithoutAuthorization - Sundshedsfaglig uden authorisation
  • HealthCareProfessionalOnBehalfOf - Sundhedsfaglig på vegne af
• Aktivering: hvor "møder" anvenderen begrænsningen. Mulighederne er som angivet i ovenstående figur.
• Kald: Er der tale om fremsøgning i registry (iti18) eller hentning i repository (iti43)
• Muligheder: hvilke konfigurationsmuligheder er der, og hvor er det defineret.
• Udtryk: hvordan kommer begrænsningen til udtryk? Fejlbesked, filtrering etc
  • SoapFault: bruger får en "hård" fejl (intet ihe svar og dermed ingen dokumenter)
  • Fejl: brugeren får en fejl i ihe svaret og 0 eller flere dokumenter
  • Advarsel: brugeren får en eller flere advarsler i ihe svaret og 0 eller flere dokumenter
  • Alt ok: brugeren får 0 eller flere dokumenter
• Faktisk konfiguration: link til hvordan drift faktisk er sat op

Generel struktur af invoker

Fælles for de service-invokere, der er beskrevet i foregående afsnit er at de hver især har ansvar for:

• at indhente krævede konfigurationsparametre (fx URL for kaldte service)
• at etablere og om nødvendigt genetablere kontakt til servicen
• at gennemføre kald af den eller de operationer
• at håndtere og indkapsle alle fejl

Der er overordnet to typer af invokers: Dem med og dem uden DGWS sikkerhed.

Invoker med anvendelse af DGWS

Når der laves kald af ConsentVerificationServiceInvoker og TreatmentRelationInvoker skal det foregå med et SOSI Idkort. Det er DDS's ansvar at anskaffe et system idkort således, at dette kald kan gennemføres.

Der er lavet generel håndtering af disse system idkort herunder caching.

Der er også tilfælde, hvor backends for enten DDS Registry eller DDS Repository forventer at få akkreditiver med i kaldet. Her er det som udgangspunkt den samme sikkerhedsbillet, som blev anvendt til DDS selv, der delegeres videre til den modtagende backend. Hvis DDS Registry eller DDS Repository bliver kaldt med en IDWS billet er videre delegering ikke muligt p.g.a Holder-of-key constraint. I dette tilfælde vil DDSens eget system idkort anvendes, som beskrevet ovenfor for kald til MInSpærring og BRS.

Invoker uden anvendelse af DGWS

Der er backends for både DDS Registry og DDS Repository, der ikke foreventer en sikkerhedsbillet. NXRG er et eksempel på dette. Til dette formål anvendes en serviceinvoker uden DGWS.

ConsentOverrideLoggingInvoker foretager blot logning lokalt og kalder ikke nogen service.

SLA logning

SLA loggeren sørger for at foretage SLA logning af alle servicekald.

SLA loggeren er implementeret som et servlet filter defineret i webapplikationens web.xml-fil.

MinLog

På et tidspunkt blev alle ITI-18 søgninger logget i MinLog med den samme konfigurerbare sætning. Dette er nødvendigt hvis søgningen returnerer flere forskellige dokumenttyper. Hvis en søgning er begrænset med en enkelt kendt TypeCode kan man dog godt konkludere at anvenderen kun har fået adgang til en bestemt slags dokumenter, hvilket kan afspejles i den sætning der logges i MinLog. Derfor udvides løsningen med denne mulighed, samt yderligere detaljeringsgrad ved også at kigge på formatcode og classcode i bestemmelse af minlog teksten.

Ved at sammenligne en ITI-18 søgnings søge parametre med opsætning i en database findes en mere detaljeret tekst til logningen. Hvis det ikke er muligt, at finde en detaljeret tekst, anvendes den oprindelige default opsætning. Der kan være flere grunde til Ikke at kunne finde en detaljeret tekst; flere forskellige værdier af de forskellige koder i kaldet, f.eks. at der både søges på aftaler og graviditetsmappe dokumenter, at der ikke er angivet nogen af de søgekriterier vi undersøger på, eller at der ikke er sat noget konfiguration op, på det anvendte søge kriterie. I sidstnævnte logges dette som en warning.

Anvendes parametren %s i den detaljerede tekst, findes en erstatnings tekst i en brugertype tabel baseret, på den rolle, der har lavet kaldet. 

De detaljerede tekster findes i følgende tabeller

minlog_text:

id

typecode_codename

typecode_schemename

classcode_codename

classcode_schemename

formatcode_codename

formatcode_schemename

text

minlog_usertype_text:

usertype

text

Mulige roller i feltet "usertype" til fremfinding af erstatningstekst er:

• professionalUser
• professionalUserConsentOverride
• childCustodyHolder
• proxyHolder
• citizen

Eksempler på scenarier og deres konkret tekst udfald.

Eksempel 1: der søges kun på een typecode. I minlog_text findes: "Opslag på aftale"

Eksempel 2: der søges kun på een typecode. I minlog_text findes: "Opslag på labsvar fra %s". proxyholder rollen slåes op i minlog_usertype_text og teksten bliver: "Opslag på labsvar fra fuldmagtshaver"

Eksempel 3: der søges på to typecodes. Default værdi for proxyholder anvendes og teksten bliver: "Opslag af oplysninger fra fuldmagtshaver"

Eksempel 4: der søges på en typecode, der ikke findes i databasen. Default værdi for childCustodyHolder anvendes og teksten bliver: "Opslag af oplysninger fra forældremyndighedsindehaver"

Integration og test

Integrationsstrategi

Der er ikke nogen specifik rækkefølge hvori DDS Registry og Repository og de services, den kalder, skal integreres.

I kraft af dens fejlhåndtering kan opslag gennemføres når blot datasources, servicen til IHE Registry, et kildesystems ITI-43-snitflade og samtykkeverifikationsservicen er tilgængelige.

For succesfuld gennemførelse af integrationstests skal alle services, DDS er afhængig af dog være tilgængelige.

For en beskrivelse af byggeprocessen og eksterne/interne afhængigheder for servicen, se [DDS udvikling].

Unit test og Integrationstests

Se testvejledningen for detaljer omkring dette [DDS Test]