For clinics and practices
Is Google Analytics HIPAA compliant?
Short answer: not by default, and Google will not sign a BAA for it. If your booking page or a symptom-specific form runs standard analytics, patient data may already be reaching Google without your knowledge, exposure sitting on your site whether or not anyone's caught it yet. Here is what the OCR guidance actually says, what a standard GA4 setup leaks on a medical site, and what a safer configuration looks like.
Source: Semrush keyword research, verified in live pulls. Demand shifts; we re-verify before every engagement.
The default analytics setup on a medical site is a decision someone else made for you.
Google Analytics is not HIPAA compliant by default, and Google does not sign a Business Associate Agreement for it. If a visitor can be identified as a patient on a page where analytics is running, such as an appointment scheduler or a symptom-specific contact form, that data can qualify as protected health information under the OCR's December 2022 guidance on tracking technologies. Careful configuration, consent controls, and server-side setups reduce the risk substantially, but the compliance decision itself belongs to your healthcare attorney or compliance officer, not to a marketing agency.
That last sentence matters more than it sounds. We are not attorneys, we do not practice law, and nothing on this page is legal advice. We are a search and measurement firm that has done this configuration work on live medical accounts and watched what OCR's own guidance and enforcement actions actually target. If your practice runs Google Analytics today, the next step is a conversation with counsel who knows your specific site and patient flow, informed by the technical facts below.
HHS Office for Civil Rights published bulletin guidance on tracking technologies in December 2022 and reaffirmed its position through 2023 after industry pushback. The core position has not changed since.
OCR's position is that IP address, device identifiers, and browsing activity become protected health information when they are connected to a person's interaction with health services, even without a name attached. A visit to an appointment page, a symptom page, or a patient portal login can qualify.
Public settlements and complaints to date have concentrated on patient portals, telehealth intake, and pages where a visitor's condition or appointment intent is implied by the page itself, not on a hospital's general homepage traffic.
OCR has been explicit that de-identifying data after the fact does not undo the exposure. The problem is the transmission to a third party without a BAA at the moment the pixel fires, not how the data looks in a report later.
None of this means a practice website cannot run analytics. It means the pages where a visitor's status as a patient becomes identifiable, appointment forms, symptom-specific contact forms, portal logins, need a different data path than your general marketing pages.
Google Analytics is not HIPAA compliant by default, and Google will not sign a BAA for it.
Out of the box, GA4's client-side tag sends more than most practice owners realize, straight from the visitor's browser to Google's servers.
| Data point | Standard client-side GA4 | Scrubbed server-side setup |
| Full page URL, including query strings | Sent automatically, including any condition or appointment-type parameters | Parameters stripped server-side before the event is forwarded |
| IP address | Sent to Google, used for geolocation before truncation | Never leaves your own server-side endpoint |
| Appointment / intake page views | Tracked the same as any other page | Excluded from the tag entirely, or tracked only as an anonymous conversion count |
| Referrer and device fingerprint data | Sent to Google in full | Filtered to only what's needed for attribution |
| Google's use of the data | No BAA exists; Google can use it under its standard terms | Same underlying limitation, but far less identifiable data ever reaches Google |
Server-side tagging reduces exposure. It does not create a BAA that does not exist, and it does not make Google Analytics HIPAA compliant on its own. It is risk reduction, not a certification.
This is the technical work, not the legal sign-off. Five changes we look for on every medical account.
Patient portal pages, post-booking confirmation pages, and any page that only loads after a visitor identifies themselves get excluded from the analytics tag entirely.
Analytics does not load until a visitor makes an affirmative choice, and the default state is off, not on.
Events route through your own domain first, where they can be filtered, before anything is forwarded to Google.
Query strings that reveal a condition, procedure, or appointment type are stripped before the event leaves your server.
Signals that would let Google connect an anonymous visit to a known identity are turned off on the pages where it matters most.
We are not compliance counsel and we do not sign off on your HIPAA posture. What we do is the measurement work that has to happen anyway, built around these limits instead of ignoring them, so you keep a usable lead picture without adding exposure your counsel has to clean up later.
We rebuild the marketing-to-lead picture from search, ads, and call data without routing identifiable page views from clinical pages through client-side tags.
We set up first-party server-side tagging so a practice keeps usable attribution data without sending raw, identifiable events straight from the browser.
Monthly tracking of exact prompts across ChatGPT, Perplexity, and AI Overviews, run independently of any on-site tracking pixel, so visibility reporting does not depend on the parts of GA4 that carry the most risk.
We work on two medical accounts today and bring live LegitScript-posture and FTC health-claim experience to that work. Same rule applies there as here: we flag what we see, we do not issue legal opinions. See how this fits together for a clinic specifically on our clinics page, or check current retainer structure on pricing.
Market Findings is a free, external-only check, no logins, no account access, delivered in about 48 hours. It will not tell you whether you're HIPAA compliant, but it will show you what's publicly visible and trackable on your site right now, which is usually the first thing your attorney asks about.
What your buyers ask AI, every day
“is google analytics hipaa compliant for my practice website”
“can I use facebook pixel on a medical site”
“what tracking is allowed on a patient booking page”
We run questions like these monthly, on every engine, and log exactly who gets named. If it is not you, that is the gap we work.
No, not by default. Google Analytics is not HIPAA compliant out of the box because Google does not sign a Business Associate Agreement for the standard product. If a page can identify a visitor as a patient, such as an appointment or symptom-specific page, running standard analytics on it creates real compliance risk under HHS OCR's guidance on tracking technologies.
No. Google does not offer a BAA for standard Google Analytics or GA4. Without a BAA, any protected health information transmitted to Analytics falls outside HIPAA's permitted disclosure framework, which is the central problem OCR's 2022-2023 guidance addresses.
HHS Office for Civil Rights issued bulletin guidance in December 2022, reaffirmed through 2023, stating that tracking technologies on a regulated entity's website or app can transmit protected health information to third parties like Google even without a visitor's name attached, and that this transmission generally requires a Business Associate Agreement or an authorization. It also states that de-identifying or aggregating the data after collection does not resolve the underlying disclosure.
Server-side tracking reduces the amount of identifiable data that reaches Google by filtering and scrubbing events on your own server before forwarding them, but it does not create a BAA that does not exist and does not by itself make the setup HIPAA compliant. It is a meaningful risk-reduction step, not a compliance certification, and the overall configuration still needs review by counsel.
Start by identifying which pages on your site could let a visitor be identified as a patient, such as appointment schedulers, symptom-specific contact forms, or portal logins, and remove or restrict standard analytics tracking on those pages. Move toward a consent-gated, server-side setup with parameter scrubbing for the rest of the site, then have your healthcare attorney or compliance officer review the final configuration before treating it as settled.