The two-layer consent UX MHMDA requires before an AI health tool processes a Washington prompt
RCW 19.373.030 requires affirmative consent for collection and a separate consent for sharing. The two consents must be distinct, unbundled from terms acceptance, and informative enough that a consumer knows what each consent covers. For AI tools, this means the collection consent must be surfaced before the first prompt is processed, and the sharing consent must be a separate UI element with its own disclosure of recipients and purposes. A unified "I accept the privacy policy" checkbox at signup fails the test. Generic CCPA, CPRA, or Connecticut Data Privacy Act consent flows fail too; they were not designed for the two-layer requirement.
The statutory anchor under RCW 19.373.030
RCW 19.373.030 states that a regulated entity may not collect consumer health data except (a) with consent for a specified purpose, or (b) where collection is necessary to provide a requested product or service. It may not share consumer health data except (a) with consent distinct from the collection consent, or (b) where sharing is necessary to provide the requested product or service. The authorization request must disclose data categories, purpose and usage methods, receiving entities, and withdrawal mechanism. Discrimination against consumers who exercise these rights is prohibited.
The seven UX moments where consent has to be designed in
1. Account creation or first session. Before any prompt is processed, the user must see a screen that identifies the product as one that processes consumer health data, describes the categories the AI tool will collect, names the recipients of any sharing, and offers two distinct affirmative actions (collection consent and sharing consent) with the sharing consent unbundled from the collection consent.
2. First prompt that triggers a health-classification. If the first prompt itself triggers a health-status inference (mental-health chatbot, symptom checker), the collection consent must be in place before the prompt is processed. The compliant pattern is to require the collection consent at account creation and gate the first prompt behind it.
3. Wearable or sensor connection. For AI fitness coaches, sleep apps, or any product that pulls sensor data from Apple Health, Google Fit, Garmin Connect, Whoop, Oura, or similar platforms, the collection consent and the sharing consent (if any data is shared back to the wearable account or to coaching partners) must be surfaced before sync begins.
4. Training-data opt-in or opt-out. If the vendor's default contract allows the vendor to use submitted prompts to improve models, the user must be told and offered a separate consent or opt-out. The compliant patterns are: enterprise tier that prohibits training, with the policy stating so; or a per-user training opt-out that is meaningful (default off, separately checked, withdrawal mechanism documented).
5. Analytics SDKs and adtech. If the app loads Mixpanel, Amplitude, GA4, Meta Pixel, or similar SDKs that may observe inferred-health data, the sharing consent must cover the SDK vendors specifically. A blanket "we use analytics" sentence does not satisfy the named-recipients requirement under RCW 19.373.020 that the consent must mirror.
6. Crisis routing or human handoff. For mental-health chatbots, any path that escalates a conversation to a human counselor, hotline, or emergency contact is a sharing event. The consent must cover the handoff path or the handoff must qualify as necessary to provide the requested service.
7. Withdrawal and consumer rights. The withdrawal mechanism must be as accessible as the original consent. RCW 19.373.040 requires confirmation of collection, sharing, or sale; access; withdrawal of consent; deletion with downstream notification; and an appeal with a written decision within 45 days. The UX must surface the withdrawal mechanism (typically in account settings) and the deletion path with a 45-day response window plus one 45-day extension.
What makes a consent invalid
- Single acceptance bundled with terms of service.
- Sharing consent presented as part of the collection consent, not separately.
- Recipients described generically ("third-party AI providers") rather than specifically.
- Service is conditioned on signing consent for sharing that is not necessary to deliver the service.
- No withdrawal mechanism, or withdrawal mechanism is harder to find than the consent.
- Discrimination against consumers who decline a non-essential consent.
What the compliant flow looks like in practice
For a typical AI mental-health chatbot, the compliant flow is approximately: account creation screen with a clear identification of the product as processing consumer health data; a dedicated consent screen with two distinct affirmative actions (collection consent and sharing consent); explicit disclosure of model providers (OpenAI, Anthropic, etc.), analytics SDK vendors, and any human-handoff partners; a separately-checked training-data treatment line (or a vendor-tier statement that no training occurs on user data); a withdrawal screen in account settings that is as accessible as the original consent; and a deletion path that meets the 45-day rights mechanism under RCW 19.373.040.
Sale-of-data is a separate authorization, not a consent
If the AI product sells consumer health data (exchanging it for monetary or other valuable consideration), RCW 19.373.070 requires a written authorization with all nine elements signed by the consumer. Missing any element invalidates the authorization. Most AI products do not sell consumer health data on the statutory definition, but adtech integrations and data-broker relationships can trigger the section. Audit the actual vendor relationships before assuming the section does not apply.
Sergei's practical note
The two-layer consent rule under RCW 19.373.030 is the second-most-missed MHMDA compliance point behind the standalone privacy policy. Most AI products ship with one accept button at signup and assume the bundled acceptance covers everything. It does not. The compliant flow requires two distinct affirmative actions, named recipients, training-data treatment, and a withdrawal mechanism as accessible as the original consent. Send me your current consent UX screenshots and the model-provider contract. The $125 written email evaluation is the right starting point; the $499 scope memo or $1,500 memo plus drafted standalone policy and consent UX language follow if the gaps justify it.
Educational resource. Sergei Tokmakov is a California attorney (CA Bar #279869) currently seeking admission to the Washington State Bar. Nothing on this page creates an attorney-client relationship or is Washington legal advice. Related: MHMDA for AI Health Tools cluster hub; AI health data privacy policy; AI health vendor and processor contracts; AI Health Tool MHMDA Analyzer.