The Compliance Challenge
Washington's My Health My Data Act, passed April 17, 2023, presents a compliance challenge for privacy teams. The Act requires consent for processing Consumer Health Data but doesn't specify a single consent standard. Instead, it varies the consent requirement by processing activity. This raises a practical question: should you build one comprehensive consent mechanism that covers all potential processing, or should you implement separate consent flows tailored to each activity type?
The stakes are high. Get it wrong, and you're either over-collecting consent (creating friction that drives users away) or under-collecting it (exposing your organization to enforcement risk). The Act defines Consumer Health Data broadly as information linked to an individual that identifies their "past, present, or future physical or mental health status." This definition pulls in organizations far beyond traditional healthcare: fitness apps, dietary supplement retailers, wellness newsletters, even grocery stores offering health-focused shopping experiences.
Because the Act excludes HIPAA-regulated entities and employers, it creates a compliance gap where non-traditional health data collectors must now make architectural decisions about consent infrastructure without clear regulatory precedent.
Unified Consent: A Simpler Approach
Some privacy teams advocate for a single, comprehensive consent mechanism. This approach reduces implementation risk. If you build one consent flow that meets the highest standard required by WMHMDA, you've covered all processing activities by default. This mirrors how many organizations handle GDPR compliance, where they apply Article 7 standards uniformly rather than parsing different legal bases for different processing operations.
The practical advantages are clear. You maintain one Consent Management Platform configuration instead of multiple flows. Your development team builds and tests one user interface. Your consent records follow a single schema, making audits straightforward. When the Act's requirements evolve or enforcement guidance emerges, you update one system rather than coordinating changes across multiple consent touchpoints.
There's also a user experience benefit. Presenting consumers with a single, clear choice about how you'll handle their health data respects their time. Multiple consent requests throughout a user journey create Consent Fatigue, where users start clicking "accept" reflexively just to access the service they came for. A well-designed unified consent notice can improve comprehension by consolidating all processing purposes into one disclosure.
For organizations with limited engineering resources, this approach offers a faster path to compliance. You're not parsing statutory language to determine whether sharing data with a research partner requires "express consent" while using it for service improvement requires something less. You apply the strictest standard everywhere and move on.
Activity-Specific Consent: Tailored to Risks
Others argue that WMHMDA's variable consent requirements are intentional, and your consent architecture should reflect that. The Act distinguishes between different processing activities because they carry different privacy implications. Collecting health data to provide a requested service differs materially from selling that data to a third party or using it for targeted advertising.
Unified consent creates its own compliance risk: you're asking for permission you don't yet need. If a user consents to "all processing activities" but you're currently only using their data for service delivery, you've collected consent for sale or sharing that you haven't actually performed. Should your business model change later, can you rely on that earlier blanket consent? The answer isn't clear, and regulatory guidance on consent validity typically requires that consent be specific to the actual processing taking place.
The Granularity principle is at work here. Valid Consent under most privacy frameworks requires that users understand what they're agreeing to. When you bundle consent for service delivery, analytics, research partnerships, and data sales into one yes/no question, you've arguably undermined that Granularity. A user who's comfortable with you using their fitness data to generate personalized workout recommendations might object to that same data being sold to insurance companies for risk modeling.
Activity-specific consent gives you operational flexibility. You can launch with minimal data processing, collect narrow consent, and expand your consent requests only as your business needs evolve. This approach aligns with Data Protection by Design principles, where you build systems that process the minimum necessary data under the narrowest sufficient permissions.
For organizations that process Consumer Health Data across genuinely different business functions, separate consent flows also create clearer audit trails. When a regulator asks whether you had valid consent to share data with a specific research partner, you can point to a discrete consent record for that activity rather than arguing it was covered under a general consent granted earlier.
The Hybrid Approach
In practice, most organizations subject to WMHMDA are adopting a hybrid model. They're implementing tiered consent that separates high-risk activities (sale, sharing with third parties, Cross-Context Behavioural Advertising) from lower-risk processing (service delivery, internal analytics). This middle path acknowledges that not all processing activities carry equal privacy implications while avoiding the user experience nightmare of multiple consent requests.
The common pattern: a Primary Consent Notice at account creation or first data collection that covers essential processing, followed by just-in-time consent requests when the user encounters a feature that triggers higher-risk processing. If someone wants to join a research study using their health data, that's when you present the specific consent for research sharing, not during initial signup.
Organizations are also building consent renewal workflows that prompt users to review and update their preferences periodically, particularly when processing activities change. This addresses the concern about stale blanket consent while avoiding the friction of constant re-consent requests.
Our Recommendation
Build for activity-specific consent even if you only implement one tier initially. The Act's variable consent requirements signal regulatory intent: different processing activities deserve different levels of scrutiny and user control. A unified consent mechanism might feel simpler today, but it creates technical debt you'll pay back with interest when enforcement guidance emerges or when your business model evolves.
The stronger compliance posture is to architect your consent infrastructure with the flexibility to add granular consent flows as needed. Start with two tiers at minimum: one for processing necessary to deliver your core service, and a separate consent flow for any sale, sharing, or advertising use of Consumer Health Data. This respects the Act's implicit risk hierarchy while keeping your initial implementation manageable.
Document your consent design decisions now. When you choose to combine certain processing activities under one consent request, write down your reasoning: why you believe those activities are sufficiently similar in privacy impact to warrant unified consent. That documentation becomes your defense if a regulator questions your approach later.
The tradeoff is real: activity-specific consent requires more engineering work upfront and more complex consent record management. But WMHMDA's broad definition of Consumer Health Data means you're likely handling information with genuine sensitivity. The cost of getting consent wrong exceeds the cost of building it right from the start.
