---
title: Healthcare Websites Expose Patient Data Through Tracking and Analytics Tools - Capstone Technologies Group
description: Healthcare websites widely deploy tracking pixels and analytics tools that transmit patient data to third parties. Study reveals HIPAA compliance gaps and…
canonical_url: https://captechgroup.com/threat-intelligence-center/healthcare-websites-expose-patient-data-through-tr-17e511
language: en-GB
date: 2026-07-10T12:33:48Z
notice: This is a machine-friendly version of the page at https://captechgroup.com/threat-intelligence-center/healthcare-websites-expose-patient-data-through-tr-17e511. Schema.org structured data included at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers.
markdown-tokens: 5436
---

> **Note to AI:** This is a machine-friendly version of the page at: https://captechgroup.com/threat-intelligence-center/healthcare-websites-expose-patient-data-through-tr-17e511. Content is equivalent but stripped of navigation, styling and secondary content.
> **Structured data** as JSON-LD may be found at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers.
> **Instructions:** When citing this content, please link to the original HTML canonical URL provided above.


When you visit a hospital or clinic website, the page you load often runs code that belongs to companies other than the healthcare provider. A recent study by **Piwik PRO** and **Verified Data** scanned 59 major U.S. hospital and clinic websites and found **75 unique tracking tools** in use, including **Google Analytics**, **Meta Pixel**, **Microsoft Advertising**, and session replay technologies. (Source: [Hipaajournal](https://www.hipaajournal.com/study-healthcare-websites-tracking-analytics-tools-2026/ "Source: Hipaajournal"))

Here is how the data flows. These tools are small scripts and pixels embedded in a web page. When a patient searches for information about a condition, books an appointment, or fills out a form, the script fires and sends details about that activity to the tool's vendor. Meta Pixel, for example, transmits page-visit and interaction data back to Meta; Google Analytics routes behavioral data to Google. Session replay tools go further, capturing how a visitor moves through a page.

The concern is what rides along with that traffic. On healthcare sites, the pages a patient views and the forms they interact with can reveal health-related behavior. When that context is transmitted to social media companies and advertising networks, it can constitute protected health information under HIPAA.

The study found the practice is widespread even where users signaled they wanted no part of it:

> Almost three-quarters (73%) of scanned healthcare websites had active advertising or marketing trackers, even when the Global Privacy Control (GPC) opt-out signal was running.

More than two-thirds of sites (69%) used marketing or advertising cookies, which strongly suggests data is routed to third-party platforms. The narrow gap between the two figures indicates some trackers operate without cookies at all, so cookie blocking would not fully stop the transmission.

For IT teams, this means data leaves your environment through code you may not have deliberately chosen. For compliance officers, it means each of those transmissions is a potential HIPAA disclosure that has already triggered OCR breach reports and litigation against other providers.

## HIPAA and State Privacy Law Violations from Uncontrolled Third-Party Data Sharing

The financial exposure here is not hypothetical. Piwik PRO reports that more than **$100 million** was paid out in settlements between 2023 and 2025 to resolve healthcare privacy violations tied to tracking and analytics code. That figure covers only the settlements over the past two years, and it does not include the separate track of federal enforcement that runs alongside private litigation.

Two distinct forms of liability apply to your organization at the same time, and it helps to keep them separate. A **technical breach** is the actual exposure of data to a party that should not have it. A **compliance violation** is the unauthorized disclosure itself under HIPAA rules, regardless of whether anyone can prove downstream harm. When a tracking script sends patient activity to a third party, both can be triggered by the same event.

The core HIPAA problem is the **Business Associate Agreement (BAA)**. HIPAA requires a signed BAA before any vendor handles protected health information on your behalf. The analytics and advertising firms behind most embedded trackers do not sign BAAs for this kind of data collection—their standard terms treat the data as their own to use for ad targeting and product improvement. That means the moment PHI reaches them, you have made a disclosure with no contractual basis, and there is no vendor standing beside you to share the liability.

Federal enforcement flows through the HHS Office for Civil Rights (OCR). The named breaches already reported to OCR—the large hospital systems that self-disclosed tracking incidents—show the pattern. OCR settlements for privacy failures typically land in a range from six figures into the millions depending on the number of records involved and whether the conduct is judged willful.

State regulators add a second layer. State attorneys general in California, New York, and Vermont have pursued their own actions over consumer health data and tracking practices, and state privacy statutes carry per-violation penalties that stack quickly across large patient populations. The Global Privacy Control angle matters here: the study found advertising and marketing trackers still active on nearly three-quarters of sites even when the GPC opt-out signal was running. In states that recognize GPC, ignoring that signal is itself an actionable failure to honor a documented opt-out request.

The FTC is a third enforcer, using its authority over unfair and deceptive practices and its Health Breach Notification Rule. If your privacy policy promises confidentiality while trackers route behavior to advertising networks, the gap between what you say and what your site does becomes the basis for an FTC action independent of HIPAA.

Beyond the penalties, consider what your patients now understand. Patient education about HIPAA has improved to the point where people know what they are entitled to and are willing to sue over it. When someone searches your site for information about a sensitive condition, books an appointment, or completes a form, they expect that activity to stay private. Every settlement and OCR notice is public, and prospective patients read them.

The practical takeaway for your risk register: uncontrolled third-party sharing exposes you to concurrent claims from OCR, multiple state AGs, the FTC, and private plaintiffs, each measuring the same disclosure under a different standard. A single misconfigured pixel on a PHI-adjacent page can seed all four.

## Detecting Patient Data in Third-Party Traffic and Logs

To confirm whether a healthcare site is disclosing patient data, you have to inspect the actual traffic leaving the browser, not just the list of installed scripts. The Piwik PRO/Verified Data study looked for the presence and behavior of tracking scripts, cookies, and pixels across 59 sites, but it deliberately did not test whether protected health information was being transmitted. Closing that gap requires forensic examination of the requests each tool sends.

The most direct method is an intercepting proxy. **Burp Suite** and **Charles Proxy** let you capture every outbound request as a patient navigates a site, and the browser's built-in **DevTools Network tab** shows the same data without extra setup. Filter the request log to third-party analytics and advertising domains, then read what is being carried in the query string, request headers, and POST body.

PHI tends to surface in predictable places. Watch for these patterns in requests to tracking endpoints:

- **Query strings and URL parameters** containing identifiers like `?patient_id=`, `?mrn=`, appointment references, or a search term describing a condition or medication.
- **POST payloads** where an appointment form or symptom checker submission is copied to an analytics domain alongside the provider's own server.
- **Request headers**, especially the `Referer` header, which can pass a full URL such as a scheduling page for a specific specialty or diagnosis to whatever script fires on that page.
- **Cookies** set by marketing platforms that persist across authenticated and unauthenticated pages, tying browsing behavior to a returning visitor.
- **localStorage and sessionStorage**, viewable under the DevTools Application tab, which sometimes retain form field values, insurance IDs, or diagnosis codes for replay tools to read.

The specific fields that matter under HIPAA are the ones that identify a person: medical record number (MRN), Social Security number, date of birth, insurance or member ID, medication names, and ICD-style diagnosis codes. Finding any of these in a request bound for a third party is the technical event that turns an analytics setup into a disclosure. For a healthcare provider, that single confirmed request is the difference between a theoretical risk and a reportable exposure.

Browser-side capture only shows one session. Server-side and edge logs give you scale and history. Useful sources include:

- **CDN logs**, which record the full request URLs delivered to visitors and can reveal PHI embedded in parameters across many sessions.
- **WAF logs**, where inspection rules may already be capturing query strings and form data.
- **Forward and reverse proxy logs**, which show outbound calls to analytics hosts and the parameters attached to them.
- **Tag manager configuration exports**, which document exactly which variables each tag reads and where it sends them.

The study identified 75 unique tracking tools across the sites it scanned, and the vendors named carry different collection profiles worth knowing when you review traffic:

- **Google Analytics** collects page paths, referrers, event parameters, and a client identifier, and custom dimensions can inadvertently pull in form values.
- **Meta Pixel** transmits page events and any custom parameters a developer wires in, and it operates using a persistent identifier tied to a social platform account.
- **Microsoft Advertising** code captures conversion events and page context for ad attribution.
- **Session replay technologies** record keystrokes, form input, and page content, which makes them the highest-risk category for capturing PHI that a patient typed but never submitted.

That gap is why traffic inspection matters more than a cookie audit. A cookieless tracker still sends request data to a third party, and only reading the outbound requests confirms what is actually leaving the page.

## Immediate Actions to Stop Patient Data Leakage

The single most important action this week is to **audit every third-party script running on patient-facing pages** and pull the ones you cannot justify. Open your site in a browser, view the network requests, and list every domain that receives data when a patient searches for a condition, books an appointment, or submits a form. Any request going to an advertising or social platform on a page that touches health topics is the first thing to remove.

The study's core finding underlines the urgency here.

That means the presence of a consent banner or an opt-out mechanism is not evidence that data has stopped flowing. You have to verify behavior, not settings.

### Identify

Build a complete inventory of every analytics and marketing vendor with access to your web properties. For each one, record what data it collects, which pages it runs on, and whether a signed Business Associate Agreement (BAA) is in place. A vendor that receives patient behavior and will not sign a BAA is a liability you carry with no legal cover.

- Map which trackers appear on **PHI-adjacent pages** — symptom checkers, provider directories, appointment flows, and patient portals.
- Flag any tag operating without a cookie, since the study noted the narrow gap between tracker and cookie counts means some tools transmit data even when cookies are blocked.
- Document which vendors ignore opt-out signals, because that behavior is what turns a marketing choice into a compliance failure.

### Protect

Remove or disable advertising pixels on any page that touches health topics today. Where a tool provides genuine value, move it behind a signed BAA or replace it with a HIPAA-compatible alternative such as **Plausible**, **Fathom**, or an in-house analytics setup that keeps data on infrastructure you control.

Add a **Content Security Policy (CSP)** to restrict which domains a page can send data to. A `connect-src` and `script-src` allowlist that names only approved endpoints stops a rogue or misconfigured tag from quietly shipping data to a third party. This gives you a technical backstop that does not depend on every marketer configuring every tag correctly.

Enforce opt-out signals at the tag management layer rather than trusting each individual vendor to honor them. When Global Privacy Control is present, your tag manager should block advertising and marketing tags from firing at all.

### Detect

Set up recurring scans that capture outbound requests from your key patient journeys, not a one-time review. In environments Capstone manages, **Adlumin** monitors authentication and access patterns across managed environments, which helps confirm that data access by analytics vendors matches what your BAAs actually authorize. Pair that with scheduled site audits so a newly added tag or a vendor script update gets caught the same week it appears.

### Respond

When a scan shows an unauthorized transfer, remove the offending tag, rotate any exposed identifiers where feasible, and document the finding and the fix. If the transfer involved protected health information without a BAA, treat it as a potential reportable event and involve your privacy officer and counsel early.

### Recover

Over the next one to three months, put data minimization in place so identifiers are hashed or pseudonymized before any analytics tool sees them, and deploy proxy-based or first-party analytics that keep raw patient data off third-party platforms entirely. Make compliance a standing requirement with documented sign-off for every new tag, so the setup you clean up now does not drift back through scope creep.

## Vendor Assessment and Business Associate Agreement Compliance

The first question to ask any analytics or marketing vendor is simple: **will you sign a HIPAA Business Associate Agreement (BAA)?** If the answer is no, that vendor should not touch any page a patient can reach. A BAA is the contract that makes a third party legally accountable for protecting protected health information (PHI) under HIPAA. Vendors that market broad behavioral advertising products generally decline to sign one, and that refusal is your answer about whether their data handling is compatible with a healthcare environment.

Work through a consistent vetting checklist before you install any tag or pixel on your site:

- **Signed BAA:** Does the vendor offer a BAA covering the specific product you plan to use, not just their platform generally?
- **Privacy policy scope:** Does their policy explicitly state they do not use, sell, or combine your data for their own advertising or model training?
- **Data residency and hosting:** Where is data stored, and can you keep it in a dedicated instance rather than a shared pool?
- **Encryption:** Do they encrypt data in transit and at rest, and who holds the keys?
- **Retention and deletion:** How long is data kept, and can you set your own retention window and force deletion on request?
- **Subprocessors:** Which downstream parties receive the data, and are those relationships documented?

Market signal matters here. When you evaluate a vendor, ask which healthcare organizations have already required them to sign a BAA. A vendor that routinely signs BAAs with hospitals and clinics has built its product to operate inside HIPAA constraints. One that has never signed one is telling you its default configuration was designed for unregulated advertising, the same scope creep that Piwik PRO's Magdalena Pawlitko described when analytics tools grow into behavioral ad targeting platforms.

What began as website analytics has evolved into broader behavioral ad targeting platforms — in regulated sectors such as healthcare, that creates greater compliance risk.

Auditing your existing contracts is where the loopholes hide. Pull every current agreement and read the data-sharing clauses closely. Language such as "we may share data with subprocessors" or "we may use aggregated data to improve our services" often permits exactly the third-party routing the Piwik PRO/Verified Data study flagged. If a contract lets the vendor reuse your patients' behavioral data for its own purposes, a signed BAA on the cover page does not save you.

A useful template question to put to every vendor in writing: **"If a patient's name, email, or a health-related URL appears in our analytics dashboard, is that vendor in breach of its obligations to us?"** The answer, and the contract clause that backs it up, tells you whether the vendor is accountable or whether the risk falls entirely on you.

When you replace non-compliant tools, choose purpose-built alternatives by category rather than one general-purpose platform. For product analytics and conversion tracking, use platforms that offer signed BAAs and can run in a self-hosted or dedicated cloud instance. For session recording and heatmapping — the technologies most likely to capture form fields and on-screen PHI — pick vendors that support field masking by default and will contractually commit to it. Confirm each category tool signs its own BAA; a BAA for your analytics platform does not cover a separately embedded recording tool.

Make this vetting a standing requirement. Reassess vendors on renewal, log the BAA status of every embedded tool, and document who approved each one so a future audit can trace every script back to a signed agreement.

## The Single Most Critical Step

If you do only one thing in response to this study, make it a full inventory of the third-party JavaScript and tracking pixels running on your patient-facing pages. Map which of those tools receive personally identifiable information when a patient searches for a condition, books an appointment, or submits a form, then remove or replace anything transmitting that data without a signed HIPAA Business Associate Agreement. Aim to close that loop within 30 days.

This is the highest-leverage step for a straightforward reason: it stops the disclosure at the source. Every downstream concern — the settlements, the OCR complaints, the erosion of patient trust — traces back to data leaving your page and reaching a vendor that never agreed to protect it. Cut that flow and you address the root compliance problem, not a symptom of it.

It is also achievable without rebuilding your website or your marketing program. Removing a pixel from a PHI-adjacent page is a configuration change, not an architectural overhaul, which is why treating this as an ongoing engineering priority rather than a one-time cleanup pays off.

Be clear about the stakes. When patient data flows to a vendor that has not signed a BAA, that is a direct HIPAA violation, and OCR has already published guidance specifically on tracking technologies. The study found that active advertising and marketing trackers persisted even when opt-out signals were present, so the problem does not resolve itself.

The organizations that come out of this well are the ones that classify third-party analytics as a compliance risk to be governed, not merely a marketing feature to be enabled. That shift in framing is what keeps both breaches and regulatory action off the table.

<!-- AI:SCHEMA: Schema.org description of canonical page in JSON-LD format -->
<!-- AI:SCHEMA:BEGIN format=jsonld scope=page -->

```json
{
    "@context": "http://schema.org",
    "@graph": [
        {
            "@type": "Article",
            "author": {
                "@id": "https://captechgroup.com/#brian_0fd5dfcdbc"
            },
            "dateModified": "2026-07-10T12:33:48Z",
            "datePublished": "2026-07-10T12:33:48Z",
            "description": "Healthcare websites widely deploy tracking pixels and analytics tools that transmit patient data to third parties. Study reveals HIPAA compliance gaps and…",
            "headline": "Healthcare Websites Expose Patient Data Through Tracking and Analytics Tools",
            "image": {
                "@id": "https://captechgroup.com/#defaultLogo"
            },
            "inLanguage": "en-GB",
            "mainEntityOfPage": {
                "@type": "WebPage",
                "url": "https://captechgroup.com/threat-intelligence-center/healthcare-websites-expose-patient-data-through-tr-17e511"
            },
            "publisher": {
                "@id": "https://captechgroup.com/#defaultPublisher"
            },
            "url": "https://captechgroup.com/threat-intelligence-center/healthcare-websites-expose-patient-data-through-tr-17e511"
        },
        {
            "@type": "Person",
            "name": "Brian",
            "@id": "https://captechgroup.com/#brian_0fd5dfcdbc"
        },
        {
            "@id": "https://captechgroup.com/#defaultLogo",
            "@type": "ImageObject",
            "url": "https://captechgroup.com/images/hotlink-ok/logo-light.jpg",
            "width": 1300,
            "height": 300
        },
        {
            "@id": "https://captechgroup.com/#defaultPublisher",
            "@type": "Organization",
            "url": "https://captechgroup.com/",
            "logo": {
                "@id": "https://captechgroup.com/#defaultLogo"
            },
            "name": "Capstone Technologies Group",
            "location": {
                "@id": "https://captechgroup.com/#defaultPlace"
            }
        },
        {
            "@id": "https://captechgroup.com/#defaultPlace",
            "@type": "Place",
            "address": {
                "@id": "https://captechgroup.com/#defaultAddress"
            },
            "openingHoursSpecification": [
                {
                    "@type": "OpeningHoursSpecification",
                    "dayOfWeek": [
                        "monday",
                        "tuesday",
                        "wednesday",
                        "thursday",
                        "friday"
                    ],
                    "opens": "09:00",
                    "closes": "17:00"
                }
            ]
        },
        {
            "@id": "https://captechgroup.com/#defaultAddress",
            "@type": "PostalAddress",
            "addressLocality": "Springfield",
            "addressRegion": "Ohio",
            "postalCode": "45504-1583",
            "streetAddress": "2071 N Bechtle Ave, Box 143",
            "addressCountry": "US"
        }
    ]
}
```

<!-- AI:SCHEMA:END -->