AI symptom checkers are inside MHMDA the moment they classify a query as health-related
An AI symptom checker accepts a free-text complaint from a consumer ("headache, mild fever, two days") and returns a structured ranking of possible explanations. That output is consumer health data on the inference prong of RCW 19.373.010. The prompt, the model output, the classification metadata, and any session log are all collected consumer health data once the system retains them. If the symptom checker serves Washington consumers, MHMDA's compliance program applies in full: standalone Consumer Health Data Privacy Policy, two-layer consent, processor contracts with the model vendor, and a geofence audit if location or facility-based features are used.
Why the inference prong catches AI symptom checkers
RCW 19.373.010 defines consumer health data as personal information linked or reasonably linkable to a consumer that identifies past, present, or future physical or mental health status, including information derived or extrapolated from non-health information. A symptom checker exists to do exactly that derivation. The prompt may include no clinical record, no diagnosis code, no lab value. The model's job is to read the prompt and infer plausible health states. That inference is consumer health data the moment the system stores it. The stored classification "user asked about chest pain" is consumer health data even if the prompt itself is ambiguous.
The four AI-specific compliance hooks
Standalone privacy policy. RCW 19.373.020 requires a Consumer Health Data Privacy Policy as a distinct document, prominently linked from the homepage in a way that survives mobile collapse. A general SaaS policy that mentions health data in a paragraph does not satisfy the rule. The standalone policy must disclose categories of consumer health data collected and the purpose, sources, sharing, the specific affiliates and third parties with whom data is shared, and the consumer rights mechanism.
Two-layer consent. RCW 19.373.030 requires affirmative consent for collection and a separate consent for sharing. A symptom checker that stores prompts to improve the product, sends prompts to a third-party model API, and uses analytics SDKs is doing three things that may each require their own consent layer. Bundling all of them into one "I accept the privacy policy" checkbox fails on this point.
Processor contract with the model vendor. If the symptom checker calls OpenAI, Anthropic, Azure OpenAI, or any external API, that vendor is a processor under RCW 19.373.060. The vendor's default API terms usually do not satisfy MHMDA's processor-contract requirement on their face. A written DPA addendum or a vendor-published MHMDA-aware addendum is required, with binding instructions, scope-of-processing limits, and the obligation to assist with consumer rights requests and security obligations.
Geofence audit. RCW 19.373.080 prohibits any virtual boundary within 2,000 feet of an in-person healthcare facility used to identify consumers seeking health services, collect consumer health data, or send notifications. AI symptom checkers that integrate with location-based "find a clinic nearby" features need to verify that no ad-platform or analytics SDK is implementing a sub-2,000-foot geofence.
Specific gaps I look for in symptom-checker reviews
- Privacy policy is one combined document, not a standalone Consumer Health Data Privacy Policy.
- Consent is one acceptance, not two; the sharing consent is missing or bundled with the terms of service.
- The API contract with the model provider is the default web-page terms, not a written DPA tuned to consumer health data.
- The vendor's default contract allows the vendor to use submitted prompts for model improvement, and the user is never given a chance to opt out at the application level.
- Analytics SDKs (Mixpanel, Amplitude, GA4) observe prompt text in event payloads.
- "Find a clinic" or "find a doctor" features use a third-party ad-platform geofence whose radius is not audited.
What the per se CPA bridge does to symptom-checker exposure
RCW 19.373.090 converts any MHMDA violation into a per se Washington Consumer Protection Act violation. A Washington consumer who can show a violation does not need to plead public-interest impact under the Hangman Ridge framework; .090 declares it. The remedy is actual damages, discretionary treble damages capped at $25,000 on the enhancement, and one-way attorney's fees to a prevailing plaintiff. The four-year SOL under RCW 19.86.120 applies. A symptom checker that handles thousands of Washington prompts a week with a non-compliant policy or consent UX is generating standing day after day.
Sergei's practical note
If you run an AI symptom checker that accepts free-text prompts from consumers, treat MHMDA as applicable until the data inventory disproves it. The conservative path is the standalone Consumer Health Data Privacy Policy plus the two-layer consent UX plus the written processor addendum, deployed before scale, not after the first AG inquiry. Send me the policy URL, two screenshots of the consent flow, and your model-provider contract. The $125 written email evaluation is the right starting point; the $499, $900, or $1,500 MHMDA memo tiers 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 mental-health chatbot MHMDA compliance; AI health vendor and processor contracts; AI Health Tool MHMDA Analyzer.