Washington educational resource

Washington Mood Tracker MHMDA Compliance: When a "Wellness App" Becomes a Regulated Entity

Mood tracker apps are the cleanest case of "we are not HIPAA, so we are fine" being wrong. The product invites the user to log mood, sleep, stress, energy, and often a PHQ-9 or GAD-7 style assessment. Every one of those data points is consumer health data under RCW 19.373.010. The inference engine that scores depression risk or recommends interventions generates additional consumer health data. If the product touches Washington consumers and the operator determines the purposes and means of processing, MHMDA applies and HIPAA does not help.

Last legally reviewed: 2026-05-19. Citations verified against Chapter 19.373 RCW.

What counts as consumer health data on a mood tracker

Mood logs: emoji-scale entries, numeric mood scores, free-text journal entries attached to a mood log.
Symptom checklists: PHQ-9, GAD-7, PCL-5, PSS, and the operator's custom variants.
Sleep markers from in-app entries or wearable integrations: bedtime, wake time, perceived quality.
Energy, stress, focus, irritability, suicidal-ideation flags, and any "how are you today" prompts.
Inferences: depression severity scores, anxiety category, "high risk" flags, recommended interventions, predicted mood next week. The definition reaches inferences expressly.
Cross-device patterns: location signals correlated with mood, screen-time and mood pairs, social-media usage correlated with mental state.

The third-party SDK risk on mood trackers

Mood tracker apps are SDK-heavy by default: analytics (Mixpanel, Amplitude, Segment), attribution (AppsFlyer, Adjust, Branch), session replay (FullStory, LogRocket, Heap), ad pixels (Meta, TikTok, Google Ads), CRM (Customer.io, Iterable, Braze), AI APIs for mood analysis or recommendations, customer support (Intercom, Zendesk). Each one that receives mood log content, assessment scores, or any inference is a sharing event for consumer health data subject to RCW 19.373.030.

The fix is a vendor map, MHMDA-compliant processor contracts under RCW 19.373.060, and either shut off the data flow at the vendor, or collect a separate sharing consent that names the vendor and discloses the purpose, or treat the vendor as a regulated entity for the data at issue. Standard GDPR DPAs and CCPA service-provider agreements usually need a Washington addendum that includes the binding-instructions language and the reasonable-assistance language from RCW 19.373.060.

The PHQ-9 trap. Many mood trackers embed the PHQ-9 because it is well-validated and free to use. The PHQ-9 includes a suicidal-ideation item (question 9). If your app collects PHQ-9 responses and routes them to an analytics vendor (or an AI model that reasons over them) without separate sharing consent, that is consumer health data going outside the entity without MHMDA-compliant consent. The crisis-language path needs a documented exception (necessary to provide a requested product or service or to respond to a threat to life) and a separate consent for sharing with crisis-line partners. The marketing pixel path does not have an exception.

What MHMDA requires for a mood tracker

Separate Consumer Health Data Privacy Policy under RCW 19.373.020, prominently linked from the homepage and the app store description.
Two-layer consent at signup under RCW 19.373.030: collection (mood logs, assessments) plus a separate sharing consent (analytics, attribution, AI features, CRM).
Operational deletion under RCW 19.373.040: deletion must reach the analytics warehouse, the AI model artifacts (vector stores, fine-tune datasets), the CRM, attribution partners, and any sub-processor. A "delete account" button that only flips a soft-delete bit in the primary database is not a compliant deletion workflow.
Reasonable-care security under RCW 19.373.050: access restricted to employees and processors whose access is necessary to further consented purposes.
MHMDA processor contracts with every SDK vendor that receives consumer health data under RCW 19.373.060.
Sale-of-data authorization under RCW 19.373.070 if mood data or any inference is sold or licensed to a researcher, advertiser, or aggregator. All nine elements must be present.
Geofence audit under RCW 19.373.080 if location-based push or ads target users within 2,000 feet of psychiatric facilities, inpatient programs, or treatment centers.

What to send for a written review

Current privacy policy and Consumer Health Data Privacy Policy if separate, plus the app store description text.
Signup screens, consent banners, and any in-app sharing toggles.
Mood log and assessment screens, including which validated instruments you embed (PHQ-9, GAD-7, etc.).
Vendor inventory and current DPA template; if any vendor has a Washington addendum, send that too.
AI feature description: what model, what inputs, retention, training-data posture.
Deletion workflow documentation, including which downstream systems are reached.

Sergei's practical note

Mood trackers usually have a clean MHMDA fix because the data categories are well-defined and the vendor list is finite. The path I take: (1) separate Consumer Health Data Privacy Policy with the five disclosures under RCW 19.373.020 and a prominent homepage link, (2) split the signup consent into collection and sharing per RCW 19.373.030, (3) MHMDA addendum on every SDK vendor's DPA, (4) operational deletion that runs against analytics and AI artifacts, (5) an internal vendor map that documents which fields go where. 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.