Healthcare · Compliance · Guide
HIPAA-compliant marketing automation, without killing attribution.
Healthcare marketers live between two fears: an OCR complaint and an unmeasurable funnel. Both are avoidable. Here's what HIPAA actually requires of marketing automation and tracking — and the architecture that stays compliant while keeping the numbers.
In one paragraph
HIPAA-compliant marketing automation means running email, CRM, tracking and ad workflows so that protected health information (PHI) — anything linking an identifiable person to their health status, treatment or payment — is only handled by vendors under a Business Associate Agreement (BAA), never sent to ad platforms, and only used with proper authorization. The practical rule: ad and analytics platforms won't sign BAAs, so nothing that touches them may contain PHI.
Where marketers actually violate HIPAA
- Pixels on authenticated or condition-specific pages. The 2022–2024 enforcement wave was largely this: analytics and ad pixels transmitting page paths and identifiers that reveal a person sought specific care.
- PHI in the CRM-to-ads pipe. Uploading customer lists with condition context, or passing treatment details in conversion payloads.
- Email automation without authorization where content implies treatment status.
- Call tracking that records clinical conversations on non-BAA platforms — the dental-specific version is covered in the call-tracking guide.
The compliant architecture
- Sort vendors by BAA. CRM, forms, call tracking, email — BAA-covered tier, PHI allowed. Ad platforms and standard analytics — no BAA, no PHI, ever.
- Strip conversion payloads to click ID + event + value. The offline conversion import that powers my attribution work sends a GCLID, a conversion name like "qualified," a timestamp and a value — no name, no condition, no notes. Full mechanics in the offline tracking guide and the healthcare version.
- Fence the pixels. Marketing pages get tags; portals, intake flows and condition-specific journeys don't — or get a server-side setup that filters what leaves.
- Paper it. BAAs filed, data-flow map current, authorization language reviewed. Boring, and exactly what an audit asks for first.
The point most compliance advice misses
Done properly, compliance and attribution are the same project. The architecture that keeps PHI out of ad platforms — click-ID-based offline imports with stripped payloads — is also the architecture that measures verified patients better than pixels ever did. Practices that "turned off tracking for HIPAA" usually turned off the wrong layer.
This is practitioner guidance, not legal advice — validate your setup with healthcare counsel.
| Tier | Examples | PHI allowed? |
|---|---|---|
| BAA-covered | CRM (HIPAA plan), call tracking (BAA), forms, email (BAA) | Yes — with signed BAA |
| Never-PHI | Google Ads, Meta, GA4, most pixels | No — click ID + event + value only |
Official documentation
Questions owners ask
Straight answers
Can healthcare practices use Google Ads under HIPAA?
Yes — advertising itself isn't the violation; leaking PHI is. Campaigns targeting conditions are fine; sending identifiable patient-plus-condition data back to Google is not. Click-ID-based imports with stripped payloads keep measurement alive compliantly.
Is GA4 HIPAA compliant?
Google doesn't sign BAAs for GA4, so it must never receive PHI. On marketing pages with a filtered, server-side setup it's workable; on patient portals and intake flows it doesn't belong.
Does GoHighLevel / my CRM need a BAA?
If it stores anything linking identity to care sought — and lead records in healthcare almost always do — yes. Use the vendor's HIPAA plan with a signed BAA, or don't put patient data in it.
Talk to the person who will actually run it.
A 30-minute call about your numbers — no pitch deck, no account managers. If I'm not the right fit, I'll say so.
Book a 30-minute call$500 audit + 90-day roadmap