.png)
Consent management for wearable health data is not just a checkbox in your onboarding flow. It is a legal requirement, a technical architecture decision, and a user trust question all at once.
Most healthcare platforms treat consent as a front-end problem: a modal, a toggle, an acceptance screen. The underlying data infrastructure often has no concept of consent at all. Data flows in from the device, gets stored, and gets processed with the assumption that because the user clicked through the onboarding, the platform has permission to do whatever comes next.
That assumption is wrong, and it is one of the more expensive compliance mistakes a digital health platform can make. What consent for wearable health data actually requires, and what a compliant consent architecture actually looks like, is more specific than most implementations reflect.
Cookie consent is governed by the ePrivacy Directive and, in practice, has become a relatively low-stakes interaction: a banner, a preference center, an opt-out. The consequences of a poorly designed cookie consent flow are real but limited.
Wearable health data operates under a different legal framework entirely. Heart rate, sleep staging, HRV, blood oxygen saturation, and blood glucose are health data under GDPR Article 4(15), and health data is special category data under Article 9. Processing special category data is prohibited by default. To process it lawfully, a platform needs both a lawful basis under Article 6 and a specific condition under Article 9(2). You can find more details about health data compliance in our GDPR Compliance blog post!
For most digital health platforms, the Article 9(2) condition they rely on is explicit consent under Article 9(2)(a). That word “explicit” carries significantly more legal weight than the consent standard that applies to ordinary personal data. The gap between ordinary GDPR consent and explicit consent for special category health data is where most platform consent implementations fall short.
The GDPR's consent requirements under Article 7, applied at the explicit standard required by Article 9, mean that valid consent for wearable health data must be:
This is the standard that wearable health data consent needs to meet, not the lower bar that applies to analytics cookies or marketing preferences.
A compliant wearable health data consent architecture treats consent as four distinct decisions, not one.
It covers whether the platform may access and ingest health data from the user's wearable device or aggregator. This is the most foundational consent and the one most platforms implement, at least partially. See what happens to your data within Thryve’s infrastructure!
What the platform may do with the data once collected: analyze it, generate insights from it, run it through algorithms. Collection and processing are distinct activities under GDPR and require separate justification.
Each specific use case the data will be applied to. Risk scoring, care recommendations, population health analytics, and research use are different purposes. Consent given for one does not extend to the others.
Whether processed data or derived insights may be shared with insurers, clinical partners, research institutions, or other third parties. This consent must name the category of recipient and the purpose of the transfer.
Bundling all four into a single consent request creates two problems. First, it makes the consent less specific and therefore less legally robust. Second, it prevents users from consenting to some purposes while declining others, which the GDPR requires platforms to allow.
Purpose limitation is one of the core GDPR data protection principles under Article 5(1)(b): data collected for one purpose cannot be used for a different, incompatible purpose without a new legal basis.
For wearable health platforms, this creates practical complexity. A platform that collects activity data to power a wellness dashboard, then later wants to use that data for population health research or to train a risk model, cannot simply extend its existing consent to cover the new use. It needs a new, separate consent from affected users, and it needs to be able to identify which users' data it wants to use for the new purpose and confirm they have consented to it.
This has direct implications for consent architecture. A platform that records consent as a binary flag “consented: yes/no” cannot support the re-consent workflows that purpose expansion requires. Consent records need to be purpose-tagged, versioned, and queryable by use case. When a new purpose is introduced, the platform needs to be able to identify users who have not yet consented to that purpose, present them with a specific consent request, and exclude their data from the new use until they have done so.
A consent record is a structured data object that needs to contain enough information to demonstrate compliance to a supervisory authority and to drive operational decisions within the platform.
A compliant consent record for wearable health data should include:
Consent records need to be versioned because consent texts change. When a platform updates its data processing terms, users who consented to a previous version have not consented to the new one. The platform needs to be able to identify those users and manage the re-consent process.
Consent records also need to survive device reconnections. If a user disconnects their wearable and reconnects it, whether to troubleshoot a sync issue or to upgrade to a new device, the reconnection should not reset or invalidate existing consent. Equally, reconnection should not be treated as fresh consent for purposes the user has not explicitly agreed to.
GDPR Article 7(3) gives users the right to withdraw consent at any time, and withdrawal must be as easy as giving consent. A platform that allows consent to be given in three taps but requires a written request to withdraw it does not meet this requirement.
When a user withdraws consent, several things need to happen:
The right to erasure under Article 17 is closely linked to consent withdrawal. When a user withdraws consent, and there is no other lawful basis for processing, erasure requests must be fulfilled within one month. For platforms that use health data in model training, this creates an additional challenge: if a user's data was used to train a model, erasure from the training dataset may not be technically straightforward and may require model retraining in some circumstances.
Most digital health platforms operating in Europe need to comply with GDPR. Platforms with users in the United States also need to consider HIPAA, and platforms operating in multiple markets face a patchwork of additional national requirements.
Where GDPR and HIPAA share common ground:
Where they differ:
For platforms operating across both frameworks, the practical approach is to build to the stricter standard, GDPR's explicit consent requirement, and document how that standard also satisfies the requirements of other applicable frameworks. A consent architecture built for GDPR compliance will generally meet or exceed HIPAA's authorization requirements for most wearable health data use cases.
A single consent covering data collection, processing, risk scoring, research use, and third-party sharing is not specific enough to be valid under GDPR for any of those purposes individually.
"To improve your health outcomes" or "to provide personalized services" do not constitute specific purposes. Consent must name what the platform actually does with the data.
If users cannot easily withdraw consent in-app, the platform is not meeting the GDPR's requirement that withdrawal be as easy as giving consent. This creates both compliance risk and user trust issues.
Reconnection events need to check for existing consent rather than treating the reconnection as a fresh start. This is a technical oversight that creates legal exposure and is more common than most teams expect.
Every time a platform introduces a new use of health data, it is either processing without consent or unable to use existing users' data for the new purpose. Building re-consent workflows into the platform from the start is significantly cheaper than retrofitting them later.
At Thryve, consent management is built into the data infrastructure layer rather than left to each partner to implement independently. Our platform includes:
If you are building a healthcare platform that handles wearable health data and need consent management infrastructure that meets the GDPR standards, book a demo with Thryve.
Paul Burggraf, co-founder and Chief Science Officer at Thryve, is the brain behind all health analytics at Thryve and drives our research partnerships with the German government and leading healthcare institutions. As an economical engineer turned strategy consultant, prior to Thryve, he built the foundational forecasting models for multi-billion investments of big utilities using complex system dynamics. Besides applying model analytics and analytical research to health sensors, he’s a guest lecturer at the Zurich University of Applied Sciences in the Life Science Master „Modelling of Complex Systems“
.png)
.png)