HIPAA vs Washington MHMDA for Mental Health SaaS: Where Each Reaches and Where the Exemption Actually Helps
The most common analytical error I see on mental health SaaS is treating the HIPAA / MHMDA question as either-or. It is not. HIPAA reaches covered entities and business associates and is data-specific within that. MHMDA reaches anyone who processes consumer health data of Washington consumers and is also data-specific. The exemption at RCW 19.373.100 is field-by-field, not entity-blanket. A platform can be partially HIPAA-covered for some data fields and fully MHMDA-covered for others, often inside the same database.
Ask my AI Legal Analyst about HIPAA 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. Answers cover the field-by-field exemption, the four surfaces HIPAA misses, and the hybrid posture.
Common HIPAA-vs-MHMDA questions, always free
Key terms?
The HIPAA-MHMDA boundary turns on a handful of defined terms. Tap a card to flip it.
- HIPAA: reaches health plans, healthcare clearinghouses, healthcare providers transmitting health information electronically in HIPAA transactions, and their business associates. Applies to protected health information (PHI) inside the covered relationship. Federal scope.
- MHMDA: reaches any legal entity that conducts business in Washington or targets products or services to Washington consumers and (alone or jointly) determines the purposes and means of collecting, processing, sharing, or selling consumer health data. Washington-state scope, but with extraterritorial reach for out-of-state companies that target Washington consumers.
- HIPAA data scope: PHI defined at 45 CFR 160.103. Tightly bounded to information created or received by a covered entity or business associate related to past, present, or future health, payment, or healthcare operations.
- MHMDA data scope: consumer health data at RCW 19.373.010, including mental health status, mood, symptoms, treatment-seeking, journal entries, and inferences. Broader category than PHI, especially around inferences and non-clinical disclosures.
The MHMDA exemption at RCW 19.373.100 excludes several data categories: PHI under HIPAA (with related data under Ch. 70.02 RCW and 42 CFR Part 2), GLBA financial data, FCRA consumer report data, FERPA education records, public-health activities under 45 CFR 164.512, de-identified data meeting the 45 CFR Part 164 standard, and processing necessary to prevent, detect, or respond to security incidents and fraud. The burden of qualifying for the exemption sits on the entity claiming it. The carve-out is data-specific, not entity-blanket. A hospital is HIPAA-covered for PHI in treatment, payment, and healthcare operations, but its public website advertising pixels on a "find a therapist" page collect data that is not PHI and is not exempt.
- Marketing pixels on the public-facing website. Conversion tracking on "depression help" or "find a therapist" landing pages is consumer health data, not PHI.
- Pre-provider intake and matching. The user discloses diagnosis history, symptoms, and treatment preference before any provider relationship exists. Not PHI yet. MHMDA-covered now.
- Self-guided modules and consumer-facing content inside a platform that also has a clinical arm. The self-guided mood log inside a hybrid product is MHMDA-covered even if the clinician session next to it is PHI.
- AI-derived inferences and aggregated analytics built on top of BAA-covered inputs, where the operator independently determines the purposes and means. The de-identification carve-out helps only if the de-identification standard is actually met and documented.
- Notice of Privacy Practices (HIPAA) covers PHI inside the covered relationship; does not satisfy the MHMDA separate Consumer Health Data Privacy Policy requirement under RCW 19.373.020.
- Authorization (HIPAA) is required for non-treatment-payment-operations uses; does not satisfy MHMDA two-layer consent under RCW 19.373.030 for consumer health data that is not PHI.
- Right of access (HIPAA, 45 CFR 164.524) coexists with the MHMDA right of confirmation and access under RCW 19.373.040. The MHMDA right reaches more data and includes a third-party recipient list.
- Business associate agreement (HIPAA) handles PHI processor relationships; does not substitute for MHMDA processor contracts under RCW 19.373.060 on consumer health data that is not PHI. A Washington addendum or a separate MHMDA processor contract is usually needed.
- HIPAA Security Rule coexists with MHMDA reasonable-care security under RCW 19.373.050. The MHMDA standard includes a consent-tethered access restriction that is more specific than role-based access policies typically deliver.
- Breach notification (HIPAA Breach Notification Rule) coexists with Washington's data breach notification statute at Chapter 19.255 RCW for breaches involving Washington residents.
The practical posture for hybrid mental health SaaS
For products with any non-covered surface, the path I take has four steps. First, build a field-by-field data map that says which fields are PHI inside a covered transaction and which are not. Second, draft a separate Consumer Health Data Privacy Policy under RCW 19.373.020 for the non-PHI surface, prominently linked from the homepage. Third, add MHMDA processor contract language to every vendor DPA that touches the non-PHI surface, layered on top of any existing BAA. Fourth, design a unified rights-handling workflow that satisfies both HIPAA right-of-access and MHMDA confirmation, access, withdrawal, deletion, and appeal under RCW 19.373.040, with documented exceptions where HIPAA retention rules override MHMDA deletion for PHI fields.
What to send for a written review
- Operating-model description with PHI vs non-PHI surface identification.
- Field-by-field data inventory if one exists; if not, a description of the data categories collected and where each is stored.
- Current Notice of Privacy Practices, privacy policy, Consumer Health Data Privacy Policy if separate, BAA template, and any MHMDA addendum.
- Vendor map and current DPAs.
- Marketing-site flows including any analytics, attribution, ad pixels, and conversion events.
- Description of any de-identified data product and the de-identification methodology used.
Sergei's practical note
The shortest version: HIPAA and MHMDA are not alternatives; they apply field by field, not entity-wide. If you have any non-PHI surface (marketing site, pre-provider intake, self-guided modules, aggregated analytics), you have MHMDA work to do even with a clean HIPAA posture. The fix is incremental, not architectural; a field-by-field data map, a separate Consumer Health Data Privacy Policy for the non-PHI surface, MHMDA processor language layered on existing BAAs, and a unified rights workflow that handles both regimes cleanly. I review under California license. This is regulatory advisory work, not Washington representation.
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.
Related: Mental Health SaaS MHMDA hub; Therapy App MHMDA Compliance; Behavioral Health SaaS Privacy Review; Mental Health SaaS MHMDA Gap Checker; Does HIPAA Apply to My Startup; Senior-Living and Sensor-Tech Privacy; Minimum Legal Scope for a Pilot.
Educational resource. Sergei Tokmakov is a California attorney (CA Bar #279869) currently seeking admission to the Washington State Bar. Nothing here creates an attorney-client relationship or is Washington legal advice.