Google Analytics on a Patient-Facing Site: Where the Risk Actually Is

Ask whether you can run Google Analytics on a medical website and you will usually get a yes or a no, delivered with more confidence than the question supports. The honest answer has three parts, and separating them is what makes the decision tractable: there is a contract question, a page question, and a configuration question. Only the third is fully in your hands, and it is the one most practices spend all their time on.

The reason this comes up more than any other tracking question is volume. GA4 is on almost every practice site in the country, usually installed by whoever built the site, often duplicated by a tag manager, and rarely reviewed since.

It is also the question most likely to be answered by analogy rather than by reading. Someone heard that a hospital system paid a large settlement, or that a competitor removed all their tags, and the conclusion travels faster than the reasoning behind it. The reasoning is worth having, because the correct answer for a cash-pay aesthetics practice and the correct answer for a multi-site group billing Medicare are not the same answer, and neither of them is the one in the article your web developer forwarded.

What Google Analytics on a medical website actually receives

Start with the payload rather than the policy. On every page view, the tag sends a request containing the page path, the page title, the referring URL, the visitor's IP address, a browser and device string, and a persistent client identifier stored in a first-party cookie.

That client identifier is the piece practice owners underestimate. It is a random string, it names nobody, and it is stable across the entire visit and across return visits for as long as the cookie survives. It is precisely the kind of value that supplies the identifying half of the definition through a reasonable basis rather than through a listed identifier, which is the mechanism covered in what counts as PHI on a website.

This is why the common first move, switching on IP anonymization, resolves less than people expect. It removes one identifier from a set that still contains a durable one, and it does nothing at all to the page path that supplies the health context.

The business associate contract problem

Here is the part that actually settles it, and it is a contract question rather than a technical one.

Where a vendor creates, receives, maintains or transmits protected health information on a covered entity's behalf, 45 CFR 164.502 requires a business associate contract. No contract, no permitted disclosure. That is the whole test, and it does not care how carefully the tool is configured.

That single fact does more work than any amount of configuration analysis. If the vendor will not enter the contract, then the tool must not receive PHI, and the entire remaining exercise is making sure it does not. The decision tree for other vendors follows the same shape and is covered in do you need a BAA with your analytics vendor.

Note what this argument does not say. It does not say the product is insecure, poorly built, or unsuitable for measurement. Google Cloud covers a long list of services under a BAA, so the company plainly signs them where it has decided to. Analytics is simply not one of those services, and that is a scoping decision by the vendor rather than a judgment about quality.

Where the risk actually concentrates

Site-wide answers are what get practices into trouble in both directions. The exposure is not evenly distributed, and treating it as though it were produces either paralysis or false comfort.

The middle row is the one that moved. The inference theory that swept treatment pages into scope was struck down in June 2024, which the walkthrough of the guidance covers in detail. The top two rows did not move and never were in dispute.

Configuring Google Analytics on a medical website more carefully

Assume you keep GA4 for the pages where it belongs. Several settings reduce what leaves, and it is worth being precise about what each one does and does not fix.

Do not send form field values as events. Enhanced measurement and tag manager form triggers can capture field contents. On an intake form, that turns a page view into a disclosure of what the visitor typed. This is the single highest-value change on most sites.

Keep health context out of page paths and titles where you reasonably can. This is a real tension, since descriptive URLs are good for search and renaming established pages costs equity. Usually the better trade is to control what reads the path rather than to rewrite it.

Use the privacy controls the product offers, and know their limits. Google documents the available privacy controls in Google Analytics, including data retention and IP handling. They reduce the surface. They do not convert a vendor that will not sign a BAA into one that will.

Gate the tag rather than trusting the configuration. Configuration is a promise about behaviour that has to be re-verified every time a plugin updates, an agency changes, or a tag manager container is edited. A tag that never loaded needs no verification. That asymmetry is the entire argument for consent gating, and it is why the gate sits in front of the script rather than inside it.

What to do about the pages that still matter

Removing measurement from a practice site altogether is an overcorrection that carries its own cost, because you then cannot tell which campaigns produce consultations. The workable position is narrower.

Keep ordinary analytics on ordinary marketing pages. Remove third-party tags entirely from anything behind a login. On pages with health-intent forms, hold non-essential tags until the visitor agrees, and never pass field contents to any third party. Where you need conversion measurement on those pages, move it server side so the record goes to a system you control under a contract you have, rather than to a browser tag you do not.

That last point is the one that turns this from a subtraction exercise into a workable setup. The measurement problem and the disclosure problem have different solutions, and conflating them is why so many practices end up either blind or exposed. Which of your pages fall into which row is an empirical question, not a philosophical one, and the answer is usually surprising.

Two failure patterns show up repeatedly when practices work through this themselves. The first is auditing the analytics property while ignoring the tag manager, which is where most of the actual tags live. GA4 is frequently the only tool anyone remembers installing, and the container next to it holds an advertising pixel, a call-tracking script and a chat widget that nobody has reviewed in three years. Fixing the one you remember and leaving the four you forgot is worse than doing nothing, because it produces confidence.

The second is treating a page as safe because the form on it is embedded from another system. An embedded scheduler or intake widget renders inside your page, which means your page's tags are running while the visitor types into it. The form data may travel to the vendor rather than to you, but everything else on the page is watching the visit happen, and the URL still says what the visit was about.

Both patterns share a root cause worth naming. Practices reason about tools they chose, while browsers execute everything present. The gap between the two is where this problem lives, and it is why the useful first step is a measurement of what actually loads rather than an inventory of what you believe you installed.