...

...

...

...

...

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å). Der findes følgende tranformationer:

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:

• Sundhedsfaglig alm og på vegne af:
  • organisationIdtype fra hsuid
  • organisationId fra hsuid
  • titel bliver sat til at være educationCode (anvendes i forbindelse med MinLog)
• 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ærdi (anvendes i forbindelse med MinLog)
• Borger
  • titel bliver sat med konfigurerbar default værdi (anvendes i forbindelse med MinLog)

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

...

Samtykkeservice

...

MinLog Service

...

Behandlingsrelationservice

...

Kaldes for at se, om der skulle foreligge et negativt samtykke mod den sundhedspersonen eller den organisations, som vedkommende repræsenterer.

I tilfældet S3, hvor der arbejdes på vegne af en anden, så er det den sundhedsperson og organisation, der arbejdes på vegne af, der tjekkes.

Ved værdispring springes samtykketjek over

...

Ja

I tilfældet S3, hvor der arbejdes på vegne af en anden, så er det den sundhedsperson og organisation, der arbejdes på vegne af, der logges.

...

Ja

I tilfældet S3, hvor der arbejdes på vegne af en anden, så er det den sundhedsperson og organisation, der arbejdes på vegne af, der tjekkes.

...

...

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.

Image Added

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

Image Added

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.

Image Added

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.

Image Added

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.

Image Added

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. 

Image Added

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.

Image Added

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

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
• SF1: sf_soeg_aftaler.feature
• SF1: sf_soeg_alle_dokumenttyper.feature
• SF1: sf_soeg_alle_dokumenttyper_byreferenceid.feature
• SF1: sf_soeg_labsvar.feature
• S3: <der findes ingen test>
• 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.

...

Mål

...

Prioritet

...

Bemærkning

...

Correctness

...

5

...

Den overordnede funktionalitet omhandler patientsikkerhed og er reguleret af et omfattende lovgrundlag.

...

Reliability

...

4

...

Prioriteret aht. patientsikkerhed.

...

Usability

...

1

...

Ingen brugergrænseflade.

...

Security

...

4

...

Prioriteret for at opfylde lovkrav om beskyttelse af personhenførbare oplysninger.

...

Performance

...

3

...

De specifikke performancekrav er ikke kendte, men performance har været prioriteret.

...

Maintainability

...

3

...

Dokumentationskrav vedrørende arkitektur, vejledninger og API-dokumentation.

...

Flexibility

...

2

...

Løsningen består af web services. Det giver den nødvendige fleksibilitet i det overordnede system. De enkelte services behøver ikke være fleksible.

...

Testability

...

3

...

Løsningen skal være testbar via automatiske tests, da der ingen brugergrænseflade er.

...

Portability

...

1

...

De grundlæggende teknologivalg er foretaget. Der bør som udgangspunkt ikke laves bindinger specifikt til JBoss.

...

Reusability

...

1

...

Der er ingen forventning om genbrugelighed af DDS business-logikken og filtrering, da disse formodentlig kun vil finde anvendelse i DDS.

...

Interoperability

...

1

...

Gennem webservice-snitflader opnås den ønskede interoperabilitet.

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 Image RemovedSDS-2506 - Auditlogging af DDS via AuditAPI ARKIVERET ).

ITI-18: foretag auditlogning af patient-id, bruger-id, på-vegne-af-id 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 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.

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.

Image Removed

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

Image Removed

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.

Image Removed

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.

Image Removed

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. 

Image Removed

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.

Image Removed

...

Generel struktur af invoker

...

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

...

• professionalUser
• professionalUserConsentOverride
• childCustodyHolder
• proxyHolder
• citizen

Eksempler på scenarier og deres konkret tekst udfald.

...