Does HIPAA compliance satisfy the My Health My Data Act?

The two laws cover different populations, and treating one as satisfying the other is a common and costly assumption. HIPAA applies to covered entities and business associates handling protected health information. MHMDA reaches any regulated entity conducting business in Washington or targeting Washington consumers, which pulls in wellness apps, retailers, advertising technology and consumer platforms that have no HIPAA relationship at all. The consumer health data definition also captures health status that is "reasonably linkable" and inferred, which is broader than the identifiers HIPAA enumerates. RCW 19.373.100 contains exemptions, and mapping those against a HIPAA posture is legal work rather than an inherited pass.

Is sending a prompt to an LLM provider a "share" under the Act?

Treat it as one until legal tells you otherwise. Sharing under the chapter covers disclosure of consumer health data to a third party, and an external model endpoint operated by another company is a third party receiving the payload. The statute's requirement that sharing consent be separate and distinct from collection consent, and that it disclose the categories of entities receiving the data, maps directly onto naming model providers as a recipient category. Deployments that route prompts through an inference provider under a general privacy policy are the ones most exposed on this point.

What compliance date applies to us?

Regulated entities came under RCW 19.373.030 beginning March 31, 2024. Small businesses, as defined by the consumer-count and revenue thresholds in RCW 19.373.010, must comply with that section beginning June 30, 2024. Both dates have passed, so the practical question for any organization reading this in 2026 is not when the obligation starts but whether the evidence exists to show it has been met since then. That evidence question is where AI deployments built after those dates tend to have gaps.

How do we prove a prompt containing health data was blocked?

The proof is a per-decision record written by something other than the application that made the request. It should carry the identity that originated the request, the classification applied to the prompt content, the consent state consulted, the policy that evaluated it, the outcome, the intended destination, and the timestamp. A record with those fields answers the question a regulator or a plaintiff asks, which is whether the data left. An application log that says the request was handled answers a different and less useful question.

Do vector embeddings of health content count as consumer health data?

Assume yes for planning purposes. An embedding derived from a consumer's health text remains linked or reasonably linkable to that consumer where the index retains an identifier, and it identifies health status by construction, since that is what makes it useful for retrieval. The practical consequence lands on the deletion path under RCW 19.373.040: a deletion workflow has to reach the vector store and the prompt logs, not just the primary record. Teams that built retrieval systems before mapping this obligation usually find the index has no deletion path at all.

Where does an enforcement layer stop being the answer?

At every point where the duty is a human or legal act. Obtaining a consumer's freely given, specific, informed, opt-in agreement is a product and legal exercise. Classifying the entity, writing processor terms, deciding whether an arrangement constitutes a sale for valuable consideration, and complying with geofence restrictions all sit outside the model boundary. What the boundary contributes is the enforcement of decisions already made and the evidence that they held, on the specific path where consumer health data moves toward a model.

← Blog

August 14, 2026

Washington My Health My Data Act AI Controls Mapping: Trigger, Owner, Test and Evidence

Washington''s My Health My Data Act separates collection consent from sharing consent, and sending consumer health data to an external model provider is a sharing event. This mapping connects RCW 19.373 duties for scope, privacy policy, dual consent, consumer rights, security practices, processors, authorization to sell and geofencing to accountable owners, implementation points, tests and evidence. Coverage is graded at the authenticated HTTP model boundary, with legal classification and consent capture kept outside it.

ByParminder Singh· Founder & CEO, DeepInspect Inc.

Compliance & Regulationcomplianceregulationai-complianceai-governancepolicy-enforcementaudit

Washington My Health My Data Act AI Controls Mapping: Trigger, Owner, Test and Evidence

Washington's My Health My Data Act splits consent in two, and the second half is the one AI deployments miss. Under RCW 19.373.030, a regulated entity may not collect consumer health data without consent for a specified purpose, and may not share it except "with consent from the consumer for such sharing that is separate and distinct from the consent obtained to collect consumer health data."

Sending a prompt containing consumer health data to an external model provider is a disclosure to a third party. A single blanket privacy consent captured at signup does not carry it.

This mapping uses the current primary text of chapter 19.373 RCW, enacted as 2023 c 191. Obligations under RCW 19.373.030 began March 31, 2024 for regulated entities, and small businesses "must comply with this section beginning June 30, 2024." I map objective, owner, implementation, test, evidence and gateway coverage for each control.

Scope and entity-classification control

The objective is to establish whether the organization is a regulated entity, a small business, or out of scope, before any technical rule is written. RCW 19.373.010 defines a regulated entity as any legal entity that conducts business in Washington or produces or provides products or services targeted to Washington consumers, and that alone or jointly determines the purpose and means of collecting, processing, sharing, or selling consumer health data.

The small business classification carries the later June 30, 2024 date and turns on volume. It applies to an entity that collects, processes, sells, or shares consumer health data of fewer than 100,000 consumers during a calendar year, or that derives less than 50 percent of gross revenue from those activities and handles fewer than 25,000 consumers.

The classification belongs to legal, with data engineering supplying the consumer counts that feed it. A useful test reproduces the calendar-year consumer count from source systems and confirms it crosses or clears the 100,000 line. Keep the count query, its run date, the revenue attribution, and legal sign-off on the resulting classification as the evidence set.

Gateway coverage is outside scope. Runtime request volumes provide an input to the count, and the classification decision stays with legal.

Data-identification control

The definition drives everything downstream and it is wider than most teams assume. RCW 19.373.010 defines consumer health data as "personal information that is linked or reasonably linkable to a consumer and that identifies the consumer's past, present, or future physical or mental health status." That sweep covers inference and future status, so a wellness score, a symptom description typed into a support chat, or a fertility-tracking entry all qualify without a clinician anywhere in the picture.

The objective is to detect consumer health data in prompt content at the moment it moves, rather than at the document level after the fact. Data governance owns the classifier definitions. The AI platform team owns where they run.

Test with a seeded corpus: symptom free-text, medication names, appointment context, and health-inference signals such as a purchase history implying a condition. Confirm each is flagged in a prompt payload before the request leaves the boundary. Evidence includes the classifier version, the seeded test set, the detection results, and the false-negative rate.

Gateway coverage is direct here, because classification of prompt content at the AI request boundary is the enforcement point, and the wider practice is covered in AI data classification.

Collection-consent control

RCW 19.373.030(1)(a) permits collection only with consent for a specified purpose, or "to the extent necessary to provide a product or service that the consumer to whom such consumer health data relates has requested." Consent is defined in RCW 19.373.010 as "a clear affirmative act that signifies a consumer's freely given, specific, informed, opt-in, voluntary, and unambiguous agreement."

Ownership splits between product, which holds the consent interface, and legal, which holds the specified-purpose wording. To test it, attempt a collection path with consent absent and confirm the path refuses. The consent record with its timestamp, the purpose string presented, and the interface version make up the evidence.

No gateway coverage here. Consent capture happens in the product surface, and no proxy can manufacture a consumer's affirmative act.

Sharing-consent control

This is the control that AI deployments break, and it deserves its own line in the register rather than a footnote under collection.

The statute requires sharing consent "separate and distinct" from collection consent, and requires the request for consent to clearly and conspicuously disclose the categories of consumer health data shared, the purpose including the specific ways it will be used, the categories of entities it is shared with, and how the consumer can withdraw consent. An external model endpoint is a category of entity. A support workflow that pastes a customer's described symptoms into a third-party LLM to draft a reply is a sharing event that needs its own consent, its own disclosure of the recipient category, and its own withdrawal path.

Legal drafts the disclosure text while the AI platform team runs the enforcement point. The test that matters: send a request carrying flagged consumer health data toward an external model endpoint under an identity whose sharing consent is absent or withdrawn, and confirm the request is refused rather than logged. Evidence is the decision record, the consent state consulted, and the destination.

Gateway coverage is direct on this control, since the consent state is an input to the policy decision, and the decision fires at the request boundary before the payload reaches the provider, the same enforcement pattern covered in LLM DLP.

Consumer rights and appeal control

RCW 19.373.040 covers consumer rights and requests, including refusal and appeal. The objective is to answer access, deletion and withdrawal requests across every system holding consumer health data, including whatever the AI stack retained.

The overlooked surface here is model-adjacent storage: prompt logs, vector embeddings built from health content, evaluation datasets, and fine-tuning corpora. A deletion request that clears the primary database and leaves the embedding index intact is unfulfilled.

Privacy operations runs the request workflow and platform engineering carries deletion in the AI stores. Submit a deletion request for a seeded consumer and confirm removal from primary storage, prompt logs, and the vector index. For evidence, retain the request identifier, the per-system deletion confirmations, the refusal-and-appeal record where applicable, and the completion timestamp.

Gateway coverage is partial on this one, because per-decision records identify which requests carried that consumer's data and where those requests went, which is what makes the deletion search bounded rather than speculative.

Data-security and processor controls

RCW 19.373.050 requires data security practices, and RCW 19.373.060 governs processors. A model provider processing consumer health data on the organization's behalf is a processor relationship, and it needs the contractual terms the section requires rather than an accepted click-through.

Security engineering holds the practices side and vendor management the processor terms. List every model endpoint any production workload can reach, match each to an executed processor agreement, then confirm an endpoint with no agreement is refused at runtime. The endpoint inventory, the agreement register, and the runtime denial record for an unapproved destination are the evidence.

Gateway coverage is direct on the destination-control half, since the enforcement layer is what makes "approved endpoints only" an enforced statement rather than a documented intention. The contract terms themselves sit outside it.

Authorization-to-sell and geofence controls

RCW 19.373.070 requires a valid authorization to sell, addresses defects in that authorization, and requires providing it to the consumer. Selling is defined as "the exchange of consumer health data for monetary or other valuable consideration." The phrase "other valuable consideration" is where an AI arrangement can drift into scope, because sending consumer health data to a provider in exchange for model improvement or preferential terms is worth a written legal opinion rather than an engineering assumption.

RCW 19.373.080 restricts geofencing around facilities providing in-person health care services. Mobile engineering owns location behaviour, and this control sits entirely outside the model boundary.

Both determinations are legal's. The sell control is tested by confirming no data flow classified as consumer health data reaches a destination flagged as a sale recipient without a valid authorization on file, and its evidence set is the authorization instrument, the consumer-provided copy, and the destination register.

Gateway coverage is partial for the sell control through destination policy, and outside scope for geofencing.

Enforcement posture

RCW 19.373.090 applies the Consumer Protection Act to violations of the chapter, which routes enforcement and consumer claims through Washington's existing consumer protection machinery rather than creating a bespoke penalty schedule. RCW 19.373.100 sets out exemptions, and the exemption analysis is legal work that should be documented before it is relied on.

What that enforcement route means operationally is that the evidence has to survive an adversarial reading. A record produced by the application that made the disclosure is the application's own account of itself. Produce it instead at an independent boundary and it carries the identity, the classification, the policy, the decision and the destination, written by infrastructure that has no stake in the outcome. Organizations that discover this distinction during a claim rather than before it end up reconstructing months of prompt traffic from logs never designed to answer the question.

DeepInspect

This is the gap DeepInspect closes for the technical half of this mapping. DeepInspect sits at the AI request boundary as a stateless proxy between authenticated users or agents and the model endpoints they call. Prompt content is classified against consumer health data definitions, the request is evaluated against the identity making it and the sharing-consent state attached to that consumer, and each decision is recorded with its destination.

The boundary is worth stating. DeepInspect's role stops at the model boundary: consent capture lives in the product surface, entity classification and processor agreements are legal work, and geofencing belongs to mobile engineering. What it covers is the point where consumer health data would otherwise cross to a third-party model provider, and it produces the record that shows whether it did.

If you are mapping RCW 19.373 obligations onto an AI deployment and the sharing-consent control has no enforcement point, that control is the one to build first. Book a technical deep dive at deepinspect.ai.

Frequently asked questions

Does HIPAA compliance satisfy the My Health My Data Act?: The two laws cover different populations, and treating one as satisfying the other is a common and costly assumption. HIPAA applies to covered entities and business associates handling protected health information. MHMDA reaches any regulated entity conducting business in Washington or targeting Washington consumers, which pulls in wellness apps, retailers, advertising technology and consumer platforms that have no HIPAA relationship at all. The consumer health data definition also captures health status that is "reasonably linkable" and inferred, which is broader than the identifiers HIPAA enumerates. RCW 19.373.100 contains exemptions, and mapping those against a HIPAA posture is legal work rather than an inherited pass.
Is sending a prompt to an LLM provider a "share" under the Act?: Treat it as one until legal tells you otherwise. Sharing under the chapter covers disclosure of consumer health data to a third party, and an external model endpoint operated by another company is a third party receiving the payload. The statute's requirement that sharing consent be separate and distinct from collection consent, and that it disclose the categories of entities receiving the data, maps directly onto naming model providers as a recipient category. Deployments that route prompts through an inference provider under a general privacy policy are the ones most exposed on this point.
What compliance date applies to us?: Regulated entities came under RCW 19.373.030 beginning March 31, 2024. Small businesses, as defined by the consumer-count and revenue thresholds in RCW 19.373.010, must comply with that section beginning June 30, 2024. Both dates have passed, so the practical question for any organization reading this in 2026 is not when the obligation starts but whether the evidence exists to show it has been met since then. That evidence question is where AI deployments built after those dates tend to have gaps.
How do we prove a prompt containing health data was blocked?: The proof is a per-decision record written by something other than the application that made the request. It should carry the identity that originated the request, the classification applied to the prompt content, the consent state consulted, the policy that evaluated it, the outcome, the intended destination, and the timestamp. A record with those fields answers the question a regulator or a plaintiff asks, which is whether the data left. An application log that says the request was handled answers a different and less useful question.
Do vector embeddings of health content count as consumer health data?: Assume yes for planning purposes. An embedding derived from a consumer's health text remains linked or reasonably linkable to that consumer where the index retains an identifier, and it identifies health status by construction, since that is what makes it useful for retrieval. The practical consequence lands on the deletion path under RCW 19.373.040: a deletion workflow has to reach the vector store and the prompt logs, not just the primary record. Teams that built retrieval systems before mapping this obligation usually find the index has no deletion path at all.
Where does an enforcement layer stop being the answer?: At every point where the duty is a human or legal act. Obtaining a consumer's freely given, specific, informed, opt-in agreement is a product and legal exercise. Classifying the entity, writing processor terms, deciding whether an arrangement constitutes a sale for valuable consideration, and complying with geofence restrictions all sit outside the model boundary. What the boundary contributes is the enforcement of decisions already made and the evidence that they held, on the specific path where consumer health data moves toward a model.

← All posts