Your "HIPAA-Compliant" Tracking Probably Isn't

Most healthcare marketing teams I audit are confident their tracking is compliant. The agency said it was. The CMP vendor confirmed it. IT signed off.

Then I open Chrome DevTools and watch patient condition data flow into Google Ads request payloads in plaintext.

This is not a hypothetical. In 4 of the last 6 healthcare tracking audits I have done, PHI was being transmitted to at least one ad platform without any filtering, hashing, or consent gating. The marketing teams had no idea.

What I Keep Finding

The same patterns show up at almost every healthcare organization running paid media. The tracking was set up by someone who understood tags but not HIPAA. Or someone who understood HIPAA but not tags. The gap between those two skill sets is where violations live.

PHI in Google Ads Tags

URL parameters are the most common vector. A patient visits /conditions/diabetes/appointment?provider=dr-smith&type=endocrinology. That full URL gets passed to Google Ads via the auto-configured conversion linker. The page path alone -- containing a condition name and provider specialty -- constitutes PHI when combined with any user identifier Google already holds.

Enhanced Conversions makes this worse. When enabled, it sends hashed email addresses to Google. A hashed email from a page path containing /conditions/hiv-treatment is PHI. The hash does not change that. HHS has been explicit: identifiers combined with health information are protected, regardless of encoding.

I reviewed a multi-location health system running Google Ads for 14 service lines. Every service line had its own landing page structure: /services/cardiology/, /services/behavioral-health/, /services/oncology/. The Google Ads conversion tag fired on form submissions across all 14. Each conversion request included the full page URL. That is 14 categories of health information flowing to Google, tied to user identifiers, with no BAA in place.

Consent Banners That Do Not Actually Gate Tags

The consent banner appears. The user clicks "reject all." The tags fire anyway.

I see this in roughly 60% of healthcare CMP implementations. The banner is cosmetic. Consent Mode v2 is configured in the CMP dashboard -- the toggles are set, the categories are mapped. But in the GTM container, the tags have no corresponding consent checks. The consent signal goes nowhere.

The result: the CMP vendor's compliance dashboard shows 100% consent coverage. The actual tag behavior ignores consent entirely. If you only check the CMP dashboard, everything looks correct. If you check the Network tab after rejecting cookies, the reality is different.

Third-Party Scripts Loading Before Consent

Even when GTM consent gating works correctly, hardcoded scripts bypass it entirely. LiveChat widgets, Hotjar session recordings, Meta Pixel base code, and chatbot scripts often get added directly to the HTML by developers who are not thinking about the consent layer.

These scripts load on page render. No consent check. No tag management. No audit trail. In healthcare contexts, a session recording tool capturing a patient portal login page is recording PHI. A chat widget that pre-populates patient name from a URL parameter is transmitting PHI to a third-party server.

I found a Hotjar implementation on a patient scheduling flow that was recording the entire appointment booking process -- condition selection, provider preference, insurance information. The session recordings were stored on Hotjar's servers with no BAA. The marketing team did not know Hotjar was on the site. A developer had added it 8 months earlier for a UX project and never removed the script tag.

No BAA with Analytics Vendors

This is the one that surprises teams the most. Even if no PHI is technically flowing through GA4, using GA4 in a healthcare context without a BAA with Google is a HIPAA violation. The regulation does not require proof of PHI transmission to require a BAA. If a vendor could potentially access PHI through the service they provide, a BAA is required.

Google will sign a BAA for Google Cloud services. Google will not sign a BAA for GA4. This means GA4 cannot be used in any context where PHI might be processed, which includes virtually every healthcare website with authenticated patient areas, condition-specific content, or appointment scheduling.

The same applies to Meta, LinkedIn, Microsoft Advertising, and most martech vendors. The list of ad platforms that will sign a BAA is effectively zero.

How to Audit Yourself

This takes 30-45 minutes. You do not need a consultant for the first pass.

1. Check your request payloads. Open your site in Chrome DevTools. Go to the Network tab. Filter by google, facebook, doubleclick, analytics. Click through 3-4 condition-specific pages. Look at the outbound request URLs and payloads. If you see condition names, provider IDs, or appointment types in any request, you have a PHI transmission problem.

2. Test your consent banner. Reject all cookies. Clear your browser storage. Reload the page. Check the Network tab again. If marketing tags still fire, your consent gating is cosmetic. Check this on at least 3 different page types -- homepage, condition page, and any scheduling or portal page.

3. Audit your GTM container. Open every tag. Does each one have a consent-based trigger or a Consent Mode v2 configuration? Are there tags firing on "All Pages" with no consent condition? Export the container JSON and search for tags without consentSettings -- that gives you the full picture faster than clicking through the UI.

4. Search your HTML source for hardcoded scripts. View source on 5 key pages. Search for <script> tags that reference third-party domains. Any script not loaded through GTM bypasses your consent layer entirely. Common offenders: chat widgets, heatmap tools, A/B testing platforms, and review/survey tools.

5. Inventory your vendor BAAs. Ask legal: do we have a signed BAA with Google, Meta, LinkedIn, Hotjar, and every other vendor receiving data from our site? If the answer is no for any vendor processing data from pages where PHI could exist, that vendor needs to be removed or replaced with a HIPAA-eligible alternative.

The Fix

This is not a tag configuration update. It is a measurement architecture rebuild with compliance as the primary constraint.

The pattern that works: sGTM with a data filtering layer between the browser and the ad platforms. Patient-facing pages send events to your server endpoint. The server container strips PHI from URLs, filters sensitive parameters, and only forwards compliant data to downstream tags. Consent state is enforced server-side, not just in the browser.

You also need to replace non-BAA-eligible tools. GA4 gets replaced with a HIPAA-eligible analytics platform or a BigQuery-based first-party analytics stack behind Google Cloud's BAA. Ad platform conversion tracking gets routed through sGTM with parameter filtering so condition names and patient identifiers never reach Google or Meta servers.

None of this is a 30-minute fix. A full remediation typically takes 4-8 weeks for a mid-size health system. But the first step is knowing what you are actually sending -- and most teams have never checked.

The Bottom Line

The problem is not that healthcare teams are careless about compliance. It is that the people who configure tracking are not the people who understand HIPAA, and the people who understand HIPAA are not looking at network request payloads.

Your CMP dashboard says compliant. Your GTM container says otherwise. The only way to know which one is telling the truth is to open DevTools and look.