How HealthPixel Check works: what we measure on a health-care website, and what we can't see

Tracking tools are usually added to a health-care website to measure marketing, not to share health information: which ads bring visitors, which pages lead to a phone call, where people drop off. The tools, however, often send more than the marketing team expects, and they usually start sending it the moment a page loads.

HealthPixel Check exists to make that data flow visible. This post explains what the check measures, how it decides what to report, and what it cannot see.

Why this matters

US regulators have pointed to online tracking technologies on health websites as a channel through which sensitive information can reach third parties. The HHS Office for Civil Rights published guidance on the use of online tracking technologies by HIPAA covered entities and business associates; in June 2024 a federal court vacated part of that guidance (American Hospital Association v. Becerra), so check the page for its current status. For health apps and other services not covered by HIPAA, the FTC’s Health Breach Notification Rule requires notice of a breach of health information, and the FTC treats an unauthorized disclosure to third parties, not only a hack, as a breach.

We mention these only as context. HealthPixel Check is a measurement tool. It does not decide whether any website complies with any law, and its results are not legal advice.

What a check does

A check opens a public website in a clean, headless Chrome browser, with no cookies and no history. The browser moves the mouse and scrolls, the way a visitor reading the page would. It never fills in or submits forms, never logs in and never types personal data.

Given a home page, the check visits it plus one or two typical inner pages: a service or condition page, and an insurance, admissions or contact page. Given a specific page, such as an ad landing page, it starts there.

While the pages load, the browser records every request sent to known advertising, analytics, session-replay, call-tracking and chat-widget services. For each one, the check looks at what was sent: the event name (for example a PageView), custom parameters, and whether the address or title of the page went along with it.

Up to five runs, each in a fresh browser

A cookie banner changes what a site does, so one visit is not enough. The check repeats the visit in up to five separate, fresh browser profiles. Accept and Reject run only if a cookie banner is found; Direct entry runs only when the check starts from the home page. The runs are described in detail on the methodology page:

1. No choice. The banner is left alone. This is what every visitor’s browser sends before deciding.
2. Accept. The browser clicks the banner’s accept button and repeats the visit.
3. Reject. The browser declines, using the open-source DuckDuckGo autoconsent rules, and repeats the visit.
4. Global Privacy Control. The browser sends the GPC opt-out signal used by privacy-focused browsers.
5. Direct entry. A separate visit lands directly on a service page, as someone arriving from an ad or a search result would. Some tools, call tracking for example, record only the first page of a visit.

Comparing the runs answers practical questions. Does anything fire before the visitor chooses? Does “Reject” actually stop the advertising tags? Is the GPC signal honored? How a finding is decided from these runs is set out in the rules table.

What counts as “condition-naming”

Knowing that a visitor loaded a page is one thing. Knowing that they loaded /opioid-addiction-treatment/ or a page titled “HIV Testing” is another. The check flags a request when the URL path, query or page title it carries contains a term that names a condition, substance, procedure or medication. The hostname is never counted, so a clinic called, say, Example Dental is not flagged for its own name.

Setting words such as treatment, outpatient or therapy are counted as “care-related” rather than “condition-naming”. On their own they say little about a particular person’s health.

Trackers that look first-party

Some tracking is served from an address on the site’s own domain, such as metrics.example.org, while the DNS record points to a vendor. This is often called CNAME cloaking. The check resolves the DNS chain for every first-party host a page contacted and compares it with the open AdGuard list of known cname trackers and with a list of server-side relays and customer-data platforms (details). It also reports signals of server-side tagging, such as Google Analytics collection on a first-party subdomain.

What we can’t see

A browser sees what a browser sends. That leaves real gaps:

• Server-to-server transfers. If a website’s server sends events directly to an advertising platform, for example through a conversions API, no request appears in the visitor’s browser.
• Logged-in areas. Patient portals and accounts are out of scope.
• Form submissions. The check never submits forms, so it cannot see what happens after someone requests an appointment.
• What happens next. The check cannot see how a vendor uses the data, or what agreements are in place.

A clean result means nothing was observed in these runs on these pages. It does not prove that nothing is shared. Sites also change; a result reflects the site at the time of the check. The methodology page lists the same limits.

Who sees the results

The public summary in the checker shows vendor names and counts, without exact page addresses or screenshots. A link to the full report, with the pages, titles and screenshots, is e-mailed only to an address at the checked organization’s own domain, and the link works for 72 hours (responsible use). The aim is to help the people who can fix a data flow, while keeping the measurement their marketing needs.

Run it yourself

The engine behind the checker is open source under the MIT licence: healthpixel-audit on GitHub. It runs the same rules from the command line and can be added to a CI pipeline to check your own site on every release. The vendor list and the condition vocabulary are plain files, and corrections are welcome.

If you think a finding about your site is wrong, write to [email protected]. The full method is described on the methodology page.