Flowet i håndhævelse er noget anderledes, idet informationerne, som skal bruges til at afgøre om og for hvem, der skal sløres, er bundet til OIOIDWS billetten. Det ser komplekst ud, men er egentligt ikke så galt, når det kommer til stykket:

Figur 4: Flowet ind til de datakilder, der anvendes af systemer med borgervendte løsninger, anvender OIOIDWS.

  1. Når borgeren logger på, sker det typisk gennem NemLogin og SEB. Her udstedes der et ”autentifikationsbevis” (SAML token) som beviser overfor systemet, at borgeren er logget på med passende stærke loginmidler mv. Inde i dette autentifikationsbevis ligger der et såkaldt ”bootstrap”- token, som systemet kan bruge til at rekvirere andre – mere målrettede – billetter med.
  2. Og det er det, der sker i skridt 2. Her ”veksler” systemet bootstraptokenet[1] til en OIOIDWS billet, som kan bruges til at få adgang til en bestemt dataservice (på vegne af borgeren). Det er STS’en på NSP, der udsteder disse billetter. Hvis der er registreret sløringer for den pågældende borger, vil dette blive indlejret i billetten (rød prik). I praksis er det en liste over CVR-numre hvis medarbejdere skal optræde under pseudonym overfor den pågældende borger.
  3. OIOIDWS billetten medsendes i kaldet til den service der skal levere data til borgervisningen.
  4. Det pseudonymiserede resultatet returneres til borgervisningssystemet, der blot (som i dag) viser oplysningerne på den borgervendte brugergrænseflade.


[1] Bemærk: STS’en kan også udstede OIOIDWS tokens på baggrund af JSON Web Tokens (JWT), så det nævnte flow er et eksempel.

Typiske skridt, hvis du skal tilrette et system med borgervendt brugergrænseflade

i -  Kontrollér at systemet lever op til krav om stærk login

For at kunne anvende den nationale pseudonymiseringsløsning, er det en grundlæggende forudsætning at løsningen skal kunne veksle et autentifikationstoken til et OIOIDWS token hos NSP’ens STS. Pt. understøtter STS’en veksling fra bootstraptokens eller fra JSON web tokens til OIOIDWS tokens. Du skal derfor kontrollere, at løsningen tilbyder login via SEB eller via en anden mekanisme, der er signeret af en troværdig JWT udsteder (pt. en OpenID Connect Provider).

ii - Aftalesystem ift. NSP og whitelisting ift. STS (hvis man ikke har det i forvejen)

Der skal indgås flere ’aftaler’ med SDS for at komme igennem det samlede flow:

  1. En sundhedsdatanetaftale og tilsvarende tilslutning
  2. En generel aftale om anvendelse af NSP (NSP serviceaftale)
  3. En ’whitelistning’ af det (eller de) system(er), som anvender STS’ens vekslingsløsning
  4. Hvis I bruger JWT, så skal jeres OpenID Connect (OIDC) JWT udsteder være ”trusted” af STS’en.

Det er en god idé at få aftaleprocesserne igangsat som noget af det første, så I ikke senere bliver bremset af manglende aftaler. Nedenfor finder du links til de forskellige typer af aftaler, der skal indgås.

Whitelist: https://www.nspop.dk/category/sup. Der skal whitelistes til både Test og Produktion.

iii - Rekvirering af OIOIDWS billet

Bootstrap right arrow OIOIDWS: Vejledning: https://www.nspop.dk/display/public/web/STS+-+Guide+til+anvendere%3A+Borgeromvekslinger samt ( https://www.nspop.dk/display/public/web/%28slettes%29+STS+-+Borger-billetomveksling )

JWT right arrow OIOIDWS: Vejledning her: https://www.nspop.dk/display/public/web/STS+-+JWT-billetomveksling

iv - Kald af OIOIWDS snitflade hos datakilde

Her henvises til dokumentation hos den ansvarlige for servicen.


Ændringslog

1.0

2023-09-21

Side oprettetSDS