Language: 🇺🇸 🇲🇽 🇷🇺
Washington cluster hub

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 . 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.

Sergei Tokmakov, Esq., California attorney
AI Legal Analyst

Ask my AI Legal Analyst about Washington consumer health data and MHMDA?

Tap a question for an instant, free answer (no email needed), or describe your product and the analyst routes you to the right next step.

Common Washington consumer-health-data questions, always free

Loading the AI Legal Analyst...

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 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 on the inference prong.

Eight pages, one compliance map

The five AI-specific compliance hooks under Chapter 19.373 RCW

1. Inferences are consumer health data. 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 . 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. 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. 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 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 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

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 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 $240 Written Attorney Consultation 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.

Payment

Flat fee, paid up front through a secure PayPal checkout, so the budget is fixed before any work starts. The flat fee for the Healthcare SaaS Legal Package is $2,500. There is no hourly meter and no surprise invoice. If a matter is unusually large or turns into extended negotiation, I tell you before any additional work and we agree on scope first.

Delivery

Drafts in 2 to 3 business days, even for complex agreements. I work weekends when a matter needs it and it is engaged. You receive the work product by email in an editable format, with brief written comments explaining the key issues and the reasoning behind the main choices.

Process

Scope

This is attorney-supervised regulatory and document work under my California license: issue spotting, compliance planning, drafting, and review. It is not Washington court representation. For Washington filings, litigation, or any court appearance, I coordinate with Washington-admitted counsel. Nothing here creates an attorney-client relationship until a conflict check clears and an engagement is confirmed in writing.

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.