The False Choice Practices Are Told They Face
Most surgical practices are given a version of this choice by their marketing agency: either run Google Analytics and Meta Pixel to measure your campaigns properly, or fly blind on your ad performance. This framing is wrong, and accepting it is costing practices both money and compliance posture.
The actual choice is between measuring what you need using infrastructure that does not create HIPAA exposure, versus measuring everything available using infrastructure that does. The former is achievable. The latter is not compliant and, because it inflates data with bot traffic, cross-domain contamination, and measurement noise, it is also not as reliable as it sounds.
This article is a decision framework for surgical practice administrators and their IT teams. It covers what you can legally measure, what tools are available, and what the architecture of a compliant analytics setup looks like.
What You Actually Need to Measure
Before evaluating tools, define the minimum viable measurement set. Most surgical practices need answers to four questions:
- Which pages are patients visiting, and in what sequence before booking? Page views and navigation paths, without any patient-identifying data attached.
- Which traffic sources are driving consultation requests? Organic search, paid search (Google Ads, Meta Ads), direct, referral. Broken down by channel, not by individual.
- Which campaigns and ad groups are producing conversions? Form submissions on the appointment request page, click-to-call events, and chat initiations attributed back to campaign source.
- What is the geographic distribution of site visitors? City or metro level, not street address or zip code.
Individual user journeys tracked across sessions with persistent cookies, demographic profiling, remarketing audiences, and lookalike modeling are either a HIPAA risk, not necessary for optimizing a surgical practice’s web presence, or both.
The good news: all four necessary measurements can be achieved without a pixel that fires third-party requests from the patient’s browser.
The GA4 BAA Reality
Google does offer a HIPAA Business Associate Agreement. The important details:
What it covers: Google Analytics 4 in “measurement” mode: basic page views, session data, and event tracking, when configured according to Google’s HIPAA guidelines, which include disabling advertising features, disabling user ID tracking, and not sending any PHI in event parameters or URLs.
What it does not cover: Any GA4 feature connected to Google’s advertising ecosystem: Google Signals, remarketing lists, Google Ads conversion import, audience exports, or any integration that sends data to Google Ads. These are excluded from the BAA by Google’s own terms.
The practical problem: The majority of surgical practices using GA4 are using it precisely for its Google Ads integration. They want to import conversions into Google Ads, build remarketing audiences, and use Smart Bidding. All of these require the advertising features that the BAA excludes. A practice that signs Google’s BAA and then uses GA4 for advertising attribution has a signed BAA that does not cover their actual use case.
The URL problem: Even with advertising features disabled, GA4 records full page URLs by default. A URL like yourpractice.com/appointments/confirm/?type=lumbar-fusion&surgeon=dr-smith transmitted to Google’s servers after a form submission contains PHI. The procedure type and surgeon identity are tied to a session that may be linkable to an individual. URL-level PHI is the specific scenario OCR addressed in its 2022 guidance.
Configuring GA4 for genuine HIPAA compliance requires stripping URL parameters that contain PHI before the hit is sent, a custom GTM configuration that most agencies do not implement, and that limits the data GA4 can collect to the point where simpler, purpose-built analytics tools become more attractive.
The Tools That Sign BAAs (and the Ones That Don’t)
Does not sign a BAA:
- Meta Pixel / Meta Conversions API: no BAA available, full stop
- Microsoft Clarity: no BAA available
- Hotjar: no BAA available
- Google Ads conversion tracking (as a standalone pixel, separate from GA4)
- Mixpanel, Amplitude: no HIPAA BAA for standard plans
Signs a BAA with significant restrictions:
- Google Analytics 4: BAA available, excludes all advertising/remarketing features, requires specific configuration to avoid URL-level PHI
- Google Ads: BAA available for Enhanced Conversions when configured correctly, but the implementation complexity is high
Signs a BAA and is purpose-built for privacy:
- Plausible Analytics: GDPR-native, cookieless, no personal data collected by design; BAA available for HIPAA compliance
- Fathom Analytics: similar privacy model to Plausible; BAA available
- Matomo (self-hosted): full control, no data leaves your infrastructure, BAA with your own hosting provider covers it
- PostHog (self-hosted): open source, self-hosted, full data ownership
Built for healthcare with BAA:
- Freshpaint: healthcare-specific CDP that acts as a proxy layer between your site and downstream analytics tools, signing a BAA and filtering PHI before forwarding data
The self-hosted options (Matomo, PostHog) are the most thorough from a compliance standpoint because the data never leaves your infrastructure; there is no third party to sign a BAA with. The tradeoff is the engineering overhead of running the analytics server.
Server-Side Analytics: The Architecture That Resolves Most of This
The fundamental problem with client-side analytics is that a JavaScript tag runs in the patient’s browser, has access to everything on the page (URL, form values, cookies, local storage), and transmits data to a third-party server before you have any control over what it sends.
Server-side analytics inverts this. Data collection happens on your server, not in the patient’s browser:
- Patient visits your site. No third-party JavaScript executes in their browser.
- Your server records the page view (path, timestamp, anonymized session, referral source).
- That data stays on your server or is forwarded only to tools you control.
- No browser-level data (cookies, form values, device fingerprints) is ever transmitted to a third party.
For attributing Google Ads conversions without a client-side pixel, Google’s Enhanced Conversions API allows you to send hashed conversion data server-to-server after a confirmed appointment request, using the patient’s hashed email (not their raw email) as the match key, sent from your server rather than from their browser. When configured correctly with a signed BAA, this provides campaign attribution without a pixel firing in the browser during the session.
The UTM Parameter Problem
UTM parameters are the strings appended to URLs in ads and emails: ?utm_source=google&utm_medium=cpc&utm_campaign=spine-surgery-tampa. They are how analytics tools attribute traffic to specific campaigns.
The problem: UTM parameters appear in the URL that analytics tools record. A URL like /appointment-confirmation/?utm_source=google&utm_campaign=lumbar-fusion-surgery&utm_medium=cpc on a post-submission page records both the patient’s procedure type (from the campaign name) and confirmation of a medical appointment, in a URL being transmitted to your analytics provider.
Good campaign naming hygiene for HIPAA compliance: campaign names should reference geographic or demographic segments, not procedure names. campaign=spine-tampa-q3 is safer than campaign=lumbar-fusion-tampa. Better still: strip UTM parameters from confirmation page URLs entirely by redirecting to a clean URL after form submission, and record the attribution server-side before the redirect.
What a Compliant Measurement Setup Looks Like in Practice
A surgical practice that needs to measure organic traffic, paid campaign performance, and form conversion rates without HIPAA exposure can achieve this with the following stack:
Traffic and page analytics: Plausible or Fathom with a signed BAA. Both are cookieless, collect no personal data by design, and provide session counts, page views, traffic sources, and geographic distribution at the city level. The script is a single lightweight tag (under 1KB) with no fingerprinting.
Paid search attribution: Google Ads Enhanced Conversions via server-side API. Conversion events (form submission, click-to-call) are sent from your server to Google’s API after the interaction completes, using hashed data. No conversion pixel in the browser, no PHI in the transmission.
Form submission tracking: A server-side form handler that records the submission timestamp, the page the form was on, the traffic source from the session (captured server-side from the referrer), and the UTM parameters, all stored in your own database, none transmitted to a third party.
Zero session recorders, heatmaps, or advertising pixels on patient-facing pages. Full stop.
This setup answers all four questions from the beginning of this article, is fully auditable, and does not require a pixel that could transmit PHI. It is also faster: removing the advertising and session recording scripts reduces page weight by 80–200KB and eliminates the main-thread JavaScript execution that drives INP failures.
The BAA You Need in Place
If any part of your analytics stack touches (or could touch) data that is individually identifiable and health-related, you need a signed BAA with that vendor before data flows to them.
For the compliant stack described above: Plausible or Fathom will sign a BAA. Google’s Enhanced Conversions BAA is available through your Google Ads account. Your hosting provider covers the server-side form database. If you use DataCentury to implement and manage this infrastructure, our BAA covers our handling of the analytics pipeline on your behalf.
The documentation requirement is as important as the BAA itself. Keep a record of: which analytics tools are in use, what data each one receives, what BAAs are in place, and when each was signed. This is the documentation OCR asks for in an investigation.
The One-Page Decision Framework
For any analytics tool you are considering:
- Does the vendor sign a HIPAA BAA? If not, do not use it on patient-facing pages.
- Does your actual use case fall within what the BAA covers? If not, the signed BAA does not protect you.
- Does the tool execute JavaScript in the patient’s browser with access to form values and URLs? If so, evaluate whether server-side alternatives can replace it.
- Does the tool use persistent cookies tied to individual identities? If so, evaluate cookieless alternatives.
- Are UTM parameters or URL parameters that reference procedure types or medical conditions being transmitted? If so, implement URL stripping or rename campaigns.
If you can answer these questions clearly for every tool in your current stack, you have the foundation of a defensible HIPAA risk analysis for your web analytics environment. If you cannot, start with the audit.