Page History
...
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
Der findes følgende brugertyper i DDS
...
- 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)
Bestemmelse og mapning til actor
De enkelte brugertyper bestemmes udfra modellen, der udstilles i Security API. Disse regler er opsummeret i tabellerne nedenfor.
...
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
...
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)
http://www.w3.org/Submission/soap11mtom10
...
MTOM SOAP 1.2
...
SOAP Message Transmission Optimization Mechanism, (W3C Recommendation 25 January 2005)
http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/
...
DDS udvikling
...
...
DDS Test
...
DDS Testvejledning
...
DDS Registry query snitflade
...
...
DDS Repository snitflade
Introduktion til DDS
Baggrund for opslag i DDS Registry
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.”
Overblik over løsningen
Dokumentdelingsservice (DDS) består af to logiske services DDS Registry og DDS Repository, der tilsammen understøtter funktionerne
- 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.
- 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.
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Figur 1 Anvendelse af services og databaser fra DDS
Servicene gennemfører en række yderligere tjek, logninger og behandlinger af data:
- 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 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.
Servicene er yderligere indpakket i headers, som ikke er en del af IHE standarden:
- 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å NSP
- registry
for sundhedsperson med minimum sikkerhedsniveau 4
for borger med minimum sikkerhedsniveau 3 eller IDWS borgerbilletter
- repository
- minimum sikkerhedsniveau 3
- registry
- kræver anvendersystem autoriseret, hvilket kontrolleres vha. whiteliste
- kræver bruger 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.
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.
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.
...
i
...
Brugertyper
...
forbindelse med bestemmelsen af endelig brugertype:
- Borger (alm og på vegne af)
- Sundhedsperson (alm og på vegne af)
- Ikke-autoriseret sundhedsprofessionel
- Ikke defineret (alm og på vegne af)
Bestemmelse og mapning til actor
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 |
|
Skal være der | audience | |||
| Validity | Er valid | |||
| Message | Verificeres ikke - må gerne være der | |||
| ActingUser | UserType | Skal være Citizen | Brugertypen: Borger | |
| IdentifierFormat | ||||
| Identifier | actionUserCpr | |||
| 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 | ||||
| Client | Name | Verificeres ikke - må gerne være der | systemName |
| Brugertypen: Sundhedsperson | 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 | actionUserCpr | ||
| GivenName | Verificeres ikke - må gerne være der | |||
| SurName | Verificeres ikke - må gerne være der | |||
| Credentials.NationalRole | Må ikke være der | |||
| PersistentUniqueKey | Verificeres ikke - må gerne være der | |||
| PrincipalUser | Må ikke være der | |||
| Organisation | Identifier | Skal være der | organisationIdentifier | |
| identifierFormat | Skal være der og skal være CVR | |||
| Client | Name | Verificeres ikke - må gerne være der | systemName |
| Brugertypen: Ikke-autoriseret sundhedsprofessionel | 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 | actionUserCpr | ||
| GivenName | Verificeres ikke - må gerne være der | |||
| SurName | Verificeres ikke - må gerne være der | |||
| Credentials.NationalRole | Må ikke være der | |||
| PersistentUniqueKey | Verificeres ikke - må gerne være der | |||
| PrincipalUser | Må ikke være der | |||
| Organisation | Identifier | Skal være der | organisationIdentifier | |
| identifierFormat | Skal være der og skal være CVR | |||
| Client | Name | Verificeres ikke - må gerne være der | systemName | |
Transformation af Systembruger
En systembruger giver ikke mening i sig selv. Systembrugeren 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 af brugertyperne Borger eller Sundhedsfaglig.
Brugertypen Borger (sundhed.dk) | Verifikation | Mapning til DDS ServiceActor | ||
HSUID Header | userType | Skal være der og skal være CITIZEN | Brugertypen: Borger | |
actingUserCivilRegistrationNumber | Skal være sat | actionUserCpr | ||
responsibleUserCpr | Må ikke være sat eller være anderledes end actingUserCivilRegistrationNumber | |||
systemName | Verificeres ikke - må gerne være der | systemName (prefix) | ||
systemVersion | Verificeres ikke - må gerne være der | systemName (postfix) | ||
Brugertypen Sundhedsfaglig (sundhed.dk) | Verifikation | Mapning til DDS ServiceActor | ||
HSUID Header | userType | Skal være der og være HEALTHCAREPROFESSIONAL | Brugertypen: Sundhedsfaglig | |
actingUserCivilRegistrationNumber | Skal være sat | actionUserCpr | ||
responsibleUserCpr | Må ikke være sat eller være anderledes end actingUserCivilRegistrationNumber | |||
orgUsingIDType | Verificeres ikke - må gerne være der | healthcareOrgType | ||
orgUsingIDName | Verificeres ikke - må gerne være der | healthCareOrg | ||
systemName | Verificeres ikke - må gerne være der | systemName (prefix) | ||
systemVersion | Verificeres ikke - må gerne være der | systemName (postfix) | ||
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.
...