Kobling og dataflyt

Sist oppdatert: 27.11.2024

Når du søker om opplysninger fra flere datakilder, trengs det en plan for hvordan dataflyten skal gå. Det er prosjektets ansvar å lage en slik plan. En slik plan skal inneholde oversikt over hvilke(n) datakilde utvalget skal defineres hos, til hvilke datakilder koblingsnøkkel skal sendes for uttrekk av opplysninger. Grunnen til dette er å lette arbeidet med datatilretteleggingen og datatilgjengeliggjøringen som skjer hos den enkelte dataansvarlige/registerforvalter.

Sammenstilling

Med sammenstilling av opplysninger menes det, i denne sammenheng, å sette sammen opplysninger fra ulike datakilder basert på en personunik id, ofte fødselsnummeret. Siden det av personvernhensyn, ikke er forenelig å distribuere helseopplysninger sammen med personers fødselsnummer, etableres det alltid en erstatning for fødselsnummer, for eksempel pseudonym.

Koblingsnøkkel

En koblingsnøkkel er en datafil som inneholder fødselsnummer og et pseudonym, personunikt id, som datakildene kan distribuere seg imellom for å hente ut opplysninger om de aktuelle personene, samt legge på det samme personunike id’en på alle datasett som blir tilgjengeliggjort for prosjektet. Dette gjør det mulig å følge en person gjennom ulike datasett uten å bruke fødselsnummeret direkte. Dette er en forutsetning for å kunne sammenstille personopplysninger fra ulike datakilder.

Ulike koblingsmetoder

Når flere aktører er involvert i å levere datafiler til samme prosjekt er det flere måter å gjøre dette på. Det er prosjektleder som har ansvaret for å lage en gjennomførbar dataflyt. De mest vanlige måtene dette gjøres på i dag er ved distribuert kobling, sentralisert kobling og med en egen dedikert nøkkelforvalter.

 

Distribuert kobling

Distribuert kobling innebærer at koblingsnøkkel med studieutvalget/personer som skal inngå i datamaterialet, etableres/lages hos en aktør og formidles til de andre involverte aktørene. Koblingsnøkkelen kan komme fra prosjektet selv, noe som er vanlig i samtykkebaserte studier, eller den kan bli laget hos en av de involverte aktørene. Dette er ofte aktuelt i studier som ikke er samtykkebasert.  Et prosjekt som studerer kreftpasienter vil ha behov for at Kreftregisteret finner frem til studiepopulasjonen, basert på kriterier fra prosjektet.

I en slik koblingsprosess må prosjektet ha laget en oversikt over hvor dataflyten starter, hvordan koblingsnøkkel definerer person som skal inngå, til hvilke aktører koblingsnøkkel oversendes, hvilke opplysninger som skal hentes fra de enkelte aktørene, til hvor de endelige analysefilene blir tilgjengeliggjort.

I et enkelt prosjekt kan dette se slik ut:

  1. Utvalget spesifiseres i Kreftregisteret og skal bestå av personer eldre enn xx år registrert i Kreftregisteret i perioden 2000-2020 med C20
  2. Koblingsnøkkel med utvalget tilgjengeliggjøres DÅR og NPR
  3. Kreftregisteret, DÅR og NPR henter ut omsøkte opplysninger hos sine registre
  4. Datafiler fra Kreftregisteret, NPR og DÅR, som inneholder løpenummer og helseopplysninger tilgjengeliggjøres prosjektet

distrubert-kobling_text.svg

Sentralisert kobling

I en sentralisert kobling gjøres datatilrettelegging hos alle involverte datakilder som så sender både data og fødselsnummerliste til en aktør. Denne aktøren lager en koblingsnøkkel med fødselsnumre og pseudonym for fødselsnummer som blir lagt på alle datafilene før disse tilgjengeliggjøres prosjektet.

Sentralisert kobling skiller seg fra distribuert kobling ved at det lages en endelig koblingsnøkkel etter at de omsøkte datakildene har gjort sine datatilrettelegginger.

Sentralisert kobling er ofte aktuelt når studiepopulasjonen etableres basert på flere datakilder. Eksempel på dette kan være et prosjekt som skal undersøke alle personer som er registrert med luftveisinfeksjon i NPR eller KPR, eller behandlet med spesielle legemidler for infeksjon. I slike tilfeller vil utvalget kunne bestå av personer kun registrert i en av de aktuelle datakildene. 

I et prosjekt kan dette se slik ut:

  1. KPR lager fnr liste over personer registrert med influensa i primærhelsetjenesten (liste 1) og datafil med opplysninger som skal til søker
  2. NPR lager fnr liste over personer registrert med influensa i spes helsetjenesten (liste 2) og datafil med opplysninger som skal til søker
  3. LMR lager fnr liste over personer registrert med uttak av Tamiflu fra apotek (liste 3) og datafil med opplysninger som skal til søker
  4. NPR og LMR sender sine lister med fnr til KPR
  5. KPR lager en prosjektspesifikk løpenummerlister som inneholder både KPR personer, NPR personer og LMR personer, samt og datafil med opplysninger som skal til søker
  6. KPR legger på samme løpenummerserie på datafil fra NPR og LMR.
  7. KPR sender de tre datafilene med samme løpenummerserie til prosjektet/forsker

Egen nøkkelforvalter

I noen prosjekter er det hensiktsmessig å ha en egen nøkkelforvalter. Med nøkkelforvalter menes her en aktør som ikke nødvendigvis bidrar med annet et å lage og distribuere koblingsnøkkel til de andre involverte aktørene. Det kan for eksempel være Folkeregisteret, Skattemyndighetene eller andre.

Egen nøkkelforvalter kan være aktuelt når det er kontrollgrupper involvert, som ikke nødvendig er registrert i et av de omsøkte datakildene. Det kan også være aktuelt når det av ulike grunner er satt som vilkår at det skal være en ekstern nøkkelforvalter.

En koblingsprosess med egen nøkkelforvalter innebærer at fødselsnumre distribueres svært begrenset. Det innebærer også at det ingen enkeltaktører sitter med oversikt over alle involverte aktører og helseopplysninger. Det er tilfellet i en sentralisert koblingsprosess.

I et prosjekt kan dette se slik ut:

  • Koblingsnøkkel for hele Norges befolkning lages hos Skatteetaten
  • Koblingsnøkkel tilgjengeliggjøres til NPR, KPR og LMR
  • NPR, KPR og LMR henter ut aktuelle helseopplysninger og tilrettelegger dette i respektive datafiler
  • NPR, KPR og LMR erstatter fnr med fnr pseudonym fra den oversendte koblingsnøkkelen
  • NPR, KPR og LMR tilgjengeliggjør hver sine datafiler til prosjektet/forskeren