Every one of those cases started the same way: a standard retargeting pixel, installed the standard way, doing exactly what it was designed to do.

This playbook covers what changed after the OCR guidance was partially vacated in June 2024, which retargeting tactics are still off the table, which ones work, and the server-side architecture that lets a medical practice run real retargeting campaigns without handing patient data to Meta and Google.

Why standard retargeting breaks HIPAA

A retargeting pixel — Meta Pixel, Google Ads remarketing tag, TikTok Pixel — works by watching every visitor on your site and reporting back to the ad platform: this browser, on this IP address, viewed this page, at this time. The platform builds an audience from those events and shows those people your ads later.

On an e-commerce site, that's fine. On a medical practice website, the pixel is reporting things like:

• An identifiable browser + IP viewed /services/erectile-dysfunction-treatment/
• The same browser landed on /thank-you-appointment-confirmed/
• The same browser opened the patient portal login page

Under HIPAA, when a covered entity discloses individually identifiable health information to a vendor without a Business Associate Agreement and without patient authorization, that's an impermissible disclosure. Meta and Google will not sign a BAA for their ad platforms. Full stop. So a pixel that connects an identifiable person to an appointment request, a condition-specific page in a patient context, or portal activity is a disclosure you can't paper over.

And it isn't just HIPAA. The FTC has hammered non-covered entities (GoodRx, BetterHelp, Cerebral) under Section 5 and the Health Breach Notification Rule for the same behavior. Plaintiff firms have filed hundreds of pixel class actions against health systems and private practices. State privacy laws — Washington's My Health My Data Act most aggressively — create private rights of action for sharing consumer health data with ad platforms.

The pixel doesn't know your visitor is a patient. The regulators don't care.

There's also a quieter cost that never shows up in a legal memo: the ad platforms themselves have started deplatforming healthcare accounts that make them nervous. Marketing tools have dropped telehealth companies outright rather than carry the risk. A practice whose ad account gets restricted mid-quarter because its pixel data looked like health targeting loses the channel entirely — no fine required.

What the 2024 court ruling changed — and what it didn't

In June 2024, a federal court in the Northern District of Texas vacated part of OCR's December 2022 tracking-technology bulletin — specifically, the position that an IP address combined with a visit to an unauthenticated public webpage is automatically individually identifiable health information. Most competitor articles you'll find on this topic were written before that ruling and are now wrong in both directions: some still treat every public pageview as PHI; others read the ruling as "pixels are legal again."

Neither is true. What the ruling actually leaves in place:

• HIPAA itself. The statute and the Privacy Rule weren't touched. Disclosures of real PHI to ad vendors are as illegal as ever.
• Authenticated pages. Anything behind a patient login — portals, intake, scheduling accounts — is squarely PHI territory. No pixel, ever.
• Forms and appointment flows. A visitor who types their name, phone, and reason for visit into your booking form has handed you PHI. If a pixel captures or co-occurs with that submission, you have a disclosure.
• FTC and state enforcement. The ruling binds OCR's bulletin, not the FTC, not state AGs, not class-action plaintiffs.

The full breakdown is in our companion piece: The OCR Tracking Guidance Was Vacated — Here's What Still Applies.

The practical upshot for retargeting: the risk didn't go away, it got more precisely located. The dangerous data is identity + health-context events — form contents, booking events tied to real identifiers, condition-page browsing linked to a person. That's exactly the data a client-side pixel exists to collect.

Retargeting tactics ranked: banned, risky, safe

Off the table

• Client-side pixels on any page with health context. Condition pages, service pages, booking flows, thank-you pages, portal. This is the URMC/Froedtert fact pattern.
• Uploading patient lists as custom audiences. Taking emails or phone numbers from your EHR or CRM and uploading them to Meta/Google for matching is a direct PHI disclosure to a non-BAA vendor. It's also the single most common "quick win" a generalist agency will suggest.
• Pixel-built lookalike audiences. A lookalike seeded from a leaked audience inherits the violation.
• URL-parameter leakage. Click IDs and UTMs are fine; condition names, patient identifiers, or appointment details in URLs that get shipped to analytics are not.

Risky and rarely worth it

• "Filtered" client-side pixels. Consent banners and pixel-config toggles reduce, but don't structurally prevent, leakage — the pixel still runs in the browser and still sees the page. When it misfires, you own the disclosure.
• Platform "limited data use" modes. These are the vendor limiting its own liability, not yours.
• "We only pixel the homepage." A blocklist approach that depends on nobody — no agency, no plugin update, no GTM edit — ever extending the tag to another page. In our audits it rarely survives six months, because the tag manager makes sitewide the default and page-scoped the exception.
• Consent-management platforms as the whole strategy. A CMP governs when a pixel fires, not what it collects when it does. Consent from a website visitor is also not HIPAA authorization — a cookie-banner click doesn't authorize disclosing PHI to Meta, and courts and the FTC have treated it accordingly.

What actually works

• Contextual and interest targeting on the platforms — no site data required.
• Search retargeting via RLSA-style engaged audiences built from safe events — only if the event stream is scrubbed server-side (below).
• Server-side conversion events with no PHI payload. The platforms don't need to know who converted or why — they need a conversion signal with a click ID to optimize bidding. That signal can be constructed server-side, stripped of everything else.
• First-party audiences you never export. Nurture the retargeting function yourself — email, SMS with proper consent, and reactivation campaigns inside a HIPAA-compliant system — instead of renting Meta's memory of your visitors.

The architecture: retarget the click, not the patient

Here's the model PilotPractice runs for its practices, and the one to hold any vendor or agency against.

1. One first-party script, allowlisted by design

Instead of five vendor pixels each free-reading the page, the site carries a single first-party tracking script. It captures an allowlisted set of parameters — UTMs and ad-platform click IDs (gclid, fbclid, and peers) — and a hidden visitor ID that stitches the ad click to the eventual inquiry. Nothing outside the allowlist leaves the browser. There is no third-party JavaScript sitting on your booking page deciding for itself what's interesting.

2. Conversions flow server-to-server

When a visitor books or submits a form, the form entry travels server-to-server into the CRM — the ad platforms are not in that pipeline. Conversion events are then uploaded to Google and Meta as offline conversions: click ID + event + value. The platform learns "the click you sold us converted." It never receives the form contents, the service requested, or the person's identity from us.

3. Analytics without the leak

The same philosophy extends to measurement: a server-side GA4 Measurement Protocol forwarder with synthetic client IDs, a PII-scrub layer, and whitelisted parameters — so the practice keeps real GA4 reporting and conversion data without Google's client-side tag on the site. That forwarder is part of the architecture we're building directly into the platform — designed as a native capability, not a separate software subscription.

4. Retraction as a feature, not an apology

Compliance systems fail at the edges. A real architecture includes retraction jobs — the ability to pull back a conversion event that shouldn't have gone out. If your current setup has no mechanism to un-send data, it was never designed for healthcare.

5. Booking that never touches the tracked surface

The other structural move: keep the highest-sensitivity flow off the marketing site entirely. PilotPractice's EHR-integrated booking widget runs iframed off WordPress — intake data never touches the WP database, and by extension never shares a page with anything that could be tagged. The widget's own micro-events (step views, slot selection) feed the practice's funnel reporting, not a third party's audience builder.

What you keep, what you give up

Be honest about the trade. You give up: platform-built website-visitor audiences, lookalikes seeded from them, and session-replay tools. You keep: full-funnel conversion reporting, source/medium and campaign ROI in GA4, bid optimization on real booked appointments (a stronger signal than pageviews ever were), and every prospecting lever the platforms offer. In our experience, practices making this switch tend to find the offline-conversion signal improves campaign performance, because the platform stops optimizing for form-page visits and starts optimizing for actual bookings.

With this in place, "retargeting" becomes: bid-optimization signals to the platforms (conversion events on click IDs), contextual prospecting for reach, and first-party nurture for the people who actually raised their hand. In our experience that combination tends to outperform pixel retargeting anyway, because the conversion feedback loop — the part that actually trains the ad platform — stays intact.

The 2026 healthcare retargeting checklist

Run this against your current setup. No email required.

1. Inventory every tag. Open DevTools → Network on your booking page and thank-you page. Any request to facebook.com, doubleclick.net, google-analytics.com, tiktok.com, clarity.ms, or hotjar.com is a finding. (Full walkthrough: the 10-minute PHI leak self-audit.)
2. Kill pixels on health-context pages first — booking, thank-you, portal, condition pages — even before you have the replacement built.
3. Never upload patient lists to any ad platform. Audit whether anyone already has.
4. Confirm no PHI in URLs or page titles that analytics can see.
5. Move conversion tracking server-side: click-ID capture on the click, offline conversion upload on the booking.
6. Demand an allowlist, not a blocklist. The safe question is "what is permitted to leave the browser," never "what have we blocked."
7. Verify a retraction path exists for mis-sent events.
8. Get BAAs from every vendor that touches identifiable data — CRM, forms, call tracking, chat. The ad platforms won't sign one; that's exactly why they only get scrubbed signals.
9. Check your consent + state-law posture — MHMDA applies if you have Washington visitors, not just Washington offices.
10. Document the architecture. In an OCR inquiry or a class action, a written data-flow diagram showing PHI never reaches ad platforms is the difference between a nuisance and a settlement.

How to actually run healthcare retargeting in 2026

Do it in this order: strip the client-side pixels, stand up first-party click-ID capture, wire offline conversion uploads to Google and Meta, replace client-side GA4 with server-side forwarding, and move audience nurture into channels you control with proper consent. Every piece of that is buildable — it's engineering work, not legal magic — and once it's running, your campaigns optimize on real conversion data while the platforms stay blind to patient identity.

Or skip the build. PilotPractice runs this architecture — the first-party tracker, server-to-server forms, offline conversion uploads, and the ad campaigns themselves, with the HIPAA-safe GA4 forwarder in active development — as one done-for-you service for medical practices, HIPAA-compliant by default.

Book a demo to see the full retargeting stack, or start with the free PHI leak scanner — it takes one URL and shows you exactly what your site is sending to ad platforms right now.

Part of the HIPAA-Compliant Marketing 2026 Guide. Compliance posture, SOC 2 + HIPAA reports, and our subprocessor list: trust.pilotpractice.com.