What HIPAA Actually Says About Tracking

HIPAA itself does not mention cookies, pixels, or web tracking — the law was written in 1996 and amended through the HITECH Act in 2009. The relevant rules for online tracking come from two places: the Privacy Rule's definition of PHI, and the Security Rule's requirements for safeguarding electronic PHI (ePHI). Together they say that any individually identifiable health information held by a covered entity or business associate must be protected, and that disclosure to third parties without authorisation or a Business Associate Agreement is an impermissible use.

The OCR Tracking Technology Bulletin

The pivotal regulatory document for publishers is the OCR bulletin titled Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates. The original December 2022 version took an aggressive position — that any IP address collected on a webpage was potentially PHI if the page concerned a specific health condition. After a federal court ruling in 2024 that struck down portions of the bulletin as exceeding OCR's authority, OCR revised the document to draw a sharper line between unauthenticated marketing pages and authenticated patient-portal pages. The 2024 revision is the controlling text in 2026, and it is the document publisher legal teams should keep open on a second monitor while configuring the CMP.

What Counts as PHI in a Tracking Context

OCR treats the combination of an identifier (IP address, device ID, browser fingerprint, hashed email) with information about a specific individual's health (a search for a condition, a click on a treatment page, a form submission with symptoms) as PHI when the combination relates to a known patient or a person who can be identified. The identifier alone is not PHI; the health information alone is not PHI; the combination is. This is the analytical move that catches publishers off-guard, because the standard ad-tech pixel is designed to pass exactly that combination to a third party for measurement and personalisation purposes.

The Authenticated vs Unauthenticated Distinction

The single most important concept in the OCR bulletin is the line between an authenticated page — one a user reaches by logging into a patient portal, an EHR-connected appointment system, a billing console — and an unauthenticated page — the public marketing pages, the condition-information articles, the find-a-doctor search. The compliance posture differs sharply between the two.

Authenticated Pages

Authenticated pages are the high-risk surface. Once a user has logged in, the covered entity knows who they are, and any tracking technology that fires on those pages is potentially disclosing PHI to whatever vendor receives the request. Third-party pixels, marketing pixels, and any analytics tag that operates outside a Business Associate Agreement should not run on authenticated pages at all. The OCR position here is unambiguous and the case settlements have been substantial.

Unauthenticated Pages

Unauthenticated pages are more nuanced. The 2024 OCR revision conceded that not every visit to a public marketing page produces PHI — a user reading a general article about diabetes is not necessarily disclosing that they have diabetes. But the line shifts when the page combines an identifier with a clear health context: a symptom checker that takes free-text input and fires a pixel with the input attached, a condition-specific landing page that uses the URL as a tracking parameter, a find-a-specialist tool that passes the specialty and zip code to an analytics vendor. Those flows turn an unauthenticated page into a PHI surface.

The Practical Test

The practical test publishers run in 2026 is the reasonable expectation test. Would a reasonable person visiting this page expect that their visit indicates a specific health concern? If yes, the page is treated as PHI-bearing for tracking purposes regardless of authentication state. The test is conservative by design — getting it wrong on the permissive side produces enforcement risk, while getting it wrong on the restrictive side produces only lost ad revenue.

Business Associate Agreements and the Vendor Stack

HIPAA permits a covered entity to share PHI with a vendor only when the vendor has signed a Business Associate Agreement (BAA) committing them to HIPAA-equivalent protections. Among the major ad-tech and analytics vendors, the BAA story is uneven and consequential.

Vendors That Sign BAAs

Google offers a HIPAA BAA for Google Workspace, Google Cloud Platform, and a limited subset of Google Analytics 4 deployments under specific configurations. Microsoft signs BAAs for Azure and a constrained Microsoft Clarity setup. A handful of healthcare-specialised analytics platforms — Freshpaint, Heap with HIPAA add-on, FullStory's healthcare configuration — sign BAAs. These are the vendors a HIPAA-covered publisher can use on authenticated or PHI-bearing surfaces.

Vendors That Do Not Sign BAAs

Meta does not sign BAAs for Meta Pixel or Conversions API in any standard configuration. TikTok does not sign BAAs for TikTok Pixel. Most programmatic SSPs and DSPs do not sign BAAs. Standard Google Analytics, standard Google Tag Manager templates, and the default Google Ads conversion tags are not covered by Google's BAA. Running any of these on a PHI-bearing surface is a HIPAA violation regardless of consent banner configuration — consent does not substitute for a BAA when PHI is involved.

The Consent-Plus-BAA Stack

The compliant pattern for a health publisher's marketing pages is the consent-plus-BAA stack. The unauthenticated marketing pages run a CMP with consent gates for any non-essential tracking, the analytics layer is configured under a BAA with a HIPAA-aware vendor, and the marketing pixel layer either runs only on pages that pass the reasonable expectation test or routes through a server-side conversion API that strips identifying information before forwarding to non-BAA vendors.

The CMP Architecture for Health Publishers

The CMP for a HIPAA-covered publisher does more than collect consent. It enforces the page-class distinction, gates vendors by BAA status, and produces an audit log that satisfies both HIPAA's Security Rule documentation requirements and any state privacy law that applies on top.

Page-Class Detection

The CMP must know which page class it is rendering on. The cleanest pattern is a CSP-injected JavaScript variable — set by the server based on URL pattern, authentication state, and content-type metadata — that the CMP reads on initialisation. The variable produces a tri-state: public-low-risk (no health context), public-PHI-bearing (health context, no authentication), or authenticated. The CMP's vendor list and consent defaults shift across the three states.

Vendor Gating by BAA Status

Every vendor in the CMP's vendor list must be tagged with its BAA status and the conditions under which the BAA applies. A vendor with no BAA is hard-blocked on PHI-bearing and authenticated surfaces regardless of consent state. A vendor with a conditional BAA — one that requires specific configuration choices — is allowed only when those conditions are confirmed. The audit log records every vendor decision with the page class, the consent state, and the BAA decision, producing a defensible record for a regulator inquiry.

State-Law Layer

HIPAA is a federal floor; the state laws — California's CMIA, Washington's My Health My Data Act, and the consumer health privacy provisions in Connecticut and Nevada — sit on top with stricter requirements in their specific scopes. The CMP architecture should treat HIPAA as the baseline and layer the strictest applicable state rule on top whenever a user's geographic signal indicates a state with a stronger consumer-health regime.

Common HIPAA Tracking Mistakes That Trigger Settlements

The HIPAA tracking enforcement actions through 2024 and 2025 have produced a clear list of the patterns that lead to OCR investigations. Meta Pixel firing on patient portals because someone added it for marketing analytics without consulting compliance. Google Analytics running on a symptom-checker tool with the symptom passed as a custom dimension. A find-a-doctor page passing the specialty as a URL parameter that the analytics tag captures and forwards. A telehealth onboarding flow with TikTok Pixel installed for paid acquisition and not removed when the user crossed into the authenticated portal. A marketing team A/B test that fired a heatmap recorder on every page including the patient-facing forms. Each of these has produced a public settlement or corrective action plan in the post-2022 enforcement window.

The Bottom Line

HIPAA in 2026 is no longer a back-office compliance regime that the marketing team can ignore. The OCR bulletin, the public settlements, and the maturing line of enforcement against pixel use on authenticated pages have made online tracking a board-level question for any covered entity with a digital footprint. The compliance posture is not impossible — it is a CMP that knows the page class, a vendor stack that respects the BAA boundary, a consent layer that handles the state-law overlay, and a documented architecture that an OCR investigator can read in an hour and walk away convinced. The publishers who invest in that architecture in 2026 keep their digital channels open and their audiences monetisable; the publishers who keep treating health pages like e-commerce pages spend the next two years drafting settlement agreements with the federal government.