Conversations about GA4 in healthcare tend to stay strangely shallow, circling the same procurement question: “Is there a BAA?” It’s as if GA4 creates risk at the contract layer, when the truth is that the risk is born earlier and lower, in the collection layer, where ordinary telemetry becomes sensitive the moment it is attached to health context and allowed to leave your site.
Google’s position makes the tension explicit. It does not offer a BAA for GA4, and it expects customers to ensure PHI never reaches Analytics. The practical implication is sharper than most teams want it to be, because it means your compliance posture depends on something more concrete than policy language: whether your implementation can reliably prevent PHI exposure across the pages and journeys where patients actually behave like patients.
That reliability lives or dies at the collection layer.
What GA4 collects determines your exposure, not what Google agrees to sign
GA4’s measurement model is designed for marketing attribution, not healthcare privacy. Enhanced Measurement runs by default, capturing site search. Pageviews pull full URL paths. Events fire when users interact. Cookies create persistent recognition. On an e-commerce site, this is fine. On a healthcare site, it becomes a PHI disclosure engine.
URLs encode care intent. GA4 captures page paths and assigns Client IDs to track individuals across condition-specific content. Someone views substance abuse treatment pages Tuesday, checks appointments Thursday, accesses billing Friday. GA4 holds a behavioral sequence tying one identifier to treatment context, portal access, and billing.
Site search captures what patients type. Healthcare visitors search for symptoms, conditions, medications. Each term is captured, linked to their Client ID, stored alongside other interactions. When that user logs into a patient portal, the profile becomes directly identifiable.
Events turn interactions into health signals. Appointment requests for oncology. Diabetes guide downloads. Psychiatry telehealth sessions. Each event parameter is health-related metadata tied to an identifier.
Referrers reveal external relationships. Employer health portals, insurance sites, provider referral links, condition-specific support groups. Each exposes relationships and health context.
User identifiers collapse the gap. User-ID tracking to “improve attribution” may send medical record numbers, email addresses, or portal usernames to Google. Once present, GA4 links every pageview, search, event, and session to that identifier.
Each collection point is a potential PHI disclosure
| GA4 data type | Healthcare context | PHI risk |
| Page URLs | /appointments/oncology, /providers/cardiology | Health condition inference |
| Site Search | “diabetes symptoms”, “pregnancy test” | Direct health information |
| IP Address | Even anonymized, combined with health pages | Individually identifiable |
| User ID | Logged-in patient portal users | Direct identification |
| Events | Button clicks on condition-specific pages | Health interest indicators |
| Referrer Data | Links from health plan portals | Insurance relationship |
| Device ID | Persistent cross-session tracking | Individual identification |
The real risk is combinatorial. A Client ID plus a URL path. A search term plus a referrer. An event parameter plus a timestamp. GA4 doesn’t need a patient’s name to build an identifiable health profile.
And that’s the problem a contract can’t solve.
A contract can’t filter what already left the browser
Google states it does not offer BAAs for Google Analytics and customers must avoid using GA4 in any manner that creates HIPAA obligations. This is a product boundary. GA4 is built for marketing attribution, audience segmentation, and advertising integration. That design is incompatible with healthcare-grade data minimization.
Even where vendors sign BAAs, the agreement doesn’t prevent PHI from being collected accidentally. A BAA obligates the vendor to handle PHI according to HIPAA rules once disclosed. It doesn’t stop a website from transmitting a medical record number in a URL or firing an event with a diagnosis code. The BAA binds the vendor to protect data, but doesn’t erase the initial violation.
GA4 defaults to comprehensive collection.
Enhanced Measurement tracks site search, clicks, video engagement, file downloads, and scroll depth by default. None of these mechanisms pause to ask whether data is PHI. A BAA is a legal instrument. It doesn’t change default behaviors, filter parameters, or suppress queries. Those are engineering problems.
HIPAA requires technical safeguards: ensuring GA4 doesn’t load where patients view health information, filtering URL parameters, suppressing site search with symptoms, blocking User IDs linking to patient accounts, preventing events from including PHI, and monitoring for drift. None of these are created by signing documents.
Which brings the focus back to what regulators actually care about.
The regulatory frame is disclosure, not agreement status
OCR’s December 2022 bulletin was explicit: regulated entities cannot use tracking technologies that result in impermissible PHI disclosures. A 2024 court ruling narrowed this, vacating the portion about IP addresses on unauthenticated public health pages.
But the ruling doesn’t create a safe harbor. If tracking collects search queries with symptoms, URL paths revealing appointments, events indicating care requests, authenticated page data, or identifiers with health interactions—PHI is disclosed and HIPAA applies. GA4 collects data types that, in healthcare contexts, frequently meet the definition of PHI. The safest posture is to treat GA4 as a potential PHI egress path and engineer accordingly.
Which leaves one question: what do you actually do about it?
Compliance depends on what you prevent, not what you document
If GA4 is running on your healthcare website, the compliance outcome hinges on whether your implementation actually prevents PHI from reaching Google, not on whether you have a policy that says it should.
Most organizations land in one of three places.
Remove GA4 from any page where health context becomes specific. GA4 runs only on general educational content where no patient interaction or portal access occurs. Clear risk reduction. But you lose visibility into the patient journey where engagement matters most, and this requires continuous validation that GA4’s scope remains confined.
Switch to a vendor willing to operate under HIPAA constraints. Some analytics platforms offer BAAs as standard, limit data retention, avoid advertising integrations, and align with healthcare compliance needs. Contractual clarity is the advantage. Migration cost and workflow changes are the disadvantages. Even with a HIPAA-aligned vendor, you still need technical controls.
Keep GA4 with enforcement layers that block PHI before transmission. This requires conditional script loading, URL and referrer sanitization, site search suppression, identity and event hygiene, and continuous monitoring. This path is viable only with dedicated resources—it’s an operational discipline, not a one-time configuration.
The audit question that matters
When OCR asks, “How do you know your website analytics stayed within HIPAA boundaries?”, defensible answers require evidence, not intent.
“We configured it correctly” is a description of effort, not proof of outcome. “We have a policy that prohibits PHI in analytics” is governance documentation, not technical validation. “We can show what data GA4 actually received from our pages, what was blocked, and when the configuration changed” is evidence.
The gap between configuration and reality is where violations occur. A developer adds a form field. A marketer creates a new event. A URL structure changes. A third-party widget introduces a new data flow. If you don’t have continuous visibility into what’s actually being transmitted from production pages, you’re operating on assumptions.
And assumptions don’t hold up when auditors ask for evidence.
Technical enforcement is the boundary that holds
Healthcare organizations that want analytics visibility without HIPAA exposure need a layer between the browser and external endpoints that monitors what scripts attempt to collect and blocks PHI transmissions.
Technical protection means blocking GA4 from pages containing PHI, filtering data before transmission, preventing URL capture on condition-specific pages, disabling site search where queries contain health information, and ensuring identification data never reaches analytics tools. These controls must operate continuously as the site evolves.
Client-side security platforms like Feroot DXComply enforce this PHI boundary in the browser, in real time, across pages where GA4 runs.
What client-side enforcement actually does
DXComply sits between your website’s scripts and external analytics endpoints, observing GA4’s behavior at the moment of collection: what data it tries to access, what parameters it includes in outbound requests, what identifiers it uses for tracking.
When GA4 attempts to transmit PHI patterns (search queries with health terms, URL parameters that could be patient IDs, events with diagnosis context, User IDs linked to portal accounts), the platform blocks transmission before it leaves the browser. The GA4 request fires, but sensitive data is stripped or suppressed.
This operates independently of GA4’s configuration. If a developer accidentally adds a custom event with a medication name, or Enhanced Measurement captures a new query parameter, the enforcement layer catches it.
The monitoring component provides audit evidence
Every blocked transmission is logged, showing what GA4 attempted to collect, what was blocked and why, which pages triggered blocks, and when configuration changes introduced new risks.
When an auditor asks whether GA4 received PHI, the answer is “here’s a log of every instance where PHI would have been transmitted, and here’s proof it was blocked.” The platform validates GA4’s configuration against HIPAA safeguards, flagging deviations like User-IDs set with patient identifiers or site search capturing health-related queries.
What it doesn’t solve
If your measurement needs require tracking individual patient journeys across authenticated portal sessions or tying analytics data to patient outcomes in your EHR, GA4 with enforcement layers is the wrong architecture. You need analytics infrastructure within your HIPAA-controlled environment, not a marketing platform with blocking rules.
DXComply solves “we want general website analytics without accidentally leaking PHI.” Compliance isn’t about pushing GA4 into contexts where it doesn’t belong. It’s about knowing where the boundary is and having controls that enforce it reliably.
The risk is in the collection layer, and the collection layer is where you have to act
GA4 and HIPAA will remain in tension because they optimize for different outcomes. GA4 optimizes for comprehensive behavioral insight, cross-session attribution, and audience building. HIPAA optimizes for limiting disclosures, protecting patient privacy, and ensuring identifiable health information is used only as necessary for care.
You can’t contract your way out of that tension. Google’s refusal to offer a BAA is a forcing function that requires you to be precise about what your website transmits and whether you can prove PHI never makes that trip.
If you’re running GA4 on a healthcare website and you haven’t validated what it’s actually collecting, you have an evidence gap. Evidence gaps are where violations occur, not because anyone intended harm, but because the collection layer operated without constraint while the compliance conversation stayed focused on paperwork.
The question that matters isn’t whether Google will sign a BAA. It’s whether you know what’s leaving your site and whether you can demonstrate that PHI isn’t part of it.
If the answer is uncertain, tools like Feroot DxComply can close that gap by monitoring what actually transmits and blocking what shouldn’t. But the first step is simpler: know what you’re sending.
