Beyond HIPAA: State Consumer Health Privacy Laws and What They Mean for Clinical Dental AI

Where does a patient's first description of a cracked molar actually land? In most dental practices running AI at the front desk, it lands in a vendor's transcript store, a vector index, and a call-analytics dashboard long before anyone opens a chart in Dentrix, Eaglesoft, or Open Dental.

That sequencing matters because HIPAA is no longer the only privacy regime that reaches health data. Washington's My Health My Data Act, Nevada's SB 370, and Connecticut's consumer health data amendments all regulate health information that falls outside HIPAA's definition of protected health information — and the pre-PMS layer is exactly where that gap opens.

This piece is written for the operators who own those pipelines: practice-group IT leads, DSO compliance officers, and the platform teams who sign vendor contracts. It is not legal advice, and any data-flow decision described below should go through counsel licensed in the states where your patients live.

Why HIPAA Compliance Does Not End the Conversation

HIPAA regulates covered entities and their business associates, and it protects a defined category of data: individually identifiable health information that those entities create, receive, maintain, or transmit. If you have read our breakdown of HIPAA requirements for clinical dental AI, you know how much of the compliance burden sits on the BAA and the minimum-necessary standard.

That said, the state consumer health laws were written specifically to cover health data held by everyone else. Washington's HIPAA exemption, for instance, is data-level rather than entity-level — a dental group that is a covered entity can still hold, or cause a vendor to hold, consumer health data that the state statute governs.

The practical consequence is that "we have a BAA" answers one question and leaves a second one open. Which of the vendor's data stores contain information it holds on your behalf, and which contain information it holds for itself?

What Washington's My Health My Data Act Actually Covers

The My Health My Data Act, codified at RCW 19.373, took effect on March 31, 2024 for most regulated entities and on June 30, 2024 for small businesses. Unlike most state privacy statutes, it carries no revenue or volume threshold — any entity that conducts business in Washington or targets Washington consumers, and that determines the purpose and means of processing consumer health data, is in scope.

The definition of consumer health data is deliberately broad. It covers personal information linked or reasonably linkable to a consumer that identifies their past, present, or future physical or mental health status.

The statute's enumerated categories include but are not limited to:

• Health conditions, treatment, and symptoms. Individual health conditions, treatments, diseases, or diagnoses, along with bodily functions, vital signs, and symptoms. A caller describing jaw pain and facial swelling fits squarely here.
• Biometric data. Voiceprints and facial geometry are both covered. An AI phone agent that builds speaker embeddings for caller recognition should assume it is processing biometric data under the Act.
• Precise location tied to care. Location data that could reasonably indicate a consumer's attempt to acquire or receive health services is covered. A mobile check-in feature that fires when a patient enters the parking lot belongs in this category.
• Inferences. Information derived or extrapolated from nonhealth information, including inferences produced by algorithms or machine learning, is covered. This is the clause that should concern AI vendors most.

Taken together, these categories mean that a model output — an urgency score, a predicted procedure, a "likely periodontal patient" tag — can itself be consumer health data, even when the input was only a booking time and a ZIP code. Accordingly, the inference layer of your stack belongs in the data map alongside the raw transcripts.

Consent, Sharing, and Sale

The Act requires consent for collection and a separate consent for sharing, except where collection is necessary to provide a product or service the consumer requested. Consent must be opt-in and specific, and it cannot be obtained through general terms of use, a hover action, or a deceptive design pattern.

Selling consumer health data requires a signed valid authorization that expires after one year. Moreover, the Act makes it unlawful for any person to implement a geofence within 2,000 feet of a facility that provides in-person health care services for the purpose of identifying or tracking consumers, collecting consumer health data, or sending health-related messages or ads.

Rights and Enforcement

Consumers have the right to confirm whether an entity holds their health data, to access it along with a list of the third parties and affiliates that received it, to withdraw consent, and to request deletion. Regulated entities must respond within 45 days, with one additional 45-day extension where reasonably necessary.

A deletion request reaches further than most engineering teams expect. It covers archived and backup systems — deletion from those systems may be delayed by up to six months — and the regulated entity must notify every processor and third party that received the data.

Finally, a violation of the Act is treated as an unfair or deceptive practice under Washington's Consumer Protection Act. That gives consumers a private right of action with actual damages that a court may treble up to $25,000 plus attorney's fees, and the first class action under the statute was filed against Amazon in early 2025.

Where Dental AI Data Lives Before It Reaches the PMS

Most dental AI deployments create data upstream of the practice management system. The PMS is where data becomes a chart; everything before it is intake, triage, marketing, and analytics — and that is where state-law exposure concentrates.

Here's how the common pre-PMS surfaces map to the question of whether the data is PHI:

• AI voice receptionists. A prospective patient calls, describes a broken crown, and the agent books a slot. The recording, transcript, and extracted symptoms are PHI if the vendor collects them on behalf of a covered-entity practice under a BAA, but the same data falls outside that protection the moment the vendor reuses it for its own model training or benchmarking.
• Website chat and intake widgets. A visitor on an unauthenticated page asks whether an implant is right for them. In June 2024, a federal court in American Hospital Association v. Becerra vacated part of HHS's online tracking guidance, narrowing which unauthenticated-page data counts as PHI — and data HIPAA does not reach is the data state laws were written to catch.
• Scheduling widgets with a "reason for visit" field. "Bleeding gums" in a free-text field, paired with an email address, is consumer health data under Washington's definition if it is not PHI. If the widget fires an analytics or ad pixel on submission, the separate sharing consent applies as well.
• Recall and reactivation scoring. A model that ranks lapsed patients by likelihood of needing scaling and root planing generates an inference. If that score is exported to a marketing platform outside the BAA, the inference clause does the work.

All of these surfaces share one property: the vendor makes architectural decisions about storage, retention, and secondary use that the practice rarely sees. This is why the contract and the data map matter more than the vendor's security page.

Three Gaps Where HIPAA Stops and State Law Starts

In practice, the exposure clusters in three patterns. Each one is common, and each one is easy to miss in a standard vendor review.

Gap One — The Vendor's Own Use

Many AI vendors' terms reserve the right to use "de-identified" or "aggregated" customer data to improve their models. If that de-identification does not meet HIPAA's Safe Harbor or Expert Determination standards — covered in depth in our guide to PHI de-identification for clinical AI — the data may be neither exempt as PHI nor properly de-identified under state law.

Keep in mind that under MHMDA, a processor that handles data outside the scope of its contract becomes a regulated entity for that data. The vendor then inherits the consent, rights, and deletion obligations, while the practice inherits the reputational fallout.

Gap Two — The Non-Covered Practice

Not every dental practice is a HIPAA covered entity. A provider becomes one by conducting standard electronic transactions such as claims or eligibility checks, so a fee-for-service cosmetic or membership-plan practice that never bills insurance electronically, directly or through a billing company, may sit outside HIPAA entirely.

For those practices, every piece of patient health data the AI vendor touches is potentially consumer health data under state law. Additionally, the HIPAA exemption in the state statutes offers no shelter, because there is no PHI to exempt.

Gap Three — The Marketing Stack

Ad pixels, call-tracking numbers, and retargeting audiences were the pattern behind the FTC's 2023 actions against GoodRx and BetterHelp. A call-tracking vendor that tags a call as "emergency extraction inquiry" and passes that tag to Google Ads or Meta is sharing an inference about a health condition, and a BAA with the AI receptionist vendor does nothing for the call-tracking vendor.

What's more, Washington's geofencing prohibition applies to any person, not just the practice. An agency running location-based ads around your offices is the party implementing the geofence, but the campaign carries your name.

How Washington, Nevada, and Connecticut Compare

Washington's law is the strictest of the three, but it is not the only one a multi-state DSO needs to track. The comparison below covers the provisions that most directly affect AI vendor architecture.

Beyond these three, the direction of travel is consistent. California's CCPA treats health information as sensitive personal information, and several comprehensive state privacy laws, including those in Virginia and Colorado, require opt-in consent before processing health data.

A DSO with locations across the Pacific Northwest and Mountain West should assume the strictest regime applies to its pre-PMS layer and build once. Remember that Washington's law follows the consumer, so an Idaho or Oregon practice near the border that serves Washington residents is not automatically out of scope.

What Steps Should a Dental Group Take Now?

The work is mostly mapping and contracting, not new technology. Here's a list of the steps we recommend for any group with patients in Washington, Nevada, or Connecticut:

1. Map every pre-PMS data store. For each AI vendor, list where recordings, transcripts, chat logs, embeddings, and model outputs live, along with retention periods. Include the analytics and ad platforms those surfaces feed.
2. Classify each store as PHI or not. Data collected on the practice's behalf under a BAA is PHI. Data the vendor holds for its own purposes, or that flows to a third party without a BAA, needs a state-law review.
3. Amend vendor contracts. Pair the BAA with a consumer health data addendum that limits processing to your instructions, prohibits training on your data without separate written consent, and requires the vendor to propagate deletion requests within a fixed window. Our checklist for evaluating SOC 2 reports from clinical AI vendors covers the audit side of the same review.
4. Capture consent where collection begins. An AI voice agent can read a short disclosure and log the caller's affirmative response with a timestamp and call ID, using the same pattern as AI informed consent in dental care. A web chat widget can require an unchecked opt-in before the first free-text field.
5. Publish a consumer health data privacy policy. MHMDA requires a separate policy with a prominent link on the homepage. It should name the categories of data collected, the purposes, and the third parties that receive it.
6. Audit the marketing stack. Remove health-condition tags from pixels and call-tracking integrations. Then confirm that no agency runs location-based campaigns inside the geofence buffers.

All of these steps produce artifacts — a data map, contract language, consent logs, a published policy — that you can hand to an auditor or opposing counsel. That paper trail is the actual deliverable.

Why Deletion Is the Hardest Requirement for AI Systems

Deleting a row from Postgres is easy. Deleting a consumer's health data from an AI system means finding it in raw audio in S3, transcripts in DynamoDB, chunks in a Pinecone or pgvector index, evaluation datasets, prompt logs in CloudWatch, and any fine-tuned model weights that saw it.

Embeddings are the most common blind spot. If a call transcript was chunked and embedded for retrieval, each chunk needs a stable consumer identifier in its metadata so a deletion job can find and remove it — a design choice we discuss in our post on vector databases for clinical AI.

Fine-tuned weights are harder still, because there is no reliable way to surgically remove one person's contribution from a trained model. As a result, the defensible position is to never fine-tune on data that could be subject to a deletion request, or to retrain on a schedule from a dataset that honors deletions — and to document which one you chose.

The deletion workflow should also share plumbing with consent withdrawal. If you already run patient opt-out tracking across AI touchpoints, extend that ledger to carry deletion requests, the 45-day clock, and confirmation receipts from each processor.

How Breach and Incident Response Change

A security incident in the pre-PMS layer may trigger two notification regimes at once. HIPAA's Breach Notification Rule governs the PHI, while Washington's general breach statute, RCW 19.255, covers personal information that includes medical information held outside HIPAA.

Therefore, the incident runbook needs to know which store is which before the incident, not after. Our walkthrough of breach notification for clinical AI systems covers the timelines on the HIPAA side.

Note that the classification work from the data map pays off here as well. A store already tagged as PHI, state-regulated, or both lets the response team start the right clocks in the first hour instead of the first week.

Getting a Second Set of Eyes on Your Data Map

State consumer health privacy laws do not replace HIPAA, but they do close the gap that most dental AI deployments leave open upstream of the PMS. The groups that handle it well treat the pre-PMS layer as its own regulated system, with its own map, contracts, and deletion path.

If you are deploying AI voice, chat, or intake tools across practices with patients in Washington, Nevada, or Connecticut, the NexV team builds and operates HIPAA-grade clinical AI designed around these boundaries. Reach out for a working session — we will map your pre-PMS data flows, flag which stores fall outside your BAAs, and leave you with contract and deletion requirements you can take to counsel.