- Google won't sign a BAA for GA4 under any circumstance, so if your site has condition pages, appointment scheduling, or a patient portal, GA4 is a standalone violation regardless of what data actually flows through it.
- Only a handful of platforms sign BAAs for web analytics: PostHog (self-hosted or their BAA tier), Piwik PRO, and a custom stack on Google Cloud or AWS behind their platform-level BAA. Most vendors marketing 'HIPAA-compliant analytics' to healthcare are reselling one of these three.
- Switching platforms doesn't fix anything if you migrate the same tracking plan. Audit what data each event actually carries before you touch the new tool, or you'll replicate the same PHI leaks on a compliant vendor.
- Budget 6-10 weeks for a real migration: 2 weeks for a BAA and data-flow audit, 2-3 weeks for event schema redesign, 2-3 weeks for implementation and parallel tracking, 1-2 weeks for validation before you cut over.
A health system I audited last year had already "solved" their HIPAA problem. They'd read the warnings, gotten nervous about GA4, and migrated to a new analytics platform. Nice dashboards. Vendor swore it was HIPAA-compliant. Legal signed off.
Six weeks later I opened DevTools on their appointment scheduling flow and watched the exact same problem show up on the new tool: condition names in the URL, no consent gating, and no BAA on file with the new vendor either. They'd changed platforms and kept every mistake.
This is the part people skip. Switching off GA4 is the easy 20% of the problem. The hard 80% is knowing which platforms will actually sign a BAA, and rebuilding your tracking plan so the new platform isn't just GA4 with a different logo.
Why GA4 Specifically Is a Problem
Google will sign a BAA for Google Cloud Platform and for Workspace. Google has never signed one for GA4, and every healthcare marketer I talk to assumes there's some enterprise tier where this changes. There isn't. I've asked Google reps directly. The answer is always the same: GA4 is not covered, full stop, no exceptions for volume or contract size.
That means if your site has anything that could touch PHI (condition pages, a scheduling flow, a patient portal login, a symptom checker) GA4 itself is the violation. Not the data flowing through it. The presence of the tool.
HIPAA doesn't require proof that PHI was transmitted to require a BAA. If a vendor could plausibly access PHI through normal use of the service, you need a signed BAA before that vendor touches your site. GA4 fails this test on any healthcare property with authenticated areas or condition-specific content, even if you think you've "cleaned" the data going in.
So the fix isn't a GA4 configuration change. It's a platform swap, plus a rebuild of what data gets collected in the first place.
The Platforms That Will Actually Sign a BAA
There are three real categories here. Everything else marketing itself as "HIPAA-compliant analytics" is a reseller sitting on top of one of these.
1. PostHog
PostHog offers a BAA on their paid plans (not the free tier) and it's the closest drop-in replacement to GA4 in terms of feature set: event tracking, funnels, session replay, feature flags. If you self-host PostHog, you control the infrastructure entirely and the BAA question becomes about your own hosting environment instead of a third party.
The catch: session replay is a PHI risk on its own. If you enable it on a patient portal, you're recording keystrokes and form fills the same way Hotjar does. Turn it off for any authenticated route or any page where a patient could type identifying health information. PostHog gives you the toggle to exclude specific URLs from replay. Use it before you launch, not after an audit finds it.
2. Piwik PRO
Piwik PRO markets directly to regulated industries and has a specific HIPAA-focused tier with a BAA included in the contract. It's built for this use case in a way PostHog wasn't originally. The reporting interface will feel closer to Universal Analytics than GA4 for anyone who misses cohort views and custom segments from the old tool.
Cost is the tradeoff. Piwik PRO's HIPAA tier runs enterprise pricing, typically starting in the low five figures annually depending on traffic volume. For a single-location practice this is overkill. For a health system with multiple service lines and real ad spend behind them, it's usually cheaper than the legal exposure of running GA4 without a BAA.
3. First-Party Stack on GCP or AWS
This is the option most engineering-led healthcare marketing teams end up building. Google Cloud Platform and AWS both sign BAAs at the platform level. That means you can build your own analytics pipeline (events into BigQuery or Redshift, a custom dashboard on top) and the entire stack sits behind a BAA that Google or Amazon already signed for you.
This is what I usually recommend for organizations already running server-side GTM, because you're not adding a new vendor relationship. You're extending infrastructure you've already vetted.
Browser → sGTM (your GCP project, BAA covered)
→ BigQuery (same GCP project, same BAA)
→ Looker Studio or custom dashboard
No PHI leaves your own cloud environment. No third-party analytics vendor touches the data at all. The downside is engineering time: you're building the reporting layer that GA4 or Piwik PRO gives you out of the box.
Ask any vendor for the actual BAA document before you sign a contract, not a sales page that says "HIPAA compliant." Several session-replay and heatmap tools use that phrase loosely to mean "we have a security certification," which is not the same as a signed Business Associate Agreement covering the specific service you're buying.
Migrating Without Copying the Same Mistakes
The health system I mentioned at the top migrated tools but not tracking plans. Their new platform received the exact same event payloads GA4 had been getting: condition names in URL paths, provider names in page titles, insurance type as a custom parameter. Compliant platform, identical leak.
Before you configure the new tool, pull your current GTM container and list every event, every parameter, every custom dimension currently being sent. For each one, ask: does this carry a condition, a provider name, an appointment type, or anything that becomes PHI once tied to a user identifier? If yes, that field gets stripped or hashed at the point of collection, not downstream in a report filter.
Concretely, this usually means:
- Rewriting URL structures so
/conditions/diabetes/schedulebecomes a route the analytics layer sees as/schedulewith condition passed as an internal, non-transmitted parameter. - Killing any custom dimension that stores provider specialty, diagnosis category, or treatment type as plain text.
- Turning off session replay and heatmaps on every authenticated route by default, then only enabling on specific pages you've manually reviewed.
None of this is platform-specific. It's the same audit whether you land on PostHog, Piwik PRO, or a custom BigQuery pipeline. The platform choice determines who signs the BAA. The tracking plan determines whether you actually stop the leak.
What the Migration Actually Costs in Time
Plan for 6 to 10 weeks for a real migration, not a weekend swap.
Weeks 1-2: BAA negotiation with the new vendor (or confirmation of GCP/AWS coverage if you're going the custom route), plus a full audit of current data flows using the DevTools method: open Network tab, filter for analytics domains, click through condition pages and scheduling flows, document every payload that contains anything sensitive.
Weeks 3-5: Redesign the event schema. This is where most of the real work happens and where teams underestimate the timeline. Every event needs a decision: keep, strip, or hash. Every custom parameter needs the same review.
Weeks 5-7: Implement the new platform in parallel with the old one, running both simultaneously so you can validate that conversion counts and funnel data match before you cut over. Don't turn off GA4 the day you flip on the new tool. You need overlap to catch discrepancies.
Weeks 7-8: Validation. Pull reports from both platforms for the same date range. Confirm the numbers reconcile within a reasonable margin. Confirm the new platform's payloads are clean using the same Network tab check you ran in week one.
What to Do Next
Get the BAA question answered before you evaluate feature sets. A platform with worse reporting and a signed BAA is usable. A platform with beautiful dashboards and no BAA is the same violation you already have.
Pull your current GTM container today and list what every tag actually sends. That list is the real migration project. The platform swap is the easy part everyone focuses on because it's the part with a vendor demo.