Govern your trackers before a pixel leaks patient data.
A full tag and tracker inventory, then the cleanup: remove or server-side proxy anything that leaks protected health information, migrate you to privacy-first or BAA-backed analytics, and enforce consent across the whole stack rather than just standing up a banner. We document how authenticated and unauthenticated pages are handled, because the rules treat them very differently. One detail up front that settles most of the question: GA4 will not sign a Business Associate Agreement, so it cannot live on any page that touches health information.
// no website is HIPAA compliant on its own; compliance is an organizational posture across your whole practice. Tracking governance is the technical layer we own. We remove the most common way a healthcare site leaks PHI; your practice still owns the agreements, the risk analysis, the training, and the breach determinations.
> A banner is not a HIPAA authorization.
> Consent has to be enforced, not performed.
The tracker you forgot about is the one that sues you.
Most tracking trouble on healthcare sites is not deliberate. It is a marketing pixel someone added years ago for a campaign, a tag manager full of half-remembered snippets, an analytics tool that came bundled with a theme. None of it was meant to handle health information, and that is exactly the problem: nobody decided it should, so nobody governed it, and it quietly kept shipping page URLs, search terms, and form interactions to advertising vendors with no agreement to receive them. Governance starts with seeing the whole picture, which is why the first thing we do is inventory every tag and tracker on the site rather than guess.
From there the cleanup is mostly judgment applied per tracker and per page. Advertising pixels on or near pages that touch health information come off, because they have no legitimate job there. The measurement you genuinely need gets migrated to a privacy-first analytics tool that does not collect identifying data, or to a vendor that will sign a Business Associate Agreement for the surfaces that require one. Where you need real analytics without handing a third party the raw payload, we route the data through a server you control first, strip what is sensitive, and forward only what is safe. The result is a site that still tells you what you need to know without leaking what it must not.
The drivers here are real and current, not theoretical. More than 100 million dollars in pixel-tracking settlements have landed since 2023, and the OCR online-tracking bulletin still binds authenticated and portal pages even after American Hospital Association v. Becerra vacated only the unauthenticated-page theory in 2024. We state those facts plainly and attach no invented outcomes of our own. This page pairs closely with our Insights article on HIPAA-aware web development, which lays out the full tracking history.
What governance covers
Tracking governance is one technical piece of a healthcare site, sized to what your site actually runs.
- A complete tag and tracker inventory across the site
- Advertising pixels removed from PHI-handling pages
- Sensitive measurement server-side proxied, not shipped raw
- Analytics migrated to privacy-first or BAA-backed tools
- Consent enforced across the whole stack
- Authenticated and unauthenticated handling documented
What the rules actually say, stated plainly.
This is regulated ground where the facts are genuine and the hype is thick. We state what is real, we mark what was narrowed by the courts, and we never dress any of it up with numbers we made up.
// the bulletin still binds authenticated pages; a banner is not authorization
OCR online-tracking guidance
The OCR online-tracking bulletin set out HHS guidance on when website trackers implicate HIPAA. In 2024, American Hospital Association v. Becerra vacated one specific part: the theory that an IP address on an unauthenticated public page, on its own, could turn ordinary browsing into protected health information.
The court vacated only that unauthenticated theory. The rest of the bulletin still stands and still binds authenticated and portal pages, where a logged-in patient is identified and the content is health-related by definition. The prudent posture barely moved: keep generic tracking off authenticated and PHI-handling pages.
More than 100M dollars since 2023
The lawsuits are not hypothetical. More than 100 million dollars in pixel-tracking settlements have landed since 2023, driven by ad and analytics trackers found on hospital and provider pages sending data to advertising platforms. These are genuine, public matters.
The recurring fact pattern is the one this work exists to prevent: a tracker quietly moving identifiable, health-adjacent data to a vendor with no agreement to handle it. We will not promise governance makes a lawsuit impossible, but it removes the exact channel these cases turn on.
The whole cleanup, not just the obvious pixels.
Governing tracking properly means seeing every tag, deciding the fate of each one on purpose, and then making consent do real work rather than perform it. These are the parts we build into the engagement, sized to what your site actually carries rather than padded.
We choose between removal and server-side proxying per tracker and per page, document each decision, and keep anything that cannot be made safe off the PHI-handling surfaces entirely. The line we hold throughout: no pixel is ever left as a channel that hands health information to a vendor you have no agreement with.
What is included
- A complete tag and tracker inventory across the site
- Remove or server-side proxy PHI-leaking trackers
- Migration to privacy-first or BAA-backed analytics
- A clear flag that GA4 will not sign a BAA
- Consent enforced across the whole stack, not just a banner
- Documented authenticated vs unauthenticated page handling
- Tracking kept off authenticated and PHI-handling pages
- No pixel left as a channel that leaks PHI to a vendor
A banner is not a HIPAA authorization.
This is the misunderstanding that does the most damage. A cookie consent banner manages cookie preferences; clicking accept on it does not give you a patient's informed, specific authorization to disclose their health information to an advertising vendor. Treating the banner as if it does is how a site convinces itself it is covered while it quietly is not.
So we enforce consent through the whole stack rather than performing it at the surface. The banner choice has to actually gate what loads and what fires, in the browser and server-side, not just set a cookie while the trackers keep running underneath. And the pages that handle protected health information are governed so that no amount of banner-clicking turns them into a lawful channel for disclosure.
We also document the boundary that the rules care about most: which surfaces are authenticated and which are not, and exactly how each is handled. That documentation is what lets you, and an auditor, see that the enforcement is real and that the dividing line is being held.
How consent is enforced, not performed
- The banner choice gates what loads and what fires
- Enforcement in the browser and server-side, not just a cookie
- PHI-handling pages governed regardless of banner state
- No tracker runs underneath an unaccepted choice
- Authenticated and unauthenticated surfaces mapped
- Each surface's handling documented for audit
- The public-versus-authenticated boundary held and recorded
- A plain account of where a banner does real work
// clicking a cookie banner is not a valid HIPAA authorization
Inventory, decide, enforce, document.
We do not guess at what is on the site. We map every tracker, decide the fate of each one deliberately, enforce consent so it does real work, and document the whole posture so it can be checked and maintained.
// see everything, govern each tag on purpose, keep nothing that leaks
- Inventory every tag and trackerWe map the whole tracking surface: tags in the tag manager, scripts hard-coded into templates, pixels embedded in themes and plugins, and anything firing on intake and search. You cannot govern what you cannot see, so the inventory comes first and it is complete rather than a sample.
- Classify against PHI scopeFor each tracker we ask what it sees and where it fires. Anything that can touch authenticated pages, intake, search terms, or condition-specific URLs is treated as in scope for protected health information, and anything that ships data to a vendor with no BAA is flagged for removal or proxying.
- Remove or server-side proxyAdvertising pixels with no legitimate job on or near PHI pages come off. Measurement you genuinely need but cannot ship raw is routed through a server you control, stripped of identifying and health-related data, and forwarded only with what is safe. The choice is made per tracker and recorded.
- Migrate the analytics that remainThe numbers you actually use move to a privacy-first analytics tool that collects no identifying data, or to a vendor that will sign a BAA for the surfaces that require one. Where a current tool will not sign a BAA, GA4 included, it comes off the PHI-handling pages entirely.
- Enforce consent and document the postureWe wire consent through the whole stack so the banner choice gates what loads and fires, then document how authenticated and unauthenticated pages are handled. The documentation is what lets you and an auditor confirm the dividing line is real and being held.
Frequently asked questions
Related services
Tracking governance is one piece of HIPAA-aware healthcare web. These are the neighboring services and the hub that ties them together. For the full history behind the tracking problem, the Insights article below lays it out in detail.
Not sure what your trackers are doing on patient pages?
That uncertainty is the risk. Tell us what is on the site and we will inventory every tag, give you a straight read on what leaks and what does not, flag anything that cannot sign a BAA, and lay out the cleanup. We build the technical layer; your practice keeps the posture.