For at man som service kan indgå i sløringssammenhæng, skal servicen have et interface, der overholder OIOIDWS (OIO identitetsbaseret web service, der leverer data til borgervendte visningsløsninger). Hvis din service skal bruges i borgervendte løsninger, og ikke allerede har en snitflade, der overholder denne standard, skal I etablere en sådan.

Flowet set fra en datakilde, der skal kunne pseudonymisere oplysninger, er relativt simpelt:

Figur 5: Flow services, der skal kunne pseudonymisere oplysninger.

1. Dataservicen modtager OIOIDWS billetten, afkoder den, og løber igennem listen af data, som skal afleveres til borgervisningssystemet for at kontrollere, om der skulle være medarbejdere med tilknytning til de CVR-numre, der skal sløres for. Hvis der er sådan nogle, skal der beregnes et pseudonym og navnet skal udskiftes med pseudonymet. Til at skabe sikre og tværgående ensrettede pseudonymer, skal dataservicen bruge et ”salt”. Det er også indlejret i billetten.
2. Med sløringsinformationerne fra billetten, saltet og listen over afdelinger, er det nu muligt at foretage sløring/pseudonymisering.
3. Det i fornødent omfang pseudonymiserede data returneres til borgerinterfacesystemet.

@startuml

skinparam sequence {
LifeLineBackgroundColor #FF4E26
ParticipantBackgroundColor #72BEDB
}

participant Borgervendtapp 
participant STS
participant IDSAS
participant Datakilde

Activate Borgervendtapp
Borgervendtapp-> STS: BST2IDWS
  Activate STS
  group #EAEAEA Skab Identitytoken
		
	'Her henter STS'en borgerspecifikke sløringer
    STS -> IDSAS: getBlurredOrganisations()
	Activate IDSAS
    return [orgId*]

	'Her henter STS'en alle afdelingssløringer
    STS -> IDSAS: listAllBlurredOrgs()
    Activate IDSAS
    return [org-id*]
  end
return IdentityToken

Borgervendtapp -> Datakilde: HentData(IdentityToken)


Activate Datakilde
Datakilde -> Datakilde: Pseudonymisér data
return Pseudonymiseret data
Deactivate Borgervendtapp

@enduml

Typiske skridt hvis du skal tilrette en datakilde til at kunne pseudonymisere

A – Aftaler og whitelisting

Der er en række ting, der skal være på plads inden du kan få adgang til alt det, du skal bruge til opgaven.

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 skal kalde IDSAS servicen på NSP.

Det er en god idé at få aftaleprocesserne igangsat som noget af det første, så I ikke senere bliver bremset af manglende aftaler.

• Sundhedsdatanet aftale og adgang: https://services.nsi.dk/OmNSIservices/supportingServices/omSDN
• NSP serviceaftale: https://www.nspop.dk/display/Web3/Mine+aftaler. Kræver login – hvis du ikke har et login, så er der vejledning til at kontakte support på siden.

Whitelist: Opret supporthenvendelse om ’whitelistning’ til IDSAS servicen på NSP. Der skal whitelistes til både Test og Produktion.
Find IDSAS i listen

Figur 6: Screenshot fra whitelist-siden.

Beskriv at det drejer sig om whitelistning ift. IDSAS (kun getCurrentSalt() metoden). Du skal i processen være klar til at give oplysninger om det kaldende system mv.

B - Afkodning af OIOIDWS billet (hvis I ikke allerede gør det)

• Se en indflyvning til anvendelse af OIOIDWS her: Anvendelsen af OIOIDWS i nationale tjenester på sundhedsområdet
• Mere om Blurring Instructions Profile og Subject Relation profile findes her: Identitetssløring

For nogle er der måske hjælp at hente ved at bruge SEAL.Java eller SEAL.NET til dette, hvis I arbejder i enten Java eller .NET. Se mere her:

• Java: https://www.nspop.dk/display/public/web/SEAL.JAVA+-+Guide+til+udviklere
• .NET: https://www.nspop.dk/display/public/web/SEAL.NET+-+Guide+til+anvendere

C - Beregning af pseudonymer

Hvis der er registreret sløringer for borgeren, bør du nu have alt det, der er nødvendigt for at pseudonymisere:

• CVR-numre på de organisationer, der vil have deres medarbejdere pseudonymiseret overfor denne borger
• SOR og SHAK koder for de afdelinger, der vil have alle registreringer fra disse afdelinger pseudonymiseret (uanset hvilken borger, der er logget ind)
• Borgerens ID (CPR-nummer)
  Bemærk: hvis brugeren er en befuldmægtiget eller forældre, der ser data for en anden person, skal man bruge ID'et for den, man ser data på (fuldmagtsgiverens eller barnets).
• For- og efternavne på de sundhedsfaglige, der skal sløres
• "Salt” som du skal bruge til at beregne pseudonymer. (Se eksempel mv. "Appendiks 1 – Test af identitestsløring" samt "Appendiks 3 – Test af afdelingssløring")

Pseudonymer skal være UUID type 5. Hvis du koder i Java, kan du finde et godt eksempel her: https://stackoverflow.com/questions/40230276/how-to-make-a-type-5-uuid-in-java

Konventionen for beregning er følgende:

1. UUID type 5 namespacet skal være ns:OID ("6ba7b812-9dad-11d1-80b4-00c04fd430c8”)
2. Input til UUID generatoren skal være ”FORNAVN(E)+EFTERNAVN(E)+BORGER_ID+SALT” (BORGER_ID er indtil videre CPR)
3. Alle navne skal være Uppercase og alle mellemrum i fornavn(e) og efternavn(e) skal erstattes med ’+’
4. Saltet modtages BASE64 encoded fra getCurrentSalt(). Det skal appendes til navnene som tekst inden der konverteres til bytes i selve UUID genereringen (husk ’+’ mellem sidste efternavn og salt).
5. Alle konverteringer fra strenge til bytes skal være baseret på UTF8
6. ’Plusserne’ (angivet i inputtet i punkt 2) skal også inkluderes i inputtet

Se også ”Appendiks 2 – Eksempler på korrekte pseudonymer”

I kan også teste jeres kode op mod pseudonymer på dette site: https://www.javainuse.com/uidv5, husk at anvende OID namespacet.

Ændringslog