...

...

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

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

...

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

...

Figur 1 Anvendelse af services og databaser fra DDS

...

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

...

• overholder Den Gode Web Service 1.0.1 (med få undtagelser som beskrevet i snitfladerne)
  • registry også OIO IDWS for borgeradgang
• kræver anvendersystem autentificeret af STS’en på NSPregistry

• for sundhedsperson med minimum sikkerhedsniveau 4

• for borger med minimum sikkerhedsniveau 3 eller IDWS borgerbilletter

• repository
  • minimum sikkerhedsniveau 3
• kræver anvendersystem autoriseret, hvilket kontrolleres vha. whiteliste
• kræver bruger/patient identificeret ved brug af attributter i en ekstra header, HSUID-headeren.
• for repository skal også patient være identificeret i HSUID-headeren
• returnerer SOAPFault ved autentifikations- og autorisationsfejl samt ved visse systemfejl.

...

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

...

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

Brugertyper

...

DDS Registry understøtter følgende DDS brugertyper

...

• Borger (alm og på vegne af)
• Sundhedsperson (alm og på vegne af)
• Ikke-autoriseret sundhedsprofessionel
• Systembruger

...

med følgende overordnede muligheder:

• Borger: Borgere kan tilgå egne data, eller data på andre borgere, som de har en passende relation til (børn, fuldmagt)
• Sundhedsfaglig: Sundhedsfaglie kan tilgå data på borgere, hvis der er hjemmel til dette (behandlingsrelation, ikke-negativt samtykke, værdispring)
• Ikke-autoriseret bruger: Myndighedspersoner uden lægefaglig autorisation, men som har brug for at tilgå data på borgere (f.eks. adgang til aftaler for kommunale medarbejdere)
• System bruger: er der kun således at systemer (i

...

• praksis sundhed.dk) kan anvende DDS og ved hjælp af en medsendt HSUID header kan opnå status som een rigtig brugertype.

Bestemmelse og mapning til actor

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

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

Bestemmelse og mapning til actor

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

Transformation af brugertyper

En system bruger giver ikke mening i sig selv, og skal mappes over til en rigtig bruger. Andre brugertyper kan også mappes til andre typer på baggrund af hsuid header information. Der findes følgende tranformationer:

• System >> Sundhedsperson
• System >> Sundhedsperson på vegne af
• Sundhedsperson >> Sundhedsperson på vegne af
• Ikke-autoriseret sundhedsprofessionel >> Sundhedsperson på vegne af
• System >> borger
• System >> borger på vegne af
• borger >> borger på vegne af

Transformation af brugertyper

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

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

...

• Sundhedsperson alm og på vegne af:
  • organisationIdtype fra hsuid
  • organisationId fra hsuid
• Ikke autoriseret sundhedsprofessionel:
  • organisationIdtype fra hsuid
  • organisationId fra hsuid
  • hvis ingen antional rolle sættes rollen "ingen_idkort_rolle"
• CitizenOnBehalfOf
  • Relation mellem borgere findes

Brugertyperne bliver til sidst valideret for:

• Borger
  • audience skal være "https://audience.nspop.dk/dds"
• Alle roller
  
  • acting user cpr på security context skal matche den på hsuid header hvis udfyldt
• Borger på vegne af
  • Der skal være fundet en relation eller den påstående (via hsuid) relation skal kontrolleres
• Sundhedsperson og sundhedsperson på vegne af
  • hvis authorisationkode stammer fra hsuid header valideres denne kode
  • hvis authorisationkode stammer fra hsuid skal den matche den fra security context
• Den endelige brugertype må ikke være af typen System
• Der skal være een og kun een type

Brugertyper og adgangsscenarier

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

• Borger: Borgere kan tilgå egne data, eller data på andre borgere, som de har en passende relation til (børn, fuldmagt)
• Sundhedsperson: Sundhedspersoner kan tilgå data på borgere, hvis der er hjemmel til dette (behandlingsrelation, ikke-negativt samtykke, værdispring)
• Ikke-autoriseret sundhedsprofessionel: Myndighedspersoner uden lægefaglig autorisation, men som har brug for at tilgå data på borgere (f.eks. adgang til aftaler for kommunale medarbejdere)

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

...

ID

...

Som en...

...

ønsker jeg at..

...

ved anvendelse af værdispring

...

så jeg...

...

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

...

Adgangsscenarier og

...

tests

Ovenstående adgangsscenarier bestemmes i DDS Registry ud fra bruger- og kaldkonteksten i DGWS - nemlig SOSI Id-kort og HSUID headeren. 

DDS Registry bestemmer DDS brugertypen udfra kaldkonteksten: Nærmere bestemt udfra HSUID-headerens attributter UserType samt ResponsibleUserAuthorizationCode. Disse kan antage een af følgende værdier brugertyper:

...

Hver brugertype kræver, at der i det indgående kald findes et gyldigt SOSI id-kort. I det nedenstående gennemgåes de forskellige krav til fremskaffelsen af SOSI-idkortet for de forskellige brugertyper.

...

Borger (B1+B2)

...

Sundhedsperson (S1+S3)

...

Ikke-autoriseret bruger (IA-1)

...

Borger (B1+B2)

...

Sundhedsperson (S1+S3)

...

Ikke-autoriseret bruger (IA-1)

...

Bestemmes i sikkerhedshandleren for komponenten. En OIO IDWS billet betyder, at brugeren er en borger.

Hvis SOSI Idkort benyttes, så bestemmes brugertypen udfra HSUID headers attribut nsi:UserType (værdi 'nsi:Citizen')

...

Niveau 3 (F/VOCES - dette kræver særskilt aftale om anvendelse, jf Dokumentdelingsservice (DDS))

...

Niveau 4 (MOCES) 

...

Hvis OIO IDWS anvedes, så trækkes cpr nummeret ud af IDWS billetten.

Hvis DGWS benyttes, så bestemmes det udfra HSUID headers attribut nsi:ActingUserCivilRegistrationNumber

...

Bestemmes udfra HSUID headers attribut nsi:ActingUserCivilRegistrationNumber

For sekrætærer (S3) er det den person, der arbejdes på vegne af, der er relevant. Denne findes i HSUID headers attribut nsi:ResponsibleUserCivilRegistrationNumber

For scenariet S1 vil værdien af de to HSUID header attributter være ens.

...

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 (

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 ID som prefix og en efterfølgende beskrivende tekst , så sammenhængen med dokumenationen bevares.
• Alle testcases i integrationstestene er implementeret som metoder, der har en titel, der forklarer intentionen med testen.
• Alle testcases er bygge op efter samme skabelon med kommentarer, der 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:

• B1BorgerVocesIntegrationsTest
• B2BorgerPaaVegneAfVocesIntegrationsTest
• S1SundhedspersonMocesIntegrationTest
• S1SundhedspersonVocesIntegrationTest
• S3SundhedspersonPaaVegneAfMocesIntegrationsTest
• S3SundhedspersonPaaVegneAfVocesIntegrationsTest
• IA1IkkeAutoriseretBrugerLaegeSekretaerIntegrationsTest
• IA1IkkeAutoriseretBrugerSundhedsAssistentIntegrationsTest
• IA1IkkeAutoriseretBrugerUdenRollerIntegrationsTest

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

...

Asynkron involvering af kontrolservices

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

...

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

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

...

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.
• DocumentRetrieveInvoker DocumentRegistryInvoker forestår videresendelse af udtræk til et kildesystems ITI-43 snitfladeopslaget til IHE Registry-servicen. Dette sker gennem et webservice-interface beskrevet i [IHE Document Repository WSDL] og [ITI TF-2IHE 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.

I Figur 5b er vist et sekvensdiagram for DDSRepository.

Image Removed

Figur 5b Sekvensdiagram for DDSRetrieveDocumentLogic

Generel struktur af invoker

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

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

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

Invoker med anvendelse af DGWS

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

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

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

Invoker uden anvendelse af DGWS

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

ConsentOverrideLoggingInvoker foretager blot logning lokalt og kalder ikke nogen service.

SLA logning

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

...

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

Generel struktur af invoker

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

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

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

Invoker med anvendelse af DGWS

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

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

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

Invoker uden anvendelse af DGWS

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

ConsentOverrideLoggingInvoker foretager blot logning lokalt og kalder ikke nogen service.

SLA logning

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

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

MinLog

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

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

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

De detaljerede tekster findes i følgende tabeller

minlog_text:

id

typecode_codename

typecode_schemename

classcode_codename

classcode_schemename

formatcode_codename

formatcode_schemename

text

minlog_usertype_text:

usertype

text

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

• professionalUser
• professionalUserConsentOverride
• childCustodyHolder
• proxyHolder
• citizen

Eksempler på scenarier og deres konkret tekst udfald.

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

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

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

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

Integration og test

Integrationsstrategi

...