When Do You Actually Need a BAA for Web Trackers?
Every healthcare vendor pitch eventually says the letters "BAA." Fewer will tell you plainly when a business associate agreement is actually required for the trackers on your website — and when it isn't. This is the honest version: what triggers a BAA, why Google and Meta won't sign one for their ad products, and what a cookie banner can and can't do.
A business associate agreement is required whenever a vendor creates, receives, maintains, or transmits protected health information (PHI) on your behalf (45 CFR 160.103). For web trackers, that means: the moment an analytics or advertising tool actually receives PHI from your site, you need a signed BAA with that vendor — or you must stop the PHI from reaching it.
The catch that trips up most healthcare organizations: the big ad and analytics platforms won't sign BAAs for their advertising products. So in practice your real choices are (1) don't send them PHI, (2) route data through a BAA-covered proxy that strips PHI first, or (3) obtain a valid HIPAA authorization. A cookie banner is none of these. This guide walks through exactly when you're in each situation. It's general information, not legal advice.
If you run marketing or compliance for a hospital, clinic, health system, or digital-health company, you've had this conversation: someone asks whether the analytics or ad tools on your website need a "BAA," and the answers you get are either hand-wavy ("better safe than sorry, get one for everything") or dangerously casual ("it's just a marketing pixel, it's fine"). Both are wrong, and both are expensive. The accurate answer is specific, and once you understand the trigger, most of the confusion disappears. Let's build that understanding from the regulation up — and be honest at every step about what does and doesn't solve the problem.
The rule: what actually triggers a BAA
HIPAA's requirement for a business associate agreement isn't vague. It flows from a single definition. Under 45 CFR 160.103, a "business associate" is a person or entity — other than a member of your workforce — that creates, receives, maintains, or transmits protected health information on behalf of a covered entity to perform a function or service.1 If a vendor does that, HIPAA requires you to have a signed BAA with them before PHI changes hands. If a vendor doesn't touch PHI at all, no BAA is required, regardless of what service they provide.
A vendor becomes a "business associate" — and a BAA becomes mandatory — the moment it creates, receives, maintains, or transmits PHI on your behalf. The service type is irrelevant; PHI access is everything. A billing company that sees patient data needs a BAA. A landscaping company that never sees PHI doesn't.
So the entire question of "do I need a BAA for this tracker?" collapses into one prior question: does this tracker actually receive PHI? That's harder to answer than it sounds, because on a healthcare website, ordinary-looking data can become PHI in combination. An IP address on its own is one thing; an IP address paired with the fact that someone booked an appointment in the oncology department, or viewed a page about a specific treatment, can be individually identifiable health information. When that combination is transmitted to a third-party tool, that tool is now receiving PHI — and the BAA trigger is pulled.
Two clarifications that matter for web trackers specifically:
- "Maintains" includes storage — even encrypted storage. HHS settled this in its 2016 Cloud Computing Guidance: a cloud service provider that merely stores ePHI is a business associate even if the data is encrypted and the vendor never holds the decryption key, because it "maintains" ePHI on your behalf.2 "We encrypted it" does not remove the BAA obligation.
- Intent doesn't matter. If a pixel transmits PHI to an ad platform, the BAA obligation exists whether or not anyone meant to send it, and whether or not the platform wanted to receive it. HIPAA looks at what happened to the data, not what you intended.
The conduit exception — and why it almost never saves a tracker
There is one genuine carve-out, and vendors love to invoke it: the conduit exception. HHS says entities whose only role is transporting PHI — without accessing it in any meaningful way — aren't business associates. The classic examples are the U.S. Postal Service, UPS, and internet service providers: they move sealed packages or packets without routinely looking inside.3
Here's why it rarely rescues a web tracker: the exception is deliberately narrow, limited to transient transmission with no access and no storage. An analytics or advertising platform doesn't just transport data — it receives it, stores it, processes it, builds profiles from it, and uses it. That's the opposite of a conduit. HHS's own guidance draws the line at "transient versus persistent" access: a courier is transient; a cloud analytics platform holding your event data is persistent. So when a martech vendor waves the conduit exception at you to explain why they don't need a BAA, that's usually a red flag, not reassurance.
Ask a vendor one question: "Do you store, process, or use the data our site sends you — or do you only transmit it unopened?" Analytics and ad platforms always do the former. If they store or use it and it can contain PHI, the conduit exception doesn't apply and a BAA (or keeping PHI away from them entirely) is required.
The decision, in one diagram
Before the details, here's the whole logic in a single flow. Every tracker on a healthcare site can be walked through these questions.
When a BAA is — and isn't — required
Putting the rule into practice, here's the clean split for the tools that show up on healthcare websites.
A BAA IS required when…
- An analytics or ad tool receives data that identifies a person and relates to their health, care, or payment — e.g. a pixel firing on an appointment-confirmation or lab-results page.
- A vendor stores or processes ePHI on your behalf — even encrypted, even if they can't read it (2016 Cloud Guidance).
- A CRM, CDP, scheduling, or chat tool ingests patient identifiers tied to health context.
- A session-replay tool captures form fields or page content containing PHI on authenticated or sensitive pages.
- Any subcontractor of a business associate touches that PHI (the BAA chain extends downstream).
A BAA is NOT required when…
- The tool genuinely never receives PHI — e.g. analytics on a purely informational page with no identifiers and no health context, properly configured.
- The vendor is a true conduit that only transports data without accessing or storing it (rare for web tools).
- Data is fully de-identified to the HIPAA standard before it leaves your control, so what the vendor receives is no longer PHI.
- The service involves no PHI at all (e.g. a font CDN, a purely cosmetic widget with no data capture).
The dangerous middle ground is a tool you believe doesn't receive PHI but actually does — because of what page it's on, or what identifiers it quietly collects. That gap between "what we think fires" and "what actually fires" is where nearly every healthcare tracking case begins. You can't answer the BAA question for a tool until you know exactly what data it receives, on which pages. That's a detection problem before it's a legal one.
Six real tracker scenarios, with verdicts
The abstract rule is clearer applied to the tools actually sitting on healthcare sites. Each verdict below assumes a US healthcare covered entity; "need," "maybe," and "no" refer to the BAA obligation specifically.
The pixel transmits the visit (which implies a condition or care) tied to identifiers to Meta. That's PHI reaching a vendor, so a BAA is required — but Meta does not sign BAAs for its advertising pixel. Result: you cannot make this arrangement compliant with a BAA. You must stop the PHI from reaching Meta (block it, or route through a BAA-covered proxy that strips identifiers) or obtain authorization. This exact pattern drove multiple multi-million-dollar settlements.
Authenticated and scheduling pages carry the strongest PHI implication. GA4 receiving that data triggers the BAA requirement — and Google does not offer a BAA for Google Analytics. Google's own policy prohibits sending PHI to GA at all. So the compliant route isn't "get a BAA," it's "ensure GA never receives PHI," which on these pages usually means keeping it off them entirely.
If the tool ingests patient identifiers with health context and the vendor will sign a BAA, this is the straightforward case: execute the BAA, configure the tool per its HIPAA guidance, and document it. This is what the "just get a BAA" advice is actually for — vendors built to be business associates.
Replay tools can capture keystrokes and form contents — potentially the most sensitive PHI on the site. A BAA would be required if the vendor receives that data; most session-replay vendors aren't set up as healthcare business associates. Separately, capturing a visitor's interaction in real time is the core theory behind CIPA "wiretapping" claims — so this tool carries both a HIPAA/BAA problem and a state-law consent problem at once.
If a page carries no PHI and the tool is configured so it receives none, the BAA trigger isn't pulled. This is the genuine "no BAA" case. Note the caveat: state consent laws (CIPA/CCPA) can still apply to non-essential trackers regardless of PHI, so "no BAA" is not "no obligations." Configuration and page context are doing the work here — verify, don't assume.
Here the proxy vendor signs a BAA with you and becomes your business associate; it strips or de-identifies PHI server-side before forwarding events to Google or Meta. You need a BAA with the proxy, not with the ad platform (which now receives only de-identified data). This is the architecture the specialized healthcare marketing vendors sell — a genuinely different product category from a consent tool.
The Google & Meta reality that changes the math
This is the single fact that reframes the whole BAA conversation for healthcare marketers, and it's worth stating bluntly: Google and Meta do not sign business associate agreements for their advertising products. Google Analytics' terms prohibit sending PHI to it; Meta's terms prohibit sending health data through its pixel. Neither will become your business associate for these tools.
Sit with the implication. If a BAA is required whenever a vendor receives PHI, and the vendor categorically won't sign a BAA, then there is no version of "send PHI to this tool" that is compliant. The only compliant states are: the tool receives no PHI, or the PHI is de-identified before it arrives. "Getting a BAA" isn't on the menu for Google Ads, GA4, or the Meta Pixel. Any vendor or consultant implying they'll "get you a BAA with Google for analytics" is describing something that doesn't exist.
That's why the serious solutions in this space don't try to obtain a BAA from the ad platforms. They either keep PHI away from those platforms, or they insert a BAA-covered intermediary that removes the PHI first. Which brings us to the three real paths.
The three real paths to a compliant tracker setup
When a tool would receive PHI and can't or won't sign a BAA, these are the only genuinely compliant options. Most mature healthcare organizations use a combination.
- Don't send PHI in the first place. Block non-essential trackers until consent, keep them off authenticated portals and sensitive pages entirely, and configure the tools that remain so they never receive identifiers tied to health context. This is the foundational move — and it's also what state consent laws require independently. You cannot have a BAA problem with data you never send.
- Use a BAA-covered proxy. Route marketing/analytics events through a server-side vendor that signs a BAA, strips or de-identifies PHI, and forwards only compliant data onward to Google, Meta, and analytics. This is a distinct product category — a data-proxy architecture, not a consent banner — and it's the right tool when you genuinely need conversion measurement and remarketing from healthcare traffic.
- Obtain a valid HIPAA authorization. A specific, HIPAA-compliant patient authorization can permit a disclosure — but authorizations are narrow, must meet strict content requirements, and are rarely practical for anonymous website visitors at scale. This path fits specific, consented programs, not general website analytics.
These aren't mutually exclusive. A well-run healthcare site typically does path 1 as the baseline for every tracker (block before consent, stay off sensitive pages), then adds path 2 (a BAA-covered proxy) specifically where it needs measurable marketing from healthcare traffic. Path 3 covers narrow, explicitly consented programs. The consent-and-detection layer sits underneath all three, because you can't run any of them safely without knowing what's actually firing.
Why a cookie banner is not a BAA — or a HIPAA authorization
Healthcare buyers deserve the truth other vendors soften: a cookie consent banner does not satisfy HIPAA. This isn't an opinion — it's the explicit position of the federal regulator. HHS Office for Civil Rights guidance states that website banners asking users to accept or reject tracking technologies "do not constitute a valid HIPAA authorization." HHS also says it is insufficient for a tracking vendor to merely agree to remove or de-identify PHI after the fact — disclosure of PHI to the vendor requires a signed BAA and an applicable Privacy Rule permission.4
So a banner and a BAA solve different problems. A BAA is a contract governing PHI a vendor legitimately receives. A HIPAA authorization is a patient's specific permission to disclose their PHI. A cookie banner is a consent mechanism for state privacy and wiretap law — it governs whether non-essential trackers fire before a visitor agrees. All three matter, but they aren't interchangeable, and the most expensive mistake in healthcare digital compliance is treating the banner as if it covers the HIPAA layer. It doesn't, and HHS says so directly.
We go deeper on how these layers interact in our pillar guide, Healthcare Website Tracking & Consent: What HIPAA, CIPA & State Law Actually Require. The short version: HIPAA is solved with a BAA or a PHI-safe path; state law is solved with a real consent layer that blocks trackers until opt-in; and neither is solved by the other.
See which trackers actually receive data before consent on your site
You can't answer the BAA question for any tool until you know what it receives, on which pages. Run the same scan a plaintiff's firm would — every tracker firing before consent, including on sensitive pages — in about 10 seconds. It's the detection step that has to come before any BAA decision.
The 2024 ruling, read accurately (AHA v. Becerra)
Any honest 2026 guide has to address the ruling that vendors on both sides misrepresent. In American Hospital Association v. Becerra (N.D. Texas, June 20, 2024), a federal court vacated one specific portion of HHS OCR's online-tracking guidance: the part treating an IP address collected from a visit to an unauthenticated public webpage about health conditions as automatically constituting PHI (what the court called the "Proscribed Combination"). The court held HHS had exceeded its authority on that narrow point, and HHS formally withdrew its appeal on August 29, 2024, making the vacatur final.5
The vacatur is partial and narrow. It struck only the IP-on-unauthenticated-public-pages rule. Everything else stands: tracking on authenticated patient portals was never touched, actual PHI combined with identifiers is still PHI, and every other HIPAA obligation — including the BAA requirement when a vendor receives PHI — remains fully in force. It also changed nothing about state law: CIPA, CCPA, CMIA, and the private class-action wave run on a completely separate track the ruling didn't reach.
Read correctly, Becerra gives genuine breathing room on public marketing pages that collect only an IP address with no other health-identifying combination — a real but limited relief. It does not mean "tracking is fine again," it does not remove the BAA requirement anywhere PHI actually flows, and it does not touch the state-law consent obligations that produced most of the sector's settlements. Treat it as a precise narrowing of one HIPAA edge case, not a green light.
What the litigation actually shows
The BAA question isn't academic — it's the exact gap plaintiffs have monetized. Healthcare organizations have paid well over $100 million settling website-tracking cases, and the recurring fact pattern is a tracker transmitting patient-identifiable data to a third party without a BAA and without consent. A few illustrative resolutions:
| Health system | Amount | What it involved |
|---|---|---|
| Kaiser Permanente (2025) | $46M | Trackers on portals sharing data with Google, Bing, X — argued largely under CIPA (state wiretap law)6 |
| Sutter Health (final Feb 2026) | $21.5M | A pixel on the MyHealthOnline portal login page alone — not even inside the portal7 |
| Advocate Aurora Health (final Jul 2024) | $12.25M | Meta Pixel + Google tools on website and patient portal; ~3M patients affected8 |
| The Christ Hospital (2025) | up to $7M | Pixel data tied to identifiers; claims that tools violate HIPAA absent a BAA or consent9 |
Two things stand out for a buyer. First, the Christ Hospital case states the core principle almost exactly as this guide frames it: these tools violate HIPAA if patient data "is transmitted to a third party without a valid business associate agreement in place, or if consent is not obtained."9 BAA or consent — the two doors, and the sites in trouble had walked through neither. Second, note how little it took: Sutter's $21.5M turned on a pixel on a login page. The exposure doesn't require a dramatic breach; it requires a tracker quietly receiving PHI it shouldn't. There is also an active federal MDL involving 660+ hospitals over data received by Meta — this wave is not over.8
Where ConsentPixel fits — honestly
We'll be straight about our lane, because in healthcare, overclaiming is the fastest way to lose a serious buyer. ConsentPixel is not a BAA-covered proxy and does not make your website "HIPAA compliant." We don't sign a BAA to receive and de-identify your PHI — that's a different product category, and the vendors who do it (server-side proxies like Freshpaint and Ours Privacy) are the right tool when you genuinely need measurable marketing from healthcare traffic. We'll tell you plainly when that's what you need.
What ConsentPixel — Privacy · Verified does is the layer alongside HIPAA that those proxies don't cover, and that no BAA addresses: state-law consent and detection. Specifically:
- Detection first. We scan your site and show exactly which trackers fire, on which pages, before consent — the information you need before you can even answer the BAA question for any tool. You can't govern, gate, or BAA what you can't see.
- Consent that actually blocks. We block non-essential third-party trackers until a visitor genuinely consents — the thing CIPA and CCPA turn on — fire Google Consent Mode v2 correctly, and honor GPC opt-out signals.
- Proof. We keep an immutable, timestamped record showing consent came before the tracker fired — your evidence if a question ever comes.
Here's the honest mapping to the three paths above: ConsentPixel is the engine of path 1 (don't send PHI — block before consent, stay off sensitive pages) and the detection layer beneath all three paths. Where you genuinely need path 2, a BAA-covered proxy, that's a complementary purchase from a different vendor — and we'll say so rather than pretend a banner replaces it. For a health system already running a proxy, we're the piece that watches everything the proxy doesn't and covers the state-law consent it was never built for. For a smaller organization, we're an affordable starting point on consent and detection, with honest guidance on the HIPAA/BAA layer you still need to solve separately.
| What you need | BAA-covered proxy (Freshpaint / Ours) | Native cookie banner | ConsentPixel |
|---|---|---|---|
| Signs a BAA & de-identifies PHI server-side | Yes — its core job | No | No — different category |
| Blocks non-essential trackers before consent (CIPA/CCPA) | Partial / vendor-scoped | Notice only | Yes — core job |
| Detects everything firing on every page | Its own scope | No | Yes — continuous |
| Honors GPC + fires Consent Mode v2 | Varies | Varies | Yes |
| Immutable consent record | Varies | Basic | Yes |
| Makes you "HIPAA compliant" on its own | No single tool does | No | No — we say so |
The honest takeaway: the proxy and ConsentPixel solve different layers, and a well-covered healthcare site often needs both plus a real HIPAA workstream. Any vendor claiming a single product makes you "HIPAA compliant" is selling the exact misunderstanding that has cost the sector nine figures.
A buyer's checklist: answering the BAA question for your site
- Inventory what actually fires. Scan every template — especially authenticated portals, scheduling, and intake forms — to see which trackers receive data and what data they receive. This is the prerequisite for every step below.
- For each tracker, ask: does it receive PHI? Consider page context and identifiers together, not just the raw field. On sensitive pages, assume yes until proven otherwise.
- Where the answer is yes, ask: will the vendor sign a BAA? If yes, execute it and configure to the vendor's HIPAA guidance. If no (Google/Meta ad products), move to a path.
- Pick a path for the "no BAA available" tools: stop sending PHI (block/relocate), route through a BAA-covered proxy, or obtain authorization. Combine as needed.
- Cover the state-law layer regardless. Block non-essential trackers until consent, honor GPC, and keep a consent record — independent of any BAA.
- Document and monitor. Keep evidence of your BAAs, your consent records, and continuous scans. Trackers get re-added through tag managers; a one-time fix decays. Note too that HHS's January 2025 Security Rule proposal would add annual business-associate verification — a reason to keep BAA documentation current.10
Key takeaways
- The trigger is simple: a BAA is required whenever a vendor creates, receives, maintains, or transmits PHI on your behalf (45 CFR 160.103). For trackers, that means the moment a tool actually receives PHI.
- The conduit exception rarely helps — analytics and ad platforms store and use data, so they're not mere conduits.
- Google and Meta won't sign BAAs for their ad products, so "get a BAA" isn't an option for GA4, Google Ads, or the Meta Pixel — you must keep PHI away from them or de-identify first.
- Three real paths: don't send PHI, use a BAA-covered proxy, or obtain authorization. A cookie banner is none of them.
- A banner is not HIPAA authorization — HHS says so explicitly. It addresses the state-law consent layer, not the HIPAA/BAA layer.
- Becerra was a narrow, partial vacatur — public-page IP relief only; authenticated portals, real PHI, the BAA rule, and all state law are untouched.
- Detection comes first: you can't answer the BAA question for any tool until you know what it receives, on which pages.
The bottom line
"When is a business associate agreement required?" has a precise answer: whenever a vendor handles your PHI. Applied to web trackers, that turns into a short, honest decision — does the tool receive PHI, and will the vendor sign a BAA? For the big ad and analytics platforms the second answer is no, which means the compliant move is to keep PHI away from them or route it through a BAA-covered proxy that strips it first. A cookie banner never fills that role, and HHS says so in plain language.
The most credible thing a healthcare organization can do is stop looking for one product that "makes us compliant" and instead treat each layer for what it is: a BAA or PHI-safe path for HIPAA, a real consent layer that blocks trackers until opt-in for state law, and continuous detection underneath both. Get those three right, in that clear-eyed way, and the BAA question stops being frightening and becomes just another line item you can answer with confidence.
Start with what you can actually see
Before any BAA decision, find out which trackers fire on your healthcare site before consent — and on which pages. Run the same scan a plaintiff's firm would, free, in about 10 seconds. It's the honest first move on the detection and state-law layers, and it tells you exactly where the BAA question even applies.
Scan your site free →ConsentPixel — Privacy · Verified builds prevention-first consent tooling that blocks trackers until visitors genuinely consent, continuously detects what fires on your pages, and proves consent came first. We cover the state-law consent and detection layers that sit alongside HIPAA — honestly, and we'll always tell you plainly what sits outside our lane, including when you need a BAA-covered proxy or legal counsel. This is general information, not legal advice; ConsentPixel is not a law firm and does not make any website "HIPAA compliant."
Frequently asked questions
When is a business associate agreement required for a web tracker?
A BAA is required whenever a vendor creates, receives, maintains, or transmits protected health information (PHI) on your behalf, per 45 CFR 160.103. For a web tracker, that means the moment an analytics or advertising tool actually receives PHI from your site — for example, a pixel firing on an appointment-confirmation page that ties a visit implying a medical condition to an identifier. If the tool never receives PHI, no BAA is required for it (though state consent laws may still apply). The practical complication is that the major ad platforms won't sign BAAs, so for those tools the compliant route is to keep PHI away from them rather than to obtain a BAA. This is general information, not legal advice.
Do Google and Meta sign BAAs for analytics and advertising?
No. Google does not offer a business associate agreement for Google Analytics or Google Ads, and its terms prohibit sending PHI to those products. Meta does not sign a BAA for the Meta Pixel and prohibits sending health data through it. Because a BAA is required whenever a vendor receives PHI, and these vendors won't sign one, there is no compliant way to send them PHI at all. The compliant options are to prevent PHI from reaching them (block the tracker before consent and keep it off sensitive pages), route data through a BAA-covered proxy that de-identifies PHI first, or rely on a valid HIPAA authorization. A cookie banner does not make sending them PHI compliant.
Does a cookie consent banner satisfy HIPAA or replace a BAA?
No. HHS Office for Civil Rights guidance states explicitly that website banners asking users to accept or reject tracking technologies do not constitute a valid HIPAA authorization, and that a vendor merely agreeing to de-identify PHI after receiving it is insufficient — a signed BAA and a Privacy Rule permission are required. A banner addresses a different layer: state privacy and wiretap laws like CIPA and CCPA, which turn on whether non-essential trackers fired before the visitor consented. Both matter, but a banner is not a substitute for a BAA, and a BAA is not a substitute for consent. This is general information, not legal advice.
When do you NOT need a BAA for a tracker?
You don't need a BAA when a tool genuinely never receives PHI — for instance, analytics on a purely informational page with no identifiers and no health context, configured so no PHI reaches the vendor. You also don't need one when data is fully de-identified to the HIPAA standard before it leaves your control, or when a vendor is a true conduit that only transports data without accessing or storing it (rare for web tools; the conduit exception is narrow). Importantly, "no BAA required" does not mean "no obligations" — state consent laws can still require blocking non-essential trackers until consent regardless of whether PHI is involved.
What is a BAA-covered proxy, and is it different from a consent tool?
Yes, they're different product categories. A BAA-covered proxy (such as Freshpaint or Ours Privacy) is a server-side vendor that signs a BAA with you, becomes your business associate, receives your event data, and strips or de-identifies PHI before forwarding compliant data onward to ad and analytics platforms. It exists to let healthcare organizations run measurable marketing without sending PHI to platforms that won't sign BAAs. A consent tool like ConsentPixel operates on a different layer: it blocks non-essential trackers until a visitor consents (the state-law requirement), detects what fires on your pages, and records consent. A well-covered healthcare site often needs both, plus its own HIPAA workstream — no single tool does all of it.
Didn't the 2024 AHA v. Becerra ruling remove these requirements?
No. In AHA v. Becerra (N.D. Texas, June 2024), a federal court vacated one narrow portion of HHS's tracking guidance — the part treating an IP address collected on an unauthenticated public webpage as automatically constituting PHI — and HHS withdrew its appeal in August 2024. But the vacatur is partial: tracking on authenticated patient portals was never affected, actual PHI combined with identifiers is still PHI, and the BAA requirement remains fully in force wherever a vendor receives PHI. The ruling also changed nothing about state laws like CIPA and CCPA, which is where most healthcare tracking settlements have actually been decided. It provides limited relief on public marketing pages, not a general exemption.
Sources
- Legal Information Institute / HHS — definition of "business associate," 45 CFR 160.103 (creates, receives, maintains, or transmits PHI).
- HHS — Guidance on HIPAA & Cloud Computing (Oct 2016): a CSP storing ePHI is a business associate even if data is encrypted and it lacks the key.
- HHS — Business Associates guidance and the conduit exception (transient transport only).
- HHS Office for Civil Rights — Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates: banner ≠ valid HIPAA authorization; BAA required for disclosure of PHI to a tracking vendor.
- Holland & Knight / Quarles — AHA v. Becerra, N.D. Tex., June 20, 2024; HHS withdrew appeal Aug 29, 2024. Vacatur limited to IP-on-unauthenticated-pages ("Proscribed Combination").
- Reporting on Kaiser Permanente's $46M tracking settlement (2025), argued substantially under CIPA.
- Reporting on Sutter Health's $21.5M settlement (final approval Feb 2026) over a pixel on the MyHealthOnline portal login page.
- HIPAA Journal / court records — Advocate Aurora Health $12.25M settlement (final approval July 2024; ~3M patients); federal MDL involving 660+ hospitals re: Meta.
- HIPAA Journal — The Christ Hospital up to $7M settlement: tools violate HIPAA if data is transmitted to a third party without a valid BAA, or if consent is not obtained.
- HHS — HIPAA Security Rule NPRM (published Jan 6, 2025), proposing annual business-associate verification; final rule pending as of publication.