Washington My Health My Data AI Compliance Checklist: 10 Production Tests
This Washington My Health My Data AI compliance checklist turns Chapter 19.373 RCW into ten production tests for AI services handling consumer health data. Each item names an owner, retained artifact and completion condition across scope, policy, consent, sharing, rights, processors, security, sale authorization and geofencing.

A model route carrying a symptom description can cross four controls before the provider receives it: scope classification, disclosed purpose, consumer choice and processor authorization. This Washington My Health My Data AI compliance checklist makes those controls testable against Chapter 19.373 RCW, the Washington My Health My Data Act.
The main regulated-entity provisions applied on 31 March 2024, and the corresponding small-business date was 30 June 2024. The Washington Attorney General’s primary guidance also explains the Act and its effective dates. Legal should verify current text and applicability before sign-off.
1. Classify the consumer and entity
Section 010 covers a Washington resident or a natural person whose consumer health data is collected in Washington, acting in an individual or household context. Employment-context activity is excluded from the consumer definition. Regulated-entity, small-business and processor roles change the control analysis.
Owner: Legal and privacy, with the business service owner.
Keep: Entity map, consumer connection, collection location, service flow, role conclusion, exemptions considered and approval date.
Done when: Every AI service has a signed scope row tied to a legal entity and release. Conditional conclusions name the fact that changes the result, such as collection in Washington or employment context.
2. Inventory health data and machine inferences
Consumer health data under Section 010 includes linked or reasonably linkable information identifying physical or mental health status. The examples cover diagnoses, treatment, medication, reproductive or sexual health, biometric and genetic data, certain precise location data, and information identifying a person seeking health care. The definition also reaches specified data derived or extrapolated by algorithms or machine learning.
Owner: Privacy engineering and AI product, with legal approval.
Keep: Input schema, output fields, prompt template, model version, inference examples, subject identifiers and classification decision.
Done when: A synthetic payload with a visible purple health marker is classified before transmission, and every inferred field maps to the reviewed data inventory. Unknown fields get an owner and investigation ticket.
3. Reconcile the privacy policy with the deployed service
Section 020 requires disclosure of collected health-data categories and purposes, source categories, shared categories, recipient categories and specific affiliates, plus the rights method. The policy link must appear prominently on the homepage. Additional undisclosed categories or purposes require disclosure and affirmative consent before the added activity.
Owner: Privacy and product counsel, supported by web operations.
Keep: Rendered policy, homepage capture, version history, release mapping, route inventory and approval.
Done when: Each production feature maps to a policy version, disclosed purpose and recipient category. A route reconciliation matches observed hosted-model endpoints to the approved list and opens a dated exception for every mismatch.
4. Test collection consent or requested-service necessity
Section 030 permits collection with consent for a specified purpose or to the extent necessary to provide a product or service requested by the consumer. Consent must precede collection and disclose the data categories, purpose and specific uses, plus the withdrawal method.
Owner: Legal owns the branch; product owns presentation; quality assurance owns the test.
Keep: Branch analysis, consent screen, approved wording, consumer action, receipt ID, timestamp, release and withdrawal path.
Done when: A clean session records the approved choice before covered collection. The selected model event joins to the exact consent receipt or to an approved necessity decision for the requested service.
5. Separate sharing consent and verify the recipient
The sharing branch in Section 030 requires consent separate and distinct from collection consent, unless sharing is necessary for the requested product or service. The consent request identifies recipient categories and specific uses. A hosted model provider can be part of this analysis when consumer health data is transmitted to it.
Owner: Privacy, legal and procurement.
Keep: Collection choice, separate sharing choice, necessity analysis, provider category, endpoint, contract and test event.
Done when: One production-like sample links the sharing basis to the exact provider route. My opinion is that a generic consent=true field deserves a Gap because it erases the separate collection and sharing decisions the statute distinguishes.
6. Make access, withdrawal and deletion reproducible
Section 040 gives consumers rights concerning collection, sharing and sale, with access to covered data and recipient information. It also addresses withdrawal and deletion. Under the statutory conditions, backup deletion can wait for restoration but the delay may not exceed six months after authentication.
Owner: Privacy operations and data governance.
Keep: Intake, authentication, search query, responsive export, recipient list, downstream notices, deletion confirmations, appeal and response.
Done when: A synthetic subject request locates application records, model disclosures and provider records through a stable subject reference. Each store returns execution evidence, and a second reviewer can repeat the query without relying on the original engineer.
7. Restrict access by purpose and requested service
Section 050 requires access restrictions for employees, processors and contractors based on consented purposes or what is necessary to provide the requested product or service. Shared service credentials identify a workload but give weak evidence of the person or agent originating an AI call.
Owner: IAM, privacy and AI platform engineering.
Keep: Role mapping, purpose policy, application-supplied identity context, access review, permit sample and denial sample.
Done when: The same health-data class is permitted for an approved role and purpose, then refused for an unapproved role or destination. Both records identify the originating principal, workload, purpose, endpoint, policy version and outcome.
8. Test security and processor instructions
Section 050 requires administrative, technical and physical security practices meeting a reasonable industry standard of care, appropriate to the volume and nature of the data. Processor duties in Section 060 require a binding contract and processing consistent with its instructions. A processor acting outside those instructions can assume different statutory responsibility for the data.
Owner: Security owns control tests; procurement and privacy own processor terms.
Keep: Contract, instructions, endpoint allowlist, classification rules, failure behavior, event schema, alert, remediation and clean retest.
Done when: Tests cover an unknown model endpoint, missing identity context and a processor-route mismatch. Each condition produces the approved restrictive result and an independently retrievable record.
9. Review sale authorization and geofence branches
Section 070 requires a separate valid authorization before sale and specifies required content, defects, duration and retention. The geofence rule in Section 080 prohibits covered uses around an entity providing in-person health care for specified tracking, collection or health-related messaging purposes.
Owner: Legal, advertising technology, location services and data partnerships.
Keep: Sale analysis, authorization form, purchaser and seller details, revocation test, data-partner contracts, geofence inventory and campaign configuration.
Done when: Every data flow has a reviewed sale conclusion and every location-based feature has a geofence conclusion. A Not applicable result names the tested facts and reviewer instead of leaving an empty spreadsheet cell.
10. Reconstruct one AI disclosure for review
Section 090 treats a violation as an unfair or deceptive act in trade or commerce under Washington’s Consumer Protection Act. Chapter 19.373 creates no universal format for a per-request AI log, but operating evidence can show how a policy acted on a selected disclosure.
Owner: Internal audit with privacy, security and AI platform engineering.
Keep: Saved query, consent or necessity artifact, event export, integrity verification, provider contract, rights linkage and reviewer sign-off.
Done when: A reviewer selects one event and retrieves the consumer or subject reference, purpose, health-data class, provider endpoint, policy version, outcome and consent receipt. The white review card should link that event to items 1 through 9 without asking the calling application to recreate history.
The Washington audit-evidence guide explains the folder structure and reproducible collection package behind these tests.
Completion register
Track each item in a scannable record:
- Control and owner: one accountable function plus supporting teams.
- State: Pass, Gap or Not applicable, with a reason.
- Test date: the day the completion condition ran.
- Evidence: direct artifact links and stable identifiers.
- Remediation: owner, due date and clean retest for each Gap.
DeepInspect
DeepInspect contributes to tests 2, 3, 4, 5, 7, 8 and 10 for authenticated users or agents calling HTTP-based LLM endpoints. It evaluates application-supplied identity, purpose, consent context, data classification, destination and policy before forwarding traffic, then writes a signed, tamper-evident record for each permit, redaction or denial outside the calling application’s write path.
Those records support route reconciliation, policy tests, disclosure scoping and repeatable review. The application must provide stable consent, session and subject references when a reviewer needs those joins. DeepInspect leaves statutory scope, notice wording, consent presentation, consumer authentication, data-store deletion, processor contracts, sale authorization and geofence controls with their named owners. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Does every health-related model output fall under the Act?
The definition depends on personal information linked or reasonably linkable to a consumer and identification of covered physical or mental health status. It expressly includes certain derived or extrapolated information. Legal should evaluate the precise input, inference, consumer link and exemptions for each service.
- Can a privacy policy replace consent?
The policy performs a transparency function under Section 020. Collection and sharing are governed separately by Section 030 through consent or the requested-product-or-service branch. Preserve both the published disclosure and the event-level branch evidence.
- Is a model provider always a processor?
Role depends on the contract and actual processing. Section 060 addresses processing on behalf of a regulated entity or small business under binding instructions. Independent use or processing outside those instructions requires legal review rather than a label copied from procurement.
- Does DeepInspect execute consumer deletion?
DeepInspect can help locate routed model events when the application supplies a stable subject reference. Source systems, vector stores, provider-held data and backups need deletion execution from their respective owners. The rights case should join those confirmations under one request ID.
- What should internal audit sample first?
Select a request containing synthetic consumer health data sent toward an unapproved provider. Retrieve the identity, purpose, subject reference, data classification, destination, policy version and restrictive outcome, then join it to the policy, consent, processor and security records.