The clinic’s home page was loading 23 third-party scripts. Third-party scripts on a clinic site are not all created equal, but they share one thing: every one of them is code you didn’t write, running on a page that may collect PHI. Nobody at the clinic could tell me what most of them did. The marketing agency that had built the site three years earlier had added some of them. A former office manager had added two more through a tag manager. A plugin update had silently introduced another. The clinic was paying, in trust and in page weight, for software the clinic could not name.

This is the normal state of affairs on most clinic sites I audit. The script count varies. The pattern does not.

What a third-party script on a clinic site can do

A third-party script is JavaScript that loads from a server you do not control. Once it loads, it has the same capabilities as your own JavaScript. It can read every element on the page. It can read every form field as the user types. It can read cookies. It can make network requests to its origin and elsewhere. It can be silently updated by the vendor at any time, without your knowledge, to do something different from what it did yesterday.

Every script on a clinic page that handles or is near PHI is a trust relationship. You are trusting the vendor to do only what they say they do, to update only in ways you would approve of, and to maintain their own infrastructure such that an attacker cannot compromise their script delivery and replace it with malicious code targeting your visitors.

The history of supply-chain attacks against analytics, advertising, and chat-widget vendors says this trust is not always rewarded.

The risk inventory

The right starting point is to know what is actually running. Pull the network panel on your home page, your contact page, and any page that has a form. For each third-party script, answer four questions.

What is this script for? If nobody at the clinic can answer this, the script is a candidate for removal regardless of other factors.
Does it have a BAA with the clinic? For any script that may receive PHI, this is the critical question. Most do not.
What is its access scope? Is it loaded on every page, or only on specific pages? Does it run before the form is rendered, or only after?
What is the vendor’s security posture? SOC 2 report available? Subresource integrity hashes published? Public incident history?

Most scripts on most clinic sites fail at least two of those four. The exercise is not to remove all of them. It is to remove the ones that fail the test and cannot justify the risk.

The usual suspects, and what to do about each

Google Analytics / GA4. Will not sign a BAA in its standard form. Should not be loaded on pages that collect PHI, including form pages. Acceptable on home, services, and other marketing pages. Configure to avoid sending identifiable URLs to GA. Strip PHI-bearing query strings.

Facebook Pixel / Meta Pixel. Will not sign a BAA. Has a documented history of receiving PHI from healthcare sites in ways that triggered HHS attention in 2022 and 2023. Default recommendation is to remove it entirely from clinic sites. If marketing absolutely requires it, restrict to top-of-funnel pages and explicitly exclude any page that mentions a service, condition, or appointment type.

Google Tag Manager. Itself is a delivery mechanism, not a tracker. The risk is what it loads. Audit the container. Most have been touched by multiple people and contain tags nobody remembers adding.

Chat widgets (Intercom, Drift, Tawk, Tidio, etc.). Capture user input by definition. Most do not sign BAAs at standard tiers. Patients regularly type PHI into chat widgets thinking it is private. The clinic absorbs the resulting HIPAA exposure. For most small clinics, the right answer is to remove the widget and put a clear phone number in its place.

Marketing automation pixels (HubSpot, Marketo, Pardot, ActiveCampaign). Varying levels of HIPAA support. Most require enterprise tiers and specific configuration to be BAA-eligible. The default install is almost never compliant. If marketing is committed to using one of these, the configuration work is real and should not be skipped.

Live captioning, accessibility overlays. Sound good on paper. Most do not improve accessibility in measurable ways and many have been subjects of class action lawsuits. They also load substantial JavaScript and can interfere with screen readers used by patients with disabilities. The honest answer is usually to fix accessibility properly in the markup, not to bolt on an overlay.

Heatmaps and session recording. See the separate post on this. The short version: not on a clinic site.

Hosted fonts (Google Fonts, Adobe Fonts). Lower-risk than the others but still a third party. Hosted fonts have privacy implications in some jurisdictions (Germany has been particularly active here). The fix is small: self-host the fonts. Three lines of CSS and one font file later, the third-party request is gone.

The two ways scripts get on the site

Scripts arrive on a site through two channels. The first is intentional: somebody added them on purpose, usually for marketing or analytics reasons. The second is incidental: they came bundled with a plugin, a theme, or a service the clinic signed up for.

The incidental ones are the harder problem. A WordPress plugin that adds a feature you wanted may also call home with telemetry to a third-party endpoint you did not consent to. A theme may load decorative scripts from a vendor’s CDN. A page builder may inject analytics that the vendor uses for product analytics on their end.

You will not find these by reading the dashboard. You will only find them by watching the network panel. The clinic’s awareness of what is loading on their site is usually a fraction of what is actually loading.

The 80/20 of cleanup

In every audit I have done, about 80 percent of third-party scripts can be removed with no observable impact on the clinic’s operation. The 20 percent that stay are usually:

A privacy-conscious analytics solution (we use Plausible for many clients, or PostHog with replay disabled).
The booking widget, if the clinic uses one and has chosen the vendor carefully.
Self-hosted, non-third-party scripts for site functionality.

That is usually the working set. Three to five scripts, none of which load on the form page, all of which have clear answers to the four-question test.

The cleanup is rarely controversial once it is laid out on a single sheet of paper. The hard part is doing the audit. Most clinics will pay for the cleanup; few will pay for the inventory that justifies the cleanup. We bundle the two so the inventory always gets done. Details on our plans page, and see the related post on vendor procurement for the broader framework.