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.

...

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:

...

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.

...

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. En SOR lookup-database indeholdende mapninger mellem SHAK-koder og SOR-koder hhv. mellem ydernumre og SOR-koder anvendes, hvis der i udtræk ikke er opgivet SHAK-kode eller ydernummer.
   1. Fejl i kald af Behandlingsrelationsservicen bevirker logning, men ikke fejl af opslaget.
   2. Fejl i mapning til SHAK-kode eller ydernummer bevirker logning, men ikke fejl af udtræk.
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:

...

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

...

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.

...

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.

...

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

...

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.

...

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

...

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.

...

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

...

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.

...

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

...