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.
  2. Til at skabe sikre og tværgående ensrettede pseudonymer, skal dataservicen bruge et ”salt”. Det skifter periodisk, og skal derfor hentes periodisk, f.eks. en gang i timen, via getCurrentSalt() servicen på IDSAS på NSP.
  3. Pseudonymer beregnes lokalt gennem en national standardiseret algoritme. Det gør det super-effektivt at beregne pseudonymer.
  4. Det i fornødent omfang pseudonymiserede data returneres til borgerinterfacesystemet.

Typiske skridt hvis du skal tilrette et system med pseudonymiserende datakilde

Step 1 – 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.

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.

Step 2: Systemcertifikat (FOCES3)

Du skal bruge et (eller to) systemcertifikat ift.

Trin 3: Afkodning af OIOIDWS billet (hvis I ikke allerede gør det)

Det kan klart anbefales at anvende SEAL.Java eller SEAL.NET til dette, hvis I arbejder i enten Java eller .NET.

Se mere her:

Trin 4: Kald af DGWS snitflade getCurrentSalt() hos IDSAS



https://www.nspop.dk/display/NDPV/IDSAS+-+Guide+til+anvendere%3A+Opslag

Trin 5: 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:

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

1.0

2023-09-21

Side oprettetSDS