DDS Registry er en national service til
Formålet med dette dokument er at beskrive systemarkitekturen for DDS Registry.
For et overblik over systemet henvises til afsnit Arkitekturoverblik.
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.
Version | Dato | Ansvarlig | Beskrivelse |
1.0 | 29.6.2012 | Systematic | Initiel udgave |
1.1 | 11.3.2013 | Systematic | NPI registreringsservice tilføjet. Refaktorering af NPI Service gennemført i den forbindelse er afspejlet. |
1.1a | 19.4.2013 | Systematic | Udgave til release candidate 1 |
1.2 | 19.6.2013 | Systematic | Kvalitetssikret |
1.3 | 28.11.2014 | Systematic | Nationalt Patientindeks (NPI) erstattet med Dokumentdelingsservice (DDS) |
1.4 | 05.05.2015 | Systematic | Kodereferencer er opdaterede pga. navneskifte fra NPI til DDS |
1.5 | 18.11.2016 | Systematic | Afspejler adfærd for DDS 2.0.1. |
1.6 | 20.09.2017 | Systematic | Tilføjet 3.2.14 med bemærkning om binding til Apache CXF JAXWS-implementation aht. thread local request contexts. |
1.7 | 06.10.2017 | Systematic | ITI-57 UpdateDocumentSet tilføjet. |
1.8 | 26.10.2017 | Systematic | Tilføjet rationale for SLA-logning for udgående kald som fejlet ved forekomst af visse, indlejrede XDS-fejl. |
1.9 | 13.06.2018 | Systematic | Migreret til NSPOP SVN |
1.9 | 12.11.2018 | KvalitetsIT | Dokumentation lagt ind på Confluence |
2.0 | 21.01.2019 | KvalitetsIT | Afspejler adfærd for DDS 2.1.12 (tilføjet afsnit vedr. adgangsscenarier) |
2.1 | 05.06.2020 | KvalitetsIT | Opdateret efter IDWS implementering (https://jira.nspop.dk/browse/SDS-3898) |
Formålet med denne sektion er at give et overblik over definitioner og dokumenter, der benyttes i dette dokument
Definition | Beskrivelse |
DDS | Dokumentdelingsservice |
NSI | National Sundheds-IT |
NSP | Den Nationale Service Platform (inden for sundheds-IT) |
XCA | Cross-Community Access |
Alias | Beskrivelse |
Behandlingsrelationsservice ws | Behandlingsrelations- og Opfølgningsservice, Guide til Anvendere |
ConsentVerificationService ws | Consent Verification Service Interface Description (SSE/11734/IFS/0014) |
IHE vol. 3 | IHE Current Technical Framework – Revision 11.0, Vol. 3: (Transaction specifications) http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf |
IHE XSD | ftp://ftp.ihe.net/TF_Implementation_Material/ITI/schema/ebRS/* |
IHE WSDL | ftp://ftp.ihe.net/TF_Implementation_Material/ITI/wsdl/XDS.b_DocumentRegistry.wsdl |
MinLogService ws | Min-log web services interface (SSE/11734/IFS/0003) |
DDSRegistry drift | |
DDSRegistry udv | Guide til Udviklere DDS Registry (SSE/11734/PHB/0010) |
DDS Registry query snitflade | DDS Registry Querying Interface Description (SSE/11734/IFS/0016) |
Baggrunden for at tilbyde opslag gennem DDS Registry er:
”Formålet med NPI (Nationalt Patientindeks) er at tilvejebringe adgang til data om patienten fra forskellige datakilder via et indeks. Anvendersystemer (f.eks. Sundhedsjournalen) kan i indekset søge efter informationer om data på en given patient (metadata) og præsentere en oversigt over disse for sundhedsfaglige brugere og borgere. Såfremt en sundhedsfaglig bruger eller borger ønsker at få adgang til de bagvedliggende detaljerede patientdata, skal indekset levere tilstrækkelig information om, hvor og hvordan dette kan hentes. Hvis det system, der er kilde til data har etableret en standardiseret snitflade til at hente disse patientdata, vil den sundhedsfaglige bruger kunne hente disse, ligesom borgeren umiddelbart vil kunne hente data via sundhed.dk.
Indekset skal skabe adgang så:
borgeren har muligheden for at se data fra de professionelle om sine undersøgelser og behandlinger
de sundhedsprofessionelle 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
…
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.”
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.
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.
I DDS Registry’s implementation af Registry Stored Query fra IHE-standarden gennemføres desuden følgende ved sundhedspersons anvendelse af servicen:
Logning i Min-log-servicen
Igangsættelse af check af behandlingsrelation mellem borger og sundhedsfaglig
Filtrering af det returnerede svar ved verifikation af at borgerens registrerede samtykker ikke forhindrer at metadata vises
Mulighed for forceret fremsøgning (værdispring), som tilsidesætter check af samtykke
Anvendes Registry Stored Query af en borger anden end den borger, der er anført som patient, da gennemfører DDS logning i Min-log-servicen.
DDS Registry’s implementation af Registry Stored Query er, som beskrevet i [DDS Registry query snitflade], indpakket i headers, så den ud over IHE-standardens body:
overholder Den Gode Web Service 1.0.1 (med få undtagelser som beskrevet i [DDS Registry query snitflade]) samt OIO IDWS for borgeradgang
kræver anvendersystem autentificeret af STS’en på NSP
for sundhedsperson med minimum sikkerhedsniveau 4
for borger med minimum sikkerhedsniveau 3 eller IDWS borgerbilletter
kræver anvendersystem autoriseret, hvilket kontrolleres vha. whiteliste
kræver bruger identificeret ved brug af attributter i en ekstra header, HSUID-headeren.
returnerer SOAPFault ved autentifikations- og autorisationsfejl samt ved visse systemfejl.
DDS Registry anvender eksterne ressourcer som vist i Figur 1 til at foretage behandling af et opslag. Denne behandling er beskrevet i det følgende afsnit.
Figur 1: DDS Registry anvender ved opslag andre services og databaser
Hvad enten bruger af DDS Registry er borger eller sundhedsperson foretages først autentificering og autorisering af henholdsvis anvendersystem og bruger.
Autorisation af anvendersystemet sker mod en whitelist i databasen.
Er bruger en borger sker følgende:
Er bruger anden borger end patienten, foretages:
Kontrol af, at der er anført relation mellem borger og patient
Kald af LogDataAdd på MinLogRegistration-servicen, så der foretages logning af borgerens adgang til den anden borgers data.
Opslaget viderestilles til IHE Registry
Fejl i kald af IHE Registry bevirker fejl af opslaget
Er bruger en sundhedsperson sker følgende:
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.
Uoverensstemmelse mellem cpr-nummer og autorisationsnummer bevirker fejl af opslaget,
Fejl i kontrollen bevirker logning, men ingen fejl af opslag
Ved kald af LogDataAdd på MinLogRegistration-servicen foretages logning af sundhedspersonens adgang til borgerdata.
Fejl i kald af MinLogRegistration-servicen bevirker logning, men ingen fejl af opslag
Medmindre der er tale om værdispring, gennemføres kontrol af samtykke mod sundhedspersonen ved kald af ConsentForUserCheck på samtykkeverifikationsservicen.
Fejl i kald af samtykkeverifikationsservicen bevirker fejl af opslaget
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
Opslaget viderestilles til IHE Registry
Fejl i kald af IHE Registry bevirker fejl af opslaget
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.
Fejl i kald af samtykkeverifikationsservicen bevirker fejl af opslaget
Er der dele af resultatet fra IHE Registry, hvor der ikke er samtykke til adgang:
Fjernes delene fra resultatet
Tilføjes en advarsel om, at der er tilbageholdt borgerdata på grund af samtykkebegrænsning
Igangsættelse af kontrol af behandlingsrelation sker ved kald af Behandlingsrelationsservicen, medmindre det er konfigureret at servicen ikke skal kaldes.
Fejl i kald af Behandlingsrelationsservicen bevirker logning, men ikke fejl af opslaget.
Det potentielt reducerede resultat returneres.
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.
Først gennemgåes de forskellige brugertyper og adgangsscenarier på et overordnet niveau (User Stories). Herefter beskrives, hvordan DDS Registry anvender eksterne services (samtykke, minlog og behandlerrelationservice) i forhold til de forskellige scenarier.
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.
DDS Registry understøtter følgende DDS brugertyper:
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... |
---|---|---|---|---|
B1 | Borger | fremsøge dokumentreferencer til egne dokumenter | Nej | kan se mine egne data |
B2 | Borger | fremsøge dokumentreferencer til en anden borgers dokumenter | Nej | kan se data på denne person, som jeg har en relation til |
S1 | Sundhedsperson med autorisationsid | fremsøge dokumentreferencer til en borgers data | Ja / Nej | kan se data på denne borger |
S3 | Sekretær, der arbejder på vegne af en person med autorisation | fremsøge dokumentreferencer til en borgers data | Ja / Nej | kan se data på denne borger |
IA-1 | Ikke-autoriseret sundhedsprofessionel | fremsøge dokumentreferencer til en borgers data | Nej | kan se dokumenter for denne borger af de typer, som min rolle giver mig adgang til |
De forskellige adgangsscenarier giver anledning til forskellige anvendelser af eksterne services. Disse anvendelser er opsummerert i nedenstående skema:
Samtykkeservice | MinLog Service | Behandlingsrelationservice | |
---|---|---|---|
B1 + B2 | Ikke relevant (samtykkeservice omhandler kun samtykke i forhold til sundhedspersoner og disses organisationer) | Logges ikke | Ikke relevant |
S1 + | 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. |
IA-1 | Kaldes med USPECIFICERET. Samtykke tjekkes herved altid udfra forsigtighedsprincippet: Det tjekkes, om den relevante borger har givet negativt samtykke mod nogen person og eller organisation overhovedet (se for detaljer) | Ja | Ja. Kaldes med '-' i stedet for autorisationskode. Se i øvrigt for detaljer. |
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) | |
---|---|---|---|
Brugertypen | 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') | Bestemmes udfra HSUID headers attribut nsi:UserType (værdi 'nsi:HealthcareProfessional') | Bestemmes udfra HSUID headers attribut nsi:UserType (værdi 'nsi:HealthcareProfessional' men uden autorisationsid) |
SOSI id-kort | Niveau 3 (F/VOCES - dette kræver særskilt aftale om anvendelse, jf Dokumentdelingsservice (DDS)) | Niveau 4 (MOCES) | Niveau 4 (MOCES) |
OIO IDWS | Understøttet | Ikke understøttet | Ikke understøttet |
Brugerens cpr nummer | 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. | Bestemmes udfra HSUID headers attribut nsi:ActingUserCivilRegistrationNumber |
Brugerens autorisationskode | Ikke relevant | Bestemmes udfra HSUID headers attribut nsi:ResponsibleUserAuthorizationCode | Ikke relevant |
Brugerens rolle | Ikke releavnt | Ikke relevant | Bestemmes ud fra national SEB rolle og læses i SOSI Id-kortet under attributten 'nsi:UserRole' |
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:
Integrationstestene er bygget op på følgende måde:
Således indeholder integrationstestsuiten følgende:
For afvikling af integrationstests henvises til dokumenterne Testvejledning DDS Registry og Testvejledning DDS Repository.
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 Registry business-logikken og filtrering, da disse formodentlig kun vil finde anvendelse i DDS Registry. |
Interoperability | 1 | Gennem webservice-snitflader opnås den ønskede interoperabilitet. |
Tabel 1: Designmålsætninger og deres indbyrdes vigtighed
I dette afsnit fastholdes væsentlige design beslutninger samt deres rationale. Hvis relevant, fastholdes også designs, som er afvist samt rationalet herfor.
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.
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.
SLA-logning understøttes ved hjælp af (SLA) logningsfunktionaliteten i NSPUtil.
SLA-logningen logger all kald til DDS Registry 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 Driftsvejledning DDS Registry er beskrevet en liste af XDS-fejl indlejret i svar fra XDS Registry/XDS-infrastruktur, der giver anledning til SLA-logning som fejlet, udadgående kald, på trods af at kaldet til den eksterne XDS-komponent (Registry 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 Registry ikke fungerer korrekt, så SLA-logges de af DDS Registry som fejlet for at lette detektion og fejludbedring.
Auditlogning i DDS Registry sker vha AuditAPI'et (introduceret i ).
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-42, ITI-61, ITI-57: foretag auditlogning for hver DocumentEntry (DE) i request DE.uniqueId, DE.repositoryUniqueId, DE.homeCommunityId, DE.typeCode
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 Driftsvejledning DDS Registry.
Applikationskonfiguration konfigureres i filen DDSRegistry.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 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:
DDS Registry skal have adgang til en datasource ved navn ’WhitelistDS’ for at kunne lave autorisation af anvendersystemer vha. whitelist.
DDS Registry skal have adgang til:
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.
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.
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.
I afsnit 4.1.13 i [IHE vol. 3] er beskrevet, hvordan implementationsspecifikke fejl/advarsler kan angives, herunder at errorCode skal sættes til "XDSRegistryError", mens codeContext skal indeholde detaljer om fejlsituationen.
Se [DDS Registry query snitflade] for de konkrete anvendelser af implementationsspecifikke fejl/advarsler.
Da DDS Registry ikke har behov for transaktionsstyring er den implementeret som almindelig web service og ikke som Java EE bean.
Kald til Samtykkeservice, MinLog og Behandlingsrelationsservice udføres i parallel, hvert kald som synkront kald.
Invokere i DDS Registry 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?
Registry 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.
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.
Dette afsnit beskriver statiske såvel som dynamiske aspekter af systemarkitekturen, herunder baggrunden for de enkelte designvalg.
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.
Figur 3: 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.
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].
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.
Figur 4 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”:
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.
Figur 5 UML Sekvensdiagram for DDSRegistryQueryLogic
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.
Fælles for de service-invokere, der er beskrevet i afsnit 4.2 er at de hver især har ansvar for:
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.
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 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.
Der er ikke nogen specifik rækkefølge hvori DDS Registry og de services, den kalder, skal integreres.
I kraft af dens fejlhåndtering kan opslag gennemføres når blot datasources, servicen til IHE Registry og samtykkeverifikationsservicen er tilgængelige.
For succesfuld gennemførelse af integrationstests skal alle services, DDS Registry er afhængig af dog være tilgængelige.
For en beskrivelse af byggeprocessen og eksterne/interne afhængigheder for servicen, se [DDSRegistry udv].
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.
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.