OpenAI, Anthropic, and downstream AI APIs are processors under MHMDA. The default API terms usually do not satisfy.
RCW 19.373.060 requires a binding contract between a regulated entity and any processor that handles consumer health data. The contract must set the processing instructions, limit the actions the processor may take, obligate the processor to assist with the regulated entity's obligations, and provide that a processor that strays outside instructions converts into a regulated entity for the data at issue. For AI products, every external API that touches a Washington prompt is a processor: the model provider, the transcription service, the sentiment-analysis service, the human-handoff platform, and the analytics SDK vendor. Standard click-through API terms rarely satisfy the section on their face. A written processor addendum, a vendor MHMDA-aware addendum, or an enterprise-tier contract that meets the requirements is needed.
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
The statutory anchor under RCW 19.373.060
RCW 19.373.060 states that a processor may process consumer health data only pursuant to a binding contract that sets the processing instructions and limits the actions the processor may take. The processor must assist the regulated entity with technical and organizational measures, insofar as possible, in fulfilling the regulated entity's obligations. A processor that fails to adhere to the regulated entity's instructions, or that processes consumer health data outside the contract's scope, is treated as a regulated entity for that data. The result of straying outside the contract is bilateral risk: the processor takes on full MHMDA obligations for the data, and the regulated entity faces a derivative violation.
Five AI vendor categories that need MHMDA-tuned processor contracts
1. Foundation-model providers. OpenAI, Anthropic, Azure OpenAI, Google (Vertex/Gemini), AWS Bedrock, and any inference-as-a-service vendor. The default consumer API tier typically permits the provider to retain submitted data for abuse monitoring and may permit training-data use. The compliant configurations are: an enterprise tier or zero-data-retention addendum that prohibits training and limits retention; or a written addendum tailored to MHMDA that addresses processing instructions, training prohibition, retention limits, and assistance obligations.
2. Transcription and speech-to-text vendors. If an AI mental-health chatbot accepts voice input or an AI fitness coach processes audio commands, the transcription vendor is processing consumer health data on the regulated entity's behalf. The vendor needs a binding contract with the same elements.
3. Sentiment, emotion, or classification vendors. Any specialized API that scores user inputs for sentiment, emotion, or health-related categories is a processor. The classification output is consumer health data, which makes the vendor's processing high-touch.
4. Human-handoff platforms. For mental-health chatbots, the platform that connects users to live counselors or hotlines is a processor (or, depending on the relationship, a third-party recipient triggering the sharing consent). The processor contract must specify what data is transmitted, how it is used, what retention applies, and how consumer rights are honored.
5. Analytics and observability platforms. Mixpanel, Amplitude, GA4, Datadog, Sentry, or any platform that may observe inferred-health data in event payloads is processing consumer health data on the regulated entity's behalf. The standard SaaS DPA typically does not address MHMDA on its face; a custom addendum is often needed.
Eight provisions the MHMDA-tuned processor addendum must include
- Processing instructions: explicit scope, limited to the agreed purposes, with all secondary uses excluded.
- Training prohibition or controlled opt-in: vendor may not use submitted consumer health data to train models unless a separate user-level consent has been obtained and the vendor agrees to honor withdrawal.
- Retention limits: how long the vendor may retain the data, and the deletion path on contract end.
- Sub-processor controls: vendor must identify sub-processors and may not add new sub-processors without notice and a right to object.
- Security obligations: vendor must maintain reasonable industry-standard security measures consistent with RCW 19.373.050.
- Assistance with consumer rights: vendor must support the regulated entity in honoring access, withdrawal, deletion, and appeal requests under RCW 19.373.040 within the 45-day window.
- Conversion clause: explicit acknowledgment that processing outside the contract's scope converts the vendor to a regulated entity for that data, consistent with the statutory rule.
- Breach notification: vendor must notify the regulated entity of security incidents involving consumer health data within a stated window (24 to 72 hours is the typical range).
What I check on the vendor stack in operator-side reviews
- API tier: consumer default, enterprise, or zero-data-retention.
- Training-data treatment: vendor's published policy and any contractual override.
- Sub-processor map: vendor's published sub-processor list, audited against your privacy policy's named recipients.
- DPA and processor addendum: signed, current, and MHMDA-tuned where the vendor has published one.
- Geofence and adtech audits: ad-platform configurations against the 2,000-foot prohibition under RCW 19.373.080.
- Sharing with non-processors: any vendor relationship that is not processor-architecture (vendor uses data for own purposes) is sharing and triggers the separate-consent rule under RCW 19.373.030.
The conversion-to-regulated-entity risk for vendors
The most-overlooked feature of RCW 19.373.060 is its conversion rule. A processor that fails to follow instructions or processes data outside the contract's scope is treated as a regulated entity for that data. This creates a direct MHMDA enforcement pathway against the vendor, separate from the regulated entity's own exposure. Vendors that hold themselves out as MHMDA-aware (zero-data-retention configurations, MHMDA addenda) are responding to this risk. Vendors that have not addressed MHMDA on their public-facing terms are an audit risk for any AI health tool using them as a processor.
The $900 memo tier is built for vendor-stack reviews
The $900 MHMDA memo tier delivers the scope memo plus drafted DPA and vendor-contract language. For AI health products with three or more external APIs in the stack, this tier is usually the right fit. The $1,500 tier adds the drafted standalone Consumer Health Data Privacy Policy. Send me your vendor list, the current DPA template, the model-provider contract or enterprise-tier confirmation, and a brief description of the data flow. The $240 Written Attorney Consultation is the right starting point.
Sergei's practical note
The vendor and processor contract gap is where I expect to find the most exposure on AI health tool reviews. Founders configure the application against the default vendor tier, never read the vendor's published DPA, and assume the click-through terms cover them. RCW 19.373.060 needs a binding contract with named processing instructions and assistance obligations; default click-through terms usually do not satisfy. The conversion rule means a non-compliant vendor stack creates exposure on both sides of the contract.
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
- Send the materials. Email me your current documents, screenshots, and a short description of the product and the Washington consumers it touches.
- I confirm scope and run a conflict check. Engagement begins only after that check and a written confirmation of what is included.
- I draft or review. You get the deliverable with plain-language comments on the highest-risk items first.
- We refine. Reasonable revision rounds are included so the final version fits how your product actually works.
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.
A flat-fee package for digital health and SaaS founders: HIPAA and BAA posture, Terms of Service and privacy policy, and the consumer-health-data layer that MHMDA adds on top. Reviewed under California license; for Washington court representation I coordinate with Washington-admitted counsel.
See the full Healthcare SaaS legal stack → or email me directly for a scoped quote.
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 tool consent flow; AI Health Tool MHMDA Analyzer.