The Problem Most Practices Don’t Know They Have
If your surgical practice website uses a booking form, a patient portal login, or even a simple “Request an Appointment” button, and you’re running Meta Pixel or Google Analytics in its default configuration, there is a reasonable probability you are transmitting protected health information (PHI) to a third party without a Business Associate Agreement in place.
That is a HIPAA violation.
The Office for Civil Rights (OCR) made this explicit in its December 2022 guidance and followed up with enforcement actions through 2024. Fines in recent settlements have ranged from $80,000 to $1.6 million per incident.
What Counts as PHI in a Web Context
HIPAA defines PHI as any individually identifiable health information transmitted or maintained in electronic form. In a web analytics context, PHI is created when two pieces of data are joined:
- An identifier: IP address, device fingerprint, cookie ID, or any value that can be tied to a specific individual
- Health-related data: the URL of a service page, a search query containing a condition name, a form submission indicating a medical need, or even the name of a physician specializing in a specific procedure
A visitor who lands on /spine-surgery/lumbar-fusion/ and whose IP address is captured by a third-party pixel has, by OCR’s interpretation, had their PHI disclosed to that third party.
The Standard Pixel Deployment Is Non-Compliant
Here is what a standard Meta Pixel installation does:
- Fires on every page load, capturing URL, referrer, and browser fingerprint
- Fires again on form interactions (FillForm, Lead events), often capturing field values
- Sends all of this to Meta’s servers in real time
- Uses the data for ad optimization across Meta’s entire user graph
Meta is not willing to sign a BAA for Pixel data. Google similarly excludes advertising products from its HIPAA BAA. This is not a gray area. It is explicitly excluded.
What OCR Has Actually Penalized
The 2024 enforcement wave targeted practices that:
- Embedded pixels on patient portal login pages
- Used URL-based event tracking that revealed appointment types
- Failed to conduct a risk analysis covering their web analytics stack
- Had no documentation that they had evaluated third-party trackers
The settlements are instructive: the violations were not discovered through breaches. OCR investigators reviewed practice websites directly using publicly available browser tools.
The Compliant Alternative: Server-Side Analytics
The architecturally sound solution is server-side, first-party analytics that never exposes raw user data to third-party JavaScript. The key properties of a compliant setup:
Data minimization. Log only what you need: page path (stripped of query parameters containing PHI), timestamp, session identifier (not tied to a persistent cookie), and referral source. Never log full URLs from authenticated sections.
No third-party script on patient-facing pages. Third-party JavaScript executes in the browser with access to everything on the page: form values, URL parameters, cookies. If it runs on a page where a patient might enter or view health information, it is a potential disclosure vector.
BAA in place for every tool that touches the data. If you use a HIPAA-eligible analytics platform (Plausible, PostHog self-hosted, or analytics-only tiers of certain vendors), get the BAA signed before the first byte of data flows.
Annual risk analysis. Document your analytics stack, evaluate each component for PHI risk, and retain that documentation. The analysis itself is what OCR asks for in an investigation.
How to Audit Your Current Setup
A basic audit takes less than an hour using browser developer tools:
- Open your practice website in a browser with DevTools open on the Network tab
- Filter requests by the domain
facebook.com,google-analytics.com,googletagmanager.com,doubleclick.net - Navigate to your appointment request page, doctor profile pages, and any page with a form
- Note which third-party domains receive requests and what data is included in each request
- Cross-reference against your signed BAAs
If you see requests to any of those domains from pages where patient intent or health information is present, you have a gap that needs to be remediated.
The Business Case for Getting This Right
Beyond compliance, there is a straightforward business argument. Surgical patients, particularly elective spine and orthopedic patients, are self-paying at high rates. They research extensively before choosing a practice. A practice that can credibly say “we do not track you with third-party advertising pixels” has a meaningful differentiator in markets where patients are aware of their privacy rights.
The cost of remediation is typically a one-time infrastructure change. The cost of an OCR investigation starts at staff time and legal fees before any fine is assessed.
What DataCentury Builds By Default
Every website we build and host for surgical practices runs zero third-party advertising trackers. Our analytics stack is first-party, self-hosted, and covered under a BAA we provide as part of the engagement. We deliver a Tracking Audit report with every new deployment: a documented baseline that satisfies the OCR risk analysis requirement for the web analytics component of your environment.
If you are running a practice website today and are unsure of your current exposure, the audit steps above are the right starting point.