Your Intake Form Might Be a HIPAA Problem
There's a setup I keep finding on healthcare practice websites: a contact form, built on a free form plugin, that emails whatever the patient typed straight to the office inbox. It works great. It's also, in most cases, transmitting protected health information through vendors who never signed a BAA — and nobody at the practice knows.
Walt Burge
Founder & Developer, Walt Builds
Published July 10, 2026 · 6 min
LawI audit a lot of small healthcare websites — therapy practices, clinics, med offices. There’s a setup I find so often I now go looking for it first: a “Contact Us” or “Request an Appointment” form, wired up with a free form service or a plugin the original web guy grabbed in an afternoon, that takes whatever the visitor typed and emails it to the front office inbox.
It works flawlessly. The office loves it. And in most of the configurations I find, it’s moving protected health information through third-party servers that have no business touching it, with no agreement in place, in plaintext, into a free email inbox.
Nobody did this on purpose. That’s the problem — this is what you get by default when a generic contact form gets installed on a healthcare site. The form doesn’t know it changed industries.
“It’s just a contact form” — no, it isn’t
Here’s the part that surprises practice owners: you don’t need a diagnosis field or an SSN box for a form submission to be PHI. Under HIPAA, health information is protected when it identifies the person and relates to their health or care. A name and phone number, plus the fact that this person is seeking services from your practice, clears that bar. On a behavioral health site the bar is on the floor — “I’d like to talk to someone about my depression, here’s my cell” is unambiguously PHI, and it’s the single most common thing typed into a therapy practice’s contact form.
The message box is where it gets worse. You can label it “How can we help?” — patients will still type medication lists, diagnoses, their kid’s situation, what happened last week. You cannot control what people put in a free-text box on a healthcare website. You have to build as if they’ll put everything in it, because they will.
Where the leak actually happens
Follow one form submission and count the hands it passes through:
- The form vendor. Free form services process the submission on their servers. Processing PHI on someone’s behalf makes a vendor a business associate — which requires a signed Business Associate Agreement. The free tier of virtually every popular form tool comes with no BAA. Some vendors offer one on a paid healthcare plan; the setups I find are almost never on it.
- The email hop. The submission gets emailed — often through another third-party mail service, then into a standard free email inbox. Regular email is not encrypted end-to-end, and a free consumer inbox is not a compliant place for PHI to live. Now the patient’s message sits there, forever, searchable, on an account with one password and no audit trail.
- The forwards. From the inbox it gets forwarded to the clinician, the biller, someone’s phone. Every hop is another copy in another place no one is tracking.
One “simple” form; three or four uncovered vendors; unlimited retention. If a regulator — or a breach — ever forces the question “where does patient data entered on your website go?”, the honest answer at many practices is we don’t actually know.
What a compliant intake path looks like
The good news: fixing this doesn’t mean scrapping your website or buying an enterprise portal. It means making a handful of deliberate choices instead of default ones.
Collect less on the form. The website form’s job is to start the relationship, not conduct the intake. Name, contact info, and a constrained “what are you looking for” selection is often enough — move the sensitive conversation to the phone call or a proper intake system. The best defense for data you don’t need yet is not collecting it yet.
Put every vendor that touches a submission under a BAA. Form processor, email or notification service, hosting where submissions are stored — each one either signs a BAA or gets out of the pipeline. This single question (“will you sign a BAA?”) sorts your options fast.
Stop terminating PHI in a regular inbox. Submissions should land somewhere access-controlled and encrypted — a compliant intake or CRM system — with email carrying, at most, a notification that something arrived. “New inquiry — log in to view” leaks nothing.
Warn honestly at the free-text box. A short line — “please don’t include medical details here; we’ll cover everything by phone” — reduces what people volunteer. It doesn’t make an uncovered pipeline compliant, but it shrinks the blast radius while you fix the plumbing.
Write down where the data goes. One page: every field, every vendor it passes through, where it rests, who can see it. If you can’t produce that page, you don’t know your own exposure — and producing it is usually the moment practices realize they need to change the setup.
Ask your web person one question
If you run a practice and you’re not sure where you stand, you don’t need to learn HIPAA. Ask whoever built your site: “Walk me through everywhere a form submission goes, and show me the BAA for each stop.” A good answer takes five minutes and names specific vendors. A long pause tells you what you needed to know.
This is fixable in days, not months, and it’s dramatically cheaper than the incident it prevents. It’s also, frankly, a floor: if the website can’t handle a name and a phone number properly, it has no business answering your phones or handling intake — which is where practices are headed next. Build the floor first. We do this work for behavioral health practices specifically, and an audit of your current setup is the cheapest thing on the menu.
- HIPAA
- Compliance
- Behavioral Health
- Web
[More]
More from the blog.
Comments.
Sign in with GitHub to join the thread.
Got a version of this problem in your own business?.