Page History

Versions Compared

Key

This line was added.
This line was removed.
Formatting was changed.

...

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) 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 Guide til Udviklere
DDS Test	DDS Testvejledning
DDS Registry query snitflade	DDS Guide til anvendere
DDS Repository snitflade	DDS Guide til anvendere

...

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

macroId	c00d2292-b281-4b3d-8d78-e88d4b33c7ad
displayName	Anvendelse af services og databaser
name	Anvendelse af services og databaser
pagePin	46

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å NSP
registry
- for 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.

...

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.

...

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

...

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.

...

~~Matche audience som findes som konfiguration i DDS~~

Skal være der

...

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)
Sundhedsfaglig: Sundhedsfaglie kan tilgå data på borgere, hvis der er hjemmel til dette (behandlingsrelation, ikke-negativt samtykke, værdispring)
Ikke-autoriseret bruger: 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 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

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

...

Skal være Citizen

...

~~Skal være CPR~~

Verificeres ikke - må gerne være der

...

~~Skal være sat~~

Verificeres ikke - må gerne være der

...

~~Må ikke være der~~

Verificeres ikke - må gerne være der

...

Brugertypen: Sundhedsperson

			Verifikation	Mapning til MinSpærring ServiceActor
SecurityContext	Ticket	Audience

Verificeres ikke - må gerne være der

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

HealthCareProfessional

Citizen

Brugertypen:

Sundhedsfaglig

Borger
		IdentifierFormat	Skal være

CPRVerificeres ikke - må gerne være der

der og Skal være CPR
	Identifier	Skal være sat	ActingUserCpr
	GivenName	Verificeres ikke - må gerne være der

ActingUserCprGivenName


		SurName	Verificeres ikke - må gerne være der

SurName

~~Må ikke være der~~


		Credentials	Verificeres ikke - må gerne være der

Credentials.NationalRole


		PersistentUniqueKey

PersistentUniqueKeyVerificeres ikke - må gerne være der

Verificeres ikke - må gerne være der

Credentials.AuthorizationCodeSkal være derAuthorizationCode

PrincipalUser		Må ikke være der
	Organisation

Identifier

~~Skal være der~~

Verificeres ikke - må gerne være der

identifierFormat~~Skal være der og skal være CVR~~

		Verificeres ikke - må gerne være der
	Client	Name	Verificeres ikke - må gerne være der	systemName

...

Brugertypen:

Ikke-autoriseret sundhedsprofessionel

Sundhedsfaglig

Verifikation

Mapning til

DDS

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

Verificeres ikke - må gerne være der


		Identifier	Skal være sat

Verificeres ikke - må gerne være der

ActingUserCpr
	GivenName	Verificeres ikke - må gerne være der
	SurName	Verificeres ikke - må gerne være der
	Credentials.NationalRole

Må

Verificeres ikke - må gerne være der

, og anvendes hvis den er. Ellers anvendes "ingen rolle"

NationalRole


		Credentials.AuthorizationCode

Må ikke

Skal være der	AuthorizationCode
		PersistentUniqueKey	Verificeres ikke - må gerne være der
	PrincipalUser		Må ikke være der
	Organisation	Identifier

~~Skal være der~~

Verificeres ikke - må gerne være der

identifierFormat

~~Skal være der og skal være CVR~~

Verificeres ikke - må gerne være der

Client

Name

Verificeres ikke - må gerne være der

systemName

ActingUser må ikke derVerificeres ikke - må ActingUser ikke

Brugertypen: Ikke defineret-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: Ikke defineretSundhedsfaglig
		IdentifierFormat	Skal være CPR
		Identifier	Skal være sat	ActingUserCpr
		GivenName	PrincipalUser	Må ikke være der	Organisation	Identifier	Verificeres ikke - må gerne være der
		identifierFormatSurName	Verificeres ikke - må gerne være der	Client	Name
		Credentials.NationalRole	Må gerne være der	systemName
Brugertypen: Ikke defineret på vegne af			Verifikation	Mapning til DDS ServiceActor
, og anvendes hvis den er. Ellers anvendes "ingen rolle"	NationalRole
		Credentials.AuthorizationCode	Må ikke være der
		PersistentUniqueKey	SecurityContext	Ticket	Audience	Verificeres ikke - må gerne være der
	PrincipalUser		Må ikke være der
	Organisation	Identifier	Verificeres ikke - må gerne være der
		identifierFormat	Validity	Er valid	Message	Verificeres ikke - må gerne være der
	ActingUserClient	UserTypeName	Verificeres ikke - må	gerne være der	systemName

Ikke defineret på vegne af

Brugertypen:			System			Verifikation	Mapning til DDS ServiceActor
SecurityContext	Ticket	Audience	PrincipalUser	Skal være der	Organisation	Identifier	Verificeres ikke - må gerne være der
		Validity	Er valid
	MessageidentifierFormat		Verificeres ikke - må gerne være der	Client
	ActingUser	UserType	Må ikke være der	Brugertypen: System
	PrincipalUser		Må ikke være der
	Organisation	IdentifierName	Verificeres ikke - må gerne være der	systemName

Transformation af Udefineret bruger

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 En udefineret bruger giver ikke mening i sig selv, og skal mappes over til en rigtig brugeranden brugertype. Andre typer brugere brugertyper kan også mappes til nye typer

~~Ikke-autoriseret sundhedsprofessionel >> Sundhedsperson~~
Ikke-autoriseret sundhedsprofessionel >> Sundhedsperson på vegne af
Borger >> Borger på vegne af
Udefineret type >> borger på vegne af
Udefineret type >> borger
Udefineret type på vegne af >> Sundhedsperson på vegne af

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

~~Har fjernet sunhed.dk i parentest efter brugertyperne. skal måske sættes på igen.~~

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

macroId	5bb5c4e2-da64-4477-8e65-7aebeae8e0c8
displayName	rolletransformering
name	rolletransformering
pagePin	7

Skal være sat

Må ikke være magen til actingUserCivilRegistrationNumber~~healthcareOrgTypehealthCareOrg~~ valideres mod db??

System >> Brugertypen Sundhedsfaglig Udefineret type på vegne af >> Brugertypen Sundhedsperson 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		Må ikke være sat eller være anderledes end 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 SecurityContext
	systemVersion	Verificeres ikke - må gerne være der	~~systemName (postfix)~~
	userAuthorizationCode	Skal være sat og	valideres med actingUser	AuthorizationCode

Actor cvr skal være whitelisted

Verificeres ikke ~~healthcareOrgTypehealthCareOrg~~

System Ikke-autoriseret sundhedsprofessionel >> Brugertypen Sundhedsperson 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 satSkal matche den på SecurityContext	ActingUserCpr
	responsibleUserRegistrationNumber	Skal være sat Må ikke være magen til actingUserCivilRegistrationNumber ~~Må ikke være sat eller være anderledes end actingUserCivilRegistrationNumber~~	responsibleUserCpr	og skal være anderledes end actingUserCivilRegistrationNumber
	orgUsingIDType	Verificeres ikke	~~orgUsingIDType~~	- 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 SecurityContext
	systemVersion	Verificeres ikke - må gerne være der	~~systemName (postfix)~~
	userAuthorizationCode	Skal være sat og valideres mod db??med responsibleUser	AuthorizationCode

Actor cvr skal være whitelisted

skal være CITIZENEr givet fra securityContext pga. rollen borger

Sundhedsfaglig Borger >> Brugertypen Borger Sundhedsfaglig på vegne af			Verifikation	Mapning til DDS ServiceActor
HSUID Header	userType		Skal være der og	være HEALTHCAREPROFESSIONAL	Brugertypen: Borger Sundhedsfaglig på vegne af
	actingUserCivilRegistrationNumber	Verificeres ikke - må gerne være der Istedet anvendes actingUser fra securityContext der skal være sat cprFromPayload skal være sat og og matche	ActingUserCpr		Skal være sat	ActingUserCpr
	responsibleUserRegistrationNumber		Skal være sat og skal være anderledes end actingUserCivilRegistrationNumber
	orgUsingIDType		Verificeres	responsibleUserRegistrationNumber	Verifices ikke - må gerne være sat Istedet anvendes cprFromPayload, der tjekkes om relation med actingUser	ResponsibleUserCpr (fra payload)	der
	orgUsingIDName		systemName	Verificeres ikke - må gerne være der
	systemName fra SecurityContext ~~systemVersion~~		Verificeres ikke - må gerne være der systemName fra actor mappes	systemName
	systemVersion (postfix) userAuthorizationCode		Verificeres ikke - må gerne være der


	userAuthorizationCode		Skal være sat og valideres med responsible user	AuthorizationCode

skal CITIZEN

Ikke-autoriseret bruger Udefineret type >> Brugertypen Borger Sundhedsfaglig på vegne af af			Verifikation	Mapning til DDS ServiceActor
HSUID Header	userType		Skal være der og	være	HEALTHCAREPROFESSIONAL	Brugertypen: Borger Sundhedsfaglig på vegne af
	actingUserCivilRegistrationNumber		Skal være der (valideres indirekte ved at relation med responsibleUser skal være tilstede) sat	ActingUserCpr
	responsibleUserRegistrationNumber		Skal være sat Skal være forskellige fra actingUserCivilRegistrationNumber Actinguser skal være/have værge, forældremyndighed eller fuldmagt over responsible	ResponsibleUserCpr	sat og skal være anderledes end actingUserCivilRegistrationNumber
	orgUsingIDType		Verificeres ikke - må gerne være der
	orgUsingIDName		systemName	Verificeres ikke - må gerne være der
	systemName fra SecurityContext	~~systemVersion~~		Verificeres ikke - må gerne være der systemName fra actor mappes	systemName (postfix)
	userAuthorizationCodesystemVersion		Verificeres ikke - må gerne være der


	userAuthorizationCode		Skal være sat og valideres med responsible user	AuthorizationCode

Skal være der og skal være CITIZEN

Borger Udefineret type >>

Brugertypen Borger på vegne af

Verifikation

Mapning til DDS ServiceActor

HSUID HeadercprFromPayload

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

actingUserCivilRegistrationNumber

Verificeres ikke - må gerne være der

ActingUserCpr

responsibleUserRegistrationNumber

Verificeres ikke - må gerne være der

ResponsibleUserCpr

systemName

Verificeres ikke - må gerne være der

systemName fra SecurityContext

~~systemVersion~~

~~Verificeres ikke - må gerne være der~~

~~systemName (postfix)~~

userAuthorizationCode

Verificeres ikke - må gerne være der

De forskellige brugertyper bliver beriget med:

Sundhedsperson alm og på vegne af:
- organisationIdtype fra hsuid
- organisationId fra hsuid
Ikke autoriseret sundhedsprofessionel:
- organisationIdtype fra hsuid
- organisationId fra hsuid

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.

...

Som en...

...

ønsker jeg at..

...

ved anvendelse af værdispring

...

så jeg...

...


			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 (kun værge/forældremyndighed, ikke fuldmagt)	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

...

	Samtykkeservice	MinLog Service	Behandlingsrelationservice
B1 + B2	Ikke relevant (samtykkeservice omhandler kun samtykke i forhold til sundhedspersoner og disses organisationer)	Logges ikke	Ikke relevant
S1 + S2 + S3SF1 + 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 Image RemovedSDS-2990 - Ikke autoriserede brugere skal fremsende bindestreg til BRS som autorisationskode ARKIVERET for detaljer.

Samtykkeservice

MinLog Service

Behandlingsrelationservice

B1 + B2

Ikke relevant (samtykkeservice omhandler kun samtykke i forhold til sundhedspersoner og disses organisationer)

Logges ikke

Ikke relevant

S1 + S2 + S3SF1 + 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

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.

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. Kaldes med '-' i stedet for autorisationskode. Se i øvrigt Image RemovedSDS-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)

Brugertypen

Bestemmes i sikkerhedshandleren for komponenten. En OIO IDWS billet betyder, at brugeren er en borger.

Hvis SOSI Idkort benyttes, så bestemmes brugertypen udfra HSUID headers attribut nsi:UserType (værdi 'nsi:Citizen')

Bestemmes udfra HSUID headers attribut nsi:UserType (værdi 'nsi:HealthcareProfessional')Bestemmes udfra HSUID headers attribut nsi:UserType (værdi 'nsi:HealthcareProfessional' men uden autorisationsid)SOSI id-kort

Niveau 3 (F/VOCES - dette kræver særskilt aftale om anvendelse, jf Dokumentdelingsservice (DDS))

Niveau 4 (MOCES)

Niveau 4 (MOCES)OIO IDWSUnderstøttetIkke understøttetIkke understøttetBrugerens cpr nummer

Hvis OIO IDWS anvedes, så trækkes cpr nummeret ud af IDWS billetten.

Hvis DGWS benyttes, så bestemmes det udfra HSUID headers attribut nsi:ActingUserCivilRegistrationNumber

Bestemmes udfra HSUID headers attribut nsi:ActingUserCivilRegistrationNumber

For sekrætærer (S3) er det den person, der arbejdes på vegne af, der er relevant. Denne findes i HSUID headers attribut nsi:ResponsibleUserCivilRegistrationNumber

For scenariet S1 vil værdien af de to HSUID header attributter være ens.

Bestemmes udfra HSUID headers attribut nsi:ActingUserCivilRegistrationNumberBrugerens autorisationskodeIkke relevantBestemmes udfra HSUID headers attribut nsi:ResponsibleUserAuthorizationCodeIkke relevantBrugerens rolleIkke releavntIkke relevantBestemmes ud fra national SEB rolle og læses i SOSI Id-kortet under attributten 'nsi:UserRole'

'-' i stedet for autorisationskode. Se i øvrigt Image AddedSDS-2990 - Ikke autoriserede brugere skal fremsende bindestreg til BRS som autorisationskode ARKIVERET for detaljer.

Adgangsscenarier og tests

...

Integrationstestene i DDS er delt ind i testklasser, der dækker de ovenstående scenarier. De er navngivet med scenariernes ID roller som prefix og en efterfølgende beskrivende tekst, så sammenhængen med dokumenationen bevares.
Alle testcases i integrationstestene er implementeret som metodercucumber test, der har en titel, der i sin anvendelse forklarer intentionen med testen.
Alle testcases er bygge op efter samme skabelon med kommentarer, der klart 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:

. 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
B1BorgerVocesIntegrationsTest
B2BorgerPaaVegneAfVocesIntegrationsTest
S1SundhedspersonMocesIntegrationTest
S1SundhedspersonVocesIntegrationTest
S3SundhedspersonPaaVegneAfMocesIntegrationsTest
S3SundhedspersonPaaVegneAfVocesIntegrationsTest
IA1IkkeAutoriseretBrugerLaegeSekretaerIntegrationsTest
IA1IkkeAutoriseretBrugerSundhedsAssistentIntegrationsTest
IA1IkkeAutoriseretBrugerUdenRollerIntegrationsTest

For afvikling af integrationstests henvises til dokumentet DDS - Testvejledning.

...

Asynkron involvering af kontrolservices

Kald til Samtykkeservice , MinLog og Behandlingsrelationsservice udføres i parallel, hvert kald som synkront kald.

...

Content

Space Tools

Versions Compared

Old Version 30

New Version Current

Key

Brugertyper

Bestemmelse og mapning til actor

Bestemmelse og mapning til actor

Transformation af Udefineret bruger

Transformation af brugertyper

Brugertyper og adgangsscenarier

Brug af eksterne services ved adgangsscenarier

Adgangsscenarier og DGWS

Adgangsscenarier og tests

Asynkron involvering af kontrolservices