Introduktion

Formål

Formålet med dette dokument er at beskrive systemarkitekturen for SFSK.

Læsevejledning

Nærværende dokument er tiltænkt udviklere og IT-arkitekter med interesse i SFSK og dens opbygning.

Definitioner og referencer

NSP	National Service Platform
SFSK	Synkroniseringsservice til Fælles Stamkort
DGWS	Den Gode WebService

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 SFSK målrettet systembrugere og dækker det behov, der kan være for synkronisering af Fælles Stamkort i anvendernes fagsystemer.

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

Løsningens afhængigheder

SFSK i samspil med andre NSP Services

SFSK kan opfattes som en alternativ DDS, som har til formål at udstille data for anvenderne i forbindelse med Fælles Stamkort.

SFKS har til ansvar at:

sikkerhedsvalidere kald fra anvendersystemer
hente data i de bagvedliggende registre FSK Registry og FSK
foretage de nødvendige tjek i forhold til dataspærringer i MinSpærring i forbindelse med fremsøgning af stamkort (da SFSK kun skal anvendes af systembrugere giver filtrering i forhold til spærringer mod enkeltpersoner) ikke mening i SFSK
foretage auditlogning

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

Relevante tredjepartsbiblioteker

SFSK betjener sig af tredjeparts biblioteker fra IPF Open eHealth Integration Platform til implementations- og hjælpeklasser, der har med XDS IHE at gøre.

SFSK anvender følgende NSP libraries:

audit-api
security-api

Løsningens opbygning

Nedenstående diagram viser den interne opbygningen af SFSK.

I designet er der lagt vægt på at definere en fornuftig struktur, hvor begge SFSK services er opbygget på en ensartet måde.

Ovenstående diagram viser, hvorledes en SFSK ITI-18 og ITI-43 services er opbygget.

Selve service interface og implementation er placeret i pakkerne dk.nsp.sfsk.ws(.impl). Klasserne i disse pakker er ansvarlige for at modtage requests fra anvenderne på de for SFKS definerede snitflader. Ved at anvende klasser i pakken dk.nsp.sfsk.security valideres det, at den indkommende sikkerhedsbillet er valid og overholder de, for SFKS, definerede krav (se sikkerhedshåndtering i SFSK nedenfor).

Klasserne i pakkerne dk.nsp.sfsk.ws(.impl) indeholder funktionalitet der har til formål at:

Validere det indkommende request (se afsnit nedenfor vedr. validering)
Konvertere de indkommende requests til domæneklasser (som defineret i biblioteket openehealth) til brug for selve forretningsservices i SFSK.

Hvis sikkerhedsvalideringen eller konverteringen i SFSK ikke er succesfuld, så returnerer SFSK passende fejlbesked til den kaldende anvender.

Ellers sendes kaldet videre til SFSKs forretningslag.

Klasserne i pakkerne dk.nsp.sfsk.serivce(.impl) indeholder forretningsfunktionaliteten (se de to afsnit ved Forretningsregler nedenfor)

Integrationen til MinSpærring er implementeret i separat modul og anvendelsen er afkoblet fra forretningslaget ved hjælp af interfaces (se dk.nsp.sfsk.components).

Kaldende fra SFSK proxy'es videre til backends ved implementation i pakken dk.nsp.sfsk.backend(.impl).

Implementationsklasser til kommunikation med backends og MinSpærring kan alle trække på moduler til håndtering af SFSKs eget SOSI Idkort i pakken dk.nsp.sfks.security.

Sikkerhedshåndtering og forretningsregler i SFSK

I det følgende beskrives sikkerhedshåndteringen og forretningsreglerne i SFKS. Først beskrives sikkerhedsprotokollen.

Dernæst beskrives flowet for de to services til hhv fremsøgning og hentning af dokumenter.

Sikkerhedshåndtering i SFSK

Brugertyper

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

ID	Som en...	ønsker jeg at..	så jeg...
B1	Borger	fremsøge dokumentreferencer til egne dokumenter	kan se mine egne data
B2	Borger på vegne af	fremsøge dokumentreferencer til en anden borgers dokumenter	kan se data på denne person, som jeg har en relation til
SF1	Sundhedsfaglig med autorisation	fremsøge dokumentreferencer til en borgers data	kan se data på denne borger
IA-1	Ikke-autoriseret sundhedsfaglig	fremsøge dokumentreferencer til en borgers data	kan se dokumenter for denne borger af de typer, som min rolle giver mig adgang til
	Systembruger

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	HsuidHeader
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		Der skal være en valid HsuidHeader der beskriver en "Borger": ValidatedHsuidAttributes.isCitizen() true v.isRelationChildCustodyHolder() false v.getActingUserCivilRegistrationNumber() skal være udfyldt v.getCitizenCivilRegistrationNumber() skal være tom v = ValidatedHsuidAttributes.getValidatedCitizenHsuidAttributes()
	PrincipalUser		Må ikke være der
	Organisation	Identifier	Skal være der	actorId
		IdentifierFormat	Skal være der og skal være CVR	actorIdType

Borger på vegne af

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 skal der laves en minlog registrering og der kontrolleres ikke for behandlingsrelation.

Brugertypen: Borger på vegne af			Verifikation	Mapning til SfskActor	HsuidHeader
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		Der skal være en valid HsuidHeader der beskriver en "Borger på vegne af anden borger": ValidatedHsuidAttributes.isCitizen() true v.isRelationChildCustodyHolder() true v.getActingUserCivilRegistrationNumber() skal være udfyldt v.getCitizenCivilRegistrationNumber() skal være udfyldt v = ValidatedHsuidAttributes.getValidatedCitizenHsuidAttributes()
	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: Sundhedsfaglig med autorisation			Verifikation	Mapning til SfskActor	HsuidHeader
SecurityContext	Ticket	Audience	Verificeres ikke - må gerne være der		Skal være tom
		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
	PrincipalUser		Må ikke være der
	Organisation	Identifier	Skal være der
		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: Sundhedsfaglig med national rolle			Verifikation	Mapning til SfskActor	HsuidHeader
SecurityContext	Ticket	Audience	Verificeres ikke - må gerne være der		Skal være tom
		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.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
		IdentifierFormat	Skal være der og skal være CVR
	Client		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: Systembruger			Verifikation	Mapning til SfskActor	HsuidHeader
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		Der skal være en valid HsuidHeader der beskriver en "Systembruger": ValidatedHsuidAttributes.isCitizen() false v.getActingUserCivilRegistrationNumber() skal være tom v.getCitizenCivilRegistrationNumber() skal være tom v = ValidatedHsuidAttributes.getValidatedCitizenHsuidAttributes()
	PrincipalUser		Må ikke være der
	Organisation	Identifier	Skal være der	actorId
		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:

System >> Brugertypen Borger		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 (kun værge/forældremyndighed, ikke fuldmagt)	relation
		Actor cvr skal være whitelisted

System >> Brugertypen System		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

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

Kald af bagvedliggende services

Når SFSK kalder videre til de bagvedliggende services sker dette også vha DGWS. Dog trækker SFSK sit eget niveau 3 SOSI Idkort i den videre kommunikation med de bagvedliggende services. Identiteten af kaldet skifter således til at være et kald udført af SFSK, hvilket betyder at der kan udføres whitelisting i FSK til at tillade niveau 3 idkort fra det CVR nummer, som er identificeret i SFSKs Idkort.

SFSK har sin egen whitelistingtabel, hvor subject serialnumber for det kaldende certifikat skal være whitelistet. Se SFSK - Driftsvejledning for detaljer.

Der skal ikke være mulighed for værdispring i løsningen.

Flow i forbindelse med "Søg dokumenter" i SFSK

Når et kald er blevet sikkerhedsvalideret sker der en validerering af det indkommende request. Der tale om en simpel validering, der tjekker, om det indkommende ITI-18 request er lovligt i henhold til standarden IHE XDS.

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

Filtrering af data via MinSpærring

De fundne metadata filtreres ved at tjekke i MinSpærring verifikationssnitfladen, om der eksisterer spærringer mod mod et af de fundne dokumenter. Et dokument tjekkes ved at at kigge på alle organisationer (sor-koder), der har redigeret dokumentet, på alle relevante tidspunkter. Disse tidspunkter er ServiceStartTime og ServiceStopTime, hvis de er tilstede, samt CreationTime for dokumenter af typen Stable, og 'nu' (opslagstidspunktet) for dokumenter af typen OnDemand. Hvis der for en eneste af disse kombinationer af sor-kode og tidspunkt er angivet andet end positivt samtykke, så filtreres dokumentet fra.

Flow i forbindelse med "Hent dokumenter" i SFSK

Når et kald er blevet sikkerhedsvalideret sker der en validering af det indkommende request. Der er tale om en simpel validering, der tjekker, om det indkommende ITI-43 request er lovligt i henhold til standarden IHE XDS.

Sekvensdiagrammerne nedenfor beskriver flowet i forbindelse med "hent dokumenter".

Afklaringer

MinSpærring kræver et cpr på den sundhedsfaglige bruger i datatjek. Vi antager, at det er ok at medsende 'USPECIFICERET'.
Hvilket tidspunkt skal bruges til at tjekke for i MinSpærring? Det er et ondemand dokument uden service start eller service endtime. Beslutning: Hvis det er obligatorisk at sende dato med i spærringstjek, så bruges "Nu".