HIPAA website compliance: health pages and ad trackers

The rule

Two federal regimes sit behind this check, and which one applies depends on who runs the site.

For websites, HHS’s Office for Civil Rights set out its reading in a bulletin on online tracking technologies. It says a regulated entity may not use tracking technologies in a way that results in impermissible disclosures of protected health information to tracking vendors, and that a vendor receiving it on the entity’s behalf is a business associate that needs an agreement. A part of that bulletin did not survive: on 20 June 2024 the Northern District of Texas, in American Hospital Association v. Becerra, vacated the guidance to the extent it said HIPAA is triggered where a tool links an IP address to a visit to an unauthenticated public page about health conditions or providers. Pages where a visitor enters an email address, a symptom or a reason for an appointment were not part of what was vacated, and the bulletin still treats those as capable of involving protected health information.

Outside HIPAA, the FTC fills the gap. The Health Breach Notification Rule applies to “vendors of personal health records, PHR related entities, and third party service providers” and expressly “does not apply to HIPAA-covered entities” (16 CFR 318.1(a)).

Enforcement under the rule runs through the FTC Act: any violation “shall be treated as a violation of a rule promulgated under section 18 of the Federal Trade Commission Act”, which carries civil penalties adjusted for inflation (16 CFR 318.7). HIPAA civil money penalties are set in tiers by culpability (45 CFR 160.404).

The FTC does not need the Health Breach Notification Rule to act. Its BetterHelp announcement, a month after GoodRx, rests on allegations that the company broke its own privacy promises, and the press release does not mention the rule. The FTC’s second Health Breach Notification Rule case, Premom, followed in May 2023 under a proposed order. The California Attorney General reached a health publisher through the CCPA, as the Healthline matter shows.

What PeekWell checks and how

US-12 asks one question about pages that are about health: does an advertising or analytics tool receive an identifier from them? It applies where a site has been marked as health-adjacent, and it is skipped for other sites.

The scan loads public pages in a clean browser and records every network request and cookie, as in the other tracker checks. Where the site is health-adjacent, it classifies each page’s context to work out which pages are about health. Tracker detection is deterministic: request domains and cookie names are matched against a maintained list of advertising and analytics tools. A finding appears when a tool on that list is seen on a health-context page, sending something that identifies the browser or the person. A language model helps with the page classification and the wording of the report. It does not decide that a tool fired.

The tracker detection is the same as in EU-01 and US-02. What differs is the page it cares about: a tracker on a contact page and one on a page about a diagnosis are different observations.

The scan has limits, and the report says so. It sees only public pages and nothing behind a sign-in, so it cannot see the patient portals where the HHS bulletin sees the most risk. It does not submit forms, test passwords or open addresses nobody linked to. It does not decide whether you are a covered entity, a business associate or a vendor of personal health records, and it does not read contracts, so it cannot know whether a business associate agreement or an authorization exists. Collection on a server or inside an app is outside what a browser visit can see, and page classification can be wrong. A Passed means the expected behaviour was observed on the pages scanned. It does not say the site complies.

Why it matters for a company

These cases share a pattern: a health service promised privacy, and an ad pixel or software kit sent identifiers and health details to an ad platform. The FTC alleged that GoodRx shared prescription and condition information with Facebook, Google, Criteo, Branch and Twilio, and used it to target ads. BetterHelp was alleged to have shared email addresses, IP addresses and questionnaire answers with four ad platforms. Monument was alleged to have told users their information was “100% confidential” while pixels sent details to Meta and Google.

The outcomes were similar. The proposed orders would ban sharing health data for advertising, require consent for other sharing, and direct the companies to seek deletion of data already shared. GoodRx agreed to a $1.5 million civil penalty, and under BetterHelp’s proposed order $7.8 million was to fund partial consumer refunds. Monument’s proposed order carried a $2.5 million penalty that was suspended because of its stated inability to pay, with the full sum due if its financial statements proved untrue, and it needed court approval.

A publisher was not outside this. The California Attorney General’s Healthline settlement concerned article titles such as “You’ve Been Newly Diagnosed with MS. What’s Next?”, which could reveal a diagnosis to advertisers, and an opt-out that was alleged not to work.

For a company the practical points are these. A health promise in a privacy notice becomes a fact an authority can compare with network traffic. Sharing may be a notifiable event under the FTC rule. And a pixel’s data has already left once the page loads. Removing a pixel later stops new sharing but does not recall what was sent.

Smaller companies and larger companies

Neither rule has a minimum company size, and the FTC rule applies “irrespective of any jurisdictional tests” (16 CFR 318.1(a)). Monument is the smaller company in the cases listed here.

In a small company, the problem usually begins with a growth tool. A telehealth startup, a clinic with a template site or a wellness app adds the Meta Pixel and Google tags to measure ads, and the same snippet runs on the page where visitors choose a condition or pick a treatment.

In a larger company the pieces are spread out. A hospital group or a health publisher has a tag manager with dozens of tags owned by different teams, several domains, and a mix of authenticated and public pages. A tag approved for the marketing site can end up on a page that asks for symptoms after a template change.

How to fix it

The aim is to make sure only the tools you have chosen see health pages, and that you can say why.

1. Decide which rulebook applies. Ask your legal adviser whether you are a covered entity or business associate under HIPAA, a vendor of personal health records under the FTC rule, or neither. Steps 2 to 4 help in all three cases.
2. List what loads on each health page. Open a private window with the browser’s network tab open and visit your condition, treatment, symptom checker and booking pages. Note every third party that receives a request, and what is in it: cookie IDs, advertising IDs, email addresses, form values and page titles or URLs that name a condition.
3. Remove or restrict advertising tags on those pages. In your tag manager, set advertising and retargeting tags to exclude health-context pages, or remove them. Where a tool is needed, check whether the vendor offers settings for sensitive data and read what it says about health categories.
4. Strip what names a condition. Keep diagnosis words out of URLs, page titles and event names that go to analytics.
5. Match the contracts and the notice. If you are a regulated entity and a vendor handles protected health information for you, confirm there is a business associate agreement. Check that the privacy notice describes what actually leaves the site, since the FTC cases rest on promises that did not match.
6. Re-scan. Clear cookies and storage, reload and run a scan again. The finding should disappear once no advertising or analytics tool receives an identifier from a health-context page.

Whether a particular setup satisfies HIPAA or the FTC rule is a question for your legal adviser, and Peeky reports only what it sees.