Page History
...
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 |
TODO: tjek alias fra orig dokument og se hvad der stadig er i spil
TODO: dds var meget konkret i link ind til dokumenter.
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 vol. * | IHE IT Infrastructure Technical Framework. Se NSP dokument delingssiden for links og læsevejledning. | ||
IHE XSD og IHE WSDL | IHE IT Infrastructure Technical Framework. Se NSP dokument delingssiden for links og læsevejledning. | ||
ITI TF-* | IHE IT Infrastructure Technical Framework. Se NSP dokument delingssiden for links og læsevejledning. | ||
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. | 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 drift | DDS Driftsvejledning |
DDS udvikling | |||
[DDS Test] | DDS Testvejledning | ||
DDS Registry query snitflade | |||
DDS Repository snitflade |
...
borgeren har muligheden for at se data fra de professionelle om sine undersøgelser og behandlinger
de sundhedsprofessionelle sundhedspersoner får mulighed for at se metadata og derigennem få adgang til yderligere data om en specifik patient fra andre organisationer, og vist eget system (via Sundhedsjournalen), f.eks. ved modtagelse af patienter som er enten akut syge, ambulante med komplekse forløb eller i øvrigt ukendte for behandleren
...
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
Figur 1 Anvendelse af services og databaser fra DDS
...
- 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å NSPregistryfor sundhedsperson med minimum sikkerhedsniveau 4
for borger med minimum sikkerhedsniveau 3 eller IDWS borgerbilletter
- repository
- minimum sikkerhedsniveau 3
- kræver anvendersystem autoriseret, hvilket kontrolleres vha. whiteliste
- kræver bruger/patient identificeret ved brug af attributter i en ekstra header, HSUID-headeren.
- for repository skal også patient være identificeret i HSUID-headeren
- returnerer SOAPFault ved autentifikations- og autorisationsfejl samt ved visse systemfejl.
Brugertyper og adgangsscenarier
...
DDS Registry understøtter en række brugertype og adgangsscenarier. Disse brugertyper stille stiller forskellige krav til autentifikations- og kaldkontekst. Derudover er anvendelsen af de eksterne services (samtykke, behandlingsrelation, minlog) forskellig for de forskellige adgangsscenarier.
Først gennemgåes 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.
Brugertyper
...
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)
- SundhedspersonSundhedsfaglig: Sundhedspersoner Sundhedsfaglie kan tilgå data på borgere, hvis der er hjemmel til dette (behandlingsrelation, ikke-negativt samtykke, værdispring)
- Ikke-autoriseret sundhedsprofessionelbruger: Myndighedspersoner uden lægefaglig autorisation, men som har brug for at tilgå data på borgere (f.eks. adgang til aftaler for kommunale medarbejdere)
- System bruger: er der kun således at systemer (i praksis sundhed.dk) kan anvende DDS og ved hjælp af en medsendt HSUID header kan opnå status som een rigtig brugertype.
De forskellige DDS brugertyper giver anledning til en række adgangsscenarier dvs. måder, hvorpå disse kan tilgå DDS Registry 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 |
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:
...
Samtykkeservice
...
MinLog Service
...
Behandlingsrelationservice
...
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.
...
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. Kaldes med '-' i stedet for autorisationskode. Se i øvrigt SDS-2990 - Ikke autoriserede brugere skal fremsende bindestreg til BRS som autorisationskode ARKIVERET for detaljer.
Adgangsscenarier og DGWS
Ovenstående adgangsscenarier bestemmes i DDS Registry ud fra bruger- og kaldkonteksten i DGWS - nemlig SOSI Id-kort og HSUID headeren.
DDS Registry bestemmer DDS brugertypen udfra kaldkonteksten: Nærmere bestemt udfra HSUID-headerens attributter UserType samt ResponsibleUserAuthorizationCode. Disse kan antage een af følgende værdier brugertyper:
...
Hver brugertype kræver, at der i det indgående kald findes et gyldigt SOSI id-kort. I det nedenstående gennemgåes de forskellige krav til fremskaffelsen af SOSI-idkortet for de forskellige brugertyper.
...
Borger (B1+B2)
...
Sundhedsperson (S1+S3)
...
Ikke-autoriseret bruger (IA-1)
...
Borger (B1+B2)
...
Sundhedsperson (S1+S3)
...
Ikke-autoriseret bruger (IA-1)
...
Bestemmes i sikkerhedshandleren for komponenten. En OIO IDWS billet betyder, at brugeren er en borger.
Hvis SOSI Idkort benyttes, så bestemmes brugertypen udfra HSUID headers attribut nsi:UserType (værdi 'nsi:Citizen')
...
Niveau 3 (F/VOCES - dette kræver særskilt aftale om anvendelse, jf Dokumentdelingsservice (DDS))
...
Niveau 4 (MOCES)
...
Hvis OIO IDWS anvedes, så trækkes cpr nummeret ud af IDWS billetten.
Hvis DGWS benyttes, så bestemmes det udfra HSUID headers attribut nsi:ActingUserCivilRegistrationNumber
...
Bestemmes udfra HSUID headers attribut nsi:ActingUserCivilRegistrationNumber
For sekrætærer (S3) er det den person, der arbejdes på vegne af, der er relevant. Denne findes i HSUID headers attribut nsi:ResponsibleUserCivilRegistrationNumber
For scenariet S1 vil værdien af de to HSUID header attributter være ens.
...
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 | 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 |
Transformation af brugertyper
En systembruger giver ikke mening i sig selv, og skal mappes over til en anden brugertype. Andre brugertyper kan også mappes til andre typer på baggrund af hsuid header information. En borger kan mappes til en borger på vegne af ved hjælp af cprFromPayload (det vil sige det cprnummer, som der forespørges på). Der findes følgende tranformationer:
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
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:
- Sundhedsfaglig alm og på vegne af:
- organisationIdtype fra hsuid
- organisationId fra hsuid
- Ikke-autoriseret bruger
- organisationIdtype fra hsuid
- organisationId fra hsuid
- hvis ingen antional rolle sættes rollen "ingen_idkort_rolle"
Brugertyperne bliver til sidst valideret for:
- Alle roller, hvis hsuid header medsendt:
- hsuid rollen skal matche den på security context
- hsuid acting user cpr skal matche den aktøren
- Borger på vegne af
- Der skal være en relation
- Sundhedsfaglig og Sundhedsfaglig på vegne af
- hsuid authorisationkode skal matche den på aktøren
- Den endelige brugertype må ikke være af typen System
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:
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. |
Adgangsscenarier og tests
De ovenstående adgangsscenarier giver anledning til en række integrationstests.
Målene med integrationstestene er at udføre en række tests, der påviser at:
- Adgangsscenarierne er understøttet af DDS som beskrevet ovenfor: Dvs det er muligt at få data ud af DDS i de forskellige scenarier
- Negative tests: For hvert scenarie vil integrationstestene inkludere en række negative tests .. det tjekkes f.eks. at der ikke kan anvendes værdispring i scenarie IA-1
Integrationstestene er bygget op på følgende måde:
- Integrationstestene i DDS er delt ind i testklasser, der dækker de ovenstående scenarier. De er navngivet med scenariernes roller som prefix og en efterfølgende beskrivende tekst, så sammenhængen med dokumenationen bevares.
- Alle testcases i integrationstestene er implementeret som cucumber test, der i sin anvendelse forklarer intentionen med testen.
- Alle testcases er bygge op efter samme skabelon som klart definerer præconditions (Given), aktivering af funktion (When) og tjek af svar/postconditions (Then). Se f.eks. Martin Fowler: Given-When-Then
Således indeholder integrationstestsuiten følgende:
- B1: borger_soeg_egne.feature
- B2: borger_soeg_andre_fuldmagt.feature
- B2: borger_soeg_andre.feature
- SF1: sf_soeg_aftaler.feature
- SF1: sf_soeg_alle_dokumenttyper.feature
- SF1: sf_soeg_labsvar.feature
- S3: <der findes ingen test>
- IA1: ia_ingen_national_rolle.feature
- IA1: ia_laege_sekraetaer.feature
- IA1: ia_sundhedsassistent.feature
For afvikling af integrationstests henvises til dokumentet DDS - Testvejledning.
Fordeling af ansvar
Der er foretaget en fordeling i ansvar for gennemførelse af aktiviteter, der foregår ved udtræk. Ansvarsfordelingen er som følger:
- DDS forestår alle aktiviteter undtagen kontrol af dokumentspecifikke samtykker
- Kildesystemer forestår fremfinding af dokumenter samt kontrol af dokumentspecifikke samtykker.
Rationalet bag denne fordeling er beskrevet i afsnit 'Kontrol af data-specifikke samtykker foretages af kildesystem' under designbeslutninger.
Et samlet overblik for applikationen Dokumentdelingsservice er lavet i nedenstående model.
HTML |
---|
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/f301b4a5-2e58-4c90-80d5-d5e3914448dd.html" name="test" height="640" width="800">You need a Frames Capable browser to view this content.</iframe> |
* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.
Behandling af udtræk i DDS Repository
I DDS guide til anvendere, afsnit hentning er der i detaljer redegjort for, hvordan DDS repository udtrækker dokumenter. Nedenfor er udvalgte områder af denne logik uddybet.
Repository bestemmelse af kildesystem(er)
Udtræk sker ved anvendelse af operationen Retrieve Document Set, hvor der i request-beskeden indgår et eller flere DocumentRequest-elementer, hver med følgende indhold:
- repositoryUniqueId, en OID, der identificerer det kildesystem, hvorfra dokumentet kan udtrækkes
- documentUniqueId, en OID, der identificerer dokumentet
- homeCommunityId, en OID, der identificerer det Community, hvorfra dokumentet kan udtrækkes (bemærk, at der kun specificeres en værdi, når denne er anført i svaret fra en Registry Stored Query, fx i svaret fra et DDS Registry)
Som beskrevet i [ITI TF-2] afsnit 3.18.4.1.2.3.8 anvendes homeCommunityId til at bestemme webservice-endpoint for services, der giver adgang til data inden for et IHE-fællesskab.
I [ITI TF-2] afsnit 3.43.4.1.3 er det beskrevet, hvordan en XCA Initiating Gateway skal reagere på en Retrieve Document Set-request:
- homeCommunityId bruges til at bestemme webservice endpoint for Responding Gateways (altså repositories)
- hvis homeCommunityId identificerer det lokale IHE-fællesskab, anvendes repositoryUniqueId til at bestemme webservice endpoint for repositories
Denne adfærd ligger til grund for bestemmelsen af kildesystemer i DDS Repository beskrevet i det følgende.
Ved gennemløb af alle DocumentRequest-elementer i Retrieve Document Set-request’en skabes en mængde (Set) af webservice-endpoints og en mængde af id, der ikke kunne fremfindes:
- Hvis homeCommunityId er anført i et DocumentRequest-element i Retrieve Document Set-request’en, da foretages opslag i konfiguration på det homeCommunityId
- Fremfindes et eller flere webservice-endpoints, da tilføjes disse til mængden af webservice-endpoints (dermed fortsættes til næste DocumentRequest-element)
- Der foretages opslag på repositoryUniqueId i DDS Repositorys konfiguration
- Fremfindes et webservice-endpoint, da tilføjes dette til mængden af webservice-endpoints (dermed fortsættes til næste DocumentRequest-element)
- Fremfindes ingen webservice-endpoints, da tilføjes repositoryUniqueId’et til mængden over id, der ikke kunne fremfindes. Disse forespørgsler resulterer i en fejl hver i det resulterende svar.
- De webservice-endpoints der ikke kan kontaktes, resulterer i en fejl i det resulterende svar.
Denne mekanisme (i DDS Repositorys bestemmelse af kildesystemer) er helt ortogonal på hvorvidt kildesystemer anvender XCA. Fordelen er, at DDS Repository ikke skal kende alle repositoryUniqueId (transitivt), således at et kildesystem i et IHE-fællesskab kan skifte til og fra XCA uden at DDS Repository-konfigurationen skal ændres.
Som vist i Figur 2 kan yderligere kildesystemer via XCA knyttes til et IHE-fællesskab uden ændring i konfigurationen i DDS Repository, når homeCommunityId er kendt af DDS Repository.
Figur 2 Konfiguration af DDS Repository baseret på repositoryUniqueId og homeCommunityId tillader tilføjelse af nye dokumentkilder. Når DDS Repository kender til dokumentkilde C’s webservice endpoint gennem dens homeCommunityId (IHE-fællesskab XYZ), da kan der tilføjes en ny dokumentkilde, her Dokumentkilde F, til IHE-fællesskabet via XCA uden at DDS Repository skal omkonfigureres.
I Figur 2 er Dokumentkilde B kendt direkte ved dens repositoryUniqueId. Tilføjes endnu en dokumentkilde via XCA til Dokumentkilde B, da skal DDS Repository enten:
- Omkonfigureres til at kende den tilføjede dokumentkildes repositoryUniqueId og webservice endpoint, eller
- Omkonfigureres så Dokumentkilde B’s webservice endpoint kendes via dens homeCommunityId (og ikke dens repositoryUniqueId)
Forudsætningen for at mekanismen ikke falder tilbage til opslag på repositoryUniqueId, er at:
- homeCommunityId blev specificeret i metadata under registrering
- homeCommunityId blev returneret ved opslag (følger automatisk, hvis specificeret under registrering af metadata)
- homeCommunityId indgår i DDS Repositorys konfiguration (liste over kendte services)
Behandling af udtræk i kildesystem
Et kildesystem har følgende ansvar:
- Overholdelse af snitflade og adfærd for IHE XDS.b ITI-43
- Fremfindelse af dokument(er)
- Kontrol af data-specifikke samtykker (medmindre der er tale om værdispring)
- Frafiltrering af dokumenter/dokument-dele omfattet af data-specifikke samtykker (herunder indsættelse af advarsler i svaret ved frafiltrering grundet samtykker samt advarsel ved manglende evne til at kontrollere samtykker).
Datastrukturen i Dokumentdelingsservice er opsummeret i nedenstående model.
HTML |
---|
<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ø
Adgangsscenarier og tests
De ovenstående adgangsscenarier giver anledning til en række integrationstests.
Målene med integrationstestene er at udføre en række tests, der påviser at:
- Adgangsscenarierne er understøttet af DDS som beskrevet ovenfor: Dvs det er muligt at få data ud af DDS i de forskellige scenarier
- Negative tests: For hvert scenarie vil integrationstestene inkludere en række negative tests .. det tjekkes f.eks. at der ikke kan anvendes værdispring i scenarie IA-1
Integrationstestene er bygget op på følgende måde:
- Integrationstestene i DDS er delt ind i testklasser, der dækker de ovenstående scenarier. De er navngivet med scenariernes ID som prefix og en efterfølgende beskrivende tekst , så sammenhængen med dokumenationen bevares.
- Alle testcases i integrationstestene er implementeret som metoder, der har en titel, der forklarer intentionen med testen.
- Alle testcases er bygge op efter samme skabelon med kommentarer, der klart definerer præconditions (Given), aktivering af funktion (When) og tjek af svar/postconditions (Then). Se f.eks. Martin Fowler: Given-When-Then
Således indeholder integrationstestsuiten følgende:
- B1BorgerVocesIntegrationsTest
- B2BorgerPaaVegneAfVocesIntegrationsTest
- S1SundhedspersonMocesIntegrationTest
- S1SundhedspersonVocesIntegrationTest
- S3SundhedspersonPaaVegneAfMocesIntegrationsTest
- S3SundhedspersonPaaVegneAfVocesIntegrationsTest
- IA1IkkeAutoriseretBrugerLaegeSekretaerIntegrationsTest
- IA1IkkeAutoriseretBrugerSundhedsAssistentIntegrationsTest
- IA1IkkeAutoriseretBrugerUdenRollerIntegrationsTest
For afvikling af integrationstests henvises til dokumentet DDS - Testvejledning.
Fordeling af ansvar
Der er foretaget en fordeling i ansvar for gennemførelse af aktiviteter, der foregår ved udtræk. Ansvarsfordelingen er som følger:
- DDS forestår alle aktiviteter undtagen kontrol af dokumentspecifikke samtykker
- Kildesystemer forestår fremfinding af dokumenter samt kontrol af dokumentspecifikke samtykker.
Rationalet bag denne fordeling er beskrevet i afsnit 'Kontrol af data-specifikke samtykker foretages af kildesystem' under designbeslutninger.
Behandling af udtræk i DDS Repository
I DDS guide til anvendere, afsnit hentning er der i detaljer redegjort for, hvordan DDS repository udtrækker dokumenter. Nedenfor er udvalgte områder af denne logik uddybet.
Repository bestemmelse af kildesystem(er)
Udtræk sker ved anvendelse af operationen Retrieve Document Set, hvor der i request-beskeden indgår et eller flere DocumentRequest-elementer, hver med følgende indhold:
- repositoryUniqueId, en OID, der identificerer det kildesystem, hvorfra dokumentet kan udtrækkes
- documentUniqueId, en OID, der identificerer dokumentet
- homeCommunityId, en OID, der identificerer det Community, hvorfra dokumentet kan udtrækkes (bemærk, at der kun specificeres en værdi, når denne er anført i svaret fra en Registry Stored Query, fx i svaret fra et DDS Registry)
Som beskrevet i [ITI TF-2a] 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-2b] afsnit 3.43.4.1.3 er det beskrevet, hvordan en XCA Initiating Gateway skal reagere på en Retrieve Document Set-request:
- homeCommunityId bruges til at bestemme webservice endpoint for Responding Gateways (altså repositories)
- hvis homeCommunityId identificerer det lokale IHE-fællesskab, anvendes repositoryUniqueId til at bestemme webservice endpoint for repositories
Denne adfærd ligger til grund for bestemmelsen af kildesystemer i DDS Repository beskrevet i det følgende.
Ved gennemløb af alle DocumentRequest-elementer i Retrieve Document Set-request’en skabes en mængde (Set) af webservice-endpoints og en mængde af id, der ikke kunne fremfindes:
- Hvis homeCommunityId er anført i et DocumentRequest-element i Retrieve Document Set-request’en, da foretages opslag i konfiguration på det homeCommunityId
- Fremfindes et eller flere webservice-endpoints, da tilføjes disse til mængden af webservice-endpoints (dermed fortsættes til næste DocumentRequest-element)
- Der foretages opslag på repositoryUniqueId i DDS Repositorys konfiguration
- Fremfindes et webservice-endpoint, da tilføjes dette til mængden af webservice-endpoints (dermed fortsættes til næste DocumentRequest-element)
- Fremfindes ingen webservice-endpoints, da tilføjes repositoryUniqueId’et til mængden over id, der ikke kunne fremfindes. Disse forespørgsler resulterer i en fejl hver i det resulterende svar.
- De webservice-endpoints der ikke kan kontaktes, resulterer i en fejl i det resulterende svar.
Denne mekanisme (i DDS Repositorys bestemmelse af kildesystemer) er helt ortogonal på hvorvidt kildesystemer anvender XCA. Fordelen er, at DDS Repository ikke skal kende alle repositoryUniqueId (transitivt), således at et kildesystem i et IHE-fællesskab kan skifte til og fra XCA uden at DDS Repository-konfigurationen skal ændres.
Som vist i Figur 2 kan yderligere kildesystemer via XCA knyttes til et IHE-fællesskab uden ændring i konfigurationen i DDS Repository, når homeCommunityId er kendt af DDS Repository.
...
Figur 2 Konfiguration af DDS Repository baseret på repositoryUniqueId og homeCommunityId tillader tilføjelse af nye dokumentkilder. Når DDS Repository kender til dokumentkilde C’s webservice endpoint gennem dens homeCommunityId (IHE-fællesskab XYZ), da kan der tilføjes en ny dokumentkilde, her Dokumentkilde F, til IHE-fællesskabet via XCA uden at DDS Repository skal omkonfigureres.
I Figur 2 er Dokumentkilde B kendt direkte ved dens repositoryUniqueId. Tilføjes endnu en dokumentkilde via XCA til Dokumentkilde B, da skal DDS Repository enten:
- Omkonfigureres til at kende den tilføjede dokumentkildes repositoryUniqueId og webservice endpoint, eller
- Omkonfigureres så Dokumentkilde B’s webservice endpoint kendes via dens homeCommunityId (og ikke dens repositoryUniqueId)
Forudsætningen for at mekanismen ikke falder tilbage til opslag på repositoryUniqueId, er at:
- homeCommunityId blev specificeret i metadata under registrering
- homeCommunityId blev returneret ved opslag (følger automatisk, hvis specificeret under registrering af metadata)
- homeCommunityId indgår i DDS Repositorys konfiguration (liste over kendte services)
Behandling af udtræk i kildesystem
Et kildesystem har følgende ansvar:
...
.
Designmålsætninger og -beslutninger
...
Alternativt skulle et af IHE-standardens egne fejlkoder [IHE vol. , 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.
...
Asynkron involvering af kontrolservices
Kald til Samtykkeservice , MinLog og Behandlingsrelationsservice udføres i parallel, hvert kald som synkront kald.
...
- ConsentVerificationServiceInvoker indkapsler kald af ConsentUserCheck på samtykkeverifikationsservicen. Se [ConsentVerificationService ws] for beskrivelse af kaldte webservice-snitflade.
- DocumentRetrieveInvoker forestår videresendelse af udtræk til et kildesystems ITI-43 snitflade. Dette sker gennem et webservice-interface beskrevet i [IHE Document Repository WSDL] og [ITI TF-2b2].
- MinLogRegistrationInvoker indkapsler kaldet til MinLogRegistration-servicen. Se [MinLogService ws] for beskrivelse af kaldte webservice-snitflade.
- TreatmentRelationInvoker laver kaldet til behandlingsrelationsservicen. Se [Behandlingsrelationsservice ws] for beskrivelse af kaldte webservice-snitflade.
- ConsentOverrideLoggingInvoker indkapsler den måde, logning af værdispring er implementeret.
...
Generel struktur af invoker
...
Fælles for de service-invokere, der er beskrevet i foregående afsnit er at de hver især har ansvar for:
- at indhente krævede konfigurationsparametre (fx URL for kaldte service)
- at etablere og om nødvendigt genetablere kontakt til servicen
- at gennemføre kald af den eller de operationer
- at håndtere og indkapsle alle fejl
Der er overordnet to typer af invokers: Dem med og dem uden DGWS sikkerhed.
Invoker med
...
anvendelse af DGWS
Når der laves kald af ConsentVerificationServiceInvoker , 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.
Repository:
For ConsentVerificationServiceInvoker, MinLogRegistrationInvoker og TreatmentRelationInvoker anvendes serviceklienter, der arver fra SosiService. Derved får de ved instantiering automatisk en DGWSConsumer-instans og altså også cached ID-kort-håndtering. Når der laves kald af disse services bliver et ID-kort, der stadig er gyldigt, genbrugt fra tidligere kald, og om nødvendigt bliver nyt ID-kort indhentet automatisk fra STS.
Ved de tre invokere’s kald af operationer på hhv. samtykkeverifikationsservicen, MinLogRegistration-servicen og behandlingsrelationsservicen benyttes DGWSConsumer til at skabe de nødvendige DGWS-headere (Medcom- og sikkerhedsheader).
Ved kald til hhv. samtykkeverifikationsservicen og MinLogRegistration-servicen, der begge i tilgift forventer en HSUID-header, genbruges HSUID-headeren modtaget med kaldet af DDS Repository.
Invoker uden DGWSConsumer eller STS-anvendelse
skal det foregå med et SOSI Idkort. Det er DDS's ansvar at anskaffe et system idkort således, at dette kald kan gennemføres.
Der er lavet generel håndtering af disse system idkort herunder caching.
Der er også tilfælde, hvor backends for enten DDS Registry eller DDS Repository forventer at få akkreditiver med i kaldet. Her er det som udgangspunkt den samme sikkerhedsbillet, som blev anvendt til DDS selv, der delegeres videre til den modtagende backend. Hvis DDS Registry eller DDS Repository bliver kaldt med en IDWS billet er videre delegering ikke muligt p.g.a Holder-of-key constraint. I dette tilfælde vil DDSens eget system idkort anvendes, som beskrevet ovenfor for kald til MInSpærring og BRS.
Invoker uden anvendelse af DGWS
Der er backends for både DDS Registry og DDS Repository, der ikke foreventer en sikkerhedsbillet. NXRG er et eksempel på dette. Til dette formål anvendes en serviceinvoker uden DGWSDocumentRegistryInvoker henholdsvis DocumentRetrieveInvoker er specielle 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.
...