samtykkehåndtering på tværs af sektorer

RM IT Arkitektur og design, LRS, Okt. 2016, rev. 0.4 Side 1

Samtykkehåndtering på tværs af sektorer


Indhold Figurliste ................................................................................................................... 2

Indledning ................................................................................................................. 3

Sikkerhedsmodel ........................................................................................................ 4

Opgavedeling mellem forespørger og den der adspørges. ................................................ 6

Forespørger: ........................................................................................................... 6

Den adspurgte: ....................................................................................................... 6

Sikkerhedsløsning ....................................................................................................... 6

Test opstilling ............................................................................................................. 7

Test dokument forklaring ............................................................................................. 8

Indhold af forespørgsel (Token) som A sender for at se oplysninger om B ....................... 9

Test senarie - simpel udgave........................................................................................ 9

Undtagelser og forudsætninger .................................................................................. 9

Forespørger: ........................................................................................................... 9

Forespørges på: ....................................................................................................... 9

Borger forespørger på egne data iht. aktindsigt. .......................................................... 9

Læge A forespørger uden specifik samtykke .............................................................. 10

Læge A forespørger med specifik samtykke ............................................................... 10

Læge A forespørger med værdispring ....................................................................... 10

Læge B forespørger uden specifik samtykke .............................................................. 10

Læge B forespørger med specifik samtykke ............................................................... 10

Læge B forespørger med værdispring ....................................................................... 11

Læge A forespørger hvor der givet et generelt samtykke til A’s organisation .................. 11

Læge B forespørger hvor der givet et generelt samtykke til B’s organisation.................. 11

Forventet resultat ..................................................................................................... 12

Figurliste Figur 1 Sikkerhed baseret på person/persona model. ......................................................... 5 Figur 2 Test opstilling ..................................................................................................... 7 Figur 3 Symbol forklaring ............................................................................................... 8 Figur 4 Samling af dokumenter ....................................................................................... 8 Figur 5 Simplificeret udgave af token der forespørges med ved test ..................................... 9 Figur 6 Test senarier og forventet resultat ...................................................................... 12


Indledning Indeværende notat er en beskrivelse af en teknisk model således gældende lovgivning kan tilgodeses ved udveksling af persondata på tværs af sektorer. Modellen er at sammenligne sikkerhedsmodellen for Sårjournalen, Sundhedsjournalen mv. Modellen er dog udvidet i forhold til disse, idet der håndteres indhentelse/videregivelse på dokument niveau (eller samling af dokumenter jf. en kontakt).

Selve sikkerhedsmodellen tager afsæt i person/persona-modellen hvor deling/udveksling af persondata er et forhold mellem to personer, eksempelvis at en navngiven læge videregiver specifik data (i behandlingsøjemed) til en anden navngiven læge. Eller en borger ønsker aktindsigt om egen behandling (egne data). Eller en Læge elektronisk indhenter oplysninger om borgeren.

Indeværende model bygger på "opt out" princippet, dvs. der kan ikke tilgås oplysninger om nogen borger uden at der er redegjort/oplyst om hjemmel herfor (det modsatte af en 'opt in'). Modellen er ikke dækkende for alt, idet der kan forekomme tilfælde hvor f.eks. en borger aktivt har blokeret for adgang til specifik information, som er nødvendig for en myndigheds videre sagsbehandling. Modellen er alene for udveksling af informationer i patientbehandlingsøjemed.

Ved enhver forespørgsel skal der oplyses med hvilken hjemmel forespørger elektronisk må indhente de ønskede oplysninger.

Adgang til information om en borger kan kun pågå jf. følgende:

1. Borgeren har tilkendegivet et samtykke1. 2. Forespørger kan redegøre for, at der er hjemmel og hvilken (oplysninger som logges)

for at måtte indhente oplysningerne (f.eks. delegation eller afløser) 3. At der søges oplysninger som er videregivet2, af den der har information i sin varetægt,

til den der forespørger. 4. Det oplyses, at borgeren ikke kan tage vare på egne interesser (værdispring & besked

til e-boks)

Ved alle forespørgsler (undtaget borgeren selv) skal der gives oplysning om aktuelle behandlerrelation samt kilde eller begrundelse for et evt. samtykke.

Modellen kan håndtere "samtykke" tilkendegivelser på flere niveauer. Eksempelvis et mundligt 'samtykke' afgivet i forbindelse med en kontakt med en sundhedsperson (samtykkeoplysningerne logges jf. forespørgsel) eller for samtykke henvises til en tilkendegivelse noteret i patientjournalen.

Samtykke kan også håndteres elektronisk som en eksplicit tilkendegivelse3 af positivt samtykke afgivet af en borger således 'ansatte (der må indhente oplysninger)' tilhørende en bestemt organisation (Region, hospital, afdeling) eller en navngiven person (f.eks. læge) elektronisk må indhente (alle) relevante oplysninger i forbindelse med en konkret behandling.

1 Et samtykke skal være frivilligt, konkret og informeret, og kan i forbindelse med behandling gives enten mundtligt eller skriftligt, både ved videregivelse og elektronisk indhentning. 2 Til brug for aktuel behandling af patienten er det muligt for sundhedspersoner at videregive oplysninger til andre sundhedspersoner. Dette skal som udgangspunkt ske med patientens samtykke. 3 En tilkendegivelse er et dokument/formular som eksplicit er godkendt af borgeren. På dokumentniveau håndteres dette som anmærkninger på/til de enkelte dokumenter. Dokument/formularen gøres som udgangspunkt kun tilgængelig for den/de det vedrører, fortrolighed om tilkendegivelsen kan fastholdes.


Borgerne kan på dokument/kontaktniveau (samling af dokumenter) eksplicit afgive negativt samtykke mod navngivne personer (dermed principielt mod alt og alle), kun et værdispring4 kan tilsidesætte dette.

Borgerne og sundhedspersoner kan på dokument/kontaktniveau (samling af dokumenter) eksplicit afgive positivt samtykke mod navngivne personer *). Et negativt samtykke, på samme dokument/kontaktniveau mod samme navngivne person tilsidesætter/ophæver et positivt samtykke5.

*) Sundhedspersoners mulighed for videregivelse evt. uden patient samtykke, begrundelse og/eller hjemmel angives ved registrering af "videregivelse".

I modellen er valgt (som eneste mulighed) for elektronisk afgivelse af Negativt samtykke, at dette kun kan angives mod en navngiven person (f.eks. læge) og angives på dokumentniveau eller samling af dokumenter (afgrænset forløb/kontakt). Der er ikke åbnet for elektronisk afgivelse af negativt samtykke mod en 'hel' organisation (f.eks. en region). Modellen kan håndtere organisations adskillelse på regions, hospitals, afdelingsniveau niveau evt. afdelingsniveau på forskellige matrikler.

I nedenstående skal et 'specifikt samtykke' forstås således, at samtykket er afgivet mundtligt i den konkrete situation og målrettet (begrænset til) en 'søgning' som en navngiven læge må foretage (elektronisk indhentelse af oplysninger).

I nedenstående skal et 'generelt samtykke' forstås således, at borgeren eksplicit har godkendt en elektronisk 'samtykke-tilkendegivelse' vedr. at en navngiven organisation (region, sygehus, sygehusafdeling, afsnit, klinik e.l.) elektronisk må indhente relevante oplysninger om borgeren. F. eks. en borger fra Region Hovedstaden har (elektronisk) givet Partikelterapien DCPT i Region Midtjylland samtykke til at måtte indhente og videregive relevant information fra/til Herlev Hospital vedr. en konkret behandling.

Sikkerhedsmodel Person A (i Figur 1) identificeres entydigt (personen), enten ved hjælp af medarbejder certifikat, NemID eller tilsvarende, ligeledes fastlægges persona, dvs. med hvilken rolle person A ønsker at se oplysninger om person B, f.eks. privatpraktiserende læge, hospitalslæge, pårørende etc.

Der kan være flere kilder/registre med oplysningerne som kan/skal hentes. Oplysningerne samles i et certifikat udstedt af en myndighed der haves tillid til. Eksempelvis for en hospitalslæge som er logget på et EPJ-system kan oplysningerne fra EPJ-systemet anvendes til entydig identifikation af person og persona, f.eks. ”autorisations ID” og persona ”læge”.

Anvendelsen af sådanne oplysninger baseres på tillid mellem de enkelte systemer og den myndighed der udsteder certifikatet.

4 Kan en patient ikke selv varetage sine interesser, indtræder den eller de personer, som efter lovgivningen er bemyndiget hertil, i patientens rettigheder efter loven i det omfang, dette er nødvendigt for at varetage patientens interesser i den pågældende situation. 5 Patienten kan på ethvert tidspunkt af det aktuelle behandlingsforløb og i øvrigt frabede sig, at oplysningerne videregives.


Figur 1 Sikkerhed baseret på person/persona model.

Tilsvarende skal der fastlægges ”person til person sammenhæng”, oplysningerne kan også her tilvejebringes på flere måder. Hvor det er mest hensigtsmæssigt, eller muligt, beriges 'Token' med disse oplysninger. Eksempel jf. ovenstående kunne en oplysning om ”relation / relevans” være givet ved at person B er indlagt i afdelingen hvor person A arbejder og person A foretager opfølgning på behandling.

Samtykke kan eksempelvis fremkomme ved at person B under dialogen med person A giver et mundligt samtykke vedr. at person A må se oplysninger om person B (dette registreres og logges naturligt). Under visse omstændigheder kan person A, med en rolle som læge, uden noget samtykke eller andet tilgå data om person B, dette logges og efterfølgende gives der besked til person B.

Oplysninger om relation/relevans og samtykke skal/kan evt. hentes fra den nationale serviceplatform (NSP). Oplysninger herfra må antages, at være af mere generel karakter i modsætning

til de lokale oplysninger som kan være dokumentrelateret. Eksempelvis kan et samtykke registreret på den nationale NSP6 være en samtykketilkendegivelse mod et hospital, eller afdeling , vedr. at måtte se information om personen, her underforstået kun relevant information ved positivt samtykke.

Sikkerhedssystemet der er lagt omkring data kan ud fra oplysningerne i certifikatet evt. suppleret med yderligere oplysninger (f.eks. fra NSP, lokale registreringer) afgøre hvilke data person A må se. Dermed kan systemet aktivt hindre person A i at tilgå data, som person A ikke umiddelbart må tilgå.

For den anbefalede model er princippet: Stilles et og samme spørgsmål, om en og samme borger (B) af en og samme person (A) skal der gives et og samme svar, dette upåagtet

6 Opmærksomheden henledes på, at et fælles register for samtykke-oplysninger skal tillige indeholde oplysninger om hvilke personer/organisationer der må tilgå 'samtykke-registeret'. Indeværende model kan også anvende dokumentbaserede 'samtykke-tilkendegivelser' (elektroniske), at sammenligne med øvrig dokumentbaseret personhenførbar information, 'samtykke-tilkendegivelser' deles kun med de organisationer/personer der må tilgå disse, dvs. en organisation kan ikke se hvilke 'samtykke-tilkendegivelser' en borger har givet til en anden organisation.


hvilken 'Dataansvarlig' der adspørges og hvor data er placeret (DDS, KIH, lokalt hos regionerne, etc.), data udveksles via den bagvedliggende XCA7 og dette i respekt til gældende regler vedr. behandlerrelation, samtykke, videregivelse etc.

Enhver forespørgsel består af to hoveddele 1) Et konkret spørgsmål (afgrænsning jf. konkrete søge-parametre) mod en borger og 2) En 'Token' (sikkerheds certifikat) der indeholder oplysninger om person, persona og person der forespørges på, samt oplysninger om foreliggende behandlerrelation (og relevans), samt evt. foreliggende samtykke.

Det er udstederen af 'Token' der er ansvarlig for at oplysningerne i 'Token' er troværdige og kan dokumenteres ved revision (relevant logning). Det adspurgte (dataansvarlige) besvarer forespørgslen ud fra oplysningerne i spørgsmål (1) og Token (2) i tillid til at 'Token' er sandfærdig. Den dataansvarlige kan kontrollere oplysningerne i 'Token' hvis dette er nødvendigt.

Opgavedeling mellem forespørger og den der adspørges.

Forespørger: Den forespørgende (eller dennes systemer) har ansvaret/opgaven med at fremskaffe og dokumentere med hvilken hjemmel de mener at kunne tilgå de ønskede data. Dvs. tilvejebringe nødvendige oplysninger herunder få udstedt certifikater (Token).

Den adspurgte: Den adspurgte (eller dennes systemer) har ansvaret/opgaven med at stille data til rådighed overfor den forespørgende (baseret på modtagne spørgsmål og indhold af token), herunder sikre at der ikke stilles data til rådighed som forespørgeren ikke har hjemmel til at tilgå.

Ovenstående bygger på trust mellem 'adspørger' og den 'adspurgte' ved brud på, eller mistanke om 'brud på trust' kan der anvendes ekstra sikkerhedshåndtering og/eller udelukkelse.

Sikkerhedsløsning Løsningen er sikkerhedsmæssigt iht. 'Referencearkitektur for informationssikkerhed', National Sundheds-it (nu Sundhedsdatastyrelsen), sep. 2013. Endvidere er erfaringerne fra det fælles EU-projekt EpSoS indarbejdet i modellen, således modellen kan være basis for dataudveksling i patientbehandlingsøjemed internationalt. Modellen er yderligere beskrevet i 'Sikkerhed i XDS-infrastruktur', RM IT Arkitektur og design, maj 2016, rev. 0.9, hvor de nærmere tekniske specifikation er anført.

7 XDS infrastruktur er anbefalet jf. aftaledeling i Sundhedsjornalen (tvær regionalt projekt).


Test opstilling I nedenstående Figur 2 er vist 2 domæner, hvert domæne kan opfattes som en dataansvarlig, f.eks. Region Midtjylland (RM) for 'DOM 1' og Region Syddanmark (RS) for 'DOM 2'.

I indeværende test er der placeret data i begge domæner. Ved 'Viderestil' forstås at 'Søgning sendes videre til et andet domæne' dvs. 'spørgsmål (1) og Token (2) i uændret form sendes videre til 'DOM 2'. DOM 2 modtager de samme spørgsmål (1) og Token (2) som DOM 1 har modtaget.

For data i 'DOM 1' er der kun data fra en og samme dataansvarlige (f.eks. RM), undtaget borgerens private dokumenter. Det samme gælder for ' DOM 2' (f.eks. RS).

Systemerne kan opsættes til logisk at håndtere data således, at et og samme domæne kan holde data fra flere dataansvarlige. Sikkerhedsmæssigt er det at sammenligne med at krydse en domæne grænse, dog håndteret internt i domænet, dvs. som at krydse en grænsen mellem to dataansvarlige. Det organisatoriske tilhørsforhold for forespørgeren har betydning for forespørgerens elektroniske indhentelse af data. Det organisatoriske tilhørsforhold kan endvidere opdeles geografisk og organisatorisk (region, hospital og afdelings).

Systemerne kan eksempelvis ligeledes håndtere skjult og ikke skjult eksistens af oplysninger. Ved 'skjult' ses ikke eksistensen af oplysninger, Ved 'Ikke skjult' ses eksistensen. F.eks. en forespørgsel giver: Du har adgang til 8 ud 10 af ti mulige 'oplysninger' (dokumenter/kontakter).

Figur 2 Test opstilling


I nedenstående skal et 'specifikt samtykke' forstås således, at samtykket kan være afgivet mundtligt eller skriftligt i den konkrete situation og kan være målrettet (begrænset til) den 'søgning' en aktuelt læge foretager (elektronisk indhentelse af oplysninger).

Et 'generelt samtykke' skal forstås som en borgers samtykketilkendegivelse overfor en organisation (sygehus, sygehusafdeling, afsnit, klinik e.l.)

Test dokument forklaring

Givet specifik negativt samtykke (dokument samling) af borgeren selv mod ‘læge A’

Læge A kendes på sit autorisationsID

Intet specifikt samtykke er registreret

Givet specifik positivt samtykke (dokument samling) til ‘læge B’

Læge B kendes på sit autorisationsID

Kan være givet af en læge (videregivelse) eller af borgeren selv.

Ikke frigivet til borger

Må kun være kortvarigt, alvorlige indikatorer etc. skal overleveres til patienten af en

læge. Anmodning om aktindsigt skal normalt efterkommes inden for 7

arbejdsdage.

Privat dokument

Borgerens egne private oplysninger som borgeren selv kan dele med andre.

F.eks. adgang for hjemmehjælper til bolig, kontaktoplysninger til familie etc.

Generel positivt samtykke mod

Læge A og Læge B organisation

Figur 3 Symbol forklaring

Ovenstående kan forstås som et enkelt dokument, eller en samling af dokumenter

som er tilvejebragt som dokumentation for en afgrænset sundhedsfaglig kontakt

med borgeren. Et dokument er den mindste enhed for sikkerhedshåndtering, dvs.

forskellig sikkerhed i samme dokument (dokument afsnit) håndteres ikke.

Figur 4 Samling af dokumenter


Indhold af forespørgsel (Token) som A sender for at se oplysninger om B Forespørger R OID8 + ID Person der anvendes ved forespørgslen

Forespørges på R OID + cpr. Den person der forespørges på. Erstatnings. Cpr. kan anvendes.

Organisation R OID + Org. Organisation som forespørgeren tilhører, uden udfyldt 'samtykke' kan der kun søges indenfor denne organisation.

Behandlerrelation R Opfyldt ! OID+ tekst

Enten eksplicit oplyst af forespørgeren eller fra relevante registre.

Samtykke O (R)

Opfyldt! OID + tekst

Enten eksplicit oplyst af forespørgeren eller fra relevante registre. Kræves oplyst når der søges på tværs af organisationer. Oplysningerne logges (ATNA/MinLog)

Værdispring Nødadgang!

O (R)

Ja/Nej Kræves eksplicit oplyst af forespørgeren! Der sendes besked til personen (e-boks) på den der forespørges på.

Viderestil R2 Ja/Nej Søgning sendes videre til andre dataansvarlige (Default= Nej)

Øvrig afgrænsning O Søge opl. Øvrige søgeoplysninger Figur 5 Simplificeret udgave af token der forespørges med ved test

Test senarie - simpel udgave

Undtagelser og forudsætninger Indeværende model er baseret på at de fleste ikke komplicerede forhold kan håndteres automatisk (ca. 95%). Hvor der er specielle forhold mellem forespørger og den der forespørges på kan dette håndteres manuelt. Ved at den der har oplysningerne i sin varetægt afgør (markerer) hvilke data 'forespørger' må tilgå. (F.eks. barn/værge, 15 års reglen etc.)

Udsteder af certifikat (Token) er ansvarlig for, at sikre at gældende regler tilgodeses ved udstedelse af 'Token'.

Forespørger: Borger der forespørger: For identifikation af borger anvendes NemID eller tilsvarende. Evt. begrænsninger i aktindsigt håndteres ved at skærme data for borgeren (hemmeligt dokument). Borger der forespørger identificeres med cpr.nummer + OID (CPR-nummer codesystem root 2.16.840.1.113883.3.4208.100.2 Indenrigsministeriet).

Læger der forespørger: Læge identificeres med AutorisationsID + OID. I 'Token' er oplysninger om/til en behandlingsrelation og relevans for at lægen søger de pågældende oplysninger.

Forespørges på: Patienter identificeres med cpr.nummer + OID (CPR-nummer codesystem root 2.16.840.1.113883.3.4208.100.2 Indenrigsministeriet).

Borger forespørger på egne data iht. aktindsigt. Der forespørges data iht. aktindsigt. Evt. begrænsninger i aktindsigt håndteres ved at skærme data for borgeren (hemmeligt dokument).

8 Objekt beskrivelse, OID=2.16.840.1.113883.3.4208.100.2 angiver at ID='cpr.nummer'.


Anmodning om aktindsigt skal efterkommes inden for 7 arbejdsdage og hvis dette ikke kan lade sig gøre, skal patienten informeres om årsagen hertil og hvornår anmodningen forventes at blive imødekommet.

I efterfølgende test senarier forudsættes at krav om behandlerrelation er opfyldt.

Læge A forespørger uden specifik samtykke Læge A indhenter elektronisk oplysninger om borgeren på behandlingsstedet (og andre behandlingssteder v/søgning sendes videre).

Borgeren har ikke givet noget samtykke til at 'læge A' må indhente oplysninger elektronisk fra andre behandlingssteder. Der medsendes ikke samtykkeoplysninger i Token.

I testen er valgt Regions niveau (domæne). Kan datamæssigt administreres så snævert, som det administrativt er ønskeligt - sygehus, sygehusafdeling, afsnit, klinik e.l.

Læge A forespørger med specifik samtykke Læge A indhenter elektronisk oplysninger om borgeren på behandlingsstedet (og andre behandlingssteder v/søgning sendes videre).

Borgeren har givet 'specifik samtykke' (mundtligt) til at 'læge A' må indhente relevante oplysninger elektronisk fra andre behandlingssteder. Der medsendes samtykkeoplysninger i Token.

I testen er valgt Regions niveau (domæne). Kan datamæssigt administreres så snævert, som det administrativt er ønskeligt - sygehuse, sygehusafdelinger, etc. herunder være relateret til den konkrete søgning.

Læge A forespørger med værdispring Læge A indhenter elektronisk oplysninger om borgeren på behandlingsstedet (og andre behandlingssteder v/søgning sendes videre), dette ved angivelse af værdispring.

Borgeren er f.eks. bevidstløs og ikke kan besvare evt. spørgsmål, manglende information kan påføre patienten/borgeren en risiko.

Borgeren har ikke givet noget samtykke til at 'læge A' må indhente oplysninger elektronisk fra andre behandlingssteder. Der medsendes ikke samtykkeoplysninger i Token.

Der fremsendes oplysning om anvendelse af værdispring i Token.

Læge B forespørger uden specifik samtykke Læge B indhenter elektronisk oplysninger om borgeren på behandlingsstedet (og andre behandlingssteder v/søgning sendes videre).

En læge har videregivet specifik information til læge B om borgeren (kan være af borgeren selv har videregivet, jf. aktindsigt)

Borgeren har ikke givet noget samtykke til at 'læge B' må indhente relevante oplysninger elektronisk fra andre behandlingssteder. Der medsendes ikke samtykkeoplysninger i Token.

I testen er valgt Regions niveau (domæne) – læge B tilhører ingen af de viste domæner. Kan datamæssigt administreres så snævert, som det administrativt er ønskeligt - sygehus, sygehusafdeling, afsnit, klinik e.l.

Læge B forespørger med specifik samtykke Læge B indhenter elektronisk oplysninger om borgeren på behandlingsstedet (og andre behandlingssteder v/søgning sendes videre).


Borgeren har givet 'specifik samtykke' (mundtligt) til at 'læge B' må indhente relevante oplysninger elektronisk fra andre behandlingssteder. Der medsendes samtykkeoplysninger i Token.

I testen er valgt Regions niveau (domæne) – læge B tilhører ingen af de viste domæner. Kan datamæssigt administreres så snævert, som det administrativt er ønskeligt - sygehuse, sygehusafdelinger, etc. herunder være relateret til den konkrete søgning.

Læge B forespørger med værdispring Læge B indhenter elektronisk oplysninger om borgeren på behandlingsstedet (og andre behandlingssteder v/søgning sendes videre), dette ved angivelse af værdispring.

Borgeren er f.eks. bevidstløs og ikke kan besvare evt. spørgsmål, manglende information kan påføre patienten/borgeren en risiko.

Borgeren har ikke givet noget samtykke til at 'læge A' må indhente relevante oplysninger elektronisk fra andre behandlingssteder. Der medsendes ikke samtykkeoplysninger i Token.

Der fremsendes oplysning om anvendelse af værdispring i Token.

Læge A forespørger hvor der givet et generelt samtykke til A’s organisation Læge A indhenter elektronisk oplysninger om borgeren på behandlingsstedet (og andre behandlingssteder v/søgning sendes videre).

Borgeren har givet et 'generelt samtykke' til at læge A afdeling (organisation) om at måtte indhente relevante oplysninger elektronisk fra andre behandlingssteder. Der medsendes samtykkeoplysninger i Token.


Læge B forespørger hvor der givet et generelt samtykke til B’s organisation Læge B indhenter elektronisk relevante oplysninger om borgeren på behandlingsstedet (og andre behandlingssteder v/søgning sendes videre)

Borgeren har givet et 'generelt samtykke' til at læge B afdeling (organisation) om at måtte indhente oplysninger elektronisk fra andre behandlingssteder. Der medsendes samtykkeoplysninger i Token.



Forventet resultat

Figur 6 Test senarier og forventet resultat

samtykkehåndtering på tværs af sektorer

Health & Medicine