A Washington startup founder is reviewing a wellness app's onboarding screen. The product team has added a privacy-policy checkbox, marketing wants to send health-related events to a retargeting vendor, and a potential partner wants to license the resulting dataset. Those activities shouldn't run through the same permission screen.
What are the different levels of consent required under Washington's MHMD Act? The practical answer is affirmative opt-in consent for collection, separate opt-in consent for sharing, and a standalone signed authorization for sales. The founder's job is to match each activity to the correct permission before the data moves.
Why Washington's MHMD Act Uses Three Consent Levels
Collection, sharing, and selling are different decisions for the consumer. A person might agree to provide health information for a wellness feature without agreeing to its disclosure to another business. Agreeing to disclosure doesn't automatically authorize monetization.
Washington's My Health My Data Act establishes a practical consent hierarchy through its requirements for collection, sharing, and sale authorization. These aren't interchangeable labels for the same checkbox. Each permission must correspond to the activity the business performs.
Match the Permission to the Business Activity
The useful starting point isn't the company's privacy banner. It's the product's data flow.
- Collection: The business obtains consumer health data for a disclosed purpose. Where consent is required, the consumer must affirmatively opt in before collection.
- Sharing: The business makes a separate decision to disclose that data. Where consent is required, sharing needs its own distinct opt-in.
- Selling: The business enters the highest permission category. Ordinary consent doesn't replace a valid written authorization.
This hierarchy is an operating model, not a claim that every vendor interaction automatically requires every permission. The requested-service exception matters for collection and sharing. Teams should examine the actual transfer and its purpose rather than classify it solely by the recipient's business label.
Practical rule: A permission to obtain health data isn't a blank check for everything the business might later do with it.
Start With Purpose, Not Interface Design
A founder should require product and engineering teams to explain why each health-data field exists before discussing checkbox placement. That makes the connection between data minimization and purpose limitation in Washington operational: fewer unnecessary fields mean fewer permissions to manage and fewer opportunities to exceed the disclosed purpose.
For teams handling sensitive recordings or datasets, the truelabel privacy and consent overview offers a supplementary resource for examining consent questions. The Washington statute remains the authority for MHMD requirements.
The recommended sequence is straightforward: identify the activity, identify any applicable exception, and then design the permission mechanism. Starting with an existing cookie banner and trying to stretch it across the entire business reverses that sequence.
Level 1 Affirmative Opt-In Consent for Collection
A collection checkbox should authorize a defined collection activity, not acknowledge an entire website. Under the Act's affirmative-consent standard and required disclosures, consent must reflect a freely given, specific, informed, opt-in, voluntary, and unambiguous agreement through a clear affirmative act. Accepting broad terms of use or a general privacy policy isn't enough.
The compliance threshold has two parts. The business needs a genuine opt-in where consent is required, and the permission must match the disclosed data categories and purposes.
What the Collection Request Must Explain
The consent request must give the consumer enough information to understand the decision:
- Data categories: Identify the categories of consumer health data involved, rather than referring vaguely to personal information.
- Purpose and specific uses: Explain what the business plans to do with those categories. Broad references to improving the experience aren't a useful product specification.
- Recipients: Identify the categories of entities receiving the data, with recipient disclosures appropriate to the proposed sharing.
- Withdrawal: Explain how the consumer can withdraw consent from future collection and sharing.
A recommended interface uses an unchecked, activity-specific control beside those disclosures. The business should record the action and the disclosure version presented with it. That recordkeeping recommendation supports proof of consent; it isn't a substitute for understandable wording.
A Fitness-App Onboarding Example
Consider a hypothetical fitness app that asks for health information to support an optional personalization feature. A screen that merely requires acceptance of the app's terms and privacy policy doesn't obtain the required collection permission.
A better design separates acceptance of contractual terms from consent to the optional health-data collection. The collection request identifies the relevant categories, explains personalization uses, describes applicable recipients, and provides the withdrawal method before the consumer activates the control.
The distinction between clickwrap and browsewrap helps teams evaluate interface mechanics. But even a clearly clicked agreement won't cure disclosures that fail to explain the health-data activity.
Is collection consent always required? No. The statute generally allows collection without consent when it's necessary to provide a product or service the consumer specifically requested. The team should document which requested function requires the information and why; optional research or unrelated marketing shouldn't be folded into that explanation.
Level 2 Separate Opt-In Consent for Sharing Consumer Health Data
A hypothetical wellness platform collects information for an optional tracking feature, then proposes sending health-related events to a retargeting vendor. The collection permission doesn't answer the sharing question. The proposed transfer needs its own analysis and, where required, a separate opt-in.
Can collection and sharing use the same bundled checkbox? No. The separate-consent requirement described in the statute above calls for a sharing decision distinct from collection consent. A combined control hides the choice the consumer must be able to make.
Collection vs Sharing Consent at a Glance
| Element | Level 1 Collection | Level 2 Sharing |
|---|---|---|
| Activity being authorized | Obtaining consumer health data | Disclosing consumer health data |
| Recommended interface | Dedicated collection control | Separate sharing control |
| Purpose explanation | Why the business needs the data and its specific uses | Why the business proposes the disclosure |
| Recipient information | Relevant recipient categories in the request | Recipients relevant to the proposed transfer |
| Requested-service exception | Evaluate necessity for the requested function | Evaluate necessity of the transfer itself |
| Operational evidence | Collection permission linked to the field and purpose | Sharing permission linked to the transfer and recipient |
The right product behavior allows a consumer to accept permitted collection while declining optional sharing. Engineering should test that distinction directly: disabling the sharing control should prevent the corresponding outbound event without disabling or rewriting the collection choice.
A Vendor Relationship Doesn't Answer the Consent Question
A familiar healthcare-style mental model separates the consumer's decision from the vendor contract. Teams shouldn't assume that a confidentiality promise answers whether the consumer authorized a particular disclosure. MHMD analysis must focus on the actual data movement and the purpose served.
Nor should teams conclude that every interaction with a service provider necessarily requires a sharing checkbox. The relevant question is whether the activity triggers the sharing requirement and whether the requested-service exception applies. Recipient labels such as analytics provider or trusted partner aren't a sufficient analysis.
For a transfer claimed to be necessary, the privacy lead should document the requested service, the recipient's task, and why that transfer is needed. A retargeting proposal shouldn't be treated as necessary merely because marketing considers it useful.
A vendor contract can describe what the recipient may do. It doesn't demonstrate what the consumer agreed to share.
Data licensing also deserves separate review. SourceX's do you need consent to license data is a supplementary resource for teams evaluating licensing arrangements, not a substitute for Washington-specific classification.
The practical recommendation is to inspect the outgoing payload and proposed use before choosing a control. Calling a transaction a partnership doesn't resolve whether it belongs in the sharing or sale category.
Level 3 Valid Authorization for Selling Health Data
A sale requires a separate written valid authorization, not a stronger-looking toggle. The Act's sale-authorization requirements call for a plain-language document identifying the transaction and carrying the consumer's signature and date. Collection or sharing consent can't perform that job.
For a startup considering monetization or business-to-business licensing, the authorization review should happen before commercial launch. The consumer-facing document must correspond to the proposed sale, rather than authorize unspecified future buyers and uses.
What the Authorization Must Contain
A usable drafting checklist separates transaction details from the consumer's rights:
- Specific data: Identify the consumer health data being sold. A blanket reference to all information collected by the business doesn't provide a useful transaction description.
- Seller and purchaser: Include the required contact information for both parties.
- Commercial purpose and purchaser use: Explain the purpose of the sale and how the purchaser will use the data.
- Revocation: Describe the consumer's right to revoke the authorization.
- Redisclosure: Address the possibility that the purchaser may disclose the data again.
- No signing condition: State that goods or services cannot be conditioned on signing.
- Execution: Include the consumer's signature and the date.
The infographic is a quick interface checklist, not the complete authorization form. The document still needs the transaction disclosures listed above.
Separate the Form From the Commercial Contract
A purchaser's contract with the startup doesn't supply the consumer's authorization. Legal and product teams should maintain a consumer-facing authorization process alongside the commercial agreement and confirm that the authorized data and uses match the deal.
The authorization must expire one year after signature, and the business must provide the consumer a copy, under the same statutory sale-authorization provision cited above. Engineering should therefore check authorization status before release rather than treat a historical signature as permanent permission.
The recommended workflow records the executed document, the transaction it covers, delivery of the consumer's copy, and the applicable expiration. A changed purchaser or changed use should trigger legal review instead of automatic reuse of an old form.
Does a signature alone make the authorization valid? No. A signed document that omits required disclosures or doesn't match the sale still misses the standard. The signature is part of the authorization, not the whole authorization.
Mapping Each Data Flow to the Right Consent Level
The practical compliance test is whether the product blocks an activity when its required permission is missing. A carefully drafted screen accomplishes little if engineering sends the event before the consumer makes a choice.
A founder should commission a field-to-purpose-to-recipient consent map. That map connects the consumer-facing disclosure to the database field, feature, outgoing payload, and permission record that control processing.
Build a Map That Engineering Can Use
| Map field | What the team should record |
|---|---|
| Data field or event | The actual information collected or transmitted |
| Product purpose | The disclosed function supported by that information |
| Recipient | The destination and proposed recipient use |
| Activity classification | Collection, sharing, or sale |
| Permission or exception | The applicable consent event or documented requested-service rationale |
| Disclosure version | The text presented when permission was obtained |
| Processing gate | The condition that must pass before the activity occurs |
| Change owner | The person responsible for reassessment before launch |
In the hypothetical wellness app, the personalization intake, retargeting export, and proposed licensing arrangement should occupy distinct entries. Combining them into a single row labeled user data makes it harder to detect which activity lacks permission.
A data processing agreement belongs alongside this map when documenting a vendor relationship. It addresses the parties’ processing arrangement; it doesn’t replace the consumer permission applicable to the mapped activity.
Treat Expanded Processing as a Launch Gate
Expanded processing isn’t another name for the sale-authorization tier. It’s a change-control trigger within the statutory workflow.
As reflected in the affirmative-consent provisions cited earlier, adding health-data categories or purposes not disclosed in the consumer health data privacy policy requires disclosure and affirmative consent before the additional collection, use, or sharing begins. Publishing revised policy text alone doesn’t complete that process.
Recommended release controls should address these failure modes:
- Premature collection: An intake form or event handler processes information before the required consent event.
- Permission reuse: A sharing integration checks the collection flag rather than its own permission.
- Missing sale gate: A licensing export runs without a matching authorization.
- Undisclosed expansion: A feature introduces new categories or uses while relying on older permission.
These are operational risks derived from the statutory requirements, not claims about named enforcement cases. Engineering, marketing, and privacy leads should test them against actual payloads and user journeys, including withdrawal paths and queued exports.
Practical Checklist and Recent Enforcement Signals
The clearest enforcement signal is the Attorney General’s published warning about unauthorized sales. The Washington Attorney General’s MHMD guidance states that selling or offering to sell consumer health data without valid authorization is unlawful. The sale-authorization rule took effect March 31, 2024, under the statutory sale provision cited earlier.
That is a concrete compliance obligation, not evidence of a particular recent lawsuit or settlement. Founders should distinguish published guidance from case-specific enforcement reporting and shouldn’t postpone remediation while waiting for a public action involving a similar product.
What the Compliance Meeting Should Resolve
The meeting should end with owners and implementation decisions, not a general conclusion that the privacy policy needs updating.
- Product owner: Confirm the business activity behind each health-data field and identify optional functions separately from requested-service necessities.
- Design owner: Present collection and sharing choices distinctly, with activity-specific disclosures rather than bundled policy acceptance.
- Engineering owner: Demonstrate the processing gates in operation, including rejected permission, withdrawal, and expired sale authorization.
- Commercial owner: Flag proposed licensing or monetization arrangements before contracts or exports proceed.
- Privacy owner: Review changes to data categories, purposes, and recipients against the existing disclosures and permission records.
The Attorney General’s guidance also identifies a six-year retention duty for both seller and purchaser to keep a copy of a valid sale authorization. That duty concerns the authorization record; teams shouldn’t interpret it as permission to retain or process every underlying dataset indefinitely.
Preserve Evidence Without Confusing It With Permission
A practical evidence package includes the disclosure presented, the consumer’s action, the covered activity, and the executed sale document where applicable. Teams should separately define controls for storing and retrieving those records.
For technical implementation planning, digna’s encryption and audit trail guidance is a supplementary resource. Encryption protects records, and audit trails help teams examine activity, but neither fixes a missing or mismatched permission.
Release criterion: The team should be able to explain why the proposed processing is permitted and demonstrate the control that enforces that answer.
A review of whether a website needs a privacy policy can help organize the disclosure work. The decisive task remains alignment among policy language, consent controls, vendor arrangements, and actual product behavior.
Before a new health-data feature launches, the founder should assign a data-flow audit, require testing of the existing consent tools, and obtain Washington privacy counsel’s review of unresolved classifications. That produces a launch decision grounded in the product’s operations rather than the appearance of its checkbox.
By Design Law Firm & Legal Consultancy, PLLC offers privacy-policy development, compliance-program guidance, and contract support for Washington startups and established businesses. Founders preparing a health-data feature or licensing arrangement can visit By Design Law Firm & Legal Consultancy, PLLC to discuss a data-flow review and consent implementation plan before launch. Contact our law office at (206) 593-1519.
