HIPAA and your practice website: forms, tracking pixels and chat

01What counts as protected health information on a website

Protected health information is individually identifiable health information handled by a covered entity or its business associates. On a website, that often includes more than people expect: a name and email together with the reason for a visit, an appointment request for a specific condition, or a message in a chat window.

Information about a person combined with the fact that they are seeking care from your practice can be sensitive on its own. Treat every form and chat as potentially containing it.

02Tracking pixels: what HHS has said

In December 2022 the HHS Office for Civil Rights published a bulletin on online tracking technologies, and updated it in March 2024. It warned that pixels and similar tools can send protected health information to vendors such as ad platforms without a BAA.

In June 2024 a federal court in Texas vacated part of that guidance, the part about unauthenticated public pages where the only data is a visit. The guidance on pages behind a login, and on pages where patients enter health information, was not the part vacated.

The practical conclusion has not changed much: keep ad pixels off patient portals, booking flows and any page with a form about symptoms or conditions. If you are unsure about a page, treat it as sensitive.

If a page asks about symptoms, no ad pixel belongs on it.

03Forms and appointment requests

A contact or appointment form is where most practice websites collect protected health information, often without meaning to, through a free-text field like "reason for visit".

• Use a form or scheduling provider that signs a BAA, and sign it.
• Ask only what you need to book the appointment. A general "what can we help with" choice is safer than an open symptoms field.
• Send form notifications without the health details in the email body. Link to the secure system instead.
• Make sure the thank-you page URL does not contain the condition or service in a way ad tags can read.

04Chat and AI assistants

Live chat and AI assistants invite people to describe their problem, which is exactly what makes them useful and risky. Any chat vendor that stores those conversations for you is a business associate and needs a BAA.

For AI assistants, also check where the conversation text goes: the model provider is a subprocessor. Configure the assistant to redirect clinical questions to staff instead of answering them.

05Which vendors need a BAA

A simple rule: if the vendor can see or store health information that came from your website, you need a BAA with them. If they refuse to sign one, they cannot receive that information.

• Form and scheduling tools.
• Chat, call tracking and phone systems that record or transcribe calls.
• The email provider that receives form notifications with health details.
• Hosting, if protected health information is stored on the website itself.
• CRM or patient communication platforms connected to the site.

06How to keep measuring marketing

Compliance does not mean flying blind. You can measure which campaigns bring bookings without sending health details to ad platforms.

Keep analytics on general marketing pages, record the conversion on your own server when a booking is confirmed, and send the ad platform only the fact of a conversion and the click ID, never the service or condition. Review the setup with your compliance officer before launch.

07A 30-minute self check

Open your site in a browser with the developer tools network tab and walk through a booking. Look for requests to ad and analytics domains on each step.

• Which third-party scripts load on the booking and contact pages?
• Does any request include form field values or the name of a condition in the URL?
• Do you have a signed BAA with every tool that receives the form?
• Does the notification email contain health details?
• Is there a written list of tracking tools and the pages they run on?