# GDPR and health data: processing patient data lawfully in Denmark > Health data is special category data under GDPR Article 9. You need a legal basis and an exception, a DPIA at high risk and 72-hour breach reporting. - URL: https://bon.do/en/articles/gdpr-medical-data - Markdown: https://bon.do/en/articles/gdpr-medical-data.md - Author: Morten Bondo Vraa - Published: 2025-08-30 - Updated: 2026-11-09 - Reading time: 8 minutes - Section: GDPR ## In 30 seconds - Health data needs both an Article 6 legal basis and an Article 9 exception. A health app outside a treatment relationship usually ends up on explicit consent. - A DPIA is not paperwork. It is how you find the risk before a patient does. - Security, retention and breach response are product requirements, built in from the first sprint. ## Key facts - **Health data:** Special category, GDPR Article 9 - **Maximum fine:** EUR 20m or 4% of global turnover - **Fines in Denmark:** Datatilsynet recommends, the courts decide - **DPIA:** Required when high risk is likely - **Breach notification:** Within 72 hours - **Patient records:** At least 10 years for doctors, dentists and others --- According to [Article 9 of the GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj), health data is special category data, and processing it is prohibited unless you have both an Article 6 legal basis and an Article 9 exception. On top of that you usually need a data protection impact assessment (DPIA), security that matches the risk, and a way to report a breach within 72 hours. This guide walks through the requirements in the order they tend to come up when you build a health app, a patient portal or a medical system in Denmark. This guide draws on our experience in our own projects. We are software engineers, not lawyers, so use this guide to ask the right questions and have your data protection adviser confirm the answers. ## What counts as health data under GDPR? Health data is any information about a person's physical or mental health, including information about healthcare services that reveals something about their health status (GDPR Article 4(15)). It covers far more than medical records. In practice, this is almost always health data: - Diagnoses, symptoms, medication and treatment history - Readings from medical devices and sensors, such as heart rate, VO₂max or blood glucose - Wearable data, when it is used to assess health - Appointments with a doctor or a psychologist, because they reveal that the person is in treatment - Combinations of data that together say something about health Genetic and biometric data are special categories too and are subject to the same strict rules. ## Which legal basis should you use for health data? You need two things: an Article 6 legal basis and an exception to the prohibition in Article 9(2). According to the Court of Justice in [case C-667/21](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62021CJ0667), processing based on an Article 9 exception must also satisfy at least one Article 6 legal basis, so the exception cannot stand on its own. Legitimate interests is not an Article 9 exception. | Article 9(2) exception | Typical use | Condition | | --- | --- | --- | | (a) explicit consent | Health apps people choose for themselves | Consent must be explicit and can be withdrawn | | (h) healthcare | Clinics, hospitals, record systems | Based on law or a contract with a health professional, and processed under professional secrecy (Article 9(3)) | | (i) public health | For example infectious disease surveillance | Needs a basis in EU or national law | | (j) research and statistics | Research databases | Needs a legal basis and appropriate safeguards | The most common mistake we see is a health app that relies on "healthcare" when no health professional bound by secrecy is involved. In that case, point (h) does not apply, and the basis is usually explicit consent. If you supply the software to a clinic, the clinic is usually the controller and you are the processor. ## When does health data require a DPIA? A DPIA is required when the processing is likely to result in a high risk to the people concerned (Article 35). Large-scale processing of special category data is explicitly listed in Article 35(3), and Datatilsynet has published a [list of processing activities that always require an impact assessment](https://www.datatilsynet.dk/Media/4/1/Datatilsynets%20liste%20over%20behandlinger%20der%20altid%20er%20underlagt%20kravet%20om%20en%20konsekvensanalyse%20%282%29.pdf). Check it before you decide you can skip one. A useful DPIA contains: 1. A description of the data flow: which data, from whom, to whom and for how long 2. An assessment of necessity and proportionality 3. The risks to patients, scored by likelihood and impact 4. The measures that reduce those risks 5. A conclusion on the residual risk If the assessment shows a high residual risk that you cannot reduce, you must consult Datatilsynet before processing starts (prior consultation under Article 36). Datatilsynet does not approve a DPIA. It can advise and, in the end, ban or restrict the processing. ## What does valid consent for health data look like? Valid consent is freely given, specific, informed and unambiguous (Article 4(11)), and Article 7 requires that you can prove it and that withdrawing it is as easy as giving it. For health data the consent must also be explicit (Article 9(2)(a)). In the product that means: - An active choice, such as an unticked box, with wording that names health data - Separate consent for treatment, research and marketing, never bundled - A consent record with the time, the exact wording and the version the user saw - A clearly visible option to withdraw consent and stop the processing immediately - Deletion when consent was the only basis and no other obligation requires retention When an information society service based on consent is offered directly to children, the age limit in Denmark is 13 (Article 8 and the Danish Data Protection Act). Below 13 you need parental consent and must make reasonable efforts to verify it. ## Which security requirements apply to patient data? GDPR Article 32 requires security appropriate to the risk, but the law names no specific algorithms, password lengths or recovery times. You set those in your risk assessment and document them. This is our starting point for health data, not a legal requirement: - **Encryption:** TLS for all traffic and encryption of databases, files and backups, with keys in a separate key vault - **Access:** role-based access with least privilege, and MFA for healthcare staff - **Login:** MitID for citizens and MitID Erhverv for staff when the solution needs national identity - **Logging:** a tamper-resistant log of reads, changes and deletions of patient data, kept for a period you can justify - **Operations:** backups tested by restoring them, and recovery targets (RTO and RPO) that fit the clinical use - **Testing and development:** pseudonymised or synthetic data instead of real patient data In the [Wear & Care platform](https://bon.do/en/work/wear-and-care), access is scoped to the individual care home, login runs through MitID and NemLog-in via Keycloak, and every event is logged. In the backend we built for [a CE-marked medical device](https://bon.do/en/work/seismofit), secrets live in Azure Key Vault, and services use Managed Identity instead of passwords in configuration. ## How long should patient data be kept? As long as the purpose requires and no longer (Article 5(1)(e)), unless another law requires longer retention. For patient records it does: according to the [Danish executive order on authorised health professionals' patient records](https://www.retsinformation.dk/eli/lta/2025/1361) (BEK no. 1361 of 24 November 2025, section 35), doctors and dentists, among others, must keep records for at least 10 years. The right to erasure (Article 17) does not apply while retention is a legal obligation. So build the retention rules into the data model: every data type needs a defined retention period, an owner and automatic deletion or anonymisation when that period ends. ## Can health data be stored with a US cloud provider? Yes, if the transfer has a valid basis under GDPR Chapter V. Within the EU and EEA there are no extra requirements. Data can go to countries with an adequacy decision without further safeguards. - **United States:** the EU-US Data Privacy Framework is an adequacy decision for certified US companies. The General Court upheld it on 3 September 2025 (Latombe, T-553/23), but the ruling has been appealed to the Court of Justice (C-703/25 P) and the case is still pending. Have a plan B. - **Other third countries:** use an Article 46 safeguard, usually the EU standard contractual clauses or binding corporate rules, and carry out a transfer impact assessment (TIA) for every transfer that relies on them. - **Remote access counts:** access to the data by support staff in a third country also constitutes a transfer, even if the data sits in an EU region. [Datatilsynet's cloud guidance from March 2022](https://www.datatilsynet.dk/Media/637824109172292652/Vejledning%20om%20cloud.pdf) sets out what to check, including support access from third countries. ## What must a data processing agreement contain? Article 28 requires a written agreement with every processor. At a minimum it covers: - Purpose, duration, types of data and categories of data subjects - The requirement for the processor to act only on instructions - Security measures and assistance with breaches - Rules for sub-processors, including approval and transfers - Assistance with data subject rights and with the DPIA - Deletion or return of data at the end - The right to audit and inspect Datatilsynet publishes a standard template for data processing agreements, which is a good starting point. ## What happens when health data is breached? You must report a breach to Datatilsynet within 72 hours of becoming aware of it, unless it is unlikely to result in a risk (Article 33). If it is likely to result in a high risk, patients must also be told without undue delay (Article 34). Every breach goes in your internal register, including those you do not report. The Article 83 ceiling is EUR 20 million or 4% of global annual turnover, whichever is higher. In Denmark, Datatilsynet cannot issue fines itself. It recommends a fine and reports the case to the police, and the courts set the fine under section 41 of the Danish Data Protection Act. Datatilsynet can still issue criticism, orders and bans on its own. ## Which Danish rules apply on top of GDPR? In Denmark, health software must also follow the Health Act, the executive order on patient records and the Data Protection Act, fit into the national infrastructure, and prepare for the European Health Data Space from 2027: - **The Health Act (Sundhedsloven):** professional secrecy, the patient's right of access to their own record, and rules on disclosing health information - **The executive order on patient records:** requirements for the content, access and retention of patient records - **The Data Protection Act (Databeskyttelsesloven):** the Danish supplementary rules, such as the age limit for children and the rules on fines - **National systems:** MedCom messaging standards, the Shared Medication Record (FMK), MitID and MitID Erhverv, and regional systems such as Sundhedsplatformen in the Capital Region and Region Zealand - **European Health Data Space:** [Regulation (EU) 2025/327](https://eur-lex.europa.eu/eli/reg/2025/327/oj) applies generally from 26 March 2027, with later deadlines for electronic health record systems and the secondary use of health data from 2029 ## How we work with GDPR in health software We are usually the processor for a manufacturer, a clinic or a municipality. We supply the technical input to your DPIA and data processing agreement: data flow, hosting, sub-processors, access model and logging. The legal assessment stays with you and your adviser. If the product also diagnoses or monitors patients, check first whether [your software is a medical device](https://bon.do/en/articles/idea-to-market-life-science), because that adds the MDR on top of GDPR. Kirsten Bondo Vraa has more than ten years of experience in pharmaceutical quality assurance, and we bring the same approach to data protection: requirements are written down, traced to tests and documented as we go rather than at the end. You get the code, the documentation and ownership. See how we [build health and life science software](https://bon.do/en/services). ## Next step If you are building a health app or a system that handles patient data, we can walk through the data flow with you and point out where GDPR shapes the architecture. It is a no-obligation conversation. [Get in touch](https://bon.do/en/contact-us), or read on about [ISO 13485 certification for medical device software](https://bon.do/en/articles/iso-13485-certification). --- ## Questions we get asked ### What is the legal basis for processing health data under GDPR? You need an Article 6 legal basis and an Article 9(2) exception. In a treatment relationship that is usually point (h), healthcare under professional secrecy. A health app that people choose for themselves usually relies on explicit consent under point (a). ### Do we need a DPIA when we process health data? Yes, if the processing is likely to result in a high risk to the people concerned, for example health data at scale or new technology. If the DPIA shows a high residual risk, you must consult Datatilsynet under Article 36 before you start. ### Can Datatilsynet fine companies for GDPR breaches? Not by itself. In Denmark, Datatilsynet recommends a fine and reports the case to the police. The prosecution brings the case, and the courts set the fine within the GDPR maximum of EUR 20 million or 4% of global turnover. ### Can we use a US cloud provider for health data? Yes, if the transfer has a valid basis: the EU-US Data Privacy Framework for certified providers, or standard contractual clauses with a transfer impact assessment. Also check who can access the data and where support sits, not only which region stores it. ### How long must patient records be kept in Denmark? Doctors, dentists and several other authorised health professionals must keep records for at least 10 years under the Danish executive order on patient records. The right to erasure does not apply while retention is a legal obligation.