Edit profile

Page History

Versions Compared

Key

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

...

Definitioner og referencer

...

NSP

...

National Service Platform
SFSK	Synkroniseringsservice til Fælles Stamkort
DGWS	Den Gode WebService
BRS	Behandlingsrelationsservice
SEAS	Stamdata autorisation enkeltopslagsservice

Overblik over SFSK

SFSK er en service til at gøre det muligt at fremsøge og hente Fælles Stamkort via snitflader, som de kendes fra Dokumentdelingsservice Registry og Repository (se DDS - Design- og Arkitekturbeskrivelse (Registry) og DDS - Design- og Arkitekturbeskrivelse (Repository)).

I modsætning til DDS, så er Tidligere var SFSK målrettet systembrugere og dækker det behov, der kan være for synkronisering af Fælles Stamkort i anvendernes fagsystemer, modsat DDS'en, men i de seneste versioner er der indført borgerkald og medarbejderkald via IDWS. Hensigten er at afkoble Fælles Stamkort fra DDS'en.

I de følgende afsnit kigger vi på SFSK og dens afhængigheder til andre NSP services og i form af tredjepartsbiblioteker.

...

Sikkerhedsvalidere kald fra anvendersystemer
Hente data i de bagvedliggende registre FSK Registry og FSK
Foretage auditlogning
SEAS kaldes når der bliver kald som en "Sundhedsfaglig på vegne af", hvor autorisationskoden valideres
Minlog skrive til ve fremsøgning af dokumenthetningkaldes ved fremsøgning- og dokument-hentning
BRS når en sunhedsfaglig sundhedsfaglig kalder servicen.

SFSK indgår i samspil med de øvrige NSP services på følgende måde:

Gliffy Diagram

macroId	ff0c9e61-57c6-4227-bb47-3e6b7a18d713
displayName	SFSK på NSP
name	SFSK på NSP
pagePin	1112

Relevante tredjepartsbiblioteker

...

Sikkerhedshåndtering i SFSK

BrugertyperBrugertyper

SFSK anvender det på platformen udstillede security-api til at validere de indkommende requests. Alle kald til SFKS skal være lovlige DGWS eller IDWS-kald. SFSK understøtter følgende brugertyper:

...

Som en...

...

ønsker jeg at..

...

så jeg...

...

Sundhedsfaglig med national rolle

...

de brugertyper, der er beskrevet i SFSK - Brugerhistorier.

Uddybende beskrivelse af de enkelte brugertyper samt skema der identificere en brugertype ud fra Security API.

Bestemmelse og mapning til actor

Borger

Borgerkald sker fra sundhed.dk via system-id-kort udstedt af sundhed.dk.

For IDWS-kald anvendes HsuidHeader ikke og forventes ikke medsendt. Brugertypen identificeres i stedet alene via Security API’et. Ved mapning af actoren ved IDWS er der kun brugertypen Borger.

Sundhed.dk anvender i dag et systemopslag til at hente Fælles Stamkort, da DDS ikke understøttede borgeropslag via IDWS. Sundhed.dk er dermed trustet til at lave borgeropslag på vegne af borgeren.

For alle borgerkald laves der registreringer i minlog, men der kontrolleres ikke for behandlingsrelation

Brugertypen IDWS: Borger			Verifikation	Mapning til SfskActor
SecurityContext	Ticket	Audience	Skal være der og skal være "https://fsk"	audience
		Validity	Er valid
	Message		Verificeres ikke - må gerne være der
	ActingUser		Skal være der
		IdentifierFormat	Skal være der og skal være CPR	actorIdType
		Identifier	Skal være der	actorId
	PrincipalUser		Verificeres ikke - må gerne være der
	Organisation		Verificeres ikke - må gerne være der

Borger på vegne af anden borger

Fuldmagtsbaseret borgeropslag fra sundhed.dk via system-id-kort udstedt af sundhed.dk. Sundhed.dk er trustet til at lave fuldmagtsopslag fra en borger på vegne af en anden borger.

Der medsendes også en HsuidHeader og indholdet af den afgør om det er en borger der kalder på vegne af en anden borger - eller om det er en systembruger. Oplysningerne på billetten fra Security API'er er identisk med oplysningerne for en systembruger.

Når der kaldes på vegne af en anden borger, laves der en minlog registrering, men der kontrolleres ikke for behandlingsrelation.

Brugertypen DGWS: Borger på vegne af anden borger			Verifikation	Mapning til SfskActor
SecurityContext	Ticket	Audience	Verificeres ikke - må gerne være der
		Validity	Er valid
	Message		Verificeres ikke - må gerne være der
	ActingUser		Må ikke være der
	PrincipalUser		Må ikke være der
	Organisation	Identifier	Skal være der	actorId
		IdentifierFormat	Skal være der og skal være CVR	actorIdType

Sundhedsfaglig med autorisation

Sundhedsfaglig opslag fra Sundhedsjournalen (og andre whitelistede fagsystemer) med medarbejderbaseret-id-kort (niveau 4). Sundhedsfaglige med autorisation, kan lave opslag på borgerens Fælles stamkort via Sundhedsjournalen

Der laves minlog registrering og der kontrolleres for behandlingsrelation.

Brugertypen DGWS: Sundhedsfaglig med autorisation			Verifikation	Mapning til SfskActor
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	actorType
		IdentifierFormat	Skal være CPR	actorIdType
		Identifier	Skal være sat	actorId
		GivenName	Verificeres ikke - må gerne være der
		SurName	Verificeres ikke - må gerne være der
		Credentials.AuthorizationCode	Skal være sat
		Credentials.NationalRole	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		Verificeres ikke - må gerne være der

Ikke-autoriseret sundhedsfaglig

Sundhedsfaglig opslag fra Sundhedsjournalen (og andre whitelistede fagsystemer) med medarbejderbaseret-id-kort (niveau 4) hvor national rolle er tilknyttet (nspSundAssistR1 og nspSundAssistR2 giver adgang til Fælles Stamkort)

Der laves minlog registering og der kontrolleres for behandlingsrelation

Brugertypen DGWS: Sundhedsfaglig med national rolle

Uddybende beskrivelse af de enkelte brugertyper samt skema der identificere en brugertype ud fra Security API.

Bestemmelse og mapning til actor

Borger

Borgerkald sker fra sundhed.dk via system-id-kort udstedt af sundhed.dk.

Der medsendes også en HsuidHeader og indholdet af den afgør om det er et borgerkald eller en systembruger. Oplysningerne på billetten fra Security API'er er identisk med oplysningerne for en systembruger.

Sundhed.dk anvender i dag et systemopslag til at hente Fælles Stamkort, da DDS ikke understøttede borgeropslag via IDWS. Sundhed.dk er dermed trustet til at lave borgeropslag på vegne af borgeren.

For borgerkald laves der ikke registreringer i minlog og der kontrolleres ikke for behandlingsrelation.

Brugertypen: Borger

			Verifikation	Mapning til SfskActor
SecurityContext	Ticket	Audience	Verificeres ikke - må gerne være der
		Validity	Er

validMessage

valid
	Message		Verificeres ikke - må gerne være der
	ActingUser	UserType	Skal være HealthcareProfessional	actorType
		IdentifierFormat	Skal være CPR	actorIdType
		Identifier	Skal være sat	actorId
		GivenName	Verificeres ikke - må gerne være der
		SurName	Verificeres ikke - må gerne være der

ActingUser


	Credentials.AuthorizationCode	Må ikke være der
	Credentials.NationalRole	Skal være der - og skal matche national rolle der er opsat i properties i SFSK
PrincipalUser		Må ikke være der
Organisation	Identifier	Skal være der

actorId

organisationIdentifier
		IdentifierFormat	Skal være der og skal være CVR

actorIdType


	Client		Verificeres ikke - må gerne være der

Sundhedsfaglig Borger på vegne af anden borgersundhedsfagligFuldmagtsbaseret borgeropslag fra sundhed.dk via system

Sundhedsfaglig opslag fra Sundhedsjournalen (og andre whitelistede fagsystemer) med medarbejderbaseret-id-kort udstedt af sundhed.dk. Sundhed.dk er trustet til at lave fuldmagtsopslag fra en borger på vegne af en anden borger.(niveau 4)

Der medsendes også en HsuidHeader og indholdet af den afgør om det er en borger sundhedsfaglig der kalder på vegne af en anden borger - eller om det er en systembrugersundhedsfaglig. Oplysningerne på billetten fra Security API'er er identisk med oplysningerne for en systembruger.en medarbejder.

Der laves minlog registering for begge sundhedsfaglige Når der kaldes på vegne af en anden borger skal der laves en minlog registrering og der kontrolleres ikke for behandlingsrelation.

Brugertypen DGWS:

Borger

Sundhedsfaglig på vegne af anden

borger

sundhedsfaglig			Verifikation	Mapning til SfskActor
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	actorType
		IdentifierFormat	Skal være CPR	actorIdType
		Identifier	Skal være sat	actorId
		GivenName	Verificeres ikke - må gerne være der

ActingUser


		SurName

Må

Verificeres ikke - må gerne være der

PrincipalUser


		Credentials.AuthorizationCode	Må ikke være der

OrganisationIdentifierSkal være deractorIdIdentifierFormatSkal være der og skal være CVRactorIdType

Sundhedsfaglig med autorisation

Der laves minlog registrering og der kontrolleres for behandlingsrelation.


	Credentials.NationalRole	Skal være der - og skal matche national rolle der er opsat i properties i SFSK
PrincipalUser		Må ikke være der
Organisation	Identifier	Skal være der	organisationIdentifier
	IdentifierFormat	Skal være der og skal være CVR
Client

Brugertypen: Sundhedsfaglig med autorisationVerifikationMapning til SfskActorSecurityContextTicketAudience

Verificeres ikke - må gerne være der

Systembruger

Systembaserede opslag fra whitelistede fagsystemer via system-id-kort. Fagsystemer kan enten lave systembaserede opslag, eller via systembaserede opslag opbygge en en lokal registerkopi af Fælles Stamkort, som holdes opdateret ud fra adviseringer fra underliggende registre

Der laves ikke minlog registrering (Det er fagsystemets ansvar at gøre dette) og der kontrolleres ikke for behandlingsrelation (Det er fagsystemets ansvar at gøre dette).

Brugertypen DGWS: Systembruger			Verifikation	Mapning til SfskActor
SecurityContext	Ticket	Audience

ValidityEr validMessageVerificeres ikke - må gerne være derActingUserUserTypeSkal være HealthcareProfessionalactorTypeIdentifierFormatSkal være CPRactorIdTypeIdentifierSkal være satactorIdGivenName

Verificeres ikke - må gerne være der

SurName


	Validity	Er valid
Message		Verificeres ikke - må gerne være der

Credentials.AuthorizationCodeSkal være sat


	ActingUser		Må ikke

Credentials.NationalRoleVerificeres ikke - må gerne

være der
	PrincipalUser	Må ikke være der
	Organisation

IdentifierSkal være derIdentifierFormatSkal være der og skal være CVRClientVerificeres ikke - må gerne være der

Ikke-autoriseret sundhedsfaglig

Der laves minlog registering og der kontrolleres for behandlingsrelation

Identifier

Skal være der

actorId /

organisationIdentifier

IdentifierFormat

Skal være der og skal være CVR

actorIdType

Transformation af brugertyper

Ved kald til SFSK kan en systembruger i virkeligheden være et kald fra en anden brugertype. Det er informationer på HsuidHeaderen der afgør om den skal transformeres til en anden brugertype. Der findes følgende tranformationer:

Gliffy Diagram

displayName	sfsk-brugertyper-transformationer
name	sfsk-brugertyper-transformationer
pagePin	4

System >> Brugertypen Borger		Verifikation	Mapning til SFSK ServiceActor
HSUID Header	userType	Skal være der og skal være CITIZEN	Brugertypen: Borger
	actingUserCivilRegistrationNumber	Skal være der	ActingUserCpr
	responsibleUserRegistrationNumber	Må ikke være der
	orgUsingIDType

Brugertypen: Sundhedsfaglig med national rolleVerifikationMapning til SfskActorSecurityContextTicketAudienceVerificeres ikke - må gerne være der ValidityEr validMessageVerificeres ikke - må gerne være derActingUserUserTypeSkal være HealthcareProfessionalactorTypeIdentifierFormatSkal være CPRactorIdTypeIdentifierSkal være satactorIdGivenNameVerificeres ikke - må gerne være derSurName

Verificeres ikke - må gerne være der

Credentials.AuthorizationCodeMå ikke være derCredentials.NationalRoleSkal være der - og skal matche national rolle der er opsat i properties i SFSK


	orgUsingIDName		Verificeres ikke - må gerne

PrincipalUserMå ikke

være der

OrganisationIdentifier


	systemName		Verificeres ikke - må gerne

Skal

være der

IdentifierFormatSkal


	systemVersion		Verificeres ikke - må gerne være der

og skal være CVR

Client


	userAuthorizationCode		Verificeres ikke - må gerne være der

Sundhedsfaglig på vegne af anden sundhedsfaglig

Sundhedsfaglig opslag fra Sundhedsjournalen (og andre whitelistede fagsystemer) med medarbejderbaseret-id-kort (niveau 4)

Der medsendes også en HsuidHeader og indholdet af den afgør om det er en sundhedsfaglig der kalder på vegne af en anden sundhedsfaglig. Oplysningerne på billetten fra Security API'er er identisk med oplysningerne for en medarbejder.

Der laves minlog registering for begge sundhedsfaglige og der kontrolleres for behandlingsrelation


	citizenCivilRegistrationNumber		Skal være der og ens med actingUserCivilRegistrationNumber

System >> Brugertypen Borger på vegne af		Verifikation	Mapning til SFSK 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
	relation	Skal være sat og en af følgende skal returnere true: isRelationChildCustodyHolder isRelationProxyHolder	relation
	orgUsingIDType

Brugertypen: Sundhedsfaglig på vegne af anden sundhedsfagligVerifikationMapning til SfskActorSecurityContextTicketAudienceVerificeres ikke - må gerne være der ValidityEr validMessageIdentifierFormatSkal være CPRactorIdTypeIdentifierSkal være satactorIdGivenName

Verificeres ikke - må gerne være der

ActingUserUserTypeSkal være HealthcareProfessionalactorType


	orgUsingIDName		Verificeres ikke - må gerne være der
	systemName

Verificeres ikke - må gerne være der

SurName


	systemVersion		Verificeres ikke - må gerne være der

Credentials.AuthorizationCode


	userAuthorizationCode

Må

Verificeres ikke - må gerne være der

Credentials.NationalRole


	citizenCivilRegistrationNumber		Skal være der

- og skal matche national rolle der er opsat i properties i SFSKPrincipalUserMå ikke være derOrganisationIdentifierSkal være derIdentifierFormatSkal være der og skal være CVRClientVerificeres ikke - må gerne være der

Systembruger

Der laves ikke minlog registrering (Det er fagsystemets ansvar at gøre dette) og der kontrolleres ikke for behandlingsrelation (Det er fagsystemets ansvar at gøre dette).

System >> Brugertypen System		Verifikation	Mapning til SFSK ServiceActor
HSUID Header	userType	Må ikke være der	Brugertypen: System
	actingUserCivilRegistrationNumber	Må ikke være der
	responsibleUserRegistrationNumber	Må ikke være der
	orgUsingIDType	Verificeres ikke - må gerne være der
	orgUsingIDName	Verificeres ikke - må gerne være der
	systemName	Verificeres ikke - må gerne være der
	systemVersion	Verificeres ikke - må gerne være der
	userAuthorizationCode	Verificeres ikke - må gerne være der
	citizenCivilRegistrationNumber

Brugertypen: SystembrugerVerifikationMapning til SfskActorSecurityContextTicketAudience

Verificeres ikke - må gerne være der

ValidityEr validMessageVerificeres ikke - må gerne være derActingUserMå ikke være derPrincipalUserMå ikke være derOrganisationIdentifierSkal være deractorIdIdentifierFormatSkal være der og skal være CVRactorIdType

Transformation af brugertyper

Gliffy Diagram

displayName	sfsk-brugertyper-transformationer
name	sfsk-brugertyper-transformationer
pagePin	3

Medarbejder >> Brugertypen Sundhedsfaglig på vegne af anden sundhedsfaglig		Verifikation	Mapning til SFSK ServiceActor
HSUID Header	userType	Skal være der og skal være HEALTHCAREPROFESSIONAL	Brugertypen: Sundhedsfaglig på vegne af anden sundhedsfaglig
	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
	systemVersion	Verificeres ikke - må gerne være der
	userAuthorizationCode	Skal være sat og valideres med responsibleUser	AuthorizationCode
	citizenCivilRegistrationNumber	Skal være der

Borger IDWS >>

Brugertypen Borger på vegne af

System >>

Brugertypen Borger

			Verifikation	Mapning til SFSK ServiceActor
SecurityContext

HSUID Header

Actor

userType

ActorType

Skal være der og

skal

være

CITIZEN

BORGER

Brugertypen: Borger

ActingUser

actingUserCivilRegistrationNumber

UserType

Skal være der

ActingUserCpr

responsibleUserRegistrationNumber

Må ikke være der

orgUsingIDType

og være Citizen
	IdentifierFormat	Verificeres ikke - må gerne være der (Den er verificeres i mapning af actoren)
	Identifier	Skal være der	actorId, hvis cprFraPayload ikke er der ellers actorId = cprFraPayload
	GivenName	Verificeres ikke - må gerne være der

orgUsingIDName


		SurName	Verificeres ikke - må gerne være der

systemName


		Credentials	Verificeres ikke - må gerne være der

systemVersion


		Age	Skal

Verificeres ikke - må gerne

orgUsingIDType

være der hvis Relation er ChildCustodyHolder

userAuthorizationCode

Verificeres ikke - må gerne være der

System >>

Brugertypen Borger på vegne af

VerifikationMapning til SFSK ServiceActor

HSUID Header

userTypeSkal 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

relation

Skal være sat og en af følgende skal returnere true:

isRelationChildCustodyHolder

isRelationProxyHolder

relation


	Relation	Skal være der og enten være ProxyHolder, Guardian eller ChildCustodyHolder. Hvis ChildCustodyHolder skal Age være større end 15 (Age < 15)	Relation
	Credentials.PowerOfAttorneyPrivileges	Hvis Relation ikke er til stede, kontrolleres det, om PowerOfAttorneyPrivileges er til stede og matcher værdien af egenskaben "sfsk.idws.citizen.powerofattorney.privileges".	Relation
PrincipalUser		Skal være der, hvis det er det er Iti43 kald. For at bestemme responsibleUser ved "Borger på vegne af".
Organisation

Verificeres ikke - må gerne være der

orgUsingIDName


	Client		Verificeres ikke - må gerne være der

systemName

Verificeres ikke - må gerne være der

systemVersion

Verificeres ikke - må gerne være der

userAuthorizationCode

Verificeres ikke - må gerne være der

System >>

Brugertypen System

VerifikationMapning til SFSK ServiceActor

HSUID Header

userTypeMå ikke være der

Brugertypen: System

actingUserCivilRegistrationNumber

Må ikke være der

responsibleUserRegistrationNumber

Må ikke være der

orgUsingIDType

Verificeres ikke - må gerne være der

orgUsingIDName

Verificeres ikke - må gerne være der

systemName

Verificeres ikke - må gerne være der

systemVersion

Verificeres ikke - må gerne være der

userAuthorizationCode

Verificeres ikke - må gerne være der

Medarbejder >>

Brugertypen Sundhedsfaglig på vegne af anden sundhedsfaglig

VerifikationMapning til SFSK ServiceActor

HSUID Header

userTypeSkal være der og skal være HEALTHCAREPROFESSIONAL

Brugertypen: Sundhedsfaglig på vegne af anden sundhedsfaglig

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

systemVersion

Verificeres ikke - må gerne være der

userAuthorizationCode

Skal være sat og valideres med responsibleUser

AuthorizationCode

2 Kald til Behandlingsrelationsservice (BRS)

Der tjekkes for behandlingsrelation, når SFSK bliver kaldt af en sunhedsfarlig.

2 Kald til Behandlingsrelationsservice (BRS)

Der tjekkes for behandlingsrelation, når SFSK bliver kaldt af en sundhedsfaglig.

Tjek for behandlingsrelation	Fremsøg stamkort	Hent stamkort
Borger	Der kontrolleres ikke for behandlingsrelation	Der kontrolleres ikke for behandlingsrelation
Borger på vegne af	Der kontrolleres ikke for behandlingsrelation	Der kontrolleres ikke for behandlingsrelation
Sundhedsfaglig m. autorisation	Der kontrolleres for behandlingsrelation	Der kontrolleres for behandlingsrelation
Sundhedsfaglig m. national rolle	Der kontrolleres for behandlingsrelation	Der kontrolleres for behandlingsrelation
Sundhedsfaglig på vegne af sundhedsfaglig	Der kontrolleres for behandlingsrelation	Der kontrolleres for behandlingsrelation
Systembruger	Der kontrolleres ikke for behandlingsrelation	Der kontrolleres ikke for behandlingsrelation

svaret fra BRS anvendes ikke til at spærre for noget, da det ikke er sikkert, at evidensgrundlaget er på plads i BRS på opslagstidspunktet.

Følgende tabel viser, hvor oplysningerne i bestillingen af opfølging i BRS stammer fra:

Tjek for behandlingsrelationFremsøg stamkortHent stamkortBorgerDer kontrolleres ikke for behandlingsrelationDer kontrolleres ikke for behandlingsrelationBorger på vegne afDer kontrolleres ikke for behandlingsrelationDer kontrolleres ikke for behandlingsrelationSundhedsfaglig m. autorisationDer kontrolleres for behandlingsrelationDer kontrolleres for behandlingsrelationSundhedsfaglig m. national rolleDer kontrolleres for behandlingsrelationDer kontrolleres for behandlingsrelationSundhedsfaglig på vegne af sundhedsfagligDer kontrolleres for behandlingsrelationDer kontrolleres for behandlingsrelationSystembrugerDer kontrolleres ikke for behandlingsrelationDer kontrolleres ikke for behandlingsrelation

Felt i TreatmentRelationRequest	Hvor stammer oplysningen fra i kald mod DDS?
PatientCpr	Borgerens CPR nummer (som opslaget drejer sig om)
HealthcareProfessionalCpr	Opslaget stammer fra en sundhedsprofessionelle bruger, derfor anvendes der CPR nummer af af den sundhedsprofessionelle (som angivet i HSUID headeren nsi:ActingUserCivilRegistrationNumber).
AuthorisationIdentifer	Hvis kaldet indeholder en autorisationskode (som angivet i HSUID headeren nsi:ResponsibleUserAuthorizationCode), så medsendes denne
OrganisationIdentifier	Organisationen (som angivet i HSUID headeren nsi:OrgUsingID)
ExternalReferenceId	Udfyldes med defaultværdi for SFSK (som angivet i konfigurationsparameteren treatment.relation.external.reference.id) Nuværende værdi: tom
QueryableCvr	Udfyldes med defaultværdi for SFSK (som angivet i konfigurationsparameteren sfsk.dgws.cvr) Nuværende værdi: 30808460
AcceptableRelations	Udfyldes med defaultværdi for SFSK (som angivet i konfigurationsparameteren treatment.relation.acceptable.relations) nuværende værdi: A,B,C
FollowupRelations	Udfyldes med defaultværdi for SFSK (som angivet i konfigurationsparameteren treatment.relation.followup.relations) nuværende værdi: All
RelationLookupTimeInterval	Fradato sættes til tidspunktet for opslaget + et offset i antal dage (som angivet i konfigurationsparameteren for SFSK treatment.relation.lookup.timeinterval.start.offset) Nuværende værdi: -1 Tildato sættes til tidspunktet for opslaget + et offset i antal dage (angivet i konfigurationsparameteren for SFSK treatment.relation.lookup.timeinterval.end.offset) Nuværende værdi: 1
TimeLimit	Sættes til konfigurationsparameteren for SFSK treatment.relation.lookup.timeinterval.timelimit.offset) Nuværende værdi: 90
ServiceProvider	Udfyldes med defaultværdi for SFSK (som angivet i konfigurationsparameteren sfsk.app.name) Nuværende værdi: sfsk Vendor sættes til konfigurationsparameteren for SFSK treatment.relation.serviceprovider.vendor Nuværende værdi: vender Version sættes til konfigurationparameteren for SFSK treatment.relation.serviceprovider.version Nuværende værdi: version

Kald til Stamdata autorisation enkeltopslagsservice (SAES)

...

Sekvensdiagrammerne nedenfor beskriver flowet i forbindelse med "søg dokumenter". Flowet minder om det tilsvarende flow i Dokumentdelingsservicen, men er simplere, da der ikke tjekkes for spærringer mod enkeltpersoner ligesom kaldet til Behandlingsrelationservice udeladesDet er kun når sundhedsfaglige søger dokumenter der laves kontrol for behandlingsrelation. Minlog registreringer laves når sundhedsfaglige og borgere søger dokumenter.

Gliffy Diagram

size	600
displayName	SFSK Søg Dokument
name	SFSK Søg Dokument
pagePin	56

Flow i forbindelse med "Hent dokumenter" i SFSK

...

Sekvensdiagrammerne nedenfor beskriver flowet i forbindelse med "hent dokumenter". Det er kun når sundhedsfaglige henter dokumenter der laves kontrol for behandlingsrelation.

Gliffy Diagram

size	600
displayName	SFSK Hent Dokument
name	SFSK Hent Dokument
pagePin	3

Afklaringer

...

Content

Space Tools

Versions Compared

Old Version 56

New Version Current

Key

Definitioner og referencer

Overblik over SFSK

Relevante tredjepartsbiblioteker

Sikkerhedshåndtering i SFSK

BrugertyperBrugertyper

Bestemmelse og mapning til actor

Bestemmelse og mapning til actor

Transformation af brugertyper

Transformation af brugertyper

2 Kald til Behandlingsrelationsservice (BRS)

2 Kald til Behandlingsrelationsservice (BRS)

Kald til Stamdata autorisation enkeltopslagsservice (SAES)

Flow i forbindelse med "Hent dokumenter" i SFSK

Afklaringer