--- title: "How to Get Valid User Consent for Health Data" canonical: "https://aifitnessapi.com/compliance/health-data-user-consent" cluster: "Compliance" primary_query: "user consent for health data" last_reviewed: "2026-07-14" description: "How to get valid consent for health data under GDPR: opt-in, granular, withdrawable. Why an OS permission is not legal consent, plus consent to sell." publisher: "AIFitnessAPI — independent, not sponsored" cite_as: "\"How to Get Valid User Consent for Health Data\", AIFitnessAPI, https://aifitnessapi.com/compliance/health-data-user-consent" --- # How to Get Valid User Consent for Health Data > Valid consent under GDPR must be freely given, specific, informed, and unambiguous — a clear opt-in, never a pre-ticked box or bundled into your terms. Because fitness data is special-category health data, you usually need explicit consent, granular per purpose and as easy to withdraw as to give. The key trap: an iOS HealthKit or Android Health Connect permission is a device access control, not automatically a legal basis for what you then do with the data. This is general guidance, not legal advice, so confirm your obligations with a qualified professional. - Canonical: https://aifitnessapi.com/compliance/health-data-user-consent - Last reviewed: 2026-07-14 - Publisher: AIFitnessAPI (https://aifitnessapi.com) — independent, not sponsored - Cite as: "How to Get Valid User Consent for Health Data", AIFitnessAPI, https://aifitnessapi.com/compliance/health-data-user-consent --- ## What makes consent "valid" under GDPR Consent is only one of several lawful bases, but when you rely on it, it has to meet every one of these conditions at once. If any is missing, the consent is not valid. | Requirement | What it means for your app | |---|---| | Freely given | The user has a genuine choice and suffers no detriment for refusing. Consent must not be bundled with your terms or made a condition of using the service. | | Specific | Tied to defined, named purposes — not a blanket "we may use your data." | | Informed | The user knows who you are (the controller), what data you take, why, and what their rights are. | | Unambiguous | A clear affirmative action. **No pre-ticked boxes, no silence or inactivity, no opt-out, no default-on settings** count as consent. | | Granular | A separate opt-in per distinct purpose or type of processing — unbundled, so a user can say yes to one thing and no to another. | | Withdrawable | As easy to withdraw as it was to give — ideally a one-step, accessible action. Withdrawal does not undo processing that was lawful before it. | Because health data is **special-category data** under GDPR Article 9, the usual route is **explicit consent** — an express opt-in statement, not something implied. And explicit consent typically has to sit on top of a separate general lawful basis. For how the two layers stack, see our [GDPR for fitness apps](/compliance/gdpr-fitness-app) page. Consent is not the only lawful basis, and it is not always the right one, so do not assume consent is always required or always the answer. ## An OS permission grant is not legal consent This is the distinction that trips up the most builders. When a user taps "Allow" on an iOS **HealthKit** authorization sheet or grants an Android **Health Connect** permission, that is a **device-level access control**. It decides whether your app is technically able to read or write those data types on that device. It is **not automatically a GDPR lawful basis** for what you subsequently do with the data. In practice you often still need a separate, GDPR-valid consent (or another lawful basis) for your actual processing — storing it on your servers, running analytics on it, sharing it, and so on. Treating the OS grant as end-to-end legal cover is a mistake: a permission and a consent are different instruments doing different jobs. App-store rules reinforce this from their own side — both Apple and Google require in-app consent and disclosure independent of the OS prompt. See [Apple's health-data rules](/compliance/app-store-health-data-rules) and [Google Play's health-data policy](/compliance/google-play-health-data-policy). ## OAuth scopes: consent to access, not to everything When a user authorizes your app through OAuth — for example, connecting a wearable or health platform — the **scopes** they grant define exactly what data access they consented to. This is a technical, auditable consent to *access* the data. It is a clean record of what the user allowed you to reach. What it is not, on its own, is consent for downstream purposes like marketing or selling the data. Access authorization and purpose consent are separate. For how OAuth works in this context, see [what is OAuth for health data](/learn/what-is-oauth-for-health-data). ## Consent to sell or share is a separate thing (US state law) Under Washington's **My Health My Data Act (MHMDA)**, consent and authorization-to-sell are treated as **different instruments**: - **Consent to collect or share** consumer health data (opt-in). - A **distinct, valid authorization to SELL** that data — a separate, standalone, **signed** document with statutorily prescribed contents. Under Washington's MHMDA, that sale authorization must be its own signed document, and **both the seller and the purchaser have to retain it for six years**. MHMDA has been in force since March 31, 2024 (small businesses June 30, 2024) and carries a notable private right of action, which makes it a real litigation risk. MHMDA is Washington-specific but reaches conduct affecting Washington residents wherever your company sits, and other states (Nevada, Connecticut expansions, and more) have similar-but-different rules. Verify the current state-law landscape for your users. ## Keep records that prove consent GDPR requires you to be able to **demonstrate** that a user consented. That means keeping versioned consent logs that capture: - **who** consented, - **when** they did, - **what they were told** — the exact wording and version they saw, and - **how** they can withdraw. If you cannot show these, you effectively cannot show valid consent. Treat consent records as a first-class part of your data model, not an afterthought. ## Children's data and age gates (briefly) If children may use your app, extra rules apply. In the US, **COPPA** requires verifiable parental consent to collect data from children under 13; the usual mechanism is an age gate or neutral age-screen. Apple and Google add their own limits for kids (for example, restrictions on behavioral advertising). Under GDPR, the digital-consent age is **16, which member states may lower to as low as 13** — below that threshold, parental or guardian consent is required. Age thresholds vary by jurisdiction, so verify the current numbers for the markets you serve. ## What this means for a fitness app - **Design consent as a real, granular opt-in** for health data — separate per purpose, never pre-ticked, never bundled into your terms. - **Make withdrawal as easy as consent** — ideally one step — and remember that prior lawful processing stays lawful. - **Do not treat the HealthKit or Health Connect prompt as your legal basis.** Layer a proper consent (or other basis) on top for what you do with the data. - **Separate "share" from "sell."** If you might sell consumer health data, treat the authorization to sell as its own signed, retained instrument. - **Log everything** — who, when, what wording, and how to withdraw — in versioned records you can produce on demand. - **Gate for age** if children may use the app, and check the threshold per jurisdiction. ## A note on limits Consent is one lawful basis among several, and for health data you generally need Article 9 explicit consent (or another Article 9 condition) on top of a general basis — do not read this page as saying consent is the only route. State laws differ, age thresholds move, and platform rules change. Use this as a starting map, not a compliance sign-off, and get advice from a qualified professional for your specific case. ## FAQ ### Is an iOS HealthKit or Android Health Connect permission the same as GDPR consent? No. An OS permission grant is a device-level access control that decides whether your app can read or write those data types. It is not automatically a GDPR lawful basis for your subsequent processing, storage, or sharing. You typically still need a separate, GDPR-valid consent (or another lawful basis) for what you do with the data. [Permalink](https://aifitnessapi.com/compliance/health-data-user-consent#faq-1) ### What makes consent valid under GDPR? It must be freely given, specific, informed, and unambiguous — a clear affirmative opt-in, with no pre-ticked boxes, silence, or default-on settings counting as consent. It should be granular (a separate opt-in per purpose) and as easy to withdraw as to give. For health data, which is special-category, the usual route is explicit consent, a higher bar. [Permalink](https://aifitnessapi.com/compliance/health-data-user-consent#faq-2) ### Do I need separate consent to sell or share health data? Under Washington's My Health My Data Act, yes — consent to collect or share is separate from a distinct, signed authorization to sell consumer health data. Per the statute, that sale authorization is its own signed document, and both seller and purchaser must retain it for six years. Other states have similar-but-different rules, so verify the current landscape. [Permalink](https://aifitnessapi.com/compliance/health-data-user-consent#faq-3) ### What consent records do I need to keep? GDPR requires you to be able to demonstrate consent, so keep versioned logs of who consented, when, what they were told (the exact wording and version they saw), and how they can withdraw. If you cannot show these, you effectively cannot show valid consent. Treat consent records as part of your data model, not an afterthought. [Permalink](https://aifitnessapi.com/compliance/health-data-user-consent#faq-4) ### What about consent for children's health data? In the US, COPPA requires verifiable parental consent to collect data from children under 13, usually via an age gate or neutral age-screen. GDPR sets a digital-consent age of 16 that member states may lower to as low as 13, below which parental consent is required. Thresholds vary by jurisdiction, so verify the current numbers for your markets. [Permalink](https://aifitnessapi.com/compliance/health-data-user-consent#faq-5)