Washington educational resource

How does Washington's My Health My Data Act apply to fertility clinic vendor contracts?

Fertility clinics tend to assume that HIPAA covers the entire data-flow exposure surface and that vendor contracts only need a business-associate addendum. The HIPAA carve-out at is data-specific, not entity-blanket. Patient-facing web properties, marketing pixels, scheduling-platform integrations, app-based check-ins, and patient-portal analytics frequently process data that is not protected health information under HIPAA but is consumer health data under MHMDA. The vendor-contract layer is where the misalignment usually surfaces.

The HIPAA carve-out is data-specific, not entity-blanket (RCW 19.373.100)

excludes protected health information under HIPAA, related data under Chapter 70.02 RCW and 42 CFR Part 2, GLBA, FCRA, FERPA, public-health activities under 45 CFR 164.512, deidentified data meeting 45 CFR Part 164, and processing necessary to prevent, detect, protect against, or respond to security incidents, identity theft, fraud, harassment, or malicious or deceptive activities. The exemption applies to the listed data, not to the entity. A HIPAA-covered fertility clinic is exempt for the PHI it processes in treatment, payment, and operations. It is not exempt for the marketing-pixel data on its public website, the appointment-request form data before a patient relationship is established, or the analytics signal from a patient-portal page where the data is not flowing under a HIPAA transaction.

The exemption burden under the statute is on the entity claiming it. For a fertility clinic this means the clinic should be able to identify, by data flow, which flows are exempt PHI under HIPAA and which are consumer health data under MHMDA. The defaults usually come out unfavorably for the clinic because the SaaS vendors did not segregate flows that way.

RCW 19.373.060 processor obligations

regulates the processor relationship. A processor may process consumer health data only pursuant to a binding contract with the regulated entity that sets forth the processing instructions and limits the actions the processor may take with respect to the data. A processor that strays outside instructions converts into a regulated entity for the data at issue and is subject to the full statute. The processor must assist the regulated entity, by appropriate technical and organizational measures insofar as possible, in fulfilling MHMDA obligations.

For a fertility clinic, the practical impact is that a generic SaaS DPA or a generic HIPAA business-associate addendum is not interchangeable with an MHMDA processor contract. The clinic's contracts with website hosting, analytics, ad-platform, appointment-scheduling, patient-portal, and SaaS-vendor partners need MHMDA-specific binding instructions for any flow that touches consumer health data outside the HIPAA carve-out. The strongest position is a layered contract: HIPAA BAA for PHI flows, MHMDA processor terms for consumer-health-data flows, and a documented separation of which data is covered by which.

The vendor categories that typically present the problem

Website and marketing analytics. Google Analytics, Meta Pixel, LinkedIn Insight Tag, and similar tools on the public clinic website collect data that is rarely PHI but is often consumer health data when the page topic is reproductive-health treatment. The vendor relationship needs an MHMDA processor contract or a clean exclusion of those flows from the consumer-health-data scope.

Appointment-scheduling platforms. Patient-intake data before a HIPAA-covered relationship exists is consumer health data, not PHI. The scheduling vendor frequently processes that data outside HIPAA, even where the clinic assumes it is covered. The processor contract needs MHMDA-specific terms for the pre-relationship phase.

Patient-portal analytics and session-replay. Session-replay and analytics on a patient-portal page can capture data that is incidentally PHI but is delivered to the vendor outside the HIPAA framework. The vendor relationship needs MHMDA-specific terms or a clean technical exclusion of those flows.

Ad-platform and retargeting partners. Audience-building and retargeting platforms that consume signals from the clinic website or patient portal are processing consumer health data. The geofence prohibition under also reaches campaign configurations near the clinic itself, so the vendor relationship needs both MHMDA processor terms and a geofence-audit clause.

Sergei's practical note

Fertility-clinic vendor reviews are the matter type where I most often see the assumption gap. The clinic believes that HIPAA covers everything; the analytics vendor believes its product is "for marketing purposes only"; the SaaS scheduling platform believes its BAA is enough. None of those positions survive close scrutiny once the data-flow inventory exists. The review I do here maps each vendor relationship against the four MHMDA hooks (separate policy, two-layer consent, sale authorization, geofence prohibition) plus the RCW 19.373.060 processor obligations and the HIPAA carve-out limits. Send the vendor list, the current BAAs and DPAs, and a brief description of each data flow, and I will tell you which contracts need MHMDA-specific terms.

Related Washington resources

For the full statutory walkthrough, see my Washington My Health My Data Act resource. The Drafting the Consumer-Health-Data Policy page covers the standalone-policy requirement under RCW 19.373.020. To run the triage, see my Reproductive Health Data Risk Checker.

Educational resource. Sergei Tokmakov is a California attorney (CA Bar #279869) currently seeking admission to the Washington State Bar. Nothing on this page creates an attorney-client relationship or is Washington legal advice.