Is your medical practice contact form HIPAA compliant? Probably not

This is one of the most common gaps we find on US medical and dental practice websites, and it is rarely deliberate. Someone installs a contact form plugin, adds a "How can we help?" field, and patients start typing their symptoms into it.

Here is when HIPAA is engaged, what compliance actually requires, and the practical route to fixing it.

When does HIPAA apply to a website form?

Two conditions have to be met.

1. You are a covered entity or business associate. Practices, dental offices, therapists, clinics and most healthcare providers that transmit health information electronically are covered entities.
2. The form collects protected health information. PHI is health information combined with an identifier — a name, email, phone number, or anything else that identifies the individual.

The second condition is where practices get caught. A form asking for name and email alone is generally not PHI. Add a free-text box labelled "Tell us about your symptoms" and it is — because the patient has now supplied a health detail attached to an identifier.

And patients will use that box for exactly that, regardless of what you intended it for.

Why a standard form is not compliant

What standard forms do	Why it fails
Email the submission in plain text	Standard email is not encrypted in transit end to end
Store entries in the website database	Usually unencrypted, on shared hosting, with no access controls
Send through a third-party form service	That service is a business associate and needs a signed BAA
Keep submissions indefinitely	No retention policy, no audit trail of who read what
Notify multiple staff by email	PHI copied to inboxes with no access control

The email point is the one that surprises people most. Sending PHI to your own practice inbox is still a transmission, and if it travels unencrypted through a general mail provider it is not a compliant channel.

What a compliant setup requires

• Encryption in transit and at rest. HTTPS on the site is necessary and nowhere near sufficient — the data has to stay encrypted where it is stored too.
• A signed Business Associate Agreement with every vendor that touches the data: the form provider, the hosting company, the email provider, the CRM.
• Access controls. Named users with individual logins, not a shared inbox everyone can open.
• Audit logging. A record of who accessed what and when.
• A retention and deletion policy. Data removed on a defined schedule, not held forever by default.
• No PHI in email notifications. The alert should say "a new submission is waiting", with staff logging in to a secure portal to read it.

That last point is the single most useful design change. It separates "you have a message" from the message itself, which removes PHI from the email channel entirely.

The realistic options

Option 1 — Use a HIPAA-compliant form service

Several providers offer compliant forms and will sign a BAA. Typical cost runs from $30 to $200 a month depending on volume and features. This is the straightforward route for most practices.

Option 2 — Do not collect PHI at all

Underrated, free, and appropriate for many practices. Restrict the website form to name, email, phone and a service dropdown with no free-text field. Then say plainly, next to the form: "Please do not include medical details in this form. We will call you to discuss."

The clinical conversation moves to a phone call or your patient portal, which is where it belonged anyway.

Option 3 — Send everything to your patient portal

If you already run a compliant portal, point patient communication there and keep the website form for general, non-clinical enquiries only.

What about appointment booking?

An online booking system that records the reason for a visit is handling PHI. Most reputable healthcare scheduling providers will sign a BAA — general-purpose booking tools usually will not.

Ask the vendor directly: "Will you sign a Business Associate Agreement?" If the answer is anything other than a plain yes, that tool is not suitable for patient scheduling.

The other places PHI leaks on a practice website

• Analytics and advertising pixels. A tracking pixel on a page about a specific condition can transmit browsing behavior tied to an identifier. This has been a significant enforcement area and is worth reviewing carefully.
• Live chat widgets. Patients type symptoms into chat constantly. Most chat tools will not sign a BAA.
• Patient reviews and testimonials. Publishing a patient's name alongside their treatment requires written authorization — and responding publicly to a review in a way that confirms someone is a patient is itself a disclosure.
• Email newsletters segmented by condition.

That review point catches practices out regularly. A patient leaves a negative review; the office replies explaining the treatment history to defend itself; that reply is a disclosure of PHI. The safe response acknowledges the concern and invites the person to make contact privately, without confirming anything.

A four-step fix

1. Look at your current form today. Does it have a free-text field? Where do submissions go? Is there a BAA with that vendor?
2. If there is no BAA, remove the free-text field as an interim measure and add a line telling patients not to include medical details. This takes ten minutes and materially reduces exposure.
3. Decide between a compliant form service and moving clinical conversation to phone or portal.
4. Audit everything else that touches the site — analytics, pixels, chat, scheduling — and get BAAs or remove them.

One thing worth stating plainly: we build websites, we are not attorneys, and HIPAA compliance is a legal determination specific to your practice. What is written here is the technical picture that informs the conversation — the conversation itself should include someone qualified to advise on it.