HIPAA Compliant Website Forms and Tracking

Why regulators put website forms and pixels on notice

In July 2023, the FTC and the HHS Office for Civil Rights sent a joint letter to approximately 130 hospital systems and telehealth providers warning them about online tracking technologies, naming the Meta/Facebook pixel and Google Analytics specifically. The agencies' concern was direct: these tools gather identifiable information about visitors, usually without their knowledge, as they interact with a website or app.

The letter spelled out what a pixel can reveal about a person: health conditions, diagnoses, medications, treatments, frequency of visits to health care professionals, and where someone seeks care. The agencies cited potential violations of HIPAA, the FTC Act, and the FTC's Health Breach Notification Rule, and pointed to enforcement actions already brought against BetterHelp, GoodRx, and Premom.

The practical takeaway for a practice owner is that the intake form is only half the exposure. The analytics and advertising scripts loaded on the same pages are the other half, and they were the specific trigger for the federal warnings.

What counts as PHI on a practice website

OCR's bulletin on tracking technologies, first issued in late 2022 and revised on March 18, 2024, draws the compliance lines. On any page behind a login, such as a patient portal, information collected by tracking code is protected health information. That part has never been controversial.

The harder line is on public pages. Under the revised guidance, whether tracking data on an unauthenticated page is PHI can turn on why the visitor is there. Legal analysis of the update gives the example of a person researching treatment options for their own brain tumor on a hospital's oncology page: transmitting that visitor's IP address, geographic location, or other identifying information to a tracking vendor is a disclosure of PHI. A visit to a job postings or visiting hours page is not.

Since no practice can read a visitor's intent, the safe operating assumption is that condition pages, service pages, and anything with an appointment form should be treated as PHI-adjacent surfaces. A completed appointment request, which pairs a name and contact details with a stated health concern, sits squarely inside that boundary.

Does a cookie banner make tracking compliant?

No. When PHI could flow to a tracking vendor, OCR's guidance gives regulated entities three workable paths: stop using the technology, configure it so PHI never reaches the vendor, or use a vendor that will sign a business associate agreement. A consent banner is not one of them.

The structural problem is that the most widely used tracking providers do not sign BAAs, a point the legal commentary on the March 2024 update makes plainly. If the vendor behind your pixel or analytics tag will not sign, no amount of banner language authorizes sending PHI to it.

Treat cookie banners as what they are: a tool for general privacy law obligations, not a HIPAA instrument. The HIPAA question is answered by architecture, not by a pop-up.

Not covered by HIPAA? The FTC still applies

Many wellness businesses, such as supplement sellers, health apps, and coaching practices, fall outside HIPAA. The FTC's Health Breach Notification Rule covers much of that gap. It applies to vendors of personal health records, PHR related entities, and their service providers, and July 2024 amendments made clear it reaches health apps, connected devices, and similar products.

The rule's definition of a breach is broader than a hack. The FTC's own compliance guidance states that a company's disclosure of covered information without a person's authorization triggers notification obligations. Sharing users' medical information along with mobile identifiers with an ad network for targeted marketing, without consent, is the FTC's first example of a reportable event.

The notification duties are concrete: notify each affected person without unreasonable delay and within 60 calendar days of discovering the breach, notify the FTC, and notify prominent media outlets when 500 or more residents of a state are affected.

Safer architectures for forms and analytics

The goal is a site where patient data and marketing data never touch. That is an engineering decision made once, not a policy you re-litigate every campaign.

For measurement, you can still count what matters. Track that a booking page was reached or a form was submitted without sending who submitted it, their IP address, or the condition they described to any third party.

• Use a form or intake vendor that will sign a BAA, and confirm the signed agreement exists before the form goes live.
• Encrypt form submissions in transit and at rest, and send them to a secured inbox or EHR, never to a general email account.
• Remove advertising pixels and third-party analytics from condition pages, service pages, booking flows, and every page hosting an intake form.
• Prefer first-party or server-side analytics configured to strip IP addresses and identifiers before anything leaves your infrastructure.
• Collect the minimum on the form itself: name, contact method, and preferred time are enough to book; detailed symptoms can wait for the visit.
• Inventory every script on the site quarterly, because tag managers and plugins reintroduce trackers silently.

What to do this week

Open your booking page and view the network requests in your browser's developer tools. If calls fire to advertising or analytics domains while a form is on screen, you have found your first fix.

Then list every vendor that receives form data and check each one against a simple question: is there a signed BAA, or is the data flow architected so no PHI reaches them? Anything that fails both tests gets removed or replaced. Rank & Rejuvenate builds practice websites this way by default, because booked appointments are only an asset when the pipeline that produces them can survive a regulator's inspection.