Washington educational resource

Washington Therapy App MHMDA Compliance: HIPAA Overlap and the Pieces That Are Not PHI

Therapy apps are the trickiest MHMDA category because the easy answer ("we are HIPAA-covered, MHMDA does not apply") is almost always wrong. The HIPAA exemption at RCW 19.373.100 is data-specific, not entity-blanket. The licensed clinical session may be PHI; the in-app journal entry, the mood log, the marketing pixel on the public site, and the matching-algorithm inputs usually are not. If you operate a Washington-reaching therapy app, the MHMDA work is to identify which fields sit inside a HIPAA-covered relationship, which do not, and then apply Chapter 19.373 RCW to the latter.

Last legally reviewed: 2026-05-19. Citations verified against Chapter 19.373 RCW. For HIPAA-MHMDA overlap mechanics, see my HIPAA vs MHMDA for Mental Health SaaS.

Three therapy-app architectures and how MHMDA treats them

Architecture A: Licensed-provider platform with full HIPAA business associate posture. The app connects users to licensed therapists who hold the provider relationship. The platform is a HIPAA business associate. Clinical session content (notes, video, asynchronous messages with the clinician about treatment) is PHI in HIPAA transactions. MHMDA still reaches the marketing pixel on the public website, the matching algorithm that infers mental health status from intake answers before any provider relationship exists, the assessment data captured at signup, and any consumer health data shared with vendors outside the BAA.

Architecture B: Coaching or peer-support platform, no clinical relationship. No licensed providers, no HIPAA covered entity. MHMDA reaches everything from intake forward. The HIPAA exemption at RCW 19.373.100 does not help.

Architecture C: Hybrid (some users see licensed clinicians, others use self-guided tools). The hardest category. The PHI carve-out applies only to data inside the HIPAA-covered transaction. Self-guided tool data, in-app journaling, mood logs, and pre-matching assessment data are MHMDA-covered. The product needs separate consent flows and a separate Consumer Health Data Privacy Policy for the MHMDA-covered surface.

The matching algorithm trap. Before any provider relationship exists, the user answers intake questions: diagnosis history, symptom severity, preferred therapy modality, prior medication. The platform uses those answers to match the user to a provider. Until the match converts into a covered transaction, that data is not PHI; it is consumer health data subject to MHMDA. The intake form needs MHMDA-compliant consent. The vendor map needs to confirm none of that data leaks to analytics, attribution, session replay, or an AI matching model under sharing terms that violate RCW 19.373.030.

What MHMDA changes for a therapy app

Separate Consumer Health Data Privacy Policy under RCW 19.373.020 covering the MHMDA-reachable surface. A general privacy policy plus the HIPAA Notice of Privacy Practices is not a substitute.
Two-layer consent at signup under RCW 19.373.030. Collection consent for intake assessment plus a separate sharing consent for analytics, attribution, and AI matching features. Bundled into the "I agree to the Terms" checkbox is insufficient.
Provider portal and asynchronous messaging: the provider-clinician channel is HIPAA-covered; analytics, crash reporting, and any AI summarization of clinician notes need to be inside the BAA or outside the system entirely.
Marketing pixels on the public website: not exempt under RCW 19.373.100. Any "I want help with depression" landing-page conversion that fires a Meta or TikTok pixel is a sharing event for consumer health data.
Operational deletion under RCW 19.373.040. Deletion must actually reach the intake assessment, the AI matching model artifacts, the analytics warehouse, and any vendor that received the data. HIPAA retention rules for PHI inside the clinical record do not block MHMDA deletion of the non-PHI fields.
Geofence audit under RCW 19.373.080: location-based push notifications or ads within 2,000 feet of psychiatric facilities, inpatient programs, or methadone clinics are flat-prohibited.

What to send for a written review

Provider model description: licensed-only, coaching-only, hybrid, with which professional licenses (LCSW, LMFT, PsyD, MD).
Intake assessment screens and the matching-algorithm posture.
Current privacy policy, Consumer Health Data Privacy Policy if separate, HIPAA Notice of Privacy Practices, BAA template.
Vendor map: analytics, attribution, ad pixels, CRM, AI matching or summarization, support tooling, video platform, cloud processors.
Consent UX screenshots and the homepage with the policy link on desktop and mobile.
Brief description: Washington-reaching marketing, AI features, any deletion workflow already operational.

Sergei's practical note

The most common gap I see on therapy apps is the assumption that the HIPAA BAA covers the pre-match intake and the marketing-side pixels. It does not. The HIPAA carve-out at RCW 19.373.100 applies field by field, not entity-wide. The fix is a documented data map, a separate Consumer Health Data Privacy Policy, two-layer consent at signup, MHMDA-compliant processor contracts for the non-PHI vendor surface, and a deletion workflow that actually executes against analytics and the AI matching artifacts. 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.