GDPR Consent Requirements for Health Data

Introduction

Consent is the most common legal basis for processing health data in consumer and clinical applications. Over 80% of health apps on European app stores rely on user consent as their primary Article 9 justification, according to a 2023 analysis by the European Data Protection Board (EDPB).

But GDPR consent for health data is not a checkbox. The regulation draws a clear line between standard consent (Article 6) and the stricter explicit consent required for special category data (Article 9). A pre-ticked box, a bundled terms screen, or a vague "we may use your health data" clause will not satisfy the requirements. And if your consent mechanism fails, it does not just affect one feature. It can invalidate the legal basis for your entire health data processing pipeline.

The fines reflect this. In 2024, the Swedish Data Protection Authority fined a healthcare provider EUR 12 million for processing patient data without adequate consent mechanisms. The Italian Garante issued a EUR 1.5 million penalty to a health app for bundling health data consent with marketing consent. These are enforcement signals, not edge cases.

This guide covers what explicit consent means in practice, how to architect consent management into your application, and the specific implementation patterns that satisfy GDPR requirements without compromising user experience.

What Makes Health Data "Special Category" Under GDPR

Article 9 and the Special Category Classification

Article 9(1) of the GDPR prohibits the processing of special category data by default. Health data falls into this category alongside genetic data, biometric data, racial or ethnic origin, political opinions, and religious beliefs. The prohibition is lifted only when one of the specific exceptions in Article 9(2) applies, and for most commercial health applications, that exception is explicit consent under Article 9(2)(a).

The distinction matters for application architecture. Standard personal data (name, email, location) can be processed under several legal bases, including legitimate interest. Health data cannot. You need an Article 9 exception for every processing operation that touches health information.

What Counts as Health Data

GDPR defines health data broadly in Article 4(15): "personal data related to the physical or mental health of a natural person, including the provision of health care services, which reveal information about his or her health status."

This definition extends further than many product teams expect:

• Medical records and diagnoses are the obvious cases. Prescription data, lab results, clinical notes.
• Wearable and sensor data including heart rate, blood oxygen, sleep stages, electrodermal activity, and menstrual cycle tracking all qualify as health data.
• Mental health inputs such as mood logs, therapy session notes, anxiety scores, and substance use tracking.
• Fitness data with health context. Step counts alone may not qualify, but step counts combined with a weight loss program, a rehabilitation protocol, or a chronic disease management plan create health data.
• Inferred health data. If your algorithm analyzes behavioral patterns to estimate stress levels or predict depressive episodes, the outputs are health data even if the inputs were not.

The EDPB's 2023 guidelines on health data confirmed that context determines classification. A heart rate reading from a casual fitness tracker and the same reading from a cardiac monitoring app receive different treatment based on the processing purpose.

Consent vs. Explicit Consent

Standard GDPR consent (Article 6) requires an "unambiguous indication" of agreement. This can be satisfied by a clear affirmative action, such as ticking a checkbox or clicking an "I agree" button.

Explicit consent (Article 9) requires a higher bar: a clear, affirmative statement from the data subject that specifically references the sensitive data being processed. The word "explicit" means the consent cannot be implied, bundled, or inferred from general behavior. It must be a deliberate, specific act.

In practice, this means a separate consent interaction dedicated to health data processing, distinct from your general terms of service or privacy policy acceptance.

The Six Requirements for Valid GDPR Consent

The GDPR and EDPB guidelines establish six conditions that consent must satisfy. All six must be met simultaneously.

1. Freely Given

Users must have a genuine choice. Consent is not free if access to the service depends on agreeing to health data processing that is not necessary for the service to function.

For health apps, this means separating core functionality consent from optional data processing. A medication reminder app can require consent to process medication schedules (necessary for the service), but cannot require consent to share that data with pharmaceutical research partners as a condition of using the app.

The EDPB calls this the "conditionality test." If refusing consent results in a penalty or loss of service that is not related to the consented processing, the consent is not freely given.

2. Specific

Each distinct processing purpose requires its own consent. A single consent for "processing your health data" is too broad.

Example of insufficient specificity: "I consent to the processing of my health data."

Example of adequate specificity: "I consent to the processing of my heart rate and sleep data for the purpose of generating personalized recovery recommendations."

If you later want to use the same heart rate data for aggregated research analytics, that requires a separate consent.

3. Informed

Before consenting, users must know:

• What specific health data will be collected
• Why it will be processed (the specific purpose)
• Who will process it (your company, any third-party processors)
• How long it will be retained
• Their right to withdraw consent at any time

This information must be presented in clear, plain language. Regulatory jargon buried in a 40-page privacy policy does not satisfy the informed requirement. The EDPB recommends layered privacy notices: a concise first layer at the point of consent, with links to detailed information.

4. Unambiguous

Consent must result from a clear affirmative action. The GDPR explicitly states in Recital 32 that "silence, pre-ticked boxes or inactivity" do not constitute consent.

Valid affirmative actions include:

• Ticking an unticked checkbox
• Selecting a consent option from a list
• Clicking a clearly labeled consent button
• Providing a typed or verbal confirmation

Scrolling past a notice, continuing to use the app, or failing to opt out are not valid.

5. Documented

You must be able to demonstrate that consent was given. Article 7(1) states: "Where processing is based on consent, the controller shall be able to demonstrate that the data subject consented."

This means storing a consent record for every user. The record should include what was consented to, when, through which mechanism, and which version of the consent text was presented. We cover the specific technical requirements in the architecture section below.

6. Withdrawable

Article 7(3) requires that withdrawing consent must be as easy as giving it. If a user consented with a single tap, they must be able to withdraw with a comparable level of effort.

Withdrawal must be accessible from within the application, not buried in a support email process. And once consent is withdrawn, processing must stop, with the data either deleted or anonymized depending on your retention policy.

"Explicit" Consent for Health Data: What It Means in Practice

Beyond the Standard Checkbox

For health data, the six requirements above still apply, but the consent itself must also be explicit. This is the additional Article 9 requirement that distinguishes health data consent from standard personal data consent.

An explicit consent mechanism requires a clear, affirmative statement from the user that specifically references the health data being processed. The key word is "statement." The EDPB's guidelines (Guidelines 05/2020) recommend the following methods:

• A written or typed statement. "I, [name], consent to the processing of my blood pressure and heart rate data for the purpose of cardiovascular risk monitoring."
• An electronic confirmation with specific language. A consent screen that names the data categories and purposes, requiring the user to actively confirm by clicking "I consent to the processing of my health data as described above."
• A two-step confirmation. The user selects their consent preferences, then confirms on a summary screen that displays exactly what they agreed to.

What does not satisfy explicit consent: implied consent from using the app, a general "I agree to the terms" button, or opt-out mechanisms where consent is assumed unless the user takes action.

Two-Step Confirmation Patterns

A two-step confirmation is one of the most practical patterns for mobile health apps. Here is how it works:

Step 1 - Selection. Present the user with granular consent options. For example:

• "Allow processing of heart rate data for health monitoring" [toggle]
• "Allow processing of sleep data for recovery recommendations" [toggle]
• "Allow sharing of anonymized health data for research purposes" [toggle]

Step 2 - Confirmation. Display a summary: "You have chosen to allow processing of heart rate data for health monitoring and sleep data for recovery recommendations. Tap Confirm to provide your consent." The user then taps a clearly labeled "Confirm" button.

This pattern satisfies the explicit requirement because it produces a deliberate, specific statement. It also creates a clear consent record that is easy to store and audit.

Separating Health Data Consent from Other Consents

Health data consent must be presented separately from:

• General terms of service acceptance
• Marketing communication preferences
• Analytics and tracking consent
• Third-party data sharing for non-health purposes

This does not mean you need five different consent screens during onboarding. You can present these on a single screen with visually distinct sections and separate confirmation actions for each category. The legal requirement is that health data consent is not bundled with or conditional on other consents.

Consent Management as Application Architecture

Consent Records: What to Store

Every consent event should generate a record containing:

Store consent records separately from user profile data. They serve a different purpose (regulatory compliance and audit) and should be retained even after the user deletes their account, for the duration required by your data protection authority.

Consent Versioning

Privacy policies and consent texts change. When they do, existing consent may no longer be valid for the updated processing purposes. Your system needs to handle this.

A practical approach:

1. Version every consent text. Store the full text (or a hash and reference) of each consent version.
2. Track which version each user consented to. When the text changes, flag users on outdated versions.
3. Trigger re-consent flows. If the changes are material (new data types, new purposes, new recipients), present users with a re-consent screen on their next app session.
4. Do not block the app entirely. Allow users to continue using features that do not require the updated consent while prompting for re-consent on affected features.

The EDPB recommends that minor clarifications (rewording for clarity without changing scope) do not require re-consent, but any expansion of processing purposes or data categories does.

Granular Consent

Users should be able to consent to specific processing activities independently. A user might agree to heart rate monitoring for health insights but decline sharing anonymized data for research.

Implement consent as a set of independent flags, not a single boolean. Your data processing pipeline should check the relevant consent flag before each operation. This adds complexity to your backend, but it is a GDPR requirement for health data, and it gives users real control.

Consent Withdrawal and Data Handling

When a user withdraws consent:

1. Stop processing immediately. The relevant data processing operations must halt.
2. Delete or anonymize the data. Depending on your retention policy and whether other legal bases apply, either delete the health data or anonymize it so it no longer qualifies as personal data.
3. Propagate to third parties. If you shared the data with processors or partners, notify them to delete their copies.
4. Retain the consent record itself. The record of consent (and withdrawal) should be retained for compliance purposes, even after the data is deleted.
5. Confirm to the user. Provide clear feedback that their consent has been withdrawn and their data has been handled accordingly.

How Momentum Approaches Consent Infrastructure

At Momentum, we treat consent management as a foundational infrastructure layer, not a frontend feature. For health applications, this means:

• Consent service as a standalone module with its own data store, API, and versioning system. It is not embedded in the user service or authentication flow.
• Event-driven consent propagation. When consent status changes, an event is published to all dependent services, triggering appropriate data handling workflows.
• Audit-ready logging. Every consent interaction is logged with sufficient detail to satisfy a supervisory authority's investigation.
• Consent-aware data pipelines. ETL and analytics pipelines check consent status before processing health data records, filtering out data from users who have not consented to the relevant purpose.

This architecture adds development time upfront, but it avoids the far more expensive problem of retrofitting consent management into a production system that was built without it.

When You Don't Need Consent (Article 9 Exceptions)

Article 9(2) lists ten exceptions to the general prohibition on processing special category data. Beyond explicit consent, the most relevant for health applications are:

• Preventive or occupational medicine (Article 9(2)(h)). Processing health data for medical diagnosis, provision of health care, or management of health systems. This applies to healthcare providers and their authorized systems, not to consumer health apps.
• Public health (Article 9(2)(i)). Processing necessary for public health purposes, such as disease surveillance or quality assurance in healthcare. Requires a basis in EU or member state law.
• Scientific research (Article 9(2)(j)). Processing for archiving, scientific research, or statistical purposes. Requires appropriate safeguards under Article 89(1), including data minimization and pseudonymization.
• Vital interests (Article 9(2)(c)). Processing necessary to protect someone's life when they cannot give consent. Limited to emergency situations.

Why most commercial health apps still need consent. These exceptions are narrowly defined. A wellness app that tracks sleep patterns does not qualify for the preventive medicine exception, which is reserved for licensed healthcare providers operating within the scope of their medical practice. A fitness platform running engagement analytics on health data cannot claim the scientific research exception without meeting the specific safeguards in Article 89.

If your application is a direct-to-consumer health product, plan for consent as your primary legal basis.

Common Consent Mistakes in Health Apps

Based on enforcement actions and EDPB guidance, these are the patterns that most frequently fail compliance reviews:

Pre-ticked consent checkboxes. The GDPR is unambiguous on this point. Recital 32 explicitly states that pre-ticked boxes do not constitute consent. The Court of Justice of the EU confirmed this in the Planet49 ruling (Case C-673/17, October 2019).

Bundling health data consent with marketing consent. Presenting a single consent covering both "processing your health data for the service" and "sending you promotional emails about health products" violates the specificity requirement. These are different purposes requiring separate consents.

"By using this app, you agree to..." Implied consent from continued use does not meet the explicit consent standard for health data. This pattern was common before GDPR and persists in many applications, but it is invalid.

No granular withdrawal mechanism. A user who consented to three types of health data processing must be able to withdraw consent for one type while maintaining the others. An all-or-nothing approach violates the granularity principle.

Failure to re-collect consent on policy changes. If you add a new data processing purpose (such as sharing anonymized data with a research partner), existing consent does not cover it. Users must be informed and asked to consent to the new purpose.

No consent records. If a regulator asks you to demonstrate that user #12345 consented to health data processing on a specific date, you need to produce that record. "They must have clicked the button because they are using the app" is not sufficient evidence.

Implementation Checklist

Use this checklist when building or auditing consent management for a health application:

Build Your Health App with GDPR Consent Built In

Consent management is infrastructure that should be designed into your application from the start. Retrofitting it into a production system with existing users and data flows is expensive, risky, and often requires re-collecting consent from your entire user base.

Momentum helps healthtech companies build applications with GDPR-compliant consent management, data residency controls, and patient rights workflows as foundational architecture, not afterthoughts.

‍Related reading:

• GDPR for HealthTech: What US-Based Health App Companies Need to Know
• HIPAA vs. GDPR: Key Differences for Health App Development

‍