Washington My Health My Data Act (MHMDA) & AI Scribes: The Clinical Library Playbook for Chief Compliance Officers

• Why MHMDA Changes Everything for AI Medical Scribes — Beyond HIPAA

• What Competitors Miss — The MHMDA Gaps No Other AI Scribe Vendor Addresses

• Scribing.io Clinical Logic — Handling the Seattle OB-GYN MHMDA Scenario

• Technical Reference — ICD-10 Documentation Standards for Sensitive Encounter Types

• Implementation Checklist for Chief Compliance Officers

• See the Dual-Consent + Delete Cascade in Action

TL;DR — What Every Chief Compliance & Privacy Officer Must Know: Washington's My Health My Data Act (MHMDA) is broader than HIPAA. It creates a private right of action for patients over "Consumer Health Data" violations, requires dual, granular opt-in (collection and sharing unbundled), mandates a prominent "Delete My Health Data" control inside any patient-facing AI portal, and enforces a 45-day deletion cascade that must reach every derived data store—including audio buffers, embeddings, vector indexes, LLM inference caches, QA logs, and subprocessor mirrors. Most AI scribe vendors address none of this. Scribing.io ships a Washington-ready compliance stack that does. This playbook explains the law, exposes what competitors miss, walks through a real-world clinical scenario, and maps the ICD-10 documentation standards that intersect with sensitive-data obligations.

Why MHMDA Changes Everything for AI Medical Scribes — Beyond HIPAA

The Washington My Health My Data Act (RCW 19.373), effective March 31, 2024—with small-business provisions phasing through June 2024 and enforcement actions accelerating into 2025–2026—represents the most consequential state health-privacy statute for AI scribe vendors operating in or serving patients located in Washington State. Scribing.io was built to address this statute at the architecture level, not as a policy addendum.

The statute explicitly covers entities that HIPAA does not reach. Any third-party AI vendor processing ambient clinical audio—even if it never touches a covered entity's EHR directly—falls within scope if it handles "consumer health data" of a Washington resident. This includes LLM inference providers, vector database hosts, and QA analytics subprocessors. The Washington Attorney General's enforcement guidance makes clear that the law was drafted to close precisely this gap.

HIPAA vs. MHMDA: A Structural Comparison

The critical takeaway: a vendor can be fully HIPAA-compliant and still face class-action liability under MHMDA. The AMA's enforcement data shows HIPAA fines averaging $1.2M per resolution agreement—but MHMDA's private-action mechanism with treble damages and per-consumer statutory penalties creates exposure orders of magnitude higher for vendors with thousands of patient interactions.

For a deeper examination of how state-level AI laws interact with federal frameworks, see our analysis of California AI Laws, which covers analogous but distinct requirements under the CCPA/CPRA health-data provisions.

What Competitors Miss — The MHMDA Gaps No Other AI Scribe Vendor Addresses

A review of leading competitors' publicly posted Consumer Health Data Privacy Policies (including Nuance/Microsoft DAX Copilot, last updated April 2024, and Abridge, updated January 2025) reveals documents that acknowledge MHMDA's existence but fail to operationalize its most technically demanding requirements. These policies read as corporate privacy notices—not architectural compliance specifications. Below are the four structural gaps that expose every client clinic to litigation.

Gap 1: No Dual, Granular Opt-In Architecture

The MHMDA does not permit a single, bundled consent covering both collection and third-party sharing. It requires:

1. Consent A — Collection: A standalone, affirmative opt-in before any consumer health data is collected (before ambient microphone capture begins).

2. Consent B — Sharing: A separate, unbundled opt-in specifically authorizing transfer to any third-party processor, including external LLM inference endpoints.

Competitor policies reference consent in general terms ("with your consent or as reasonably necessary to complete any transaction") but do not describe, disclose, or implement a two-gate consent flow. A single "I agree" checkbox bundling collection + sharing + LLM routing violates the MHMDA's granularity requirement under RCW 19.373.010(1).

Scribing.io's approach: Our Washington-ready dual-consent UI presents two distinct consent gates at the point of care—one for ambient audio collection, one for any third-party LLM processing—each with plain-language disclosures specifying data categories, named third parties, and processing purpose. Both consents are revocable independently, with revocation propagating in real time to halt downstream data flows.

Gap 2: No Verifiable Deletion Cascade

Competitor policies state that consumers may "request to exercise" deletion rights and point to a generic OneTrust or privacy-center web form. None disclose:

• What constitutes "deletion" across derived data stores

• Whether deletion extends to raw audio buffers (WAV/FLAC shards in temporary processing queues)

• Whether ASR artifacts—intermediate transcription lattices, confidence scores, speaker-diarization metadata—are purged

• Whether embeddings and vector indexes (used for retrieval-augmented generation) are removed or merely soft-deleted

• Whether prompt/inference caches at the LLM layer are flushed

• Whether QA/debug logs containing verbatim audio excerpts or transcript snippets are included

• Whether subprocessor mirrors (copies at downstream cloud providers, analytics vendors, or EHR integration endpoints) are subject to the same timeline

• What verification mechanism confirms deletion is complete

Under the MHMDA, deletion must be meaningful and complete. A vendor that removes a transcript but leaves searchable embeddings or audio shards in QA storage has not fulfilled its deletion obligation—and is exposed to private litigation. The NIH's 2023 analysis of health-data deletion challenges confirms that vector embeddings retain sufficient semantic content to reconstruct sensitive clinical details, making their retention functionally equivalent to retaining the source data.

Scribing.io's approach: A single "Delete My Health Data" button inside the patient portal—prominently placed, not buried in a settings submenu—initiates a 45-day deletion cascade via signed purge webhooks to: internal audio/transcript storage, ASR artifact stores, embedding/vector databases (hard-delete via index-level removal, not tombstoning), LLM prompt and inference caches, QA and debug log repositories, EHR integration endpoints (Epic/Cerner), and all contracted subprocessors with MHMDA-compliant DPAs. Each subprocessor must return a cryptographically signed acknowledgment within its SLA window.

Upon cascade completion, the system generates a signed audit certificate containing: request ID, data categories purged, per-store confirmation timestamps, subprocessor acknowledgments, and a DPA-aligned job ledger hash. This certificate is delivered to the patient and retained for compliance records. See our Safety & Privacy Guide for the full technical architecture.

Gap 3: The 2,000-Foot Geofencing Prohibition — Completely Absent

This is the provision most overlooked across the industry. RCW 19.373.030 prohibits any person from implementing a geofence within 2,000 feet of a healthcare facility to "identify or track consumers seeking health care services" or to "collect consumer health data from consumers near the entity."

For AI scribe portals, this means that any analytics pixels, advertising trackers, session-replay scripts, or behavioral telemetry tags that fire when a clinician or patient accesses the portal from within a care site constitute a potential geofencing violation if those tools could identify or infer health-service-seeking behavior.

Competitor portals routinely load Google Analytics 4, Hotjar, FullStory, Segment, and advertising pixels. Their products (DAX Copilot, Dragon Medical) are used almost exclusively inside healthcare facilities. If any third-party analytics or telemetry SDK loads when a clinician opens the tool within a hospital or clinic, the vendor is potentially in violation. No competitor policy reviewed addresses this.

Scribing.io's approach: Our portal performs real-time location inference (IP geolocation cross-referenced against CMS's Provider of Services file + optional device-GPS with consent) and auto-suppresses all non-essential analytics pixels, ad trackers, and session-replay scripts when the access point falls within 2,000 feet of a registered care site. Suppression events are logged and auditable.

Gap 4: Processor DPA Requirements — No Disclosure of Retention Limits

The MHMDA imposes specific obligations on "processors" (entities processing consumer health data on behalf of a "regulated entity"). Processor agreements must include:

• Explicit retention limits (not open-ended "as long as necessary")

• Documented processing instructions from the controller

• A duty to assist the controller in fulfilling deletion and access requests within statutory timelines

Competitor policies reference "service providers" and "processors" generically but do not disclose whether their processor DPAs contain MHMDA-specific retention limits or documented-instruction clauses. For Chief Compliance Officers negotiating BAAs and DPAs, this is a critical due-diligence gap.

Scribing.io's approach: Every subprocessor DPA in our vendor chain includes MHMDA-specific clauses: enumerated retention ceilings (by data category—audio: 72 hours post-processing unless consent retained; transcripts: session duration + 30 days; embeddings: 0 days post-deletion request), documented processing instructions, deletion-cascade obligations with SLA-bound response windows (24 hours for acknowledgment, 30 days for completion), and audit-right provisions.

Scribing.io Clinical Logic — Handling the Seattle OB-GYN MHMDA Scenario

Scenario: A Seattle OB-GYN clinic deploys an AI scribe that records exams and forwards audio to an external LLM using a single, bundled consent. A patient later clicks the portal's privacy link to request deletion; the vendor removes the transcript but leaves audio shards in QA logs and embeddings still searchable. Eight weeks later, the patient's attorney files an MHMDA action after an authenticated request reveals ongoing retention and undisclosed sharing, triggering an AG inquiry and class-action risk.

This is not a hypothetical. The intersection of sensitive reproductive health data (see ICD-10 codes below), Washington's political and legal environment around health privacy post-Dobbs, and the technical complexity of modern AI pipelines makes this the highest-probability compliance failure pattern for AI scribes in 2025–2026. The JAMA analysis of post-Dobbs data-privacy risks specifically identifies ambient clinical documentation systems as a vector for reproductive health data exposure.

How a Non-Compliant Vendor Fails: Step-by-Step

How Scribing.io Prevents Every Failure Point

With Scribing.io, the Seattle OB-GYN scenario resolves cleanly: dual consent gates collection vs. sharing at the point of care; geofenced trackers auto-disable inside the clinic; and a one-click Washington "Delete My Health Data" button initiates a verifiable 45-day deletion cascade—audio, transcripts, embeddings, LLM caches, and EHR attachments are hard-deleted across subprocessors—returning a signed audit certificate and DPA-aligned job ledger to close the loop before any attorney has standing to file.

For additional context on how HIPAA's 2026 regulatory updates interact with state deletion rights, see our HIPAA 2026 Update.

Technical Reference — ICD-10 Documentation Standards for Sensitive Encounter Types

The MHMDA's broad definition of "consumer health data" encompasses any information that identifies or could reasonably be linked to a consumer and relates to health conditions, health status, or reproductive/sexual health. This makes ICD-10 code specificity a dual compliance concern: insufficient specificity causes claim denials, while the presence of certain codes in AI-scribed notes triggers heightened MHMDA obligations around consent, sharing, and deletion.

Sensitive OB-GYN Encounter Codes

The following codes represent encounter types where MHMDA obligations are most acute—and where documentation specificity directly impacts both reimbursement and privacy compliance:

Z32.01 - Encounter for pregnancy test — This code requires specificity to the "result positive" qualifier. Ambient AI scribes frequently under-document this encounter by defaulting to the non-specific Z32.0 parent code, which does not distinguish between positive and negative results. The distinction matters clinically (it triggers the prenatal care pathway) and legally (a positive pregnancy test result is explicitly "reproductive or sexual health information" under MHMDA § 19.373.005(4), elevating consent and deletion obligations). Scribing.io's clinical NLP pipeline detects pregnancy-test-positive language patterns in clinician dictation and auto-suggests the maximum-specificity Z32.01 code with the "result positive" qualifier, flagging the encounter for enhanced MHMDA consent verification.

result positive; Z11.3 - Screening for infections with a predominantly sexual mode of transmission — This screening code covers STI panels (chlamydia, gonorrhea, syphilis, HIV screening in asymptomatic patients). Documentation failures here are rampant: clinicians often dictate "STI screen ordered" without specifying which infections are being screened, forcing coders to use the less-specific Z11.3 parent rather than drilling to Z11.3 with appropriate secondary codes (B97.35 for HIV, A56.x for chlamydia, etc.). Scribing.io's ambient capture identifies specific infection-screening language and maps to the most specific applicable code, while simultaneously flagging the encounter as containing "sexual health information" under MHMDA—triggering the dual-consent verification and ensuring the patient's deletion rights are prominently surfaced.

How Scribing.io Ensures Maximum Specificity

The relationship between ICD-10 specificity and MHMDA compliance is bidirectional: more specific codes enable better clinical care and reimbursement, but they also more precisely identify the nature of sensitive health information—which in turn determines the rigor of consent, sharing, and deletion obligations. Scribing.io treats these as a unified compliance surface rather than siloed functions.

Implementation Checklist for Chief Compliance Officers

Use this checklist when evaluating any AI scribe vendor for Washington MHMDA compliance. Each item maps to a specific statutory provision.

Red Flags in Vendor Evaluation

• Single consent checkbox covering both collection and LLM sharing — immediate MHMDA violation

• Generic OneTrust form as the sole deletion mechanism with no disclosure of cascade scope — insufficient

• No mention of audio buffer or embedding deletion in privacy policy — retention of derived data

• "Aggregate/de-identified" carve-out without methodology disclosure — MHMDA's de-identification standard is stricter than HIPAA Safe Harbor; vendor must demonstrate the data "cannot reasonably be linked" to a consumer

• Third-party analytics pixels loading inside clinical portal — potential geofencing violation at every care site

• Open-ended retention language ("as long as necessary for business purposes") — violates MHMDA processor obligations

See the Dual-Consent + Delete Cascade in Action

See our Washington MHMDA Dual-Consent + Delete Cascade in action—Epic/Cerner hard-delete, vector DB and LLM cache purge proofs, and a downloadable 45-day compliance certificate from a single request.

Schedule a compliance-focused demonstration at Scribing.io where we will:

1. Walk through the dual-consent UI with your compliance team—show both gates, the named-vendor disclosure, and the independent revocation flow

2. Trigger a live deletion cascade against a test patient record and show real-time webhook delivery to Epic sandbox, vector DB, and LLM cache endpoints

3. Generate and deliver a signed audit certificate with full DPA-aligned job ledger

4. Demonstrate geofence-aware tracker suppression from a simulated care-site IP address

5. Show the sensitive-code detection layer triggering enhanced consent verification on Z32.01 and Z11.3 encounters

Washington's MHMDA private right of action means your patients don't need to file an OCR complaint and wait years for resolution. They can sue tomorrow. The 45-day deletion clock is already ticking on every ambient recording your current vendor has collected without proper dual consent. The question is not whether to comply—it is whether your current vendor can comply. If the answer requires architectural changes they haven't shipped, you are carrying unquantified class-action risk on every patient encounter.

Scribing.io was built for this statute. Not retrofitted. Not patched with a policy update. Built.