MHMDA for AI health tools: when an LLM symptom checker, AI mental-health chatbot, or AI fitness coach becomes a regulated entity
If your AI product answers health, wellness, symptom, mental-health, fertility, sleep, or medication questions for Washington users, MHMDA reaches you whether or not the input was a "medical" record. The statute counts inferences as consumer health data. An LLM that takes ordinary prompts and outputs a health-status hypothesis is generating consumer health data on the fly. That alone pulls AI tools into Chapter 19.373 RCW, with the per se Consumer Protection Act bridge under RCW 19.373.090. This hub is the practical compliance map for AI health products: scope, separate privacy policy, two-layer consent, vendor and processor contracts (OpenAI, Anthropic, third-party APIs), training-data exposure, and the geofence prohibition.
The inference problem: why "we are just an AI assistant" does not get you out of MHMDA
The single most-missed point in operator-side reviews of AI health products is that RCW 19.373.010 defines consumer health data as "personal information that is linked or reasonably linkable to a consumer and that identifies the consumer's past, present, or future physical or mental health status," and that definition expressly includes "any information that is derived or extrapolated from non-health information." An LLM that takes a prompt like "I have been feeling tired and anxious for two weeks, what could be going on" and returns a list of plausible explanations is extrapolating health status from non-health input. The output is consumer health data. So is the prompt itself, once the model has classified it as a health query and the system has stored the classification. The product can be a general-purpose chatbot, a customer-service bot that occasionally answers health questions, or an AI fitness coach that infers sleep quality from heart-rate data. All three sit inside RCW 19.373.010 on the inference prong.
Eight pages, one compliance map
- AI symptom checker MHMDA compliance: scope, inference risk, contraindications for direct-to-consumer triage.
- AI mental-health chatbot MHMDA compliance: the highest-risk product category under RCW 19.373.010, including emotional-state inferences.
- AI fitness coach MHMDA compliance: how step, heart-rate, sleep, and recovery inferences cross the consumer-health-data line.
- AI health data privacy policy: the standalone policy required by RCW 19.373.020, rewritten for AI inputs, model usage, training, and third-party APIs.
- AI health tool consent flow: building the two-layer consent regime from RCW 19.373.030 into an actual UX.
- AI health vendor and processor contracts: OpenAI, Anthropic, Azure OpenAI, and downstream AI APIs as processors under RCW 19.373.060.
- AI health startup legal checklist: founder-stage checklist mapped to MHMDA, plus the AI-specific risks investors will ask about.
- AI Health Tool MHMDA Analyzer (interactive calculator).
The five AI-specific compliance hooks under Chapter 19.373 RCW
1. Inferences are consumer health data. RCW 19.373.010 reaches "information that is derived or extrapolated from non-health information." If your model classifies a user query as health-adjacent, generates a probabilistic explanation, or stores the classification as metadata, that output is consumer health data. Generic SaaS posture ("we do not collect health data, we are just a chat product") does not survive the inference prong.
2. Prompts and conversation logs are collected data. Once a user enters a prompt about a symptom, sleep pattern, mood, medication, or fertility question, and the system retains the prompt, that is collection of consumer health data under RCW 19.373.030. Affirmative consent for collection is required before storage, and a separate consent is required for any sharing with third parties.
3. Using prompts for model training is a sharing event with high audit risk. If your provider terms with OpenAI, Anthropic, or another model provider allow the provider to use submitted data to improve models, that arrangement is a sharing of consumer health data. RCW 19.373.030(1)(b) requires a separate consent for sharing, distinct from collection consent. Most consumer SaaS terms do not surface a training opt-out at the user level, which is the compliance gap.
4. Third-party AI APIs are processors. When your application sends a Washington user's prompt to OpenAI, Anthropic, Azure OpenAI, or any external model API, that vendor is processing consumer health data on your behalf. RCW 19.373.060 requires a binding contract that sets the processing instructions, limits permissible actions, and obligates the processor to assist with your obligations. Standard API terms of service usually do not satisfy this on their face; a written DPA addendum or a vendor that publishes an MHMDA-aware addendum is required.
5. Adtech and analytics inside the product are a separate risk surface. If your AI product loads Google Analytics, Meta Pixel, Mixpanel, or any third-party SDK that observes user queries or session metadata, those SDKs may be sharing inferred-health data. The geofence prohibition under RCW 19.373.080 bars any virtual boundary within 2,000 feet of a healthcare facility used to identify consumers seeking health services, collect consumer health data, or send notifications. Adtech configurations that target healthcare-facility radii are categorically off the menu.
Why "we are not HIPAA-covered" is not a defense
HIPAA reaches covered entities (health plans, clearinghouses, providers transmitting health information electronically in HIPAA transactions) and their business associates. Most AI health products sit outside the HIPAA perimeter: they are direct-to-consumer apps, not providers. MHMDA was designed to fill that gap. The exemption at RCW 19.373.100 is data-specific, not entity-blanket. A wellness app that is not HIPAA-covered cannot claim a HIPAA exemption. A telehealth provider that is HIPAA-covered for clinical PHI cannot extend that coverage to marketing pixels on a public landing page.
What I review when an AI health product comes in
- Scope: do you serve Washington users, and does your model output ever amount to a health-status inference under RCW 19.373.010?
- Privacy policy: standalone Consumer Health Data Privacy Policy under RCW 19.373.020, prominently linked from the homepage in a way that survives mobile collapse?
- Consent UX: two affirmative consents under RCW 19.373.030, with the sharing consent distinct from the collection consent?
- Vendor stack: API terms with OpenAI, Anthropic, Azure OpenAI, or any external model provider, plus a written processor addendum under RCW 19.373.060?
- Training-data exposure: does your provider's default contract use submitted data to train models, and is that surfaced to users with a separate sharing consent?
- Analytics and adtech: any SDK that may observe health-adjacent prompts; any campaign geofence inside 2,000 feet of a healthcare facility under RCW 19.373.080.
Sergei's practical note
Most AI founders I review come in convinced that MHMDA does not apply because they are "not a health product." The inference prong of RCW 19.373.010 is what catches them. Once a Washington user types "I have been anxious lately" and the model returns a structured response, the system is processing consumer health data. The fastest way to triage is to run the AI Health Tool MHMDA Analyzer, then send me the privacy policy URL, consent UX screenshots, and your AI provider contract. The $125 written email evaluation is the right starting point; the $499 scope memo, $900 memo plus DPA language, or $1,500 memo plus drafted standalone policy follow if the gaps are material.
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. MHMDA review for AI health products is regulatory advisory work under California license. Related: Washington MHMDA hub; MHMDA Scope Analyzer; Privacy Policy Gap Checker; Washington SaaS Terms Guide.