Washington educational resource

Washington Journaling App MHMDA Compliance: Free-Text Is the Highest-Sensitivity Input

Journaling apps look benign next to clinical mental health products, but under MHMDA the sensitivity is higher because the user is invited to disclose mental health status in free-text form. A journal entry that names a diagnosis, references medication, describes treatment-seeking, mentions a therapist, or describes symptoms is consumer health data under RCW 19.373.010. Any AI feature that summarizes, classifies, or extracts sentiment from journal entries generates additional consumer health data through inference. If the product touches Washington consumers and the operator determines the purposes and means of processing, MHMDA applies and HIPAA almost never reaches the product.

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

Why free-text journal entries carry more risk than structured logs

The user disclosure is unfiltered: diagnoses, medications, providers by name, suicidal ideation, substance use, trauma history, sexual orientation, reproductive health, immigration status, custody disputes.
The data is high-volume per user: a 2-minute journal entry contains more identifying mental health detail than ten PHQ-9 scores.
AI features become processor relationships: a "summarize my week" or "find patterns" feature sends the full journal text to a model API. Every API call is a sharing event under RCW 19.373.030 unless the consent and processor posture are MHMDA-compliant.
Search and export features create downstream copies: the journal is now in the analytics index, the AI vector store, and possibly the customer-support tool, all subject to MHMDA deletion under RCW 19.373.040.
Crash logs and session replay can include journal content. Most session replay vendors offer masking, but the masking has to be configured per field and verified.

The AI feature trap on journaling apps. The most common MHMDA gap I see is a "summarize my journal" or "find emotional themes" feature that sends raw journal text to a third-party AI model API without a separate sharing consent and without a Washington addendum to the model provider's DPA. The fix is either (a) collect a separate, specific sharing consent that names the AI provider and discloses the purpose, (b) run the model in your own cloud as a true processor under MHMDA-compliant terms per RCW 19.373.060, or (c) disable the feature for Washington consumers and document the geographic gate.

What MHMDA requires for a journaling app

Separate Consumer Health Data Privacy Policy under RCW 19.373.020 that addresses free-text journal content, AI summarization, sentiment analysis, and any inference outputs.
Two-layer consent at signup under RCW 19.373.030: collection (journal storage) plus a separate sharing consent for AI features, analytics, attribution, and CRM. AI feature consent should be granular per feature.
Operational deletion under RCW 19.373.040 that runs against the journal store, search index, AI vector store, AI fine-tune datasets, analytics warehouse, CRM, support tool, and backups.
Reasonable-care security under RCW 19.373.050, with encryption at rest as a practical baseline for journal content and access restrictions on engineering and support team views.
MHMDA-compliant processor contracts under RCW 19.373.060 with every AI provider and every SDK vendor that receives journal content or derived inferences.
Training-data posture: a clear policy that journal content is not used to train external models without separate opt-in consent. The "we may use customer data to improve our services" language in standard SaaS terms does not satisfy MHMDA.
Sale-of-data authorization under RCW 19.373.070 if journal-derived insights are sold or licensed. All nine elements required.

What to send for a written review

Current privacy policy, Consumer Health Data Privacy Policy if separate, terms of service, and any AI feature description on the marketing site.
Signup and consent screens, AI feature opt-in screens, and the homepage link to the policy on desktop and mobile.
AI architecture: which model provider, hosted vs API, retention, training-data posture, vector store posture, fine-tune posture.
Vendor map: analytics, attribution, session replay, ad pixels, CRM, AI APIs, support tooling, cloud processors, sub-processors.
Current DPA templates and any Washington addendum already in place.
Deletion workflow: which systems are reached, whether deletion is verified, retention windows for backups.

Sergei's practical note

Journaling apps are where the AI processor question gets pointed. Most operators have a model-provider DPA that satisfies GDPR but does not satisfy MHMDA's binding-instructions and reasonable-assistance language under RCW 19.373.060. The fix is either a Washington addendum on top of the existing DPA, a switch to a self-hosted model, or a geographic gate. None of those are hard to implement, but they need to be documented and aligned with the consent flow and the privacy policy. 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.