GDPR og sundhedsdata: behandl patientdata lovligt i Danmark

GDPR stiller særlige krav til sundhedsdata: ifølge GDPR artikel 9 er helbredsoplysninger en særlig kategori af personoplysninger, og behandlingen er forbudt, medmindre du har både et grundlag i artikel 6 og en undtagelse i artikel 9. Derudover skal du som regel lave en konsekvensanalyse (DPIA), beskytte data med sikkerhedsforanstaltninger, der svarer til risikoen og kunne anmelde et brud inden for 72 timer. Denne guide gennemgår kravene i den rækkefølge, de typisk dukker op, når du bygger en sundhedsapp, en patientportal eller et medicinsk system i Danmark.

Vi skriver ud fra det, vi ser i vores egne projekter. Vi er softwareudviklere, ikke advokater, så brug guiden til at stille de rigtige spørgsmål og få jeres databeskyttelsesrådgiver til at bekræfte svarene.

Hvad tæller som sundhedsdata efter GDPR?

Sundhedsdata er alle oplysninger om en persons fysiske eller mentale helbred, herunder sundhedsydelser, der afslører noget om helbredstilstanden (GDPR artikel 4, nr. 15). Det omfatter mere end journaler.

I praksis er disse data næsten altid sundhedsdata:

• Diagnoser, symptomer, medicin og behandlingsforløb
• Målinger fra medicinsk udstyr og sensorer, fx puls, iltoptag eller blodsukker
• Data fra wearables, når de bruges til at vurdere helbredet
• Bookinger hos en læge eller en psykolog, fordi de afslører, at personen er i behandling
• Kombinationer af data, der tilsammen siger noget om helbredet

Genetiske og biometriske data er også særlige kategorier og følger de samme stramme regler.

Hvilket behandlingsgrundlag skal du bruge til sundhedsdata?

Du skal bruge to ting: et behandlingsgrundlag i artikel 6 og en undtagelse fra forbuddet i artikel 9, stk. 2. Ifølge EU-Domstolens dom i sag C-667/21 skal en behandling efter en undtagelse i artikel 9 også opfylde mindst ét grundlag i artikel 6, så undtagelsen kan ikke stå alene. Legitime interesser er ikke en undtagelse i artikel 9.

Den hyppigste fejl, vi ser, er, at en sundhedsapp henviser til “sundhedsbehandling”, selv om ingen sundhedsperson med tavshedspligt er involveret. Så kan litra h ikke bruges, og grundlaget er typisk udtrykkeligt samtykke. Leverer du softwaren til en klinik, er klinikken som regel dataansvarlig, og du er databehandler.

Hvornår kræver sundhedsdata en konsekvensanalyse (DPIA)?

En DPIA er påkrævet, når behandlingen sandsynligvis medfører høj risiko for de registrerede (artikel 35). Behandling af særlige kategorier af data i stort omfang er nævnt direkte i artikel 35, stk. 3, og Datatilsynet har offentliggjort en liste over behandlinger, der altid kræver en konsekvensanalyse. Tjek den, før I beslutter, at I kan undlade en DPIA.

En brugbar DPIA indeholder:

1. En beskrivelse af dataflowet: hvilke data, fra hvem, til hvem og hvor længe
2. En vurdering af nødvendighed og proportionalitet
3. Risici for patienterne, vurderet ud fra sandsynlighed og konsekvens
4. De foranstaltninger, der reducerer risiciene
5. En konklusion om restrisikoen

Viser analysen en høj restrisiko, som I ikke kan reducere, skal I høre Datatilsynet, før behandlingen begynder (forudgående høring efter artikel 36). Datatilsynet godkender ikke en DPIA. Tilsynet kan rådgive og i sidste ende forbyde eller begrænse behandlingen.

Hvordan skal et samtykke til behandling af sundhedsdata se ud?

Et gyldigt samtykke er frivilligt, specifikt, informeret og utvetydigt (artikel 4, nr. 11), og artikel 7 kræver, at du kan bevise det, og at det er lige så let at trække tilbage som at give. For sundhedsdata skal samtykket desuden være udtrykkeligt (artikel 9, stk. 2, litra a).

I produktet betyder det:

• Et aktivt valg, fx et felt, der ikke er udfyldt på forhånd, med tekst, der nævner sundhedsdata
• Separate samtykker til behandling, forskning og markedsføring, aldrig samlet i ét
• Logning af samtykket med tidspunkt og den præcise tekst og version, brugeren så
• En tydelig mulighed for at trække samtykket tilbage, så behandlingen stopper med det samme
• Sletning, hvis samtykket var det eneste grundlag, og ingen anden pligt kræver opbevaring

Når en informationssamfundstjeneste baseret på samtykke henvender sig direkte til børn, er aldersgrænsen i Danmark 13 år (artikel 8 og databeskyttelsesloven). Under 13 år kræver det forældrenes samtykke, og du skal gøre en rimelig indsats for at kontrollere det.

Hvilke sikkerhedskrav gælder for patientdata?

GDPR artikel 32 kræver et sikkerhedsniveau, der passer til risikoen, men loven nævner ingen bestemte algoritmer, adgangskodelængder eller gendannelsestider. Dem skal du fastsætte i jeres risikovurdering og dokumentere.

Følgende er vores udgangspunkt for sundhedsdata, ikke lovkrav:

• Kryptering: TLS på al trafik og kryptering af databaser, filer og backups, med nøgler i en separat nøgleboks
• Adgang: Rollebaseret adgang efter princippet om færrest mulige rettigheder og MFA for sundhedspersonale
• Login: MitID til borgere og MitID Erhverv til medarbejdere, når løsningen skal bruge national identitet
• Logning: En log over opslag, ændringer og sletninger i patientdata, beskyttet mod manipulation og med en opbevaringsperiode, I har begrundet
• Drift: Backup, der er testet ved gendannelse, og mål for nedetid og datatab (RTO og RPO), som passer til den kliniske brug
• Test og udvikling: Pseudonymiserede eller syntetiske data i stedet for rigtige patientdata

I Wear & Care-platformen er adgangen afgrænset til det enkelte plejehjem, login går via MitID og NemLog-in gennem Keycloak, og hver hændelse logges. I backenden, vi byggede til et CE-mærket medicinsk udstyr, ligger hemmeligheder i Azure Key Vault, og tjenesterne bruger Managed Identity i stedet for adgangskoder i konfigurationen.

Hvor længe skal patientdata opbevares?

Så længe formålet kræver det, og ikke længere (artikel 5, stk. 1, litra e), medmindre en anden lov kræver længere opbevaring. For patientjournaler gælder et sådant krav: ifølge bekendtgørelse om autoriserede sundhedspersoners patientjournaler (BEK nr. 1361 af 24/11/2025, § 35) skal blandt andre læger og tandlæger opbevare journaler i mindst 10 år.

Retten til sletning (artikel 17) gælder ikke, så længe opbevaringen er en retlig forpligtelse. Byg derfor opbevaringsreglerne ind i datamodellen: For hver datatype skal der være en fastlagt opbevaringsperiode og en ansvarlig, og data skal automatisk slettes eller anonymiseres, når perioden udløber.

Må sundhedsdata ligge hos en amerikansk cloududbyder?

Ja, hvis overførslen har et gyldigt grundlag efter GDPR kapitel V. Inden for EU og EØS er der ingen ekstra krav. Til lande med en tilstrækkelighedsafgørelse kan data overføres uden yderligere garantier.

• USA: EU-US Data Privacy Framework er en tilstrækkelighedsafgørelse for certificerede amerikanske virksomheder. EU-Rettens dom af 3. september 2025 (Latombe, T-553/23) fastholdt den, men sagen er anket til EU-Domstolen (C-703/25 P) og er fortsat verserende. Hav en plan B.
• Andre tredjelande: Brug en garanti efter artikel 46, typisk EU’s standardkontraktbestemmelser eller bindende virksomhedsregler, og lav en overførselsvurdering (TIA) for hver overførsel, der hviler på dem.
• Fjernadgang tæller: Support fra et tredjeland med adgang til data er også en overførsel, selv om data ligger i en EU-region. Datatilsynets vejledning om cloud fra marts 2022 gennemgår, hvad I skal undersøge, herunder supportadgang fra tredjelande.

Hvad skal en databehandleraftale indeholde?

En databehandleraftale skal mindst dække punkterne nedenfor. Artikel 28 kræver en skriftlig aftale med hver databehandler:

• Formål, varighed, typer af data og kategorier af registrerede
• At databehandleren kun handler efter instruks
• Sikkerhedsforanstaltninger og hjælp ved brud
• Regler for underdatabehandlere, herunder godkendelse og overførsler
• Hjælp med de registreredes rettigheder og med DPIA
• Sletning eller tilbagelevering ved ophør
• Ret til audit og kontrol

Datatilsynet har en standardskabelon til databehandleraftaler, som er et godt udgangspunkt.

Hvad sker der ved et brud på persondatasikkerheden for sundhedsdata?

Et brud skal anmeldes til Datatilsynet inden for 72 timer efter, at I er blevet opmærksomme på det, medmindre det sandsynligvis ikke medfører en risiko (artikel 33). Indebærer bruddet en høj risiko, skal patienterne også underrettes uden unødig forsinkelse (artikel 34). Alle brud skal registreres internt, også dem, der ikke anmeldes.

Bødeloftet i artikel 83 er 20 mio. EUR eller 4 % af den globale årlige omsætning, alt efter hvad der er højest. I Danmark kan Datatilsynet ikke selv udstede bøder. Tilsynet indstiller til bøde og politianmelder, og domstolene fastsætter bøden efter databeskyttelseslovens § 41. Tilsynet kan dog selv udtale kritik, give påbud og forbyde en behandling.

Hvilke danske regler gælder ud over GDPR?

I Danmark skal sundhedssoftware også følge sundhedsloven, journalføringsbekendtgørelsen og databeskyttelsesloven, passe ind i den nationale infrastruktur og forberede sig på European Health Data Space fra 2027:

• Sundhedsloven: tavshedspligt for sundhedspersoner, patientens ret til aktindsigt i egen journal og regler for videregivelse af helbredsoplysninger
• Journalføringsbekendtgørelsen: krav til indhold, adgang og opbevaring af patientjournaler
• Databeskyttelsesloven: de danske supplerende regler, fx aldersgrænsen for børn og bødereglerne
• Nationale systemer: MedCom-standarder til beskeder, Fælles Medicinkort (FMK), MitID og MitID Erhverv, og regionernes systemer som Sundhedsplatformen i Region Hovedstaden og Region Sjælland
• European Health Data Space: forordning (EU) 2025/327 gælder generelt fra 26. marts 2027, med senere frister for elektroniske patientjournalsystemer og sekundær brug af sundhedsdata fra 2029

Sådan arbejder vi med GDPR i sundhedssoftware

Vi er typisk databehandler for en producent, en klinik eller en kommune. Vi bidrager med det tekniske grundlag til jeres DPIA og databehandleraftale: dataflow, hosting, underdatabehandlere, adgangsmodel og logning. Den juridiske vurdering ligger hos jer og jeres rådgiver. Hvis produktet også diagnosticerer eller overvåger patienter, så tjek først, om jeres software er medicinsk udstyr, for så kommer MDR oven i GDPR.

Kirsten Bondo Vraa har mere end ti års erfaring med farmaceutisk kvalitetssikring, og den tilgang bruger vi også i arbejdet med databeskyttelse: krav skrives ned, spores til test og dokumenteres løbende i stedet for til sidst. I får koden, dokumentationen og ejerskabet. Se, hvordan vi udvikler software til sundhed og life science.

Næste skridt

Er I i gang med en sundhedsapp eller et system med patientdata, kan vi gennemgå dataflowet sammen med jer og pege på, hvor GDPR stiller krav til arkitekturen. Det er en uforpligtende samtale. Kontakt os, eller læs videre om ISO 13485-certificering til medicinsk software.