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
GroupBackgroundColor #EAEAEA
}

participant Borgervendtapp #72BEDB
participant STS #72BEDB
participant IDSAS #72BEDB
participant Datakilde #72BEDB

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

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

Borgervendtapp -> Datakilde: HentData(IdentityToken)


Activate Datakilde #FF4E26
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 Instrictions Profile:
  • Word: OIOITP_Blurring_Instructions_Profile-v05.docx
  • XML Schema: OIOITP_Blurring_Instructions_Profile-v05.xsd

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)
• "salt” som du skal bruge til at beregne pseudonymer.

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)+SALT”
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’ (også de med rødt angivne i b) skal inkluderes i inputtet

Se korrekte også ”Appendiks B – 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