The tracking-pixel problem: OCR's guidance and your website

Can my practice website use analytics and tracking pixels?

Yes, but with a hard line: a tracker is fine only if it does not send individually identifiable health information to a third party. Many pixels, cookies, and analytics scripts transmit what a visitor did on your site — the page viewed, a form submitted, an appointment booked — to an outside advertising or analytics network. When that data can be tied to a person and relates to their health, sending it is a disclosure of PHI 1Ref 1HHS Office for Civil Rights (2026).Summary of the HIPAA Privacy Rule.The Privacy Rule definition of PHI and the disclosure framework that makes a tracker transmitting identifiable health data a regulated disclosure..

That is the whole of the tracking-pixel problem: not that analytics is banned, but that the common consumer setup routes protected data to a company you have no agreement with. So the useful move is not to strip every tool off the practice website, but to sort the tools by what they send and to whom. A basic visitor counter that records nothing identifiable is very different from an ad pixel that fires on a page where a patient books a specific service.

Why a pixel can be a HIPAA disclosure

A tracker works by sending data to a third party's servers as the page loads, and that payload is richer than it looks: the URL visited, the referring page, device identifiers, an IP address, and sometimes the content of forms. Under the Privacy Rule, information is PHI when it identifies an individual and relates to their health or care 1Ref 1HHS Office for Civil Rights (2026).Summary of the HIPAA Privacy Rule.The Privacy Rule definition of PHI and the disclosure framework that makes a tracker transmitting identifiable health data a regulated disclosure.. A URL revealing a condition, plus an IP that identifies the visitor, can meet both parts.

This is why 'we anonymized the IP' is rarely a complete answer. Re-identification from the remaining signals is often feasible, and the combination — not any single field — is what makes the data protected. The minimum necessary instinct helps here: if a third party has no need for patient-identifiable browsing data to do its job for you, it should not be receiving it. Treat every tag that fires on a page a patient uses as a potential disclosure until you have confirmed otherwise.

Authenticated vs. public pages

Risk is not uniform across your site, so triage it page by page. Pages behind a login — a patient portal, an intake form, an appointment-booking flow that captures identity and reason for visit — almost always involve PHI, because identity and health information are joined there. A purely informational public page with no identifiers and no form is the lowest-risk case. Most practice sites are a mix, and each page gets its own answer.

Work from a simple gradient:

• Highest risk: logged-in portal pages, symptom checkers, and booking flows that tie a person to a service or condition. Keep third-party ad and analytics tags off these entirely unless the vendor is under a BAA.
• Middle: contact and appointment-request forms. The form contents are sensitive; confine analytics to a tool you control or that is BAA-covered.
• Lowest: static informational pages with no identifiers. Ordinary analytics here carries the least exposure, though the safest posture is still a privacy-respecting configuration.

The point is to stop treating 'the website' as one decision. It is a set of pages with different data, and the tracker policy follows the data.

The two ways to make a tracker lawful

If a tool must receive PHI to do its job, HIPAA gives you exactly two lawful paths, and 'we didn't realize it counted' is not one of them. Either the vendor signs a business-associate agreement and handles the data under HIPAA's rules 2Ref 2HHS Office for Civil Rights (2026).Business Associates.That an analytics or advertising vendor receiving PHI is a business associate requiring a signed BAA., or you obtain the individual's valid HIPAA authorization before the disclosure. Using PHI to market to patients specifically requires that authorization, with only narrow exceptions 3Ref 3HHS Office for Civil Rights (2026).Marketing.That using PHI to market to patients requires authorization, with only narrow exceptions..

In practice this narrows the field fast. Major consumer advertising platforms generally will not sign a BAA, which means you cannot lawfully feed them PHI — so their pixels come off any page that would transmit it. Analytics vendors that do offer a BAA, or a self-hosted tool where the data never leaves your control, are the workable options. This is also where marketing choices collide with privacy: retargeting people who viewed a service page is exactly the use HIPAA's marketing rule restricts, and it is a different question from lawfully asking for reviews or posting patient photos and testimonials with consent.

What to do this week

Turn the analysis into a short cleanup you can finish quickly, because an impermissible disclosure through a tracker can itself be a reportable breach 4Ref 4HHS Office for Civil Rights (2026).Breach Notification Rule.That an impermissible disclosure of unsecured PHI can be a reportable breach subject to notification duties., and OCR does investigate small practices 5Ref 5HHS Office for Civil Rights (2026).HIPAA Compliance and Enforcement.That OCR investigates impermissible disclosures, including at very small practices.. Start by inventorying every tag on your site — a browser developer console or a tag scanner will list them — then map each to the page it fires on and the company it reports to. That inventory is the whole job in miniature.

• Pull third-party ad and analytics tags off PHI pages. Portal, intake, and booking flows first.
• Replace, don't just delete. Move to a BAA-covered or self-hosted analytics tool so you keep the traffic data you actually need.
• Get the BAA for anything touching PHI, and file it with your other agreements.
• Do not rely on IP anonymization alone as a fix; treat the combination of signals as the risk.
• Document the review with a date, so you can show the decision if asked.

If you discover a tracker has been transmitting PHI without a basis, treat it as a potential breach: run the risk assessment, and follow your breach-response steps rather than quietly removing the tag. Handling a mistake on the record is what keeps the bad week from becoming a worse one.

Two adjacent website duties

Two obligations sit right next to the tracking question and are easy to fold into the same website review. First, if your site is not run by a HIPAA covered entity — say a wellness venture or a non-clinical tool — the FTC's Health Breach Notification Rule can reach the same tracking data instead 6Ref 6Federal Trade Commission (2026).Health Breach Notification Rule.That for non-HIPAA websites and apps, the FTC's Health Breach Notification Rule can reach the same tracking data.. Second, a practice website is a place of public accommodation, so ADA web-accessibility expectations apply 7Ref 7U.S. Department of Justice (2026).The Americans with Disabilities Act.That Title III of the ADA treats a practice website as a public accommodation, carrying web-accessibility expectations..

For accessibility, the durable move is to build to a recognized standard — sufficient color contrast, text alternatives for images, keyboard navigation, and captions on any video — rather than waiting for a complaint. It protects patients who use assistive technology and reduces a real legal exposure at the same time. Bundle it with the tracker cleanup so the site gets one thorough review a year instead of a scramble when someone raises an issue.