Washington Substance Use App MHMDA Compliance: When 42 CFR Part 2 Helps and When It Does Not
Substance use disorder apps include sobriety trackers, recovery community platforms, peer-support apps, medication-assisted treatment support tools, harm-reduction information apps, and the SUD modules inside broader mental health products. The exemption at RCW 19.373.100 carves out PHI under HIPAA and related data under 42 CFR Part 2 (substance use disorder records from federally assisted programs). That helps clinical-program apps; it does not help consumer-facing SUD products. Confirm the exemption posture against the actual operating model before relying on it.
Three SUD app architectures and the MHMDA posture
Architecture A: Consumer-facing sobriety tracker, no clinical relationship. Examples: day-counter, urge logger, trigger journal, recovery peer chat. No 42 CFR Part 2 program. MHMDA applies to all of the data. The exemption analysis is brief and unhelpful.
Architecture B: SaaS that supports a federally assisted Part 2 program. The operator is a contractor or business associate of a Part 2 program. The data carve-out at RCW 19.373.100 may apply to data inside the Part 2 relationship. MHMDA still reaches the marketing pixels on the public site, the pre-program intake, the recovery community module that sits outside the Part 2 record, and any analytics on those surfaces.
Architecture C: Hybrid SUD platform with clinical and community modules. The hardest category. The Part 2 exemption applies field-by-field, not entity-wide. Self-guided modules, peer community content, in-app journaling, and pre-intake assessments are MHMDA-covered. The product needs separate consent flows and a separate Consumer Health Data Privacy Policy for the MHMDA-covered surface.
MHMDA compliance stack for SUD apps
- Separate Consumer Health Data Privacy Policy under RCW 19.373.020 that clearly describes the SUD data categories, the 42 CFR Part 2 carve-out if it applies, and the data that sits outside the Part 2 relationship.
- Two-layer consent under RCW 19.373.030 at signup. Sharing consent should be granular per vendor category (analytics, attribution, AI features) and should not be bundled with the Part 2 release of information.
- Operational deletion under RCW 19.373.040 with documented handling of any Part 2 retention obligations. Where Part 2 requires retention for a defined period, document the exception in the deletion workflow.
- Reasonable-care security under RCW 19.373.050. Access restrictions on engineering and support team views are especially important on SUD content given employment and custody risk.
- MHMDA-compliant processor contracts under RCW 19.373.060 with every SDK vendor that receives SUD content.
- No marketing pixels firing from URLs that disclose SUD status. Conversion events should be funneled through a server-side mechanism that strips SUD context before any third-party platform sees the request.
- Geofence audit under RCW 19.373.080: methadone clinics, detox centers, inpatient SUD programs, MAT providers, and AA / NA meeting venues are all in-person healthcare facilities for the 2,000-foot prohibition where treatment is provided.
What to send for a written review
- Brief operating-model description: consumer-facing only, Part 2 program support, or hybrid; which licensed providers if any.
- Current privacy policy, Consumer Health Data Privacy Policy if separate, and any Part 2 Notice of Privacy Practices.
- Signup, consent, and intake screens; the homepage with the policy link on desktop and mobile.
- Vendor map: analytics, attribution, session replay, ad pixels, CRM, AI features, customer support tooling.
- AI feature description if any (recommendation engine, peer-matching, content moderation).
- Deletion workflow and any Part 2 retention rules that override deletion.
Sergei's practical note
SUD apps are the category where the 42 CFR Part 2 carve-out at RCW 19.373.100 gets misread most often. The carve-out applies to data inside the Part 2 relationship, not to the operator's whole business. Marketing pixels, pre-intake assessments, peer community content, and any analytics on the public website are MHMDA-covered even when the clinical record is exempt. The fix is the standard MHMDA stack: separate Consumer Health Data Privacy Policy, two-layer consent, MHMDA-compliant processor contracts, operational deletion, and an honest data map that says which fields sit inside the Part 2 carve-out and which do not. I review under California license. This is regulatory advisory work, not Washington representation.
Related: Mental Health SaaS MHMDA hub; HIPAA vs MHMDA for Mental Health SaaS; Mental Health SaaS MHMDA Gap Checker.
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.