Introduktion

Formål

DDS Registry er en national service til

...

For et overblik over systemet henvises til afsnit Arkitekturoverblik.

Læsevejledning

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

Dokumenthistorik

Definitioner og referencer

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

...

Introduktion til DDS Registry

Baggrund for opslag i DDS Registry

Baggrunden for at tilbyde opslag gennem DDS Registry er:

...

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

Baggrund for registrering i DDS Registry

Baggrunden for registrering i DDS Registry er naturligvis, at opslag kun giver mening i det omfang, der findes data i indekset. Selvom opslag kunne returnere indhold fra andre indeks ved brug af IHE XDS Cross-Community Access (XCA), så opnås bedre performance ved at have indhold i det lokale indeks, dvs. i IHE Registry.

...

1. Der kan etableres multiple DDS Registry-instanser, således at registrering til et enkelt IHE Repository kan foregå gennem flere adgangspunkter. Der kan fx etableres en DDS Registry pr. region med adgang til det ene IHE Repository.

2. NSP-baserede sikkerhedsløsninger kan anvendes til kontrol af, hvilke kildesystemer, der må foretage registrering i IHE Repository.

3. Sikring af overholdelse af affinitetsdomænet. Ved registrering af dokument-metadata kan der foretages skræddersyet validering af brug af klassifikationer og koder. Det er ikke givet, at det bagvedliggende IHE Registry kan varetage denne opgave.

4. Tidspunktet for en kildes seneste registrering kan opsamles (pt. er dette dog ikke implementeret) og returneres som ekstra information ved opslag. Derved kan en dokumentanvender afgøre, om alderen på dokument-metadata skyldes kildesystemets manglende forbindelse til indekset.

Overblik over løsningen

Der etableres med løsningen en DDS Registry web service, som giver mulighed for opslag i DDS Registry for både sundhedspersoner og borgere. Dette er beskrevet i DDS Registry opslag.

Med løsningen giver DDS Registry web service tillige mulighed for at kildesystemer kan registrere metadata om dokumenter om patienter, beskrevet i afsnit DDS Registry registrering.

Anchor
DDS Registry opslag DDS Registry opslag

DDS Registry opslag

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.

...

Figur 1:  DDS Registry anvender ved opslag andre services og databaser

Behandling af opslag

Hvad enten bruger af DDS Registry er borger eller sundhedsperson foretages først autentificering og autorisering af henholdsvis anvendersystem og bruger.

...

1. Er der anført cpr-nummer og Sundhedsstyrelsens autorisationsnummer for en sundhedsperson, som er ansvarlig for opslaget, kontrolleres overensstemmelse mellem cpr-nummer og autorisationsnummer i et autorisationsregister i database.

   1. Uoverensstemmelse mellem cpr-nummer og autorisationsnummer bevirker fejl af opslaget,

   2. Fejl i kontrollen bevirker logning, men ingen fejl af opslag

2. Ved kald af LogDataAdd på MinLogRegistration-servicen foretages logning af sundhedspersonens adgang til borgerdata.

   1. Fejl i kald af MinLogRegistration-servicen bevirker logning, men ingen fejl af opslag

3. Medmindre der er tale om værdispring, gennemføres kontrol af samtykke mod sundhedspersonen ved kald af ConsentForUserCheck på samtykkeverifikationsservicen.

   1. Fejl i kald af samtykkeverifikationsservicen bevirker fejl af opslaget

   2. Er der personligt negativt samtykke mod sundhedspersonen eller mod den sundhedsperson under hvis ansvar, der foretages opslag, da returnerer opslaget med en advarsel om, at samtykke forhindrer adgang til borgerdata

4. Opslaget viderestilles til IHE Registry

   1. Fejl i kald af IHE Registry bevirker fejl af opslaget

5. Medmindre der er tale om værdispring og medmindre forrige kald af samtykkeverifikationsservicen viste, at der ikke findes data-specifikke samtykker registreret for borgeren, gennemføres kontrol af data-specifikke samtykker mod sundhedspersonen. Dette sker ved kald af ConsentForDataCheck på samtykkeverifikationsservicen under anvendelse af udtræk fra resultatet fra IHE Registry.

   1. Fejl i kald af samtykkeverifikationsservicen bevirker fejl af opslaget

   2. Er der dele af resultatet fra IHE Registry, hvor der ikke er samtykke til adgang:

      1. Fjernes delene fra resultatet

      2. Tilføjes en advarsel om, at der er tilbageholdt borgerdata på grund af samtykkebegrænsning

6. Igangsættelse af kontrol af behandlingsrelation sker ved kald af Behandlingsrelationsservicen, medmindre det er konfigureret at servicen ikke skal kaldes. En SOR lookup-database indeholdende mapninger mellem SHAK-koder og SOR-koder hhv. mellem ydernumre og SOR-koder anvendes, hvis der i opslaget ikke er opgivet SHAK-kode eller ydernummer.

   1. Fejl i kald af Behandlingsrelationsservicen bevirker logning, men ikke fejl af opslaget.

   2. Fejl i mapning til SHAK-kode eller ydernummer bevirker logning, men ikke fejl af opslaget.

7. Det potentielt reducerede resultat returneres.

Anchor
DDSRegistryBrugertyperAdgangsscenarier DDSRegistryBrugertyperAdgangsscenarier

Brugertyper og adgangsscenarier

DDS Registry understøtter en række brugertype og adgangsscenarier. Disse brugertyper stille 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 og adgangsscenarier

DDS Registry understøtter følgende DDS brugertyper:

...

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 DGWS

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

...

Adgangsscenarier og tests

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

...

For afvikling af integrationstests henvises til dokumenterne Testvejledning DDS Registry og Testvejledning DDS Repository.

DDS Registry registrering

Der er to operationer til registrering af metadata om dokumenter: en operation til registrering af såkaldt statiske dokumenter og en til on-demand-dokumenter.

...

Figur 2:  Til registrering anvender DDS Registry de viste services og databaser

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.

...

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

Auditlogning

Auditlogning i DDS Registry sker vha AuditAPI'et (introduceret i

...

ITI-42, ITI-61, ITI-57: foretag auditlogning for hver DocumentEntry (DE) i request DE.uniqueId, DE.repositoryUniqueId, DE.homeCommunityId, DE.typeCode

Statisk konfiguration i propertyfil

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

...

• Generel DDS Registry 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 Registry skal have adgang til en datasource ved navn ’WhitelistDS’ for at kunne lave autorisation af anvendersystemer vha. whitelist.

Brug af datasources

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

Implicitte headers i WSDL

For at DDS Registry 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 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 fejlkoder, som beskrevet i afsnit 4.1.13 i [IHE vol. 3], være anvendt på bekostning af entydighed for så vidt angår årsagen til fejlen/advarslen.

...

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

Beslutning vedrørende servicearkitektur

Da DDS Registry 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, MinLog og Behandlingsrelationsservice udføres i parallel, hvert kald som synkront kald.

Beslutninger vedrørende kald til BRS

Såfremt det ikke lykkes at mappe SOR-koden til en SHAK-kode eller et ydernummer skal Behandlingsrelationsservice ikke kaldes. Dette skal dog logges. Såfremt Behandlingsrelationsservice kaldes og kaldet fejler skal DDS-kaldet også fejle.

Anvendelse af thread local request context

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

...

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

Arkitekturdesign

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

Overblik

Den generelle servicestruktur er at servicen implementeres som to webservices, 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. De to weboperationer til registrering håndteres af DDSRegistryRegisterImpl.

...

Figur 3: Implementationen af webservice-interfaces

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.

...

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

Behandling af registrering

DDSRegistryRegisterImpl foretager også autentifikation og autorisation af anvendersystem vha. DGWSProvider. Da registrering håndteres som system-til-system-kald gennemføres ingen bruger-autentifikation eller –autorisation.

Øvrig behandling af registrering foretages i DDSRegistryRegisterLogic beskrevet i afsnit DDS Registry Register Logic.

Service business logik

DDSRegistryQueryLogic

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.

...

I Figur 5 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.

DDSRegistryRegisterLogic

DDSRegistryRegisterLogic foretager validering af registrerings-requesten – for nuværende implementeret i hjælpeklassen SubmitObjectsRequestWrapper. Derefter kaldes den dependency-injectede DocumentRegistryInvoker (se forrige afsnit) med henblik på at registrere i IHE Repository. Endelig foretages audit-logning, der fastholder hvilket system, der har registeret dokument-metadata om en borger.

Generel struktur af invoker

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

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

Invoker med implicit DGWSConsumer-anvendelse

Når der laves kald af ConsentVerificationServiceInvoker, MinLogRegistrationInvoker og TreatmentRelationInvoker genanvendes det indkommende ID-kort anvendt ved dokumentanvenders kald af DDS. Der skabes en kopi af indkommende Medcom-header, dog med nyt MessageId.

Ved kald til samtykkeverifikationsservicen, der i tilgift forventer en HSUID-header, genbruges HSUID-headeren fra DDS Registry-opslaget.

Invoker uden DGWSConsumer eller STS-anvendelse

DocumentRegistryInvoker er speciel derved, at IHE Registry ikke overholder DGWS og derfor ikke kræver ID-kort indhentet fra STS for at kunne kaldes.

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.

Integration og test

Integrationsstrategi

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

...

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

Integrationstests

Der findes integrationstests, der matcher de dokumenterede adgangsscenarier ovenfor.

Følgende illustration er et screenshot af en afviklet integrationstest mod TEST02. Bemærk, hvordan de overordnede adgangsscenarier er implementeret i hver deres testklasse. De specifikke tests ligger som metoder under hver testklasse.

Unittests

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

...