HIPAA and Your Practice Website: Contact Forms, Booking, and What "Compliant" Actually Means

This article explains how HIPAA applies to a practice website in general terms. It is not legal advice. Your compliance officer or attorney should sign off on your specific setup.

Search "HIPAA compliant website builder" and you will find vendors implying that the right software makes you compliant. It does not work that way. HIPAA does not certify websites. It regulates how covered entities handle protected health information (PHI), and a website is compliant or not depending on what information it collects, where that information goes, and what agreements are in place with whoever touches it.

The good news: most of a practice website has nothing to do with PHI, and the parts that do can be handled with a few deliberate choices.

Which parts of a website involve PHI

PHI is health information that can be tied to an individual. On a website, it shows up in exactly three places:

1. Forms. A contact form that asks "what would you like help with?" and gets back "my daughter has been cutting and needs to see someone" contains PHI the moment it is submitted. So does an intake form, an insurance form, a symptom checklist.
2. Scheduling and messaging. An online booking tool, a client portal, a chat widget. Anything where an identifiable person tells you something about their health.
3. Tracking tools, in some cases. Analytics, ad pixels and session-recording scripts on pages where a logged-in patient is doing something (a portal, a booking confirmation page).

Everything else, your service pages, your about page, your blog, your address and hours, is public information about you, not health information about anyone. You can host it anywhere.

Contact forms: the most common mistake

The default contact form on Squarespace, Wix, WordPress and most builders emails submissions to your inbox and stores a copy on the builder's servers. If that form collects anything health-related, you now have PHI sitting in two places without a Business Associate Agreement (BAA) covering either.

You have three good options:

Option A: Keep the form free of PHI. Ask only for name, phone, email and preferred contact time. Do not include an open "message" box, or label it clearly: "Please do not include health details here; we will discuss those by phone." This is the simplest route and it is how many practices handle it. Your website's job is to get someone to reach out; the clinical conversation happens on the phone or in a secure portal.

Option B: Use a form vendor that will sign a BAA. Hushmail, JotForm (on its HIPAA plan), SimplePractice, TherapyNotes, IntakeQ and similar tools will sign a BAA and encrypt submissions. Embed their form on your site instead of the builder's default. Now the PHI goes to a covered system and the agreement exists.

Option C: Send people straight to your EHR's booking or intake link. If you use SimplePractice, TherapyNotes, Jane, Kareo or similar, the client portal already has the safeguards and the BAA. A "Request an appointment" button that opens that portal is often the cleanest answer, and it removes a step for the client.

What does not work: a plain Google Form (without a Google Workspace BAA and the right configuration), a Typeform on a standard plan, a builder's default form with a "message" field, or a form that emails PHI to a Gmail address. "We delete it right away" is not a safeguard.

Online booking and chat widgets

Same logic. If the booking tool collects reason-for-visit or any health information, the vendor needs to sign a BAA. Most EHR-integrated schedulers do. Generic schedulers (Calendly on a standard plan, for example) generally do not, so either keep the booking free of health details or use a vendor that will.

Live chat and AI chat widgets are a newer problem. If a visitor types "I think I'm having panic attacks, can you help?" into a chat box, that transcript is PHI. Unless the chat vendor signs a BAA and stores transcripts appropriately, do not put one on a practice site.

Analytics and tracking: what changed in 2024

In December 2022, HHS's Office for Civil Rights published guidance saying that tracking tools like Google Analytics and the Meta pixel could create HIPAA problems even on public pages, on the theory that an IP address plus a visit to a page about, say, depression treatment could count as PHI. That caused a lot of practices to strip analytics from their sites entirely.

In June 2024 a federal court in Texas vacated that part of the guidance, ruling that HHS had exceeded its authority in treating a visit to a public page as PHI. OCR filed an appeal and then withdrew it. As of 2026, the practical position is:

• Public, unauthenticated pages (your homepage, service pages, blog): standard analytics are not, by themselves, a HIPAA violation under current law. Many practices still choose a privacy-respecting setup anyway, which is reasonable.
• Authenticated pages (patient portal, booking confirmation, anything behind a login): tracking tools that send identifiable data to third parties still require a BAA or authorization. Do not put ad pixels or session recording there.
• Forms: never let a tracking script capture form field contents.

State privacy laws (California, Washington's My Health My Data Act, and others) add their own rules about health data and tracking that apply regardless of HIPAA. If you see clients in those states, ask your attorney.

Hosting and "HIPAA-compliant" builders

You will see hosting companies and builders advertising HIPAA compliance. What they mean is that they will sign a BAA and their infrastructure meets the technical safeguards. That matters only if PHI lives on their servers, which, if you follow the advice above, it mostly will not. Your public website does not need HIPAA hosting. Your forms and portal need a vendor with a BAA.

Paying a premium for HIPAA hosting while emailing intake forms to Gmail is the wrong way around.

A checklist you can run in ten minutes

• Does any form on the site have a free-text field? If yes, either remove it, add a "no health details" notice, or move to a BAA-backed form vendor.
• Where do form submissions go? If the answer is "the builder's dashboard and my email," see above.
• Does the booking tool collect reason for visit? If yes, does the vendor have a signed BAA with you?
• Is there a chat widget? If yes, who stores the transcripts and is there a BAA?
• Are there tracking scripts on any logged-in or confirmation pages? Remove them.
• Is the site served over HTTPS (padlock in the browser)? If not, fix it today; it is free.
• Does your Notice of Privacy Practices live somewhere on the site? It should.
• Do you have a written record of which vendors touch PHI and which agreements cover them? Keep one.

How Arclo handles this

Practice sites we build keep the public site free of PHI by design: contact forms collect name, phone, email and a preferred time; the "message" field, if a practice wants one, carries a notice; and booking buttons hand off to the practice's own EHR portal or a BAA-backed scheduler. Tracking is limited to public pages and never reads form contents. The practice owns the site and the domain, so if their compliance officer wants a different setup, it is their call to make.

If you want a quick read on your current site, run a free scan. It will not audit your BAAs, but it will show what forms and scripts are on each page so you know where to look.