What the Consumer Health Data Privacy Policy looks like when the product is an AI tool
The privacy policy required by RCW 19.373.020 is a standalone document, not a section in a general SaaS terms-of-service file. Bundling MHMDA disclosures into a general policy is the most common compliance failure on operator-side reviews. For AI products, the standalone policy must specifically address prompt collection, inferred-health classifications generated by the model, third-party model APIs as recipients, training-data treatment, and the sharing pathways that adtech and analytics SDKs create. This page walks through the structure I use when drafting the standalone policy for AI health tools.
The statutory anchor under RCW 19.373.020
RCW 19.373.020 requires a Consumer Health Data Privacy Policy that clearly and conspicuously discloses categories of consumer health data collected and purpose, sources, categories shared, the specific affiliates and third parties with whom data is shared, and the consumer rights mechanism. The policy must be prominently published with a homepage link. A footer-only link buried behind a hamburger menu on mobile is often inadequate. The policy must match the actual data flows; any inconsistency with processor contracts is treated as a violation under the section's flow-down provisions.
Eight sections every AI health tool's standalone policy must contain
1. Scope statement. Identify the product (e.g., "this Consumer Health Data Privacy Policy applies to [App Name], an AI-powered symptom-triage tool, mental-health chatbot, or fitness coach available to consumers including residents of Washington State"). State that the policy is the Consumer Health Data Privacy Policy required by Chapter 19.373 RCW and that it supplements, not replaces, the general privacy policy.
2. Categories of consumer health data collected. For AI tools, this section is longer than for typical SaaS products. Include: prompt content submitted by the user; conversation transcripts; structured inferences generated by the model (mood classifications, sleep-quality scores, recovery scores, suicidality flags, symptom hypotheses); sensor data ingested from wearables; account profile data linked to health categories; and inferred location data when proximate to healthcare facilities.
3. Purposes of collection. Spell out the AI-specific purposes: generating the response to the user, training the in-house model (if any), improving the third-party model (if the vendor contract permits and the user has consented), product analytics, fraud and abuse prevention, and any clinical-decision-support use. Vague phrasing such as "to improve our services" does not satisfy RCW 19.373.020 on its own.
4. Sources from which consumer health data is collected. Include direct submission by the user (prompts, journaling, mood entries); sensor streams from connected wearables (Apple Health, Google Fit, Garmin Connect, Whoop, Oura); third-party model providers (output classifications); and analytics SDKs.
5. Categories of consumer health data shared. List inputs sent to model providers, outputs returned, transcripts sent to coaching partners or human counselors, and any data shared with analytics SDKs.
6. Specific affiliates and third parties with whom data is shared. RCW 19.373.020 requires the list to be specific. Name OpenAI, Anthropic, Azure OpenAI, the specific analytics SDK vendors, the specific wearable platforms, the specific human-counselor platform, and any other downstream recipient. Generic phrasing such as "third-party AI providers" is the most-flagged compliance gap.
7. Consumer rights mechanism. Explain how the consumer exercises the rights under RCW 19.373.040: confirmation of collection, sharing, or sale; access; withdrawal of consent for collection and for sharing; deletion with downstream notification; appeal; the 45-day response window with one 45-day extension; and the contact channel.
8. Authority and updates. Identify the policy as required by Chapter 19.373 RCW. State the last-modified date. Identify whether the policy is intended for Washington consumers specifically or applies to all users.
AI-specific provisions the standalone policy should add
Inference disclosure. Make explicit that the model generates inferred health states (mood, recovery, symptom hypotheses, suicidality flags), and treat those inferences as consumer health data subject to the policy.
Training-data treatment. State whether prompts and inferences are used for in-house model training, third-party model improvement, both, or neither. If the vendor contract permits training-data use, the policy must say so and must explain the consent and opt-out mechanism. Silence on training is read against the operator.
Vendor disclosure. Name the model providers. Identify whether the vendor tier prohibits training on submitted data. State the retention period the vendor's contract permits.
Crisis routing or human handoff. For mental-health chatbots, disclose any path that escalates a conversation to a human counselor, hotline, or emergency contact, and identify the specific third party.
Geofence disclosure. If the product uses location data, state whether any geofence inside 2,000 feet of a healthcare facility is used; if not (the compliant configuration), say so.
Homepage link requirements
RCW 19.373.020 requires the standalone policy to be prominently published with a homepage link. The acceptable patterns are a dedicated header or page-chrome link visible without scrolling, a footer link that survives mobile collapse and is visible without a hamburger expansion, or a dedicated banner. Burying the link behind a hamburger menu that is not signed as "Health Data Privacy" fails the prominent-link test on most reviews.
Common drafting failures I see
- Policy is bundled with the general privacy policy; no standalone document exists.
- "Third-party AI providers" appears without naming the specific vendors.
- The training-data section is silent; the vendor's default contract permits training.
- The inference clause is not addressed; the policy treats only direct user submissions as health data.
- Consumer rights mechanism is generic CCPA boilerplate, not MHMDA-specific.
- Homepage link is in the footer behind a mobile hamburger expansion and is labeled "Privacy" without distinguishing the health policy.
The drafted policy is part of the $1,500 MHMDA memo tier
I draft the standalone Consumer Health Data Privacy Policy as part of the $1,500 MHMDA memo tier: the memo identifies the gaps, the policy delivers the compliant document tuned to the actual data flows, and the consent UX language is drafted alongside. For the $499 scope memo and $900 memo plus DPA tiers, the drafted policy is delivered separately at the standalone rate. Send me your current policy URL, the consent UX screenshots, and the model-provider contract. The $125 written email evaluation is the right starting point.
Sergei's practical note
The standalone Consumer Health Data Privacy Policy is the most-missed compliance point I see in operator-side reviews of AI health products. Most AI startups already have a general SaaS privacy policy and assume that mentioning health data inside it is enough. RCW 19.373.020 requires the document to be standalone, prominently linked, and substantively complete on the five disclosure categories. For AI products, the policy also has to address inferences, vendors, training-data treatment, and any human-handoff path explicitly. Generic SaaS boilerplate does not satisfy.
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 tool consent flow; AI health vendor and processor contracts; MHMDA Privacy Policy Gap Checker.