Bringing a Health App Into Compliance With Consumer Health Data Laws: A Practical Guide

Picture the head of growth at a twelve-person sleep app, opening her laptop on a Monday to find a letter from a plaintiffs' firm in Seattle. It quotes the app's marketing page ("your data stays yours"), attaches a packet capture of the app's traffic, and points to a line where an event called insomnia_score_high leaves for an ad network. She has never heard of the statute it cites. The engineer who added the SDK left a year ago. Nobody can say which of the app's forty events go where.

This is what most consumer health data compliance projects look like on day one. The law isn't especially mysterious, but a company has to learn four things about itself at once: what law applies, what data it has, where that data goes, and who decided. This guide is the order of operations.

For the doctrine and the leading cases, read Consumer Health Data Outside HIPAA: My Health My Data, the FTC, and the Apps That Know Too Much. The status of the law here is as of November 2026.

The short answer

• Start by stopping the leaks. Before policies or consent screens, find out what your app and site send to third parties, and turn off health-revealing events going to ad platforms. Every other step is easier once that is done, and it reduces exposure immediately. Preserve the evidence first.
• Assume more than one regime applies. The FTC Act applies to nearly everyone. The Health Breach Notification Rule applies if your product can draw data from more than one source. Washington's law applies if you sell to anyone in Washington, regardless of size. HIPAA may apply to one product line and not another.
• Design around Washington. Its statute is the strictest and has a private claim through the Consumer Protection Act. A program built to Washington's text will satisfy most of Nevada and Connecticut, with a shorter geofence check and the state-specific differences noted below.
• Treat advertising and health data as incompatible by default. Every FTC health order since GoodRx bans the combination. Getting valid consent to continue is possible, but the conversion loss and the risk usually make removal the better choice.
• Consent has to come first, and it has to be real. It must be opt-in, specific, separate for collection and sharing, and in place before the data moves. A cookie banner that doesn't actually block the script is worse than no banner.
• A selling authorization is almost never worth building. Structure so that you don't sell. If you think you need to, talk to counsel about how "sale" reaches non-cash exchanges.
• Pick your breach position before you need it. An unauthorized disclosure can start a 60-day clock with no hacker involved. Write down who decides and on what facts.

A realistic timetable for a small company is 6 to 12 weeks for steps 1 through 8 and another quarter to make deletion and rights handling reliable. The biggest variable is how many vendors you have and how well anyone remembers why.

Who does what

Marketing has to be at the table from the start. In the FTC's cases, the marketing function is where the facts happened. The class complaint in In re BetterHelp, Inc. Data Disclosure Cases, No. 23-cv-01033 (N.D. Cal. July 15, 2024), repeated the FTC's allegation that a junior analyst with little training had been given most of the decision-making authority over Facebook advertising.

Step 1: Work out whether you are inside HIPAA (week 1)

Owner: counsel, with whoever signs customer contracts.

HIPAA is the first question because its answer changes every later step. Data that is protected health information is carved out of Washington's Act and the FTC's breach rule, and it carries its own rules on advertising.

Ask these in order, for each product line:

1. Do you bill insurance or otherwise run standard electronic transactions? A provider is a covered entity only if it transmits health information electronically in connection with a covered transaction. See the definitions at 45 C.F.R. § 160.103. A cash-pay clinic might not be covered, and should confirm this with its billing vendors before saying so. A pharmacy that bills plans is covered.
2. Are you a health plan or clearinghouse? Usually obvious.
3. Does a covered entity pay you, contract with you, or direct patients to you to do something on its behalf? If you create, receive, maintain, or transmit PHI for it, you are a business associate for that activity, under the same definition and under 42 U.S.C. § 17934. A subcontractor to a business associate is one too.
4. Do you offer the same product directly to consumers? Then you have two hats. HHS treats a developer's direct-to-consumer version as outside HIPAA even where the same company serves hospitals under a BAA.
5. What have you said? Check the website, footer, sales decks, and privacy policy for the words "HIPAA compliant." If you are not covered, take them down. If you are, make sure they are true.

That last item is practical as well as cosmetic. The FTC charged GoodRx with displaying a HIPAA seal it hadn't earned. In Kady v. Opencare, Inc., No. 4:25-cv-05037 (N.D. Cal. Aug. 31, 2026), a dental referral company's own policy statement about acting as a business associate helped keep the case alive at the pleading stage.

If you are a business associate for some customers, segregate that data logically and in contracts. It needs a BAA and the Security Rule at 45 C.F.R. Part 164, and your pixels can't be anywhere near it. OCR's bulletin on tracking technologies remains in place for authenticated pages, because American Hospital Ass'n v. Becerra, 738 F. Supp. 3d 780 (N.D. Tex. 2024), vacated only the portion addressing an IP address connected to a visit to an unauthenticated public page. Read HIPAA Business Associates and Cloud Computing and run the HIPAA Security Rule Risk Analysis Checklist for that side.

Do not rely on a vendor's "HIPAA-ready" label. A BAA with your cloud host doesn't make your marketing analytics compliant, and an ad platform that won't sign one can't touch PHI. Platform terms also push responsibility back on you. As described in In re Meta Pixel Healthcare Litigation, 647 F. Supp. 3d 778 (N.D. Cal. 2022), Meta's Business Tools Terms make the site owner represent that it has the necessary rights and a lawful basis to send the data.

Step 2: Work out which other laws apply (week 1)

Owner: counsel.

Use this matrix per product. The toolkit has a fuller version.

Three judgment calls come up constantly.

Are we a "personal health record"? Under § 318.2, a PHR must have the technical capacity to draw information from multiple sources. The FTC's compliance guide says a health app that can sync with a fitness tracker probably qualifies, even if some users don't connect one. If your product imports anything from HealthKit, Health Connect, a wearable, a lab, or a food database keyed to the user's input, assume yes. If you believe you're outside, write down why, and revisit it every time a product manager proposes an integration.

Is any of our data "consumer health data"? In Washington, the list includes "data that identifies a consumer seeking health care services," and inferences derived from non-health data. The attorney general's FAQ says toiletry purchases ordinarily don't count and that "[n]on-prescription data is only considered consumer health data if the regulated entity draws an inference." Use that, carefully. It is non-binding guidance, a plaintiff will cite the statutory categories for diagnostic testing and reproductive health, and a marketing segment called "diabetes care shoppers" is an inference by any definition. A retailer selling reading glasses, pregnancy tests, and hair growth treatments should assume some of its data qualifies. A retailer selling only shoes generally has none, unless someone builds a model. After Rand v. Eyemart Express, L.L.C., No. 25-10784 (5th Cir. Oct. 23, 2026), held that shopping and scheduling on an eyewear site plausibly relate to health at the pleading stage, retailers should stop assuming their data is too commercial to count.

Does the Washington "consumer" definition reach beyond Washington residents? It covers a person whose data is "collected in Washington," and "collect" includes any processing. The attorney general says that "[a]n entity that only stores data in Washington is not a regulated entity," so a company with no other Washington connection has a good answer. A company that is already regulated because it has Washington customers should not assume its non-Washington users are excluded if their data runs through a Washington data center or vendor. Most companies find a single national standard simpler than dividing users by state.

For the wider omnibus picture, see State Consumer Privacy Laws: The CCPA, the CPRA, and the Multi-State Patchwork.

Step 3: Build the data map from traffic, not from memory (weeks 1 to 3)

Owner: engineering, with marketing, under counsel's direction.

Do this under privilege if you can. Have counsel direct the work in writing, because the output may reveal past disclosures, and a clean description of what you found may later matter under the breach rule.

Preserve first. If a letter, regulator contact, or credible complaint has arrived, or if you can reasonably anticipate litigation, issue a hold before changing tags. Export tag manager configurations and version history, ad platform event settings, audience upload logs, and SDK versions. You want the ability to show what ran and when.

Then collect evidence from five places. People's memories are the worst of the available sources.

1. Mobile traffic. Run the app through an intercepting proxy on a test device (mitmproxy or Charles are the common tools), walk each flow as a test user with obvious fake conditions, and record each destination and payload. Do it on both iOS and Android, and with tracking permission both granted and denied. Certificate pinning may require a debug build.
2. Web traffic. Use browser developer tools and a crawler on key pages, both logged in and out. Check the URLs in requests. Query strings and paths often contain symptoms, drug names, and provider specialties, and in one case the plaintiffs' expert described a link granting access to a patient's full health assessment, as recounted in Doe v. Adventist Health System/West, No. B344951 (Cal. Ct. App. July 24, 2026).
3. Server-side integrations. Ask specifically about Conversions API, server-side tag managers, customer data platforms, reverse ETL, and data warehouse exports. These don't show up in a browser capture at all. The FTC's complaint against Hims & Hers describes both the pixel and the Conversions API.
4. Ad accounts. Log in to the ad platforms. List custom audiences, customer lists, lookalike seeds, and event names as the platform sees them. Check the dates. List uploads are usually a person's manual habit and appear nowhere in the code.
5. Contracts and finance. The accounts payable list and the SSO catalog will reveal vendors nobody mentioned, and they also reveal any exchange of value, which you need for the sale analysis.

For each data flow, record: data element, source, purpose, legal basis in each state (consent or necessity), recipient, recipient's role (processor, third party, affiliate), contract status, retention, and deletion path. The toolkit has a template. Separate tools for web tracking are covered in Auditing Your Website Tracking Stack: A Practical Guide.

Classify with the event name in view. Reading the payload, not just the vendor list, is the entire point. The FTC alleged Monument named its events "Paid: Weekly Therapy" and "Paid: Med Management." A vendor that looks benign in a spreadsheet can be carrying a diagnosis in a string.

Worked example: the sleep app's audit

Suppose Tessaly, the sleep and mood app from the opening, runs the audit. It finds six SDKs: crash reporting, product analytics, install attribution, a push notification service, a Facebook SDK that was added for one campaign in 2023, and an ad network. Its events include insomnia_score_high, mood_low_3days, and sleep_aid_recommended. The attribution SDK and the Facebook SDK both receive events automatically, because someone once checked a box to "forward all events." The web onboarding quiz uses a pixel, and the quiz's URL is /quiz/result?type=anxiety.

Tessaly's map shows that crash reporting receives no health events, product analytics receives all of them under a contract that lets the vendor use the data only for Tessaly, and the other three SDKs have no restrictions at all. Tessaly also lets users import Apple Health sleep data, so its "multiple sources" answer is plainly yes. Washington, Connecticut, and Nevada all apply, and the breach rule does too. HIPAA doesn't, because nobody's doctor is involved. At this point, Tessaly has a remediation list and a potential breach question, which step 12 takes up.

Step 4: Triage ad tech now (weeks 2 to 3)

Owner: executive sponsor makes the call; engineering executes.

Don't wait for the consent project. These are your options, in rough order of risk:

The safer default is to remove first and add back only with a legal review. Removal is reversible and you can A/B test its revenue effect in a matter of weeks. If revenue really depends on health-event optimization, the company should know that fact and decide with its eyes open, because that's a business model question and not an engineering one.

Stop the customer list uploads too. If growth needs a replacement, contextual ads on health content don't require user-level data.

One caution about changing things quickly. When the tag comes down, keep the record of what it did. The question of whether a past disclosure was a reportable breach survives the fix. That's covered in step 12.

Step 5: Build the consent flows (weeks 3 to 8)

Owner: product and counsel.

First, sort every collection and sharing activity into "necessary" or "consent required." RCW 19.373.030 lets you collect or share without consent only "to the extent necessary to provide a product or service that the consumer . . . has requested." Storing a sleep log to show it back to a user is necessary. Using it to train an unrelated model or to send it to an ad network isn't. Read "necessary" narrowly, as no court has defined it and your likely reviewer is a plaintiff's lawyer.

For what needs consent, the Washington requirements are:

• Before the collection or sharing. Consent obtained after the data leaves is useless. In Kady, users were allegedly asked to accept the policy only after completing a questionnaire and the data was already flowing, and the court held that the plaintiffs had adequately pleaded that they did not consent.
• Clear affirmative act. Not general terms of use, not hovering or closing content, and not via a "deceptive design" (the statute's phrase for an interface that impairs user autonomy).
• Separate and distinct for sharing and for collection. Two checkboxes or two screens. A single "I agree" doesn't do it.
• Disclosures inside the request: categories collected or shared, purpose including the specific ways the data will be used, categories of recipients, and how to withdraw.
• Purpose-specific. New purposes or categories need new consent. RCW 19.373.020(1)(c)-(d).

Here is sample language. It is a starting point for your facts, and it must be true of your actual system.

Collect your sleep and mood data?

Tessaly collects the sleep times, mood check-ins, and symptoms you enter, and any sleep data you import from Apple Health. We use it to show your trends and give you sleep suggestions. You can withdraw this consent any time in Settings > Privacy, and we will stop collecting and delete this data.

[Allow] [Not now]

Share with our research partner? (Optional)

With your permission, we'd share your sleep trends with research organizations studying insomnia, so they can publish findings. We would not share your name or email. Tessaly works the same if you say no. You can withdraw any time in Settings > Privacy.

[Share] [Don't share]

Design notes:

• Equal prominence. The "no" option should be as easy to find as "yes." Regulators read these as dark patterns if it isn't, and the FTC's orders bar them. See Dark Patterns, Auto-Renewal, and the FTC Click-to-Cancel Rule.
• Actual blocking. The consent state has to control the code. If the SDK initializes at app launch and consent comes on screen three, you've already collected. Change the initialization order, and test with a proxy.
• Honor the opt-out on the web too. In Shah v. MyFitnessPal, Inc., No. 25-cv-04430 (N.D. Cal. Sept. 28, 2026), the core allegation was that tracking continued after users rejected optional cookies. The court also treated those allegations as supporting fraudulent concealment tolling, because users could not know the site was ignoring them. A broken banner can extend your limitations exposure.
• Keep a consent ledger. User ID, version of the text, time, and choice. You will need to prove consent existed, and it's the first thing a regulator or plaintiff asks for. In a wiretap case, the burden on consent often falls on the party asserting it.
• Handle withdrawal. It must actually stop future collection and sharing, and flow downstream.
• Conversion cost. Expect some drop for optional items, and little for what users plainly expect. If a consent screen for your core feature performs badly, the feature may be "necessary" and not require consent at all. Don't ask for consent you don't need.
• Don't condition service on it, unnecessarily. The Act bars discriminating against consumers for exercising rights, and a sale authorization can't be conditioned at all.

Connecticut and most omnibus states require opt-in for sensitive data with their own definitions of consent, and a flow meeting Washington's will generally do. California's CCPA uses a "limit" model, so add that link if you meet its thresholds. For general notice mechanics, see Privacy Notice Toolkit: Policy Templates, Consent Flows, and Change Management Records.

Step 6: Publish a consumer health data policy that matches reality (weeks 3 to 6)

Owner: counsel, reviewed by engineering line by line.

RCW 19.373.020 requires a separate policy disclosing categories collected and why, sources, categories shared, categories of third parties and specific affiliates, and how to exercise rights. It needs a prominent link on your homepage. For an app, "homepage" includes the app store page and a link within the app's settings or about page. Nevada has parallel requirements. Don't bury this inside the general privacy policy. Washington's attorney general says it "must be a separate and distinct link" and may not contain additional information the Act doesn't require.

The legal risk in a privacy policy lies less in omissions than in comforting adjectives. Hims & Hers is alleged to have said that sensitive information is "only accessed by the medical providers managing your care," and to have advertised a "100% online, private, and secure process." Those statements are the core of the FTC's deception counts. BetterHelp, GoodRx, Premom, Flo, and Monument all involved statements like that. Before publishing, have an engineer read each sentence and ask, "Is this true of every data flow on the map?"

Strike or qualify:

• "We never share your health information." True only if you truly never do.
• "Anonymous" or "de-identified." Only if it meets a recognized standard. Flo argued its data was de-identified and could not win that point at summary judgment in Frasco v. Flo Health, Inc., No. 21-cv-00757 (N.D. Cal. May 22, 2025), because a jury could find the events carried identifying information.
• "HIPAA compliant" (see step 1).
• "We don't sell your data," unless you've actually analyzed the Washington definition.
• "Your data stays yours." It's marketing, but it's also a promise.

Drafting and Maintaining a Privacy Policy: A Practical Guide covers general mechanics. The toolkit has clauses specific to health data.

Step 7: Fix the vendors (weeks 3 to 10)

Owner: counsel and procurement.

Washington's law sorts every recipient into categories, and the category decides what you need.

The processor label has to be earned. A vendor that can use your data for its own product improvement, advertising network, or cross-customer modeling isn't acting only on your behalf, whatever its paper calls it. And under RCW 19.373.060(1)(c), a processor that steps outside its instructions becomes a regulated entity for that data. That gives you a helpful pressure point in negotiation. It also gives you a problem, because you may still be liable for an improper share. RCW 19.373.020(1)(e) makes it a violation for you to contract with a processor in a way inconsistent with your policy.

In your vendor review, look at the data terms in the SDK's documentation and at the settings, as well as the contract. Many analytics SDKs have a setting that decides whether the vendor may use data across customers. Keep screenshots.

Minimum terms for anyone touching consumer health data:

• Purpose limitation and no use for vendor's own benefit, model training, or advertising.
• Sub-processor disclosure and flow-down.
• Security standard and access controls.
• Assistance with consumer requests, plus deletion on notice. RCW 19.373.040 obligates recipients to honor deletion, and you need a path to trigger it.
• Prompt incident notice to a named official. 16 C.F.R. § 318.3(b) requires a third party service provider to notify the official designated in the contract, and requires you to tell your service providers you are subject to the rule. Most companies have not done this. Send the notice.
• Audit or evidence rights in proportion to the risk.
• Return and deletion at termination.

For SDKs offered on non-negotiable terms, your choice is to accept what's on offer, configure, or replace. Our view is that a vendor who won't commit to purpose limits should not receive health events, however useful the dashboard. See Building a Vendor and Third-Party Risk Management Program and the Vendor Cybersecurity Diligence Checklist.

Vendor exposure runs in both directions, and SDK companies should read this too. In the Flo litigation, the 2024 order refused to require proof that Google used the data, and a jury later found Meta liable under California's eavesdropping statute.

Step 8: Decide you aren't selling, and make it true (weeks 3 to 6)

Owner: counsel and executive sponsor.

RCW 19.373.070 requires a signed authorization to "sell or offer to sell" and defines sale as an exchange for "monetary or other valuable consideration." Run these questions:

1. Does anyone pay you for data? That's a sale.
2. Do you receive free or discounted services because you let the vendor use your users' data for its own purposes? This is the live risk. "Other valuable consideration" is the phrase plaintiffs will quote.
3. Do you get data back in return, as in data co-ops and audience exchanges? Probably a sale.
4. Is a partner paying you a referral fee linked to users' health status? For instance, a telehealth lead sold to a clinic. That's probably a sale, and it may raise other issues.
5. Is there a merger or financing with a data room? The Act excludes a transfer in a merger, acquisition, or bankruptcy where the acquirer assumes control and "complies with the requirements and obligations in this chapter." Put that in the deal documents. The acquisition theory failed on its facts in Bridges v. Blackstone, Inc., 66 F.4th 687 (7th Cir. 2023), a genetic privacy case, but that doesn't mean every deal is safe, and 11 U.S.C. § 363(b) adds its own limits in bankruptcy.

If you truly do plan to sell, the authorization must be plain language and a standalone document, with the specific data, seller and purchaser with contact details, purpose and use, a no-conditioning statement, a revocation right and method, a redisclosure warning, an expiration one year from signature, and a signature and date. Give the consumer a copy. Keep it for six years. The purchaser keeps one too. A compound authorization is invalid. The toolkit has a form.

Nevada requires written authorization too, Connecticut requires consent for sale, and Maryland bars sale of sensitive data, so a nationwide sale program is close to unworkable.

Step 9: Make consumer rights work (weeks 6 to 16)

Owner: engineering and support.

Washington's rights go further than most privacy programs are built for.

• Confirm and access, including a list of all third parties and affiliates who got the data, with an active email address or online contact for each. Most omnibus laws ask only for categories. You need this list to exist, and the map from step 3 feeds it.
• Withdraw consent.
• Delete, from "all parts of the" network, including archives and backups, with backups permitted up to six months' delay after authentication. And you must notify all affiliates, processors, contractors, and third parties who received the data.
• Timing: without undue delay, and within 45 days of receipt, with one 45-day extension if you tell the consumer why within the first period. Authentication doesn't stop the clock.
• Fees: free up to twice a year.
• Appeals: a conspicuous process, a written response in 45 days, and if you deny, a way to contact the attorney general.
• Don't force account creation, though you can require use of an existing account.

The engineering issues to settle:

Backups. Six months gives you a design target. Either your backup retention is six months or less, or you need crypto-shredding (per-user encryption keys you can destroy) or a suppression list reapplied on restore. A team that keeps seven-year backups because "storage is cheap" has just found a deletion problem. See Data Minimization and Avoiding the Over-Retention of Personal Information.

Downstream propagation. Build a list of recipients per user, or per class of user and time window, and an automated or scripted notice. Vendor APIs for deletion exist for many analytics products. Others require a ticket.

Non-account users. If a site visitor without an account asks you to delete pixel data tied to a cookie, authentication is hard. Using a commercially reasonable effort, and asking for what you need to authenticate, is what the statute calls for. Log what you did.

Scripts. Support staff should know that a request needn't use magic words. See the toolkit for scripts and the Data Subject Rights Request Handling Checklist.

Cost. For a small app with few vendors, a workable manual process plus one week of scripting is enough. For a larger stack, deletion propagation is a real project. If you have to choose, reduce the number of recipients first, which reduces every later cost.

Step 10: Set a security baseline (weeks 4 to 12)

Owner: engineering lead.

RCW 19.373.050 requires need-to-know access limits for employees, processors, and contractors, and administrative, technical, and physical practices that "satisfy reasonable standard of care within the regulated entity's or the small business's industry." The FTC's cases give you a working list of what counts as unreasonable. Cerebral allegedly let former employees keep record access for months, and it had a single sign-on flaw that exposed other patients' files. Those are ordinary failures, and regulators will treat them as such.

Under FTC v. Wyndham Worldwide Corp., 799 F.3d 236 (3d Cir. 2015), unfairness reaches data security. LabMD, 894 F.3d 1221 (11th Cir. 2018), limits how vague the order can be, but won't help you avoid the investigation. In California, J.M. v. Illuminate Education, Inc., No. S286699 (Cal. May 14, 2026), means a CMIA plaintiff no longer needs to allege anyone actually viewed the stolen records, at least against an entity the Act covers. The test is whether the data was exposed to a significant risk of unauthorized access or use. Encryption and fast detection now matter more to your damages story than they used to.

A baseline for a small company: SSO with MFA for production and analytics tools, role-based access, offboarding within a day, encryption in transit and at rest, audit logs kept for at least a year, secrets management, dependency updates, an annual outside test, a tested incident plan, and a retention schedule. If you also carry a HIPAA hat, the Security Rule's risk analysis applies to that side. See the Cybersecurity Program Toolkit.

Step 11: Get out of the geofence business (week 2, then ongoing)

Owner: growth and engineering.

Washington bars "any person" from using a geofence around an entity that provides in-person health care services to identify or track consumers seeking care, collect consumer health data, or send messages or ads related to consumer health data or health care services. The boundary is 2,000 feet or less from the perimeter. Nevada's is 1,750 feet around in-person care. Connecticut's and Maryland's are 1,750 feet around mental health and reproductive or sexual health facilities. Washington's section has no consent exception on its face and applies to small businesses, and Nevada is commonly read the same way.

Audit for these:

• Ad campaigns with radius targeting or location audiences near clinics, hospitals, pharmacies, or fertility centers, whether you ordered them or your agency did.
• Audience segments purchased from data brokers, labeled "visited urgent care" and so on.
• In-app triggers, such as a notification that fires when the app detects someone near a pharmacy or gym.
• SDKs that collect location in the background. The Amazon Ads SDK litigation centers on this theory. See In re Amazon Ads SDK Litigation, No. 2:25-cv-00252 (W.D. Wash.).
• Store-locator features. A feature showing a user the nearest clinic when she asks for one is likely a requested service and not a geofence "used to" track, although you should avoid storing or sharing the result.

Then take these actions. Ban health-facility location targeting in written instructions to agencies. Drop to coarse location unless precision is core to the product (Washington's precise location threshold is a 1,750-foot radius). Stop buying location audiences that you can't trace to real consent, and remember that the FTC's May 2026 stipulated order resolving FTC v. Kochava, Inc., No. 2:22-cv-00377 (D. Idaho), requires a supplier assessment program, which shows what the FTC thinks diligence looks like. Virginia and Connecticut have also recently moved to bar sale of precise geolocation data.

Worked example: the retail chain

Suppose Corvane Home & Health is a regional chain of 80 stores in Oregon and Washington, each with a pharmacy counter. Its marketing team runs a "come back to the store" campaign, geofencing store parking lots and sending app notifications with front-of-store coupons. It also runs a loyalty program, an e-commerce site with a pixel, and a pharmacy app.

Three legal regimes meet here. The pharmacy is a HIPAA covered entity, so prescription data and the pharmacy app are PHI, and pixels in the pharmacy app are an OCR problem in addition to a privacy one. A front-of-store purchase of a home glucose monitor isn't PHI. Under the attorney general's FAQ it may not be consumer health data either, until Corvane's loyalty system files that shopper in a "diabetes care" segment, at which point Corvane has drawn the inference. And the geofence has now become a statutory question, because a store with a pharmacy counter is an entity providing in-person health care services (a pharmacist's assessment fits "assess, measure, improve") and the parking lot is within 2,000 feet of it.

Does the coupon campaign violate RCW 19.373.080? The ban requires the geofence to be used to identify or track consumers seeking care, collect consumer health data, or send messages "related to their consumer health data or health care services." A generic coupon for paper towels has a decent argument that it doesn't. A coupon for allergy medicine sent in the parking lot doesn't. Corvane has good reasons to simplify: exclude the pharmacy category from geofenced messaging, keep the location history out of the health data set, and stop feeding pharmacy-adjacent purchases into ad audiences.

The data segmentation matters most. Corvane should ensure PHI does not enter the loyalty system without a HIPAA authorization, since a shared customer ID can turn "front of store" into a PHI question. A retailer's data architecture decides whether it has one regime or three.

Step 12: Make breach decisions before you have to (weeks 2 to 4, then on demand)

Owner: counsel and executive sponsor.

This step is where the guide differs most from a general incident response plan. The breach rule's definition includes an unauthorized disclosure, so you may already have an event on your hands from what step 3 found.

The decision path looks like this:

1. Does the rule apply? PHR status from step 2, and no HIPAA carve-out for this data.
2. Is it unsecured PHR identifiable health information? "Unsecured" refers to HHS's guidance on encryption and destruction. As we read it, data sent in readable form to a recipient that can read it is unsecured as to that recipient, whatever TLS did on the wire.
3. Was there an acquisition without the individual's authorization? Unauthorized access is presumed to include acquisition unless you have reliable evidence otherwise. The FTC's guide says a company's disclosure without authorization counts. Authorization is where consent records come in: did the user actually agree to that disclosure, in a manner that would hold up? An old privacy policy disclosing "analytics partners" is a thin reed.
4. When did you discover it? On the first day it was known or reasonably should have been known, including by an employee or agent other than the wrongdoer. A marketing manager's knowledge may count. The rule doesn't help you by waiting for legal to hear about it.
5. Who gets notice? Individuals without unreasonable delay and within 60 calendar days. The FTC at the same time if 500 or more people, and annually if fewer. Prominent media in any state or jurisdiction with 500 or more affected residents. The vendor bears the burden of showing all notice was made.
6. Content. § 318.6 requires a description of what happened, including the date, and the identity of third parties who acquired the information, the data types (including "the individual's use of a health-related mobile application"), protective steps, what you're doing, and contact methods with two or more channels.

Also check state breach statutes. Many have medical information triggers and shorter deadlines. Most are aimed at unauthorized acquisition by an outsider and don't obviously reach a voluntary disclosure, but a true security incident is another matter. Washington's own statute, RCW 19.255, covers medical information and requires notice within 30 calendar days of discovery, with notice to the attorney general where more than 500 residents are affected. Check 42 U.S.C. § 17951 on how the federal rule relates to state law. Business associates follow 45 C.F.R. §§ 164.400-414 and 42 U.S.C. § 17932 by notifying the covered entity instead.

The hard version of this question

Back to Tessaly. Its audit shows insomnia_score_high went to an ad network tied to advertising IDs for about 40,000 users over two years. The policy said "we may share usage data with partners." The ad network's terms allow its own use. Nobody clicked a consent screen. Tessaly has an unauthorized disclosure under the FTC's reading, and its discovery date is arguably the day the audit found it, or arguably earlier if the marketer understood what the SDK did.

The arguments for notifying: the rule's text, GoodRx and Premom, a burden of proof on the company, and civil penalties. The cost: the notice is close to a confession, it invites a class action, and it names recipients. The arguments against notifying rest on defenses that the product isn't a PHR, or that disclosure was authorized by a policy. A company with a strong defense on PHR status may reasonably reach a different conclusion. Tessaly's Apple Health import makes that hard.

So Tessaly's realistic plan is to engage counsel before the discovery clock has run long, stop the flow, send deletion requests to recipients (FTC orders routinely require this anyway), quantify users, prepare the notice and FTC submission, and line up the communications. It should also check insurance. Cyber policies vary on wrongful collection and pixels, and notice provisions are strict, as Directors and Officers and Cyber Insurance: Towers, Triggers, Allocation, and the Claim You Must Notice explains.

Document the reasoning either way. In a later investigation, a dated memo showing that a responsible person weighed the rule is a good deal better than silence. The toolkit has a decision tree.

Telehealth worked example: two hats, one disclosure

Suppose Bluequay is a telehealth company prescribing hair loss and sexual health medication. It takes cash, partners with a mail-order pharmacy, and for one hospital system also runs a white-label intake portal under a BAA. A review finds that a Conversions API integration has been sending purchase events with product names to Meta from both the consumer site and, due to shared code, the hospital portal.

The hospital portal data is PHI. Bluequay, as a business associate, must notify the hospital without unreasonable delay and no later than 60 days. The hospital decides about patient notice under HIPAA, and the BAA probably has a shorter deadline. HIPAA's breach presumption and four-factor risk assessment apply at 45 C.F.R. § 164.402.

The consumer data isn't PHI if Bluequay is outside HIPAA as a cash-pay provider, which needs checking with the pharmacy and billing facts. If it does count as a provider conducting electronic transactions, the consumer data may be PHI as well, and everything shifts. If not, the breach rule applies assuming PHR capacity, the MHMDA and similar laws apply, and section 5 applies to whatever "discreet" promises the site made. Those promises are the center of the current FTC complaint against a company with similar products.

Note the separate tracks: one disclosure, two notice regimes, two clocks, and potentially different letters to the same person. The first move is to separate the code. For clinical regulatory context, see Telehealth Law: Licensure, Prescribing, Reimbursement, and Privacy.

Step 13: Decide how you respond to legal process (week 6)

Owner: counsel.

Reproductive and gender-affirming data makes this a live risk, and Washington's statute doesn't include a general exception for legal process. See RCW 19.373.100(3), which addresses activity illegal under Washington or federal law. With the HIPAA reproductive rule vacated in Purl v. U.S. Department of Health & Human Services, No. 2:24-cv-228 (N.D. Tex. June 18, 2025), there is no federal backstop for this data anyway, and that rule never reached non-HIPAA data.

Adopt a written procedure. Route all demands to counsel, require proper process, check jurisdiction, narrow the scope, notify the user where the law permits, publish a transparency line if you can, and collect less to begin with. For the working procedure, see Government Data Demand Toolkit: Legal Process Review, Objections, and Notification.

Step 14: Keep it from drifting (ongoing)

Owner: privacy lead, with a named engineer.

Compliance fails here most often, because a new campaign puts the tag back.

• Release gate. No new SDK, tag, or data recipient without privacy review. Enforce it in the tag manager's publish permissions and in the mobile build's dependency review.
• Quarterly traffic capture. Repeat the proxy test against production flows. Compare it with the map. Automate it for web pages.
• Event-name review. Treat the naming of analytics events as a data disclosure decision.
• Annual applicability review. Watch for the Connecticut changes, new state laws, and new integrations affecting PHR status. New York's revised bill passed the legislature in June 2026 and awaits the governor's action.
• Train marketing. One hour, with examples of real event names from FTC complaints, will accomplish more than a policy nobody reads.
• Board-level record. A short annual note on what was reviewed and changed helps in any later inquiry.

The Consumer Health Data Compliance Checklist: A Practical Checklist is built for the recurring review, and the Consumer Health Data Toolkit: Consent Forms, Data Maps, and Breach Notification Decisions has the forms. See also Developing a Privacy Compliance Program.

When a dispute arrives: both sides

If you are the company

A demand letter or complaint in this area typically arrives with a capture of your traffic. Respond in this order: preserve, investigate under privilege, fix, notify any insurer, then answer.

Your defenses, roughly in order of strength:

• Arbitration and class waiver, where a user actually clicked. Neblock v. Gene by Gene, Ltd., No. 24 CV 12118 (N.D. Ill. May 19, 2026), compelled arbitration of a pixel case under a click-to-accept account flow. It doesn't help with site visitors who never accepted anything. Flo's class waiver failed. And mass arbitration has its own costs.
• Pleading specificity. Where plaintiffs won't say what they did or what was sent, Santoro v. Tower Health, No. 24-3173 (3d Cir. Aug. 28, 2026), affirmed dismissal with prejudice, and Nichols v. PeaceHealth Networks on Demand LLC, No. 2:25-cv-01831 (W.D. Wash. Mar. 4, 2026), dismissed with leave.
• Article III, in federal court. Popa v. Microsoft Corp., 153 F.4th 784 (9th Cir. 2025), is useful in that circuit for low-sensitivity browsing. It is weak for intake data. Be careful what you ask for, since a win may send a state court case back to state court, where Article III doesn't apply. And Doe v. Cedars-Sinai Health System, 106 F.4th 907 (9th Cir. 2024), closes the federal officer route.
• Wiretap party exception. See 18 U.S.C. § 2511(2)(d) and Sweat for what a helpful record looks like. It won't stop CIPA, MHMDA, or tort claims. In re Group Health Plan Litigation, No. 23-cv-267 (D. Minn. Dec. 21, 2023), shows the crime-tort exception can survive the pleadings.
• Injury under the Washington Consumer Protection Act. Hangman Ridge Training Stables, Inc. v. Safeco Title Insurance Co., 105 Wash. 2d 778 (1986), requires injury to business or property, and Ambach v. French, 167 Wash. 2d 167 (2009), excludes personal injury losses. No appellate court has applied them to the Act, as far as we can find.
• Contents. Shah v. MyFitnessPal separates reading a public page from telling the site about yourself.
• Class certification. Adventist shows that a uniform technical record can support certification, and that "medical information" may not be uniform across patient portal URLs.

If the FTC sends a civil investigative demand under 15 U.S.C. § 57b-1, get counsel at once. Consent orders typically last 20 years. Their common terms are in the article. AMG, 593 U.S. 67 (2021), limits equitable money under section 13(b), but penalties under the rule and other statutes remain.

If you represent the consumer

Take a look at what the complaints that survived have in common.

• Plead facts, under a pseudonym if needed. Name the site, pages, conditions, dates, and account status. The Santoro plaintiffs refused to, and they lost with prejudice. Rand shows that facts about browsing can carry a complaint.
• Attach real captures, but label them as examples. The Rand district court treated a sample screenshot as the whole complaint. The Fifth Circuit reversed, but plan for that reaction.
• Plead the identity link. Facebook ID, cookie, customer list upload. Rand's concession rested on that link.
• Pick claims by forum. Federal wiretap claims have the party exception problem. CIPA, tort, CMIA, and contract theories have done better. In Kady, negligence, privacy, and breach of confidence survived while the wiretap claim did not. In Frasco, the computer crime claim lost at summary judgment for lack of evidence of damage or loss.
• Name the promise. The privacy policy statements drive contract, deception, and offensiveness analysis.
• Think about Washington injury early. Plead a benefit-of-the-bargain loss if you have one, along with the statutory violation.
• Check limitations and tolling. Kady's pen register claim was dismissed with leave because the plaintiff received targeted ads right away, then waited two years. Shah accepted concealment on a different record.
• Check for an arbitration clause and who agreed to it before you file.

For a person who simply wants to protect herself and isn't looking to litigate, Washington residents can make access and deletion requests and get the list of recipients. Protecting Your Personal Information: A Practical Guide walks through it.

Common mistakes

1. Treating the question as "are we HIPAA?" Answering no doesn't end the inquiry. It begins it. Everyone in this area who got sued outside HIPAA had the same answer.
2. Trusting the vendor list instead of the traffic. Forwarded events, automatic event collection, and server-side connections don't show up in a spreadsheet.
3. Fixing the tag without preserving the record. Destroying evidence after anticipating litigation is its own disaster, and you will need the history for a breach analysis.
4. Believing in hashing. A hash is designed to be matched. Treat it as an identifier.
5. A banner that doesn't block anything. It creates a misrepresentation in place of a mere omission.
6. One big consent. A single "I agree" that bundles collection, sharing, and terms isn't valid in Washington, and it likely fails elsewhere too.
7. Asking for consent after the first event fires. Test the order of initialization with a proxy.
8. Forgetting list uploads. They are a deliberate, documented disclosure and often the worst fact in the file.
9. Saying "we do not sell your data" without reading the definition. Washington's language is broader than the ordinary meaning.
10. Assuming the 2026 rescission ended the breach rule. The Commission withdrew a 2021 policy statement. The 2024 rule remains, and the agency said it superseded the statement.
11. Assuming small companies are exempt. Washington's small-business category only delayed the date. It's now irrelevant.
12. Geofencing through an agency and assuming that's the agency's problem. The statute reaches "any person." Both can be liable.
13. Letting the HIPAA hat and the consumer hat share a codebase. That's how PHI ends up in the marketing tag, as in the telehealth example above.
14. Leaving the discovery date to chance. The rule imputes knowledge from employees and agents. Train marketers to escalate.
15. Writing comforting adjectives. "Private," "secure," "discreet," and "anonymous" have been pleaded as misrepresentations in nearly every case discussed here.

A note on cost and sequencing

A small company with a clean stack can do the first pass for the cost of a few weeks of engineering and a modest legal budget. A company with years of accumulated SDKs and marketing automation should expect more, mostly in deletion and governance. Ad revenue loss from removal is the number that decides how hard the conversation gets, so measure it before arguing about it. A small A/B holdout can answer that question for a modest cost.

If you have to choose, do the steps in this order: traffic capture, ad-tech removal, breach assessment, policy corrections, consent flows, vendor terms, deletion. Everything after the third step can be phased. If you'd like a second set of eyes on where your product falls, MC Law can help. This guide is general information and is not legal advice for a specific situation.

Related Documents

Related Articles

• Consumer Health Data Outside HIPAA: My Health My Data, the FTC, and the Apps That Know Too Much: the doctrine and cases behind each step.
• Telehealth Law: Licensure, Prescribing, Reimbursement, and Privacy: the clinical regulatory layer for telehealth companies.
• Dark Patterns, Auto-Renewal, and the FTC Click-to-Cancel Rule: design limits on consent and cancellation.
• Directors and Officers and Cyber Insurance: Towers, Triggers, Allocation, and the Claim You Must Notice: coverage and notice for privacy claims.
• People-Search Sites and the Right of Publicity: Yearbooks, Data Brokers, and the Persona Class Actions: useful if your data supply chain touches brokers.

Related Guides

• Auditing Your Website Tracking Stack: A Practical Guide: the method for step 3 on the web side.
• HIPAA Business Associates and Cloud Computing: the business associate hat.
• Drafting and Maintaining a Privacy Policy: A Practical Guide: general policy mechanics.
• Data Minimization and Avoiding the Over-Retention of Personal Information: retention and deletion design.
• Bringing or Defending a Civil Computer Fraud and Abuse Act Claim: A Practical Guide: the neighboring access-based claim, including how loss is proved.

Related Checklists

• Consumer Health Data Compliance Checklist: A Practical Checklist: the review tool for this project.
• Data Subject Rights Request Handling Checklist: A Practical Checklist: operations for step 9.
• Vendor Cybersecurity Diligence Checklist: A Practical Checklist: diligence for step 7.

Related Toolkits

• Consumer Health Data Toolkit: Consent Forms, Data Maps, and Breach Notification Decisions: the forms referred to throughout.
• Government Data Demand Toolkit: Legal Process Review, Objections, and Notification: process for step 13.
• Privacy Notice Toolkit: Policy Templates, Consent Flows, and Change Management Records: broader notice materials.