Is GA4 HIPAA Compliant Healthcare Organisations Guide

Is GA4 HIPAA Compliant? Healthcare Organisations Guide

No. Google Analytics 4 is not HIPAA-compliant, and you can’t make it compliant through configuration.

The reason is simple and comes from Google itself. Google does not sign Business Associate Agreements for Google Analytics. Without a BAA, a HIPAA-regulated entity cannot lawfully disclose Protected Health Information to a vendor, no matter what settings it applies.

That leaves healthcare organisations with a narrower question: which pages on your site can carry a GA4 tag at all.

Key Takeaways

Google states plainly that it makes no representations about HIPAA and “does not offer Business Associate Agreements in connection with this service.” No BAA means no lawful route to send PHI to Google Analytics.

GA4 routinely collects IP addresses, device identifiers, and page URLs. Each of those appears in the Privacy Rule’s list of 18 identifiers, and combined with a health context, they can become PHI.

A federal court vacated part of the HHS tracking guidance in June 2024, narrowing what counts as PHI on public webpages. Authenticated areas such as patient portals were not affected, and tracking tags still do not belong there.

GA4 Is Not HIPAA Compliant, and Configuration Does Not Fix It

HIPAA works through contracts. When a covered entity lets a vendor create, receive, maintain, or transmit PHI on its behalf, that vendor becomes a business associate, and the relationship has to be governed by a Business Associate Agreement.

Google will not enter into one for Analytics. Its published HIPAA guidance says the product makes no representations about satisfying HIPAA requirements and that BAAs are not offered for the service.

This matters more than it first appears. Google does sign BAAs for parts of Google Cloud and Google Workspace. Analytics sits outside that list, which tells you the position is deliberate rather than an oversight.

A second obstacle sits beneath the first. Google Analytics terms already prohibit sending Google any data that could identify a person. So even setting HIPAA aside, pushing patient-identifying data into GA4 breaches the product’s own terms of service.

The version number changes nothing. Universal Analytics was not HIPAA-compliant, GA4 is not HIPAA-compliant, and neither was ever designed to hold health data.

What GA4 Collects That Can Become PHI

The Privacy Rule’s Safe Harbour de-identification standard lists 18 identifiers that have to be removed before health information stops being individually identifiable. Three of them show up in standard GA4 collection.

IP addresses. GA4 processes IP addresses to derive approximate location. Even when it doesn’t store the address long-term, GA4 still transmits it to Google.

Device identifiers. Client IDs, cookie values, advertising IDs, and app instance IDs all persist across sessions and are designed to distinguish one user from another.

URLs. This is the one organisations underestimate. A page path like /appointments/oncology/confirm?patient=48213 carries a health context and an internal reference in a single string, and GA4 collects page paths by default.

Query parameters are a recurring failure point. Booking flows, symptom checkers, and search functions frequently write personal details into the URL, where analytics picks them up automatically.

None of these identifiers is PHI on its own. They become PHI when a regulated entity holds them, and they connect to an individual’s past, present, or future health, healthcare, or payment for healthcare.

The HHS Guidance and the Court Ruling That Narrowed It

Most articles on this topic are out of date, because the legal position changed in 2024.

In December 2022, the HHS Office for Civil Rights published a bulletin on online tracking technologies, revised in March 2024. It took an expansive view: that connecting a user’s IP address to a visit to a public webpage about a specific health condition could itself trigger HIPAA obligations.

The American Hospital Association sued. On 20 June 2024, the US District Court for the Northern District of Texas vacated that part of the bulletin, holding that the rule was adopted in “clear excess of HHS’s authority under HIPAA.” HHS withdrew its appeal on 29 August 2024, which settled the matter.

What the ruling changed

HHS updated the bulletin to reflect the decision. The current text states that an online tracking technology connecting an IP address with a visit to a webpage about health conditions or listing providers is not enough on its own to constitute individually identifiable health information, where the visit does not relate to that individual’s health, healthcare, or payment for healthcare.

In practice, a visitor reading a public page about diabetes does not automatically create a HIPAA disclosure.

What the ruling did not change

Everything else in the bulletin stands, and the parts that matter most were untouched.

Tracking technologies on user-authenticated pages generally do have access to PHI. Patient portals, telehealth platforms, and any logged-in area fall squarely inside HIPAA. Vendors receiving PHI from those pages are business associates and need a BAA.

Unauthenticated pages can still involve PHI. A public appointment booking form that transmits an appointment request alongside an IP address is a disclosure, regardless of whether the user logged in.

The vacatur narrowed one specific proposition about public browsing. It did not create a general permission to run third-party analytics across a healthcare website.

Google’s Own Instructions to Healthcare Customers

Google’s HIPAA page tells regulated entities exactly what it expects, and the instructions are more restrictive than most implementations.

Customers subject to HIPAA must not use Analytics in any way that involves Google accessing or collecting PHI, and may only use it on pages that are not HIPAA-covered.

On authenticated pages, Google’s position is direct: these are likely to be HIPAA-covered, and customers should not place Analytics tags on them.

On unauthenticated pages related to the provision of healthcare services, Google says these are more likely to be HIPAA-covered, and tags should not be set on them either.

Google then advises customers to work with their legal team to identify which pages do not relate to the provision of healthcare services.

Read together, that is Google telling healthcare organisations to keep GA4 off the clinically relevant parts of their site and to get legal sign-off on where the line falls.

What Getting This Wrong Costs

Civil monetary penalties under HIPAA run in four tiers based on culpability. Under the inflation adjustment published in the Federal Register on 28 January 2026, the adjusted amounts start at $145 per violation and reach an annual cap of $2,190,294 for the most serious tier. They apply to penalties assessed on or after that date, where the violation occurred on or after 2 November 2015.

Regulatory penalties are only part of the exposure. Class action litigation over tracking pixels has produced larger numbers than most OCR settlements.

Novant Health reached a $6.66 million settlement over a Meta Pixel on its MyChart patient portal. The health system had reported that the protected health information of up to 1,362,296 individuals was disclosed to third parties, including Meta, between May 2020 and August 2022. Novant said the settlement was not an admission of wrongdoing and that the court made no finding of wrongdoing. Advocate Aurora Health settled a comparable pixel claim for $12.225 million.

There is also breach notification to account for. An impermissible disclosure of PHI to an analytics vendor is presumed to be a reportable breach unless you can demonstrate a low probability that the data was compromised. Reporting means notifying affected individuals, HHS, and in larger incidents, the media.

Safer Alternatives to GA4 for Healthcare Sites

Four approaches work, and most organisations combine them.

Split your site and tag only the safe parts

This is the approach Google describes. Map every page, classify each as HIPAA-covered or not, and deploy GA4 only on the clearly non-covered pages such as careers, visiting hours, and general corporate information. Document the classification, because you will need to defend it.

Use an analytics platform that signs a BAA

Several analytics vendors sign BAAs and are built for regulated environments, including self-hosted options where the data never leaves your infrastructure. If you need analytics on patient portals or booking flows, this is the route that actually works.

Filter server-side before data reaches Google

Server-side tagging lets you strip identifiers and rewrite URLs before anything is transmitted. Used carefully, it reduces what leaves your systems, but it does not solve the BAA problem. Your obligation is that no PHI reaches Google at all, and a filter that leaks once is a disclosure.

Redact at the source

Stop writing personal data into URLs and form submissions that analytics reads. Move identifiers into POST bodies, replace them with opaque tokens, and audit query strings across booking and search functions. This is unglamorous work that removes whole categories of risk.

HIPAA and GDPR Are Separate Problems

Healthcare organisations operating on both sides of the Atlantic sometimes assume one analytics setup can satisfy both regimes. It cannot, because the two laws are built differently.

HIPAA applies to defined covered entities and business associates, and turns on contracts and permitted disclosures. GDPR applies to any organisation processing the personal data of people in the EU, turns on lawful bases and data subject rights, and treats health data as a special category under Article 9.

A GA4 deployment made GDPR-defensible through consent management and data minimisation can still breach HIPAA because GDPR has no equivalent of the BAA requirement. Our comparison of HIPAA and GDPR covers where the two frameworks diverge.

Conclusion

GA4 is not HIPAA compliant, and no configuration changes can make it so, because Google has decided not to offer a BAA for the product. The practical work is deciding which pages on your site are HIPAA-covered and keeping Google’s tags off them.

Start with an inventory. Classify and document every page, tag, and query parameter. Most organisations that run this exercise find at least one tag somewhere it should not be.

If you need help mapping where health data flows through your website, our data protection consultants work across HIPAA, GDPR, and UK GDPR.

Frequently Asked Questions

Can I make GA4 HIPAA compliant by turning off IP collection?

No. IP address handling is one input among several, and disabling it does not change the underlying problem. Google will not sign a BAA for Analytics, so you have no lawful basis to disclose PHI to the service, regardless of which settings you adjust.

Does Google sign a BAA for any of its products?

Yes, for certain Google Cloud and Google Workspace services. Google Analytics is not among them, and Google’s HIPAA guidance says it does not offer BAAs for that service.

Is it safe to run GA4 on a hospital’s public website?

It depends on the page. Following the 2024 court ruling, a visitor reading general public information does not automatically create a HIPAA disclosure. Google still advises keeping tags off pages related to the provision of healthcare services, and off any authenticated area such as a patient portal.

Was the HHS tracking technologies bulletin withdrawn entirely?

No. A federal court vacated one specific part of it in June 2024, covering IP addresses and visits to unauthenticated public webpages. The rest of the guidance remains published, including the requirement for a BAA where a tracking vendor receives PHI.

What analytics can healthcare organisations use instead of GA4?

Analytics platforms that sign a BAA, including self-hosted tools where data stays inside your own infrastructure. The test is whether the vendor will contractually accept business associate obligations in writing.

Disclaimer: This blog post is for informational purposes only. It does not offer legal advice or opinions. This article is not a guide for resolving legal issues or managing litigation on your own. It should not be considered a replacement for professional legal counsel and does not provide legal advice for any specific situation or employer.

About the Author

Zlatko Delev

Head of Commercial & Country Manager

Zlatko Delev is Head of Commercial and Country Manager at GDPRLocal, where he leads the company’s commercial strategy and market presence. He brings international experience across sales, marketing, and customer success, along with a legal background from his studies at Iustinianus Primus Law School in Skopje, Macedonia.

Zlatko sits at the front line of GDPRLocal’s client relationships, guiding organisations through the first stages of their compliance journey and helping them understand where they stand and where they need to go on GDPR, information security, and the emerging landscape of AI regulation. His role bridges commercial strategy with practical data protection knowledge, ensuring clients get clear, actionable direction from their very first conversation with GDPRLocal.

Alongside his commercial focus, Zlatko has trained extensively in project management and organisational leadership, including risk management, stakeholder communication, agile methodology, and digital marketing, a broad skill set that supports his structured, delivery-focused approach to growing GDPRLocal’s business internationally.