When a website falls under HIPAA
HIPAA is the federal law governing protected health information, PHI, which is any information that can identify a patient and relates to their health or care, even something as small as a name attached to an appointment request. Plenty of medical practice websites, glorified brochures with hours and directions, barely touch HIPAA at all. The moment your site collects patient information, through forms, appointment requests, chat, or portals, the rules follow the data.
I should say plainly: I am not a lawyer, and this is orientation, not legal advice. What I can offer is the technology side: where websites typically create HIPAA problems, and how the compliant setups differ from the risky ones.
Contact forms are where trouble starts
A generic contact form seems harmless until a patient types one describing symptoms and asking about treatment. Name plus health context is PHI, and that submission now travels through your form plugin, your email provider, and maybe your developer's inbox, none of which was chosen with HIPAA in mind.
The fix is not to remove contact forms. It is to route health-related intake through tools built for it, keep the general contact form for general questions, and label it accordingly, with wording like: please do not include medical information in this form; for appointments and medical questions, use our secure form or call us. Wording alone is not a defense if the rest of the page invites medical detail, but a clear separation of channels is the foundation everything else builds on.
Hosting, email, and the BAA
When a vendor handles PHI on your behalf, HIPAA requires a business associate agreement, a BAA, which is a contract in which the vendor accepts its own compliance obligations. This is the bright line for your website stack: any service that stores or transmits patient data needs to be willing to sign one.
Ordinary shared hosting, free email accounts, and most consumer tools will not sign a BAA. Microsoft 365 and Google Workspace will on business plans, which is one reason practices standardize on them for email. Form and intake vendors that advertise HIPAA support with a BAA typically run 30 to 120 dollars a month, more than a generic form plugin costs, and worth it. The question to ask every vendor in the path of patient data is the same: will you sign a BAA? No is a complete answer, and it means that vendor cannot touch PHI.
The analytics and tracking trap
This is the pitfall practices least expect. Analytics and advertising scripts, the invisible code that measures visits and powers retargeting ads, can transmit page URLs and visitor identifiers to third parties. On a retail site that is ordinary marketing. On a medical site, where the URL might name a condition or a treatment and the visitor can be identified, that transmission can amount to disclosing health information to an advertising platform, and this pattern has drawn regulatory scrutiny and lawsuits across the healthcare industry.
The pragmatic stance: keep marketing pixels and ad trackers off pages involved in care, especially appointment booking, patient portals, and condition-specific pages, and have someone technical inventory what scripts your site actually loads, because plugins and tag managers accumulate trackers nobody remembers adding.
What secure intake looks like
A compliant setup is not exotic. In practice it means:
- A HIPAA-focused form or intake vendor, with a signed BAA, for anything patients submit about their health.
- Submissions delivered into a system covered by a BAA, such as your EHR or a compliant inbox, never forwarded to a personal email account.
- Encryption in transit, meaning the site runs on HTTPS everywhere, which should be true of any site today regardless.
- Access limited to staff who need it, with individual logins and multi-factor authentication rather than one shared password.
- Collecting the minimum: the appointment form needs a name, contact details, and a preferred time; it does not need a symptom essay.
Most of this is choosing the right vendors and settings, not building anything custom.
What to do next
- Inventory every way your website collects information: forms, chat widgets, booking tools, portals.
- For each, trace where submissions go and ask whether every vendor in that path will sign a BAA. Replace the ones that will not.
- Have the tracking scripts on your site listed, and remove ad pixels from care-related and booking pages.
- Add clear channel-separation wording to your general contact form.
- Bring the findings to your compliance officer or healthcare attorney; the technology inventory is exactly what they need to assess risk properly.
An afternoon of inventory now is far cheaper than explaining a leak later. If your web person is not conversant in this, bring in one who is; it is a routine conversation at HashWhales, and it should be routine wherever you take your business.