How does the Washington My Health My Data Act work?

How the Act changes collection and disclosure practices

The law is not just about whether an organisation has “health data” somewhere in its stack, it changes how that data is collected, disclosed, shared, and sold. For practitioners, the first question is whether a source, tag, event stream, pixel, SDK, or vendor process is handling consumer health data under the statute’s definitions. That means data mapping has to include product telemetry, ad-tech pathways, and any third-party disclosure chain, not just obvious patient or clinical records.

For teams used to privacy notices that are broad but generic, the practical shift is toward more specific disclosures and more deliberate consent handling where the law requires it. If the data is collected through a consumer-facing app or website, the surrounding notice and request flow need to match the actual processing path, including any sharing for analytics, measurement, or advertising.

One useful way to think about implementation is to trace each health-data use case from capture to retention to downstream sharing. The law becomes harder to satisfy when the same dataset is reused across marketing, product, and vendor analytics without a clean purpose boundary.

Where compliance breaks down in practice

Most compliance failures are not caused by a single policy gap. They usually come from invisible integrations, copied tracking libraries, stale vendor contracts, or data that continues to flow after the business team has stopped thinking about it. That is why the highest-friction issues are often ad pixels, session replay tools, embedded widgets, and mobile SDKs that receive or infer sensitive health information.

The operational problem is that these channels are often maintained outside the privacy program’s day-to-day line of sight. A team may believe it is sending only product analytics, while the integration actually exposes health-related search terms, symptoms, appointment data, or treatment-related interactions. In that situation, the legal risk and the technical risk are the same problem viewed from different angles.

US State Privacy Laws Guide is a useful companion when you need to situate Washington’s law inside the wider state privacy patchwork, especially where sensitive data, opt-out signals, and enforcement expectations overlap.

What organisations should do before responding to requests

The practical test is whether the organisation can reliably find, classify, and act on consumer health data when a disclosure, deletion, or opt-out request arrives. If the answer depends on manual memory or ad hoc system-by-system investigation, the workflow is too fragile. The law rewards traceability: you need to know which systems hold the data, which processors receive it, and which business logic determines whether a request can be honoured.

Deletion and opt-out handling should therefore be treated as data operations, not only as legal intake tasks. That usually means building a repeatable inventory of health-data sources, documenting third-party recipients, and identifying which systems must suppress future sharing rather than simply delete one record in one database. Where advertising or analytics tools are involved, the business must also decide whether the control is removal, suppression, or redesign of the integration.

Global Privacy Regulatory Map helps teams compare Washington’s requirements with other privacy regimes when they need a broader compliance baseline across jurisdictions.

Risk and Threat Considerations

The main risk is uncontrolled downstream use of consumer health data, especially when analytics and advertising tools receive information the organisation did not intend to expose. Once that data leaves the first-party environment, the compliance burden increases because the organisation must rely on vendor behaviour, contract terms, and technical segregation that may not exist in practice.

Failure mechanism: Tracking scripts, SDKs, or data-sharing integrations ingest health data before governance, consent, or deletion controls are applied, then propagate it into third-party systems or advertising workflows.

Impact: The organisation can create unlawful disclosure, retention, or sale conditions, lose the ability to honour user requests consistently, and expose itself to enforcement risk and reputational harm.

Practitioner Guidance

What to verify: Confirm whether your data inventory covers web, mobile, CRM, analytics, and ad-tech sources together, not as separate privacy silos. If a consumer health signal can reach a third party, assume it must be reviewable and defensible end to end.

Decision rule: If a tracker, vendor, or SDK touches health-related data and you cannot clearly explain the business purpose, data recipient, and request-handling behaviour, treat it as a control failure and review it before relying on a policy statement.

Practitioner takeaway: The hardest part of this law is usually not drafting the notice, it is proving that the live data flow matches the notice after analytics, advertising, and vendor sharing are taken into account.

Related resources from NHI Mgmt Group

• How should organisations prepare for the Washington My Health My Data Act before it takes effect?
• Why does collecting consumer health data under the Washington My Health My Data Act create higher compliance risk?
• What are the signs that a consumer health data program is failing under the Washington My Health My Data Act?
• What is the difference between consumer health data and personal information in the Washington My Health My Data Act?