Website Security & Patient Privacy for Practices: Analytics, Forms and the HHS Tracking Guidance

Here is a question most practice websites cannot answer: what does your site send to other companies? Not what it shows patients, what it quietly reports, on every page, to the analytics platforms, advertising networks, chat providers and form tools stitched into it. Most owners have never been handed the full list. The marketing agency added a pixel two redesigns ago. The chat widget arrived as a plugin's helpful extra. The homepage video phones home to its host on every visit. None of it was added carelessly. It was added invisibly, and the invisibility is the problem this article works through.

This article treats the website as a privacy surface. Choosing security software for the whole practice is a larger subject, covered in our guide to healthcare cybersecurity software. Here the lens is narrower, the public website, its trackers and its forms, and the position the US Department of Health and Human Services (HHS) has taken on them. It is education, not legal advice: use it to have a sharper conversation with your privacy counsel and your developer, not to replace either.

'HIPAA Compliant Website' Is the Wrong Question

Start with the phrase itself, because it misleads in both directions. HIPAA is a law about organisations and behaviour: it binds covered entities, most healthcare providers, and their business associates, and it governs how protected health information is used, disclosed and safeguarded. It does not certify products. There is no official stamp that makes a website 'HIPAA compliant' in the way a padlock icon suggests, and no vendor badge can carry your obligations for you.

So the phrase cuts both ways. A website can run over HTTPS on reputable hosting and still be passing identifiable information to a dozen third parties through its trackers and forms. A plainer site may share almost nothing. The honest question is never 'is our website compliant?' It is four questions: what does our website collect, where does it go, who receives it, and under what agreements? Everything in this article hangs off those.

Where a Practice Website Can Share Patient Information

Tracking technologies are, in HHS's description, the scripts and code on a website that gather information about users and their actions, cookies, tracking pixels, session-replay tools, fingerprinting scripts. Practices install them for ordinary reasons: counting visitors, advertising services, answering questions out of hours. But third-party code reports to its owner, not to you, and it may keep following the visitor after they leave your site. The sensitive payload is a combination: an identifier for the visitor, plus the context of a health page.

• Analytics running on appointment, condition and treatment pages, where the page address itself can describe a health interest and travels with the visitor's identifiers.
• Advertising pixels placed site-wide to build marketing audiences, including audiences built from visits to specific service pages.
• Chat and scheduling widgets embedded from third parties, which may receive whatever a visitor types or selects while booking.
• Embedded videos, maps and review widgets, each loading its provider's code onto your pages.
• Form tools that receive and store submissions on the vendor's systems, including everything a patient typed into the message box.

None of these tools is automatically a violation, and several are genuinely useful. The exposure lives in not knowing they are there, what they receive, and whether the company behind them has signed a business associate agreement to safeguard what it gets. That gap is what the HHS guidance was written about.

What the HHS Tracking Guidance Actually Says

In its guidance on online tracking technologies, HHS's Office for Civil Rights explains how the HIPAA Rules apply here. The core idea: individually identifiable health information collected on a regulated entity's website generally is protected health information, even if the visitor is not yet your patient, and even when what is collected is an identifier such as an IP address, an email address or a device ID rather than anything that looks medical. A disclosure to a tracking vendor that the Privacy Rule does not permit is an impermissible disclosure.

The guidance then separates two kinds of pages. Behind a login, patient portals, telehealth areas, tracking tools generally can access protected health information, potentially including appointment dates and clinical detail, so those areas must be configured accordingly and their vendors treated as business associates. On public pages, tracking often touches no protected information at all. But public pages where visitors book appointments or check symptoms are different: what a visitor types or selects there, combined with their identifiers, can be protected information. Even a portal's public login and registration pages count, because the details entered on them are identifying.

Three practical consequences follow. Where a vendor receives protected health information as a business associate, a signed BAA must be in place before the disclosure, and a vendor's promise to delete the information after receiving it is no substitute. Telling visitors in a privacy policy that tracking happens is not, by itself, a permission. And a cookie banner asking visitors to accept tracking is not a HIPAA authorization. And an impermissible disclosure made with no permission and no BAA is presumed to be a breach unless the practice can show a low probability that the information was compromised, with the notification duties that follow.

One part of this story later changed in court. In June 2024, a federal court in Texas, in the American Hospital Association's case against HHS, vacated a portion of the guidance: the part that treated HIPAA as triggered by a technology merely connecting a visitor's IP address with a visit to a public, unauthenticated webpage about specific conditions or providers. The guidance page itself now carries that ruling, and notes HHS is evaluating its next steps. Read the decision narrowly, as it was written: it addressed that public-page, IP-address theory. It did not concern logged-in areas, scheduling and symptom tools, registration pages or forms, the places where identifiable details are actually entered. The careful course is unchanged: audit what your site shares, then take advice on your own situation.

The Form Problem: Never Invite Health Details Into the Wrong Tool

If trackers are the quiet leak, forms are the loud one. A general contact form with an open box asking 'How can we help?' is an engraved invitation to describe symptoms, and patients accept it in detail, because from their side of the screen it feels like writing to their doctor. Where that text lands depends entirely on the tool behind the form: stored in a vendor's database, forwarded to a shared inbox, often both, and usually under no arrangement that contemplates health information.

• Ask only for what the front desk needs in order to respond: a name, contact details and a callback preference, never a description of the condition.
• Say so on the form itself, in words patients will actually read: please don't include medical details here. We will call you to discuss those.
• Route appointment requests into the systems your practice already governs, instead of letting a general form tool become a shadow intake file.
• Know where submissions are stored, who can read them and how long they are kept, and clear out what has accumulated there.

Baseline Website Security Hygiene

Privacy is half the subject. The other half is keeping the site itself out of hostile hands. A compromised practice website is a privacy incident in a different coat, patient-facing pages altered, forms redirected, malicious code served under your name. The defences are unglamorous, mostly free, and identical in spirit to every other checklist on this site: maintenance done on schedule, by someone named.

• HTTPS on every page, with certificates renewed before they expire. Encryption in transit is the floor, not the achievement.
• The website platform, plugins and themes kept updated. Compromised small sites are usually breached through something old, not something clever.
• A separate account for every person who can edit the site, multi-factor authentication on all of them, and no shared administrator login whose password nobody remembers setting.
• Least privilege: the marketing agency, the freelancer and the intern each receive the access their task needs, and lose it when the task ends.
• Backups that run automatically, live away from the site itself, and have been restored once in a test. An untested backup is a rumour.
• Unused plugins, themes and old administrator accounts removed. Every leftover is a door nobody is watching.

The One-Afternoon Audit

Everything above reduces to an afternoon with a spreadsheet. Open your website the way a patient does, then list every third-party thing that loads on it: each script, pixel, widget, embed and form. Your developer can pull the technical list in minutes. Tag managers and plugin settings explain most entries, and the unexplained ones are the interesting ones. It is the same habit as our accessibility checklist: a short, repeatable inspection of the site you actually have.

• What does it collect, page views only, or identifiers, selections and typed text as well?
• Where does the information go, and what does the vendor do with it for its own purposes?
• Will the vendor sign a business associate agreement? Where protected information can reach them, that answer decides whether the tool stays.
• Can anyone at the practice explain, in one sentence, why this tool earns its place? If not, it goes.

Run the forms through the same afternoon: submit a test entry to each one and follow where it lands. Then write the results down and date them. An undocumented audit must be repeated from memory next year. A documented one becomes part of the practice's risk analysis, which is exactly where HHS expects tracking technologies to be addressed.

When to Bring In Professionals

Two kinds of help, for two kinds of question. The legal questions, whether a past disclosure was permitted, what an old form submission obliges you to do, how the guidance and the 2024 ruling bear on your setup, belong to privacy counsel or your compliance advisor. The technical questions, what is running on the site, what it sends, what should be removed, reconfigured or put under agreement, belong to whoever builds and maintains your website, and a written inventory of your trackers and forms should be part of the deliverable you expect from them.

That documentation-first approach is how our healthcare website service treats the privacy surface of a build: the third parties on the site are listed, justified and agreed as part of the work, not discovered by the client afterwards. Planning a new site instead? Our guide to how to build a website for a medical practice covers the planning end to end. You can explore our demos to see the standard of site, and if you would rather the audit were done on your current site than described to you, request a quote and tell us what you found, or what you are afraid you will find.

The reassurance to end on: most practices that run this audit find a handful of fixes, not a catastrophe. The risk was never the tools themselves. It was not knowing they were there.