In June 2024 a federal court in Texas vacated part of the federal guidance on tracking technologies in healthcare, and a lot of marketing teams heard a single sentence: the pixel rules were struck down.
They were not, and the gap between what the court did and what people believe it did is now one of the more expensive misunderstandings in healthcare digital.
Here is what actually happened. In December 2022 the Office for Civil Rights issued a bulletin stating that an IP address combined with a visit to an unauthenticated page about a specific condition or provider could constitute individually identifiable health information. The American Hospital Association, the Texas Hospital Association, and two health systems sued. In March 2024, while the case was pending, OCR revised the guidance to hinge on the visitor's subjective reason for visiting, which made compliance harder rather than easier, since no organisation can read a visitor's mind. On 20 June 2024 the court held that the department had exceeded its authority and vacated the guidance as to that specific combination. HHS later withdrew its appeal.
So one narrow claim about unauthenticated pages was struck down. That is the whole of it.
A note before the detail: this is engineering guidance, not legal advice. Where the line falls for a specific organisation is a question for privacy counsel, and the architecture below is designed to be defensible wherever counsel draws it.
The line that did not move
The ruling left the guidance on authenticated pages entirely intact.
That matters more than the part that was vacated, because authenticated pages are where the actual risk lives. Patient portals. Telehealth platforms. Appointment booking behind a login. Anything a user has to sign in to reach. Tracking technologies on those pages generally do have access to protected health information, and nothing about the 2024 decision changed that.
Nor did the decision touch three other exposures that were never based on the guidance in the first place.
Class actions. Litigation against health systems over tracking technologies proceeded independently of the bulletin and continues. Those claims rest on state privacy statutes, wiretapping laws, and common law theories, none of which the court's ruling addressed.
State privacy law. A growing body of state legislation covers consumer health data on its own terms, with obligations that do not track HIPAA's definitions at all.
The FTC. Enforcement activity around health data sharing runs on a separate authority entirely.
Put together, an organisation that responded to the ruling by restoring its previous tracking setup reduced one category of federal exposure and left the others exactly where they were.
Why the legal question is the wrong one to optimise
The instinct after a ruling like this is to work out precisely how much tracking is now permitted and run right up to that line.
That is a bad strategy here for three reasons. The permitted line is contested and moves. It differs by state. And the most expensive exposures, the class actions, do not depend on where the federal line sits.
The better question is an engineering one. Rather than asking whether a given pixel is legal, ask what your site actually sends to third parties, and redesign the flow so the answer is defensible under any of the competing standards. That is a data architecture problem, and it has a clean solution that does not require predicting how the law settles.
The architecture answer
Four moves, in order of effect.
1. Zone the site by what it handles
Not every page carries the same risk, and treating the whole domain as one environment is what creates the problem.
Draw a hard boundary between pages that handle no patient-specific data, pages where a visitor supplies clinical context such as a symptom-led form or condition-specific enquiry, and pages behind authentication. Those are three different tracking regimes, and they need three different tag configurations rather than one global container.
Most healthcare sites deploy a single tag manager container everywhere, which means the strictest page inherits the loosest configuration. Zoning is the single highest-impact change available and it is mostly configuration rather than engineering.
2. Move measurement server-side
Client-side tags send whatever the browser has, including the full URL, referrer, and any identifiers present in the page, directly to a third party. You do not get to inspect that payload before it leaves.
Server-side collection inverts it. The browser reports to infrastructure you control, you decide what is forwarded, and identifiers can be stripped or replaced before anything reaches an external vendor. That is a backend development and cloud engineering build rather than a marketing setting, which is precisely why it usually does not get done.
It is also the change that makes the rest of the architecture possible, because you cannot control what you cannot intercept.
3. Stop sending identity to vendors who will not sign a BAA
This is the rule that cuts through most of the ambiguity.
The major advertising and analytics platforms do not sign business associate agreements. If a vendor will not sign one, the practical conclusion is that nothing identifying should reach it from any page where clinical context exists. Not because a court has definitively said so, but because there is no configuration under which that arrangement becomes comfortable if the data is ever characterised as PHI.
Where a healthcare organisation needs measurement on sensitive pages, the options are self-hosted analytics, a vendor that will sign a BAA, or aggregate reporting that never carries an identifier. All three are workable. Running a consumer ad platform on a portal is not.
4. Instrument outcomes, not identities
Most of what marketing teams actually need from analytics is counts and conversion rates, not person-level tracking.
How many people started a booking, how many finished, which pages precede enquiry. Those questions are answerable from aggregate, de-identified data. The identity-level tracking is typically there because the default installation includes it, not because anyone specified it.
Ask what decision each data point informs. A surprising proportion of the risk on a healthcare site is being carried for measurement nobody uses.
What to audit this week
Five checks, none requiring a project.
Open the site with a network inspector and list every third-party domain receiving data. Most teams find vendors nobody remembers installing.
Do the same on a page behind login. That is the one that matters.
Check what appears in the URL on form and booking flows. Conditions, procedures, and provider specialties in query strings are sent to every tag on the page.
List which of those vendors will sign a business associate agreement. It is usually a short list.
Check whether your intake and enquiry forms post anywhere other than your own systems, which is the same discipline covered in intake forms software work.
Where Woltrio fits
Woltrio builds the collection and routing layer that sits between a healthcare website and its analytics vendors, which is where this problem is actually solved.
In practice that means zoned tag configuration, server-side collection with identifiers stripped before forwarding, and measurement designed to answer the questions the marketing team has without carrying person-level data it never needed. Where the exposure sits behind authentication, the work extends into patient portal software development and the frontend development that controls what the page exposes in the first place. The wider capability set sits under services.
The framing worth taking away is that the 2024 ruling made one federal question narrower and left the underlying engineering question untouched. Organisations that treated it as permission are carrying the same risk they had in 2023. Organisations that treated it as a prompt to fix the data flow are now compliant under standards that have not been written yet.
Start with a scoped assessment from Woltrio.