How do I draft the standalone Consumer Health Data Privacy Policy for a reproductive-health product?
The Consumer Health Data Privacy Policy required by RCW 19.373.020 is a standalone document, not a section inside a general privacy policy. For a reproductive-health product the document is also the most-read piece of legal text in your stack, because regulators, plaintiffs, and reporters all pull it first. The drafting traps are concrete and recurring: bundling, missing the specific-affiliates list, weak categorization, and the homepage-link failure.
Ask my AI Legal Analyst about Washington consumer health data and MHMDA?
Tap a question for an instant, free answer (no email needed), or describe your product and the analyst routes you to the right next step.
Common Washington consumer-health-data questions, always free
The five substantive disclosures required by RCW 19.373.020
RCW 19.373.020 requires a regulated entity to maintain a consumer health data privacy policy that clearly and conspicuously discloses: (i) the categories of consumer health data collected and the purpose for which the data is collected, including how the data will be used; (ii) the categories of sources from which the consumer health data is collected; (iii) the categories of consumer health data that is shared; (iv) a list of the categories of third parties and specific affiliates with whom the regulated entity shares the consumer health data; and (v) how a consumer can exercise the rights provided in RCW 19.373.040.
For a reproductive-health product, "categories of consumer health data" needs to name the specific reproductive-health categories you process: cycle data, ovulation predictions, pregnancy data, miscarriage events, contraception data, sexual-activity logs, partner data, location data near healthcare facilities, search and content-engagement signals, and inferences derived from any of the above. Generic phrasing such as "wellness data" or "health-related information" fails to satisfy the disclosure standard for a reproductive-health product because the specific categories are what give the user notice.
Sources, sharing, and specific affiliates
"Categories of sources" means the user, the user's device, third-party integrations, ad partners, and any data brokers or research partners that feed data into your product. "Categories of consumer health data that is shared" must be specific: not "health data," but "predicted ovulation window," "pregnancy status," "logged sexual activity," and so on. "List of categories of third parties and specific affiliates" is the disclosure most operators understate. The statute requires both a category list (ad networks, analytics platforms, cloud processors, research partners) and a named-affiliate list (specific corporate affiliates inside your group that share the data). Generic categories without the named affiliates is not enough.
The homepage link rule
RCW 19.373.020 requires the consumer health data privacy policy to be prominently published with a link on the homepage. A footer link that survives mobile collapse is the minimum; a dedicated link at page-chrome level on desktop and a persistent menu item on mobile is the safer position. The most common compliance failure I see is a homepage where the standalone policy link is buried in a footer that collapses on mobile and is not present in the mobile menu.
Drafting traps specific to reproductive-health products
Inferences. The product almost certainly derives inferences (predicted ovulation, predicted pregnancy, predicted contraception need) from non-medical signals. Each inference is itself consumer health data under RCW 19.373.010. The policy needs to disclose the inference category, not just the input data.
Adtech SDK signals. The third-party SDKs in the product collect data the operator may not see in raw form (Meta Pixel, Google Ads, AppsFlyer, Branch). If the SDK relationship transmits any user signal that is reasonably linkable to reproductive-health status, the SDK partner is a named-affiliate disclosure.
Partner clinic and lab flows. If the product integrates with a partner fertility clinic, lab, or telehealth provider, the policy needs to disclose the data flow to that partner specifically. A generic "we share with healthcare providers" is not enough.
Research-data flows. If the product participates in a research-data licensing or data-sale arrangement, the policy needs to disclose the recipients and the categories shared. The sale path also requires a separate written authorization under RCW 19.373.070; the policy disclosure is not a substitute.
Two-layer consent flow ties to the policy (RCW 19.373.030)
The policy is one half of the compliance posture. The other half is the consent flow under RCW 19.373.030: affirmative opt-in consent for collection, separate from affirmative opt-in consent for sharing. The policy must match what the consent flow actually obtains. A common failure mode is a policy that describes more sharing than the consent flow has authorized, or a consent flow that bundles collection and sharing into one acceptance and is therefore invalid for the sharing component.
Sergei's practical note
The standalone-policy requirement is the easiest MHMDA hook to satisfy on paper and the easiest to get wrong in practice. The fix is structural: a separate document at a separate URL, a homepage link that survives mobile collapse, specific category and affiliate disclosures, and a consent flow that aligns. The draft I provide here is calibrated to your actual data flows, not to a generic template. Send the current policy, the SDK and partner inventory, the consent screenshots, and a brief data-flow description, and I will tell you whether the right tier is a scope memo, a memo plus drafted DPA terms, or the full memo plus a drafted standalone policy.
Payment
Flat fee, paid up front through a secure PayPal checkout, so the budget is fixed before any work starts. The flat fee for the Healthcare SaaS Legal Package is $2,500. There is no hourly meter and no surprise invoice. If a matter is unusually large or turns into extended negotiation, I tell you before any additional work and we agree on scope first.
Delivery
Drafts in 2 to 3 business days, even for complex agreements. I work weekends when a matter needs it and it is engaged. You receive the work product by email in an editable format, with brief written comments explaining the key issues and the reasoning behind the main choices.
Process
- Send the materials. Email me your current documents, screenshots, and a short description of the product and the Washington consumers it touches.
- I confirm scope and run a conflict check. Engagement begins only after that check and a written confirmation of what is included.
- I draft or review. You get the deliverable with plain-language comments on the highest-risk items first.
- We refine. Reasonable revision rounds are included so the final version fits how your product actually works.
Scope
This is attorney-supervised regulatory and document work under my California license: issue spotting, compliance planning, drafting, and review. It is not Washington court representation. For Washington filings, litigation, or any court appearance, I coordinate with Washington-admitted counsel. Nothing here creates an attorney-client relationship until a conflict check clears and an engagement is confirmed in writing.
A flat-fee package for digital health and SaaS founders: HIPAA and BAA posture, Terms of Service and privacy policy, and the consumer-health-data layer that MHMDA adds on top. Reviewed under California license; for Washington court representation I coordinate with Washington-admitted counsel.
See the full Healthcare SaaS legal stack → or email me directly for a scoped quote.
Related Washington resources
For the full statutory walkthrough, see my Washington My Health My Data Act resource. The Fertility Clinic Vendor Privacy Review page covers vendor and processor contracts under RCW 19.373.060. To run the triage, see my Reproductive Health Data Risk Checker and my MHMDA Privacy Policy Gap 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.