HIPAA and Google Analytics on a clinic website
Your practice website runs Google Analytics, maybe a Meta pixel, maybe a chat widget. What the HHS tracking guidance said, what a court removed from it in 2024, what still applies, where PHI actually shows up on a site, and what to do about it.
Your practice has a website. The marketing company put Google Analytics on it, and a Meta pixel so the ads could be measured, and a chat widget because patients like to ask questions. Then someone forwarded you an article about hospitals being sued over tracking pixels, and you want to know whether that is your problem.
I was the HIPAA compliance officer at an agency for stretches of my time there, and I built and remediated healthcare sites under those rules. The short answer is that it depends on where on the site the tracking runs, and that most clinic sites have it running in the wrong places. Here is the longer answer.
What the guidance said, and what a court took out
In December 2022, the HHS Office for Civil Rights published a bulletin on tracking technologies. It said, in plain terms, that if a HIPAA-regulated entity puts a tracking tool on its site and that tool collects information that can identify a person together with information about their health or care, that is protected health information, and it can only go to a vendor under a business associate agreement, and only for a permitted purpose. Consent banners do not change that, because a visitor cannot authorise a disclosure the entity is not permitted to make.
The bulletin went further. It said that even on a public page, the combination of a visitor’s IP address with a visit to a page about a condition or a provider could be PHI. That was the part hospitals objected to. In June 2024 a federal court in Texas agreed with them and vacated that specific reading, and in August 2024 HHS dropped its appeal.
So here is where things stand. A visit to your public “about knee surgery” page, on its own, is no longer treated by the guidance as PHI just because an IP address came with it. Everything else in the bulletin is still the government’s position: authenticated pages, patient portals, appointment and intake forms, anything where a person identifies themselves and their care is involved, and any vendor that sees that data needs an agreement with you. The lawsuits from patients, which run under state privacy and wiretap laws instead of HIPAA, did not stop when the ruling came out.
Where PHI actually shows up on a clinic website
This is the part the marketing company does not know, because it is not their job. Walk the site with this list.
| Where | What is there | Tracking on it means |
|---|---|---|
| The appointment request form | Name, contact details, reason for visit, preferred provider | The analytics tag sees the page and often the field values. The pixel sees the submit. Both now hold PHI |
| The patient portal link and login | The fact that this person is a patient | A tag on the login page is a disclosure of patient status |
| Contact form with a free-text message | Whatever the patient typed | Same as the appointment form, and patients type diagnoses |
| Provider pages with “book with Dr. X” | Interest in a specialty, tied to a click | On its own after the ruling, probably fine. With a form on the page, it is the form that matters |
| Symptom checkers, quizzes, “am I a candidate” tools | Health answers, often with contact details at the end | PHI from the first answer |
| Prescription refill, test results, telehealth | Everything | Nothing third party belongs on these pages at all |
| Chat widget | Whatever the patient types, held by the chat vendor | The vendor is a business associate, or it should not be there |
| Session replay tools | A recording of the whole visit, including typing | Almost never defensible on a healthcare site |
The rule I use is simple. A page where a person can identify themselves, or where being there identifies them as a patient, is a PHI page. Third-party scripts do not run on PHI pages. Pages that are purely informational can carry analytics, with care about what the analytics vendor is allowed to receive.
What to do about it, in order
First, inventory. Open the site with the browser’s developer tools and list every third-party request on every template: analytics, pixels, tag managers, chat, replay, embedded video, fonts, maps. Most clinic sites have more than the owner thinks, because tag managers let anyone add things without a developer.
Second, split the site. Decide which pages are PHI pages and which are informational, and write it down. For most practices that is a short list: the appointment and contact forms, the portal pages, any tool that asks health questions. Everything else is informational.
Third, remove. On PHI pages, no third-party tags at all. That includes the tag manager itself, because an empty container today is a pixel tomorrow when someone in marketing adds one. The forms on those pages go to your own server, which writes the record to a database you control under an agreement with whoever hosts it. I have written separately about what a form submission should do; the healthcare version is the same with the plumbing changed.
Fourth, decide what to do with analytics on the informational pages. The honest options are:
| Option | What it does | What it costs you |
|---|---|---|
| Google Analytics stays on informational pages only, with IP handling and data retention set tight | You keep page-level reporting on content and campaigns | Google will not sign a BAA, so nothing identifying can reach it, and the split has to hold |
| Replace it with a privacy-first analytics tool that keeps no individual identifiers | Page views and referrers without a person behind them | Less detail, fewer attribution features |
| Server-side analytics from your own logs or CDN | Counts that never involve a third party script | Someone has to build and read the reports |
| Measure ads by conversions sent from your server, with no health details in the event | Campaigns still get credit when someone books | A small build, and a rule about what the event may contain |
Fifth, the vendors you keep. Chat, scheduling, forms, email: each one that can see PHI signs a business associate agreement or leaves. The ones that will sign are known. The free tier of anything usually will not.
Sixth, consent. A consent banner still matters for state privacy laws and for the informational pages, and it is the thing that keeps tracking off until a visitor allows it. It is not a licence to run a pixel on the intake form. I built CookieSteward with a HIPAA mode for exactly this: it keeps marketing tags off the pages you mark as PHI pages no matter what the visitor clicks, and it records what was blocked.
What the marketing company will say
They will say the ads cannot be measured without the pixel. They can, from the server, with an event that says a booking happened and nothing about what for. They will say Google Analytics is anonymous. It is not, in the way that matters, and the guidance says so. They will say everyone else does it. The plaintiffs’ firms are working through everyone else.
None of this requires giving up marketing. It requires deciding which pages are clinical and keeping the advertising stack off them. That is a day of inventory and usually a week of changes.
The audit to run first
If you run a practice, a clinic, a lab, a dental office or anything that bills insurance, do the inventory this month. It takes an afternoon to find out what is on the forms, and the fix is small compared to the letter. The guidance may change again. The direction has been the same for years, and the patients suing are not waiting for HHS.