DDS Registry og Repository er en national service til
Formålet med dette dokument er at beskrive systemarkitekturen for DDS Registry og Repository.
For et overblik over systemet henvises til afsnit Arkitekturdesign - overblik.
Nærværende dokument er tiltænkt udviklere og IT-arkitekter med interesse i anvendelsen af DDS Registry/Repository. Herunder hører naturligvis personer involveret i konkrete dokument-kildesystemers brug af DDS Repository.
I dokumentet bruges begreberne autorisation og autoriseret primært i en sikkerhedskontekst, dvs. i forståelsen at en person eller et system har tilladelse til at anvende en given ressource. Anvendes begreberne om sundhedspersoner med dansk autorisation opført i Sundhedsstyrelsens autorisationsregister vil dette fremgå eksplicit.
Formålet med denne sektion er at give et overblik over definitioner og dokumenter, der benyttes i dette dokument
Definition | Beskrivelse |
DDS | Dokumentdelingsservice |
IHE | Integrating the Healthcare Enterprise |
IHE-fællesskab | Community i IHE XDS |
MTOM | Message Transmission Optimization Mechanism |
NSI | National Sundheds-IT |
NSP | Den Nationale Service Platform (inden for sundheds-IT) |
STS | Security Token Service |
XCA | Cross-Community Access |
XDS | Cross-Enterprise Document Sharing |
Alias | Beskrivelse |
Behandlingsrelationsservice ws | Behandlingsrelations- og Opfølgningsservice, Guide til Anvendere |
ConsentVerificationService ws | Samtykke service, anvenderguide |
DGWS 1.0.1 | Den Gode Webservice 1.0.1, Medcom |
HSUID-header | Healthcare Service User Identification Header |
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 |
ITI TF-2 | IHE IT Infrastructure (ITI) Technical Framework, Volume 2 Revision 19.0, June 17, 2022 – Final Text https://profiles.ihe.net/ITI/TF/Volume2/index.html |
ITI TF-3 | IHE IT Infrastructure (ITI) Technical Framework, Volume 3 Revision 19.0, June 17, 2022 – Final Text https://profiles.ihe.net/ITI/TF/Volume3/index.html |
ITI-43++ SOAP 1.1 WSDL | WSDL for RetrieveDocumentSet (ITI-43) med SOAP 1.1-binding udvidet med HSUID-header og DGWS-header |
ITI-43++ SOAP 1.2 WSDL | WSDL for RetrieveDocumentSet (ITI-43) med SOAP 1.2-binding udvidet med HSUID-header og DGWS-header |
MinLogService ws | Min-log Service, anvenderguide |
MTOM SOAP 1.1 | SOAP 1.1 Binding for MTOM 1.0, (W3C Member Submission 05 April 2006) |
MTOM SOAP 1.2 | SOAP Message Transmission Optimization Mechanism, (W3C Recommendation 25 January 2005) |
DDS udvikling | |
DDS Test | DDS Testvejledning |
DDS Registry query snitflade | |
DDS Repository snitflade |
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
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
…
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.”
Dokumentdelingsservice (DDS) består af to logiske services DDS Registry og DDS Repository, der tilsammen understøtter funktionerne
Figur 1 Anvendelse af services og databaser fra DDS
Servicene gennemfører en række yderligere tjek, logninger og behandlinger af data:
Servicene er yderligere indpakket i headers, som ikke er en del af IHE standarden:
DDS Registry understøtter en række brugertype og adgangsscenarier. Disse brugertyper stiller forskellige krav til autentifikations- og kaldkontekst. Derudover er anvendelsen af de eksterne services (samtykke, behandlingsrelation, minlog) forskellig for de forskellige adgangsscenarier.
Først beskrives, hvordan en given brugertype fremkommer ud fra modellen, der udstilles i Security API. Så 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 med følgende overordnede muligheder:
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 på vegne af | fremsøge dokumentreferencer til en anden borgers dokumenter | Nej | kan se data på denne person, som jeg har en relation til |
SF1 | Sundhedsfaglig med autorisation | fremsøge dokumentreferencer til en borgers data | Ja / Nej | kan se data på denne borger |
SF3 | Sundhedsfaglig på vegne af. F.eks en 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 bruger | 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 enkelte brugertyper bestemmes udfra modellen, der udstilles i Security API. Disse regler er opsummeret i tabellerne nedenfor.
Brugertypen: Borger | Verifikation | Mapning til MinSpærring ServiceActor | ||
SecurityContext | Ticket | Audience | Matche audience som findes som konfiguration i DDS | audience |
Validity | Er valid | |||
Message | Verificeres ikke - må gerne være der | |||
ActingUser | UserType | Skal være Citizen | Brugertypen: Borger | |
IdentifierFormat | Skal være der og Skal være CPR | |||
Identifier | Skal være sat | ActingUserCpr | ||
GivenName | Verificeres ikke - må gerne være der | |||
SurName | Verificeres ikke - må gerne være der | |||
Credentials | Verificeres ikke - må gerne være der | |||
PersistentUniqueKey | Verificeres ikke - må gerne være der | |||
PrincipalUser | Må ikke være der | |||
Organisation | Verificeres ikke - må gerne være der | |||
Client | Name | Verificeres ikke - må gerne være der | systemName |
Brugertypen: Sundhedsfaglig | Verifikation | Mapning til MinSpærring ServiceActor | ||
SecurityContext | Ticket | Audience | Verificeres ikke - må gerne være der | |
Validity | Er valid | |||
Message | Verificeres ikke - må gerne være der | |||
ActingUser | UserType | Skal være HealthCareProfessional | Brugertypen: Sundhedsfaglig | |
IdentifierFormat | Skal være CPR | |||
Identifier | Skal være sat | ActingUserCpr | ||
GivenName | Verificeres ikke - må gerne være der | |||
SurName | Verificeres ikke - må gerne være der | |||
Credentials.NationalRole | Verificeres ikke - må gerne være der | |||
Credentials.AuthorizationCode | Skal være der | AuthorizationCode | ||
PersistentUniqueKey | Verificeres ikke - må gerne være der | |||
PrincipalUser | Må ikke være der | |||
Organisation | Identifier | Verificeres ikke - må gerne være der | ||
identifierFormat |
Verificeres ikke - må gerne være der | |||
Client | Name | Verificeres ikke - må gerne være der | systemName |
Brugertypen: Ikke-autoriseret bruger | Verifikation | Mapning til DDS ServiceActor | ||
SecurityContext | Ticket | Audience | Verificeres ikke - må gerne være der | |
Validity | Er valid | |||
Message | Verificeres ikke - må gerne være der | |||
ActingUser | UserType | Skal være HealthCareProfessional | Brugertypen: Sundhedsfaglig | |
IdentifierFormat | Skal være CPR | |||
Identifier | Skal være sat | ActingUserCpr | ||
GivenName | Verificeres ikke - må gerne være der | |||
SurName | Verificeres ikke - må gerne være der | |||
Credentials.NationalRole | Må gerne være der, og anvendes hvis den er. Ellers anvendes "ingen rolle" | NationalRole | ||
Credentials.AuthorizationCode | Må ikke være der | |||
PersistentUniqueKey | Verificeres ikke - må gerne være der | |||
PrincipalUser | Må ikke være der | |||
Organisation | Identifier | Verificeres ikke - må gerne være der | ||
identifierFormat | Verificeres ikke - må gerne være der | |||
Client | Name | Verificeres ikke - må gerne være der | systemName |
Brugertypen: System | Verifikation | Mapning til DDS ServiceActor | ||
SecurityContext | Ticket | Audience | Verificeres ikke - må gerne være der | |
Validity | Er valid | |||
Message | Verificeres ikke - må gerne være der | |||
ActingUser | UserType | Må ikke være der | Brugertypen: System | |
PrincipalUser | Må ikke være der | |||
Organisation | Identifier | Verificeres ikke - må gerne være der Hvis brugertypen transformeres til en anden type, tjekkes at dette cvr nummer er whitelistet sammen med subject serial number. | cvr | |
identifierFormat | Verificeres ikke - må gerne være der | |||
Client | Name | Verificeres ikke - må gerne være der | systemName |
En systembruger giver ikke mening i sig selv, og skal mappes over til en anden brugertype. Andre brugertyper kan også mappes til andre typer på baggrund af hsuid header information. En borger kan mappes til en borger på vegne af ved hjælp af cprFromPayload (det vil sige det cprnummer, som der forespørges på). Der findes følgende tranformationer:
System >> Brugertypen Sundhedsfaglig | Verifikation | Mapning til DDS ServiceActor | ||
HSUID Header | userType | Skal være der og være HEALTHCAREPROFESSIONAL | Brugertypen: Sundhedsfaglig | |
actingUserCivilRegistrationNumber | Skal være sat | ActingUserCpr | ||
responsibleUserRegistrationNumber | Må ikke være sat eller hvis sat skal den være matche actingUserCivilRegistrationNumber | |||
orgUsingIDType | Verificeres ikke - må gerne være der | |||
orgUsingIDName | Verificeres ikke - må gerne være der | |||
systemName | Verificeres ikke - må gerne være der systemName fra actor mappes | systemName | ||
systemVersion | Verificeres ikke - må gerne være der | |||
userAuthorizationCode | Skal være sat og valideres med actingUser | AuthorizationCode | ||
Actor cvr skal være whitelisted |
System >> Brugertypen Sundhedsfaglig på vegne af | Verifikation | Mapning til DDS ServiceActor | ||
HSUID Header | userType | Skal være der og være HEALTHCAREPROFESSIONAL | Brugertypen: Sundhedsfaglig på vegne af | |
actingUserCivilRegistrationNumber | Skal være sat | ActingUserCpr | ||
responsibleUserRegistrationNumber | Skal være sat og skal være anderledes end actingUserCivilRegistrationNumber | |||
orgUsingIDType | Verificeres ikke - må gerne være der | |||
orgUsingIDName | Verificeres ikke - må gerne være der | |||
systemName | Verificeres ikke - må gerne være der systemName fra actor mappes | systemName | ||
systemVersion | Verificeres ikke - må gerne være der | |||
userAuthorizationCode | Skal være sat og valideres med responsibleUser | AuthorizationCode | ||
Actor cvr skal være whitelisted |
Sundhedsfaglig >> Brugertypen Sundhedsfaglig på vegne af | Verifikation | Mapning til DDS ServiceActor | ||
HSUID Header | userType | Skal være der og være HEALTHCAREPROFESSIONAL | Brugertypen: Sundhedsfaglig på vegne af | |
actingUserCivilRegistrationNumber | Skal være sat | ActingUserCpr | ||
responsibleUserRegistrationNumber | Skal være sat og skal være anderledes end actingUserCivilRegistrationNumber | |||
orgUsingIDType | Verificeres ikke - må gerne være der | |||
orgUsingIDName | Verificeres ikke - må gerne være der | |||
systemName | Verificeres ikke - må gerne være der systemName fra actor mappes | systemName | ||
systemVersion | Verificeres ikke - må gerne være der | |||
userAuthorizationCode | Skal være sat og valideres med responsible user | AuthorizationCode |
Ikke-autoriseret bruger >> Brugertypen Sundhedsfaglig på vegne af | Verifikation | Mapning til DDS ServiceActor | ||
HSUID Header | userType | Skal være der og være HEALTHCAREPROFESSIONAL | Brugertypen: Sundhedsfaglig på vegne af | |
actingUserCivilRegistrationNumber | Skal være sat | ActingUserCpr | ||
responsibleUserRegistrationNumber | Skal være sat og skal være anderledes end actingUserCivilRegistrationNumber | |||
orgUsingIDType | Verificeres ikke - må gerne være der | |||
orgUsingIDName | Verificeres ikke - må gerne være der | |||
systemName | Verificeres ikke - må gerne være der systemName fra actor mappes | systemName | ||
systemVersion | Verificeres ikke - må gerne være der | |||
userAuthorizationCode | Skal være sat og valideres med responsible user | AuthorizationCode |
Borger >> Brugertypen Borger på vegne af | Verifikation | Mapning til DDS ServiceActor | ||
cprFromPayload | userType | Er givet fra securityContext pga. rollen borger | Brugertypen: Borger på vegne af | |
actingUser fra securityContext. | ActingUserCpr | |||
cprFromPayload skal være sat og være anderledes end actingUser. | ResponsibleUserCpr (fra payload) | |||
systemName | systemName fra actor mappes | systemName | ||
userAuthorizationCode | Verificeres ikke - må gerne være der | |||
vha. actinguser fra security context og cprFromPayload findes en relation | relation |
System >> Brugertypen Borger på vegne af | Verifikation | Mapning til DDS ServiceActor | ||
HSUID Header | userType | Skal være der og skal være CITIZEN | Brugertypen: Borger på vegne af | |
actingUserCivilRegistrationNumber | Skal være der (valideres indirekte ved at relation med responsibleUser skal være tilstede) | ActingUserCpr | ||
responsibleUserRegistrationNumber | Skal være sat Skal være forskellige fra actingUserCivilRegistrationNumber | ResponsibleUserCpr | ||
orgUsingIDType | Verificeres ikke - må gerne være der | |||
orgUsingIDName | Verificeres ikke - må gerne være der | |||
systemName | Verificeres ikke - må gerne være der systemName fra actor mappes | systemName | ||
systemVersion | Verificeres ikke - må gerne være der | |||
userAuthorizationCode | Verificeres ikke - må gerne være der | |||
vha. actinguser fra hsuid og responsible user fra hsuid slåes den påstående hsuid relation op | relation | |||
Actor cvr skal være whitelisted |
System >> Brugertypen Borger | Verifikation | Mapning til DDS ServiceActor | ||
HSUID Header | userType | Skal være der og skal være CITIZEN | Brugertypen: Borger | |
actingUserCivilRegistrationNumber | Verificeres ikke - må gerne være der | ActingUserCpr | ||
responsibleUserRegistrationNumber | Verificeres ikke - må gerne være der | ResponsibleUserCpr | ||
orgUsingIDType | Verificeres ikke - må gerne være der | |||
orgUsingIDName | Verificeres ikke - må gerne være der | |||
systemName | Verificeres ikke - må gerne være der systemName fra actor mappes | systemName | ||
systemVersion | Verificeres ikke - må gerne være der | |||
userAuthorizationCode | Verificeres ikke - må gerne være der | |||
Actor cvr skal være whitelisted |
De forskellige brugertyper bliver beriget med:
Brugertyperne bliver til sidst valideret for:
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 |
SF1 + SF3 | 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 SDS-2503 - Adgang for ikke aut. sundhedspersoner på DDS via trust ARKIVERET for detaljer) | Ja | Ja. Kaldes med '-' i stedet for autorisationskode. Se i øvrigt SDS-2990 - Ikke autoriserede brugere skal fremsende bindestreg til BRS som autorisationskode ARKIVERET for detaljer. |
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 dokumentet DDS - Testvejledning.
Der er foretaget en fordeling i ansvar for gennemførelse af aktiviteter, der foregår ved udtræk. Ansvarsfordelingen er som følger:
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.
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.
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:
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:
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:
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:
Forudsætningen for at mekanismen ikke falder tilbage til opslag på repositoryUniqueId, er at:
Et kildesystem har følgende ansvar:
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ø.
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
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 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 i DDS Registry sker vha AuditAPI'et (introduceret i SDS-2506 - Auditlogging af DDS via AuditAPI ARKIVERET ).
ITI-18: foretag auditlogning af patient-id, bruger-id, på-vegne-af-id og for hver DocumentEntry (DE) i returneret svar (der kan være frafiltreret metadata pga. samtykker): DE.uniqueId, DE.repositoryUniqueId, DE.homeCommunityId, DE.typeCode.
ITI-43: foretag auditlogning af patient-id, bruger-id, på-vegne-af-id og for hver DocumentResponse (DR) i returneret svar (der kan være frafiltreret metadata pga. samtykker): DR.uniqueId, DR.repositoryUniqueId, DR.homeCommunityId.
Servicekonfigurationen foretages i en properties-fil, der skal deployes på webserveren et sted i applikationens classpath.
Ændringer i konfigurationen skal ledsages af genstart af servicen, da konfigurationen indlæses og verificeres ved opstart af de enkelte services. Properties kontrolleres for tilstedeværelse i property-filen, ikke for anførte værdi.
For en beskrivelse af hvad der skal opsættes i konfigurationen, se DDS - Driftsvejledning.
Applikationskonfiguration konfigureres i filerne DDSRegistry.properties og DDSRepository.properties. Al konfiguration af sikkerhed og klientopsætning angives i denne fil. Derudover angives også placeringen af logkonfigurationsfilen.
Serviceklientkonfiguration, der omfatter konfiguration af DDS Registry’s og Repositories kald til andre services, udpeges i applikationskonfigurationen. Det er muligt at lade applikationskonfigurationen ”pege på sig selv” angive serviceklientkonfigurationsparametre i applikationskonfigurationen, men der kan også foretages serviceklientkonfiguration i separate filer.
Placeringen af serviceklientkonfiguration angives i applikationskonfigurationen.
Logkonfiguration udpeges i applikationskonfigurationen. I logkonfigurationsfilen angives logger-properties for:
DDS skal have adgang til en datasource ved navn ’WhitelistDS’ for at kunne lave autorisation af anvendersystemer vha. whitelist.
DDS Registry og Repository skal have adgang til:
Derudover skal DDS Repository have adgang til:
For at DDS Registry og Repository kan eksponere et webservice-interface, der i videst muligt omfang implementerer Registry Stored Query i henhold til IHE-standarden, er det søgt at minimere ændringer. Derfor er DGWS-headerne og HSUID-headeren tilføjet som implicitte headere, dvs. tilføjet til bindings i DDS Registry/Repository WSDL, men ikke input/output-beskederne.
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 egne fejlkoder, som beskrevet i afsnit 4.2.4 i [ITI TF-3], være anvendt på bekostning af entydighed for så vidt angår årsagen til fejlen/advarslen.
I IHE standarden er beskrevet, hvordan implementationsspecifikke fejl/advarsler kan angives, herunder at errorCode skal sættes til "XDSRegistryError", mens codeContext skal indeholde detaljer om fejlsituationen.
Se [DDS Registry query snitflade] og [DDS Repository snitflade] for de konkrete anvendelser af implementationsspecifikke fejl/advarsler.
Da DDS ikke har behov for transaktionsstyring er den implementeret som almindelig web service og ikke som Java EE bean.
Kald til Samtykkeservice og Behandlingsrelationsservice udføres i parallel, hvert kald som synkront kald.
Invokere i DDS for kald af MinLog, BRS, Samtykkeverifikationsservicen samt for XDS Registry benytter JAXWS klient-proxier.
Disse er tunge at skabe, da det involverer udstrakt grad af reflection. Dette er undgået ved at skabe klient-proxyerne en gang og genbruge dem ved hver forespørgsel.
En forudsætning for denne fremgangsmåde (når udstrakt brug af synchronized fravælges grundet ineffektivitet) er brug af trådsikker port.
Ifølge JAXWS specifikationen er klient-proxy porte ikke trådsikre.
Derfor anvendes en udvidelse i Apache CXF, der indgår i den underliggende platform i Wildfly, der sikrer trådsikker request context beskrevet i http://cxf.apache.org/faq.html#FAQ-AreJAX-WSclientproxiesthreadsafe?
DDS er i sine invokere afhængig af trådsikker request context stillet til rådighed af CXF-implementationen af JAXWS i Wildfly
Der er risiko for sammenblanding af patient-data/behandling af patient-data, hvis ikke CXF’s JAXWS-implementation anvendes.
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.
Alternativer:
Når data-specifikke samtykker skal kontrolleres ved kald af Samtykkeverifikationsservicen skal sundhedspersonens organisation gives ved dennes kode i SOR-klassifikationen.
Ved kald af DDS Repository er der som beskrevet i [DDS Repository snitflade] mulighed for i HSUID-header at angive sundhedspersonens organisation ved:
Er SOR-koden ikke givet ved kaldet af DDS Repository, foretages mapning til SOR-kode ud fra organisation angivet HSUID-headeren. Den fremfundne SOR-kode tilføjes til HSUID-header brugt ved kaldet til kildesystemet, således at kildesystemet ikke skal foretage mapningen.
Snitfladen for DDS Registry/Repository skal indeholde SOAP-headere fra DGWS 1.0.1 og SOAP-header samt SOAP-body med indhold specificeret af IHE XDS.
DGWS 1.0.1 specificerer anvendelse af SOAP 1.1, mens webservices for IHE XDS er baseret på SOAP 1.2.
Det er valgt, at DDS skal udstille services med SOAP 1.1-binding af hensyn til overholdelse af DGWS.
Konsekvensen af valget er, at MTOM-anvendelse sker med SOAP 1.1-binding [MTOM SOAP 1.1] og ikke [MTOM SOAP 1.2].
Både DDS Repository og kildesystemet har behov for at kende identifikation af den borger, der udtrækkes dokumenter om (patient-id). DDS Repository har behovet i kraft af, at denne skal kalde Samtykkeverifikationsservicen, Behandlingsrelationsservicen og MinLogRegistreringsservicen, hvor patient-id er krævet information. Tilsvarende skal kildesystemet kende patient-id, når data-specifikke samtykker kontrolleres ved kald af Samtykkeverifikationsservicen.
Patient-id indgår ikke i den request-struktur, der anvendes ved ITI-43 RetrieveDocumentSet.
Det er valgt, at tilføje en attribut til et enkelt patient-id til HSUID-headeren. Det er dermed anvendersystemets ansvar at specificere det korrekte patient-id. Med RetrieveDocumentSet er det muligt at udtrække dokumenter for flere dokument-id. Support blot for et enkelt patient-id har den konsekvens, at kald af RetrieveDocumentSet kun må anvendes, når alle specificerede dokument-id gælder samme patient. Det påhviler anvendersystemet at sikre, at dette er tilfældet.
Alternative løsninger:
Supplerende løsninger til valgte løsning:
Med RetrieveDocumentSet er det muligt at udtrække dokumenter for flere dokument-id. Som beskrevet i forrige afsnit angives et enkelt patient-id i HSUID-headeren.
Det er valgt, at der ikke foretages kontrol af overensstemmelse mellem patient-id angivet i HSUID-header og patient-id for de dokumenter, der ønskes udtræk af.
Det påhviler anvendersystemet at sikre, at der er overensstemmelse mellem angivne patient-id og patient-id for de dokumenter, der ønskes udtræk af.
Med RetrieveDocumentSet er det teknisk muligt med et kald at udtrække dokumenter for flere forskellige patienter. Af hensyn til patient-sikkerhed må der dog kun udtrækkes dokumenter for samme patient.
Det er valgt, at der ikke foretages kontrol af, at alle dokumenter, der ønskes udtræk af, vedrører samme patient.
Det påhviler anvendersystemet at sikre, at der kun forespørges om udtræk for samme patient.
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 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.
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].
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.
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].
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 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”:
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 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.
DDSRepository implementerer den sekvens af kald af services og håndtering af fejlsituationer, der er beskrevet i afsnit 2.1.1. Dog håndteres autentificering og autorisation af DDSRepository som beskrevet ovenfor.
Figur 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”:
I Figur 5b er vist et sekvensdiagram for DDSRepository.
Figur 5b Sekvensdiagram for DDSRetrieveDocumentLogic
Fælles for de service-invokere, der er beskrevet i foregående afsnit er at de hver især har ansvar for:
Der er overordnet to typer af invokers: Dem med og dem uden DGWS sikkerhed.
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.
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 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 Repository 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, et kildesystems ITI-43-snitflade og samtykkeverifikationsservicen er tilgængelige.
For succesfuld gennemførelse af integrationstests skal alle services, DDS er afhængig af dog være tilgængelige.
For en beskrivelse af byggeprocessen og eksterne/interne afhængigheder for servicen, se [DDS udvikling].
Se testvejledningen for detaljer omkring dette [DDS Test]