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.
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.
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.