Seventy-three percent of major U.S. hospital websites are running advertising or marketing trackers in ways that would be difficult to defend under current regulatory guidance. That finding, from a 2026 Piwik PRO audit of 59 healthcare sites, should alarm every marketing executive in the sector. The trackers were firing despite active Global Privacy Control signals, meaning traditional cookie-blocking approaches would not have stopped them.

The instinct when evaluating any martech tool is to ask: will the vendor sign a BAA? It is the wrong first question. A Business Associate Agreement is a contract. It does not make a tool compliant, and it does not tell you whether HIPAA applies to the data flow you are about to create.

What a BAA Actually Covers

A BAA binds the vendor who signs it to specific safeguards and breach notification obligations. It does nothing for the ad platform you sync audiences to, the pixel another team added last quarter, or the analytics script firing on your patient portal. As Kevin Haag at Qualified Digital puts it, the BAA covers the vendor who signed it, full stop.

The math here is straightforward. Google will not sign a BAA for Google Analytics 4. Meta will not sign one for the Meta Pixel. Neither will TikTok for its tracking code. If your marketing stack sends identifiable health information to any of these platforms, you have an impermissible disclosure under 45 CFR § 164.502(a), regardless of what other vendors in your stack have signed.

The settlements tell the story. Advocate Aurora Health paid $12.225 million to resolve claims that Meta Pixel, Google Analytics, and other tracking tools on its website, patient portal, and scheduling app disclosed protected health information to third parties without consent. Novant Health settled for $6.6 million over a misconfigured Meta Pixel that transmitted patient data from its MyChart portal. Both organizations had compliance programs. Both had BAAs with their covered vendors. Neither had visibility into what their client-side tracking code was actually sending.

The Identifier Problem

HIPAA regulates entities, not data categories. It covers health plans, clearinghouses, and providers that bill electronically, plus the business associates who handle protected health information for them. The question is whether the data qualifies as PHI: identifiable information tied to someone's health, care, or payment for care.

In martech, the identifier is rarely a name. It is an IP address next to a URL that reveals a condition. A hashed email paired with an appointment date. A device ID combined with a form submission on a page about oncology consultations. The HHS tracking guidance makes clear that these combinations can constitute PHI when they reveal health context.

A 2024 federal court ruling vacated the portion of that guidance covering IP addresses on unauthenticated public pages about conditions or providers. Some marketers read that as a green light. It was not. The rest of the guidance stands. Patient portals, apps, booking flows, and pages where people enter symptoms remain in scope. And as Coast Studio's tracking analysis notes, the enforcement risk simply moved to three other places: the FTC, state attorneys general, and plaintiffs' lawyers.

The FTC Parallel Track

If you are not a covered entity, you are not in the clear. The FTC's Health Breach Notification Rule requires vendors of personal health records and related entities to notify consumers, the FTC, and in some cases the media if there is a breach of unsecured, individually identifiable health information. July 2024 amendments made clear that makers of health apps, connected devices, and similar products must comply.

The FTC defines breach broadly. It includes unauthorized disclosures, not just cybersecurity incidents. Sharing user data with advertising platforms without proper consent can trigger notification obligations. GoodRx paid $25 million in a class action settlement for sharing prescription data with ad networks. BetterHelp paid $7.8 million for sharing mental health information. Neither was a HIPAA covered entity.

In September 2026, the FTC rescinded its 2021 policy statement that had extended the Health Breach Notification Rule to health apps outside HIPAA's reach, calling it "obsolete" and "superseded by rulemaking." That does not mean the underlying rule disappeared. It means the interpretive guidance shifted. Health app developers still face FTC Act Section 5 exposure for unfair or deceptive practices, and state consumer protection laws remain fully in force.

The code that powers your marketing may be undermining your compliance.
The code that powers your marketing may be undermining your compliance.

The Proposed Security Rule Changes

The compliance surface is about to expand. In January 2025, HHS published a Notice of Proposed Rulemaking that would significantly strengthen the HIPAA Security Rule. Among the proposed requirements: covered entities would need to obtain written verifications from their business associates that each has deployed and is operating technical safeguards protecting ePHI.

The proposed rule would remove the distinction between "required" and "addressable" implementation specifications, making all specifications mandatory with limited exceptions. It would require technology asset inventories, network maps illustrating ePHI movement, annual compliance audits, and vulnerability scanning every six months. According to HIPAA Journal, the final rule has been delayed until July 2027, but the direction is clear: documentation that your policies describe a world your systems actually enforce.

Server-Side Is Not a Silver Bullet

Server-side tagging changes where data is collected, not what gets sent onward. Forward PHI to a vendor without a BAA, and it is the same disclosure through a different pipe. Federal guidance says a vendor's promise to strip PHI after receipt does not cure the impermissible disclosure.

The value of server-side architecture is the control point. You can filter before anything leaves. You can scrub identifiers, hash data properly, and document what you are sending and why. But the architecture alone earns nothing. The FTC named Meta's Conversions API in the Hims complaint, demonstrating that server-side transport without proper controls is still a violation.

The Audit You Should Run This Quarter

Start with a client-side review of every page that touches health context: patient portals, booking flows, intake forms, condition-specific landing pages. Document every script, pixel, and network call. Map where data goes and who receives it.

For each vendor receiving identifiable data, answer three questions. First, do they have a signed BAA? Second, does the data flow match what the BAA covers? Third, is the use case permissible under HIPAA's marketing rules, which require patient authorization for most marketing uses of PHI?

Then look at your consent architecture. State privacy laws with private rights of action, particularly California's CCPA and the growing list of states recognizing Global Privacy Control signals, create exposure independent of HIPAA. If your trackers fire despite opt-out signals, you have a problem that no BAA can solve.

The organizations that treat compliance as an infrastructure capability rather than a documentation exercise operate with a fundamentally different posture. They embed privacy controls in data pipelines instead of layering them on top after the fact. They know what their systems actually do, not just what their policies say they should do.

A BAA is necessary. It is not sufficient. The gap between those two words is where the $100 million in pixel settlements came from.