1      Introduktion

1.1     Formål

DDS Repository tilbyder en snitflade til udtræk af dokumenter. Baseret på opslag på patienter i Dokumentdelingsservice Registry kan et anvendersystem benytte snitfladen for DDS Repository til at udtrække dokumenter.

Formålet med dette dokument er at beskrive systemarkitekturen for DDS Repository. For et overblik over systemet henvises til afsnit 4.1.

1.2     Læsevejledning

Nærværende dokument er tiltænkt udviklere og IT-arkitekter med interesse i anvendelsen af DDS 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.

1.3     Dokumenthistorik

1.4     Definitioner og referencer

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

2       Introduktion til DDS Repository

2.1          Overblik over løsningen

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.

Ved kald af webservice-operationen Retrieve Document Set på DDS Repository gennemføres følgende:

• Autentificering og autorisation af anvendersystemet
• Audit-logning af brugers (forsøg på) udtræk af dokumenter om patient
• Autorisation af bruger
• Logning i værdisprings-log, hvis bruger er sundhedsperson og foretager værdispring
• Logning i Min-log-servicen, hvis bruger er sundhedsperson
• Kontrol af samtykke mod sundhedsperson, hvis bruger er sundhedsperson og værdispring ikke er foretaget. Er der samtykke(r) mod sundhedspersonen returneres svar med notits herom.
• Bestemmelse af dokumentkildes webservice-endpoint
• Indhentning af dokument(er) fra dokumentkilde
• Kontrol af data-specifikke samtykker, hvis bruger er sundhedsperson og værdispring ikke er foretaget.
  Denne kontrol er betinget af, at dokumentkilden kontrollerer data-specifikke samtykker. Derved foretages evt. frafiltrering af dokumenter/dokument-dele med tilhørende notits herom i svaret
• Igangsættelse af check af behandlingsrelation mellem borger og sundhedsperson, hvis bruger er sundhedsperson.
  
  

DDS Repository:

• overholder Den Gode Web Service 1.0.1 (med få undtagelser som beskrevet i [DDS Repository snitflade])
• kræver anvendersystem autentificeret af STS’en på NSP med minimum sikkerhedsniveau 3
• kræver anvendersystem autoriseret, hvilket kontrolleres vha. whiteliste
• kræver bruger og patient identificeret ved brug af attributter i en ekstra header, HSUID-headeren.
• returnerer SOAPFault ved autentifikations- og autorisationsfejl samt ved visse systemfejl.

DDS Repository anvender eksterne ressourcer som vist i Figur 1 til at foretage behandling af et udtræk. Denne behandling er beskrevet i det følgende afsnit.

Figur 1 Anvendelse af services og databaser fra DDS Repository

2.1.1      Fordeling af ansvar

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

• DDS Repository 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 3.2.1.

2.2          Behandling af udtræk i DDS Repository

Hvad enten bruger af DDS Repository er borger eller sundhedsperson foretages først autentificering og autorisering af henholdsvis anvendersystem og bruger. Autorisation af anvendersystemet sker mod en whitelist i databasen.

Er bruger en borger viderestilles udtræk direkte til IHE Repository, og resultatet derfra returneres til anvendersystemet.

Er bruger en sundhedsperson sker følgende:

1. Er der anført cpr-nummer og Sundhedsstyrelsens autorisationsnummer for en sundhedsperson, som er ansvarlig for udførsel af udtræk, kontrolleres overensstemmelse mellem cpr-nummer og autorisationsnummer i et autorisationsregister i database.
   
   1. Uoverensstemmelse mellem cpr-nummer og autorisationsnummer bevirker fejl af udtræk
   2. Teknisk fejl i forbindelse med kontrollen bevirker logning, men ingen fejl af udtræk
2. Ved kald af LogDataAdd på MinLogRegistration-servicen foretages logning af sundhedspersonens adgang til borgerdata.
   
   1. Fejl i kald af MinLogRegistration-servicen bevirker logning, men ingen fejl af udtræk
3. Medmindre der er tale om værdispring, gennemføres kontrol af samtykke mod sundhedspersonen gennem kald af ConsentForUserCheck på samtykkeverifikationsservicen.
   
   1. Fejl i kald af samtykkeverifikationsservicen bevirker fejl af udtræk
   2. Er der personligt negativt samtykke mod sundhedspersonen eller mod den sundhedsperson under hvis ansvar, der foretages udtræk, da returnerer udtræk med en advarsel om, at samtykke forhindrer adgang til borgerdata
4. Bestemmelse af kildesystem(er) ved opslag på homeCommunityId og evt. repositoryUniqueId fra request som beskrevet i afsnit 2.2.1.
   1. Kan et eller flere kildesystemer ikke bestemmes, tilføjes en advarsel til svaret (der om nødvendigt også skabes)
5. Udtræk viderestilles til fremfundne kildesystemers ITI-43 snitflade
   1. Tekniske fejl i forbindelse med kald af et kildesystems ITI-43 snitflade bevirker ikke fejl af udtræk (i stedet tilføjes advarsel herom til svaret)
6. Igangsættelse af kontrol af behandlingsrelation sker ved kald af Behandlingsrelationsservicen, medmindre det er konfigureret at servicen ikke skal kaldes.
   
   1. Fejl i kald af Behandlingsrelationsservicen bevirker logning, men ikke fejl af opslaget.
7. Det potentielt reducerede resultat returneres.

2.2.1      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-2a] 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-2b] 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)

2.3     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).

3       Designmålsætninger og -beslutninger

3.1          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

3.2          Designbeslutninger

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

3.2.1       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)

3.2.1.1     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.

3.2.2      Anvendelse af SOAP 1.1 for DDS Repository webservices

Snitfladen for DDS 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 Repository 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].

3.2.3      Angivelse af patient-identifikation

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.

3.2.4      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 afsnit 3.2.3 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.

3.2.5      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.

3.2.6       Øvrige designbeslutninger

3.2.6.1     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.

3.2.6.2     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.

3.2.6.3     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 Repository 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.

3.2.6.4     Audit logning

Audit logning foregår også gennem log4j, til kategorien ”audit”. Auditlogning skal logge

• Tidspunkt (zulu tid)
• Bruger-id
• Type af anvendelse
• Borgeren
• CVR for kaldende system
• Sessions-id fra DGWS

Typen af anvendelse er metodekaldet.

3.2.6.5     Statisk konfiguration i property-fil

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 Repository drift].

Applikationskonfiguration konfigureres i filen 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 Repositorys 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 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.
• Auditloggen konfigureres med en log4j-logger property med navn log4j.logger.audit.
• 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.

3.2.6.6     Dynamisk konfiguration i database

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

3.2.6.7     Brug af datasources

DDS 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.
• en datasource med navn ’DocumentSourcesDS’, der har adgang til documentsources databasen til brug ved opslag af IHE repository.

3.2.6.8     Implicitte headere i WSDL

For at DDS 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 Repository WSDL, men ikke input/output-beskederne.

3.2.6.9     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.

3.2.6.10  Advarsler i svaret

For entydigt at kunne kommunikere, at samtykkebegrænsninger har bevirket fravær af metadata i svaret fra DDS Registry, er det valgt at benytte IHE-standardens mulighed for implementationsspecifikke fejlbeskrivelser. Alternativt skulle et af IHE-standardens fejlkoder, som beskrevet i afsnit 4.1.13 i [ITI TF-3], være anvendt på bekostning af entydighed for så vidt angår årsagen til fejlen/advarslen.

I afsnit 4.1.13 i [ITI TF-3] 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 Repository snitflade] for de konkrete anvendelser af implementationsspecifikke fejl/advarsler.

3.2.6.11  Beslutning vedrørende servicearkitektur

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

4       Arkitekturdesign

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

4.1          Overblik

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 3 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].

4.2          Service business-logik

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 4 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-2b].
• 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 5 er vist et sekvensdiagram for DDSRepository.

Figur 5 Sekvensdiagram for DDSRetrieveDocumentLogic

4.3          Generel struktur af invoker

Fælles for de service-invokere, der er beskrevet i afsnit 4.2 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 webservice-operation(er)
• at håndtere og indkapsle alle fejl

4.3.1       Invoker med implicit DGWSConsumer-anvendelse

For ConsentVerificationServiceInvoker, MinLogRegistrationInvoker og TreatmentRelationInvoker anvendes serviceklienter, der arver fra SosiService. Derved får de ved instantiering automatisk en DGWSConsumer-instans og altså også cached ID-kort-håndtering. Når der laves kald af disse services bliver et ID-kort, der stadig er gyldigt, genbrugt fra tidligere kald, og om nødvendigt bliver nyt ID-kort indhentet automatisk fra STS.

Ved de tre invokere’s kald af operationer på hhv. samtykkeverifikationsservicen, MinLogRegistration-servicen og behandlingsrelationsservicen benyttes DGWSConsumer til at skabe de nødvendige DGWS-headere (Medcom- og sikkerhedsheader).

Ved kald til hhv. samtykkeverifikationsservicen og MinLogRegistration-servicen, der begge i tilgift forventer en HSUID-header, genbruges HSUID-headeren modtaget med kaldet af DDS Repository.

4.3.2       Invoker uden DGWSConsumer eller STS-anvendelse

4.3.2.1     DocumentRetrieveInvoker

DocumentRetrieveInvoker er speciel derved, at kildesystemers ITI-43 snitflade ikke overholder DGWS og derfor ikke kræver ID-kort indhentet fra STS for at kunne kaldes.

Figur 6 Karakteristika for snitflader

4.3.2.2     ConsentOverrideLoggingInvoker

ConsentOverrideLoggingInvoker foretager blot logning lokalt og kalder ikke nogen service.

4.4          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.

5       Integration og test

5.1          Integrationsstrategi

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

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

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

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

5.2          Integrationstests

Der findes følgende integrationstestklasse til DDS Repository: DDSRepositoryIT.

DDSRepositoryIT verificerer, at DDS Repository:

• accepterer valide ID-kort med sikkerhedsniveau 3 og 4 i sikkerhedsheaderen
• ikke accepterer ID-kort med sikkerhedsniveau 1
• kun accepterer kald fra anvendersystemer, der optræder på dens whiteliste
• tillader autentificeret og autoriseret borger at foretage opslag
• tillader autentificeret og autoriseret sundhedsperson at foretage opslag, i forskellige varianter med og uden hhv. værdispring, samtykker imod sig, etc.
• afviser kald hvor datoformatet krævet af DGWS 1.0.1 ikke er overholdt
• foretager SLA-logning

5.3          Unittests

Der findes en række unittests, der sikrer at de forskellige del-komponenter er implementeret korrekt. Fx verificeres med DDSRetrieveDocumentLogicTest at services anvendes og at fejl håndteres som forventet i forskellige situationer.