Washington educational resource

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.

Last legally reviewed: 2026-05-19. Citations verified against Chapter 19.373 RCW. HIPAA references should be confirmed against the current text at 45 CFR Parts 160 and 164 before relying on them in a specific matter.

Coverage scope side by side

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.

How RCW 19.373.100 actually works

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.

The four predictable places HIPAA does not cover but MHMDA does, on mental health SaaS.

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.

Which obligations apply where

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.

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.