Does HIPAA apply to your practice’s forms at all?
HIPAA’s rules bind covered entities and their business associates. HHS defines a covered health care provider as one "who conducts certain billing and payment related transactions electronically".1 Most chiropractic, dental and acupuncture practices that bill insurance meet that definition. A cash-only health coach who never sends an electronic claim may not.
Being outside HIPAA is not a free pass. The FTC says its Act applies to covered entities and business associates "as well as to companies that collect, use, or share health information that aren’t required to comply with HIPAA".5 If your website promises privacy and your form tool shares answers with an ad platform, that gap is what the FTC looks at. The rest of this post assumes you are covered, and the same habits are sound either way.
Which tools count as a business associate?
HHS describes a business associate as a person or entity that performs functions or activities involving protected health information on behalf of a covered entity, other than its own workforce.2 The Privacy Rule requires the covered entity to get "satisfactory assurances", in writing, that the business associate will safeguard the information.2 That written contract is the business associate agreement (BAA).
The cloud computing guidance settles the question most practices ask. When a covered entity uses a cloud service to "create, receive, maintain, or transmit" electronic health information on its behalf, the cloud service is a business associate. HHS adds: "This is true even if the CSP processes or stores only encrypted ePHI and lacks an encryption key for the data."1 The vendor is then liable both under the contract and directly under the HIPAA Rules.1
So the working test is simple. If patient answers pass through or rest on a vendor’s servers, you need a signed BAA with that vendor before the first patient submits anything. Check whether the vendor signs a BAA for the exact plan you pay for. If it does not, that plan is not suitable for intake, whatever its security page says.
| Tool | Handles patient answers? | BAA needed? |
|---|---|---|
| Online form builder used for intake | Yes, stores submissions | Yes |
| Email service that receives form notifications with answers | Yes, transmits and stores | Yes |
| Cloud drive where completed PDFs are saved | Yes, stores | Yes |
| Practice management or EHR system with a patient portal | Yes | Yes, usually offered as standard |
| Website host for a page with no form | No patient answers | Usually no |
| Scheduling tool that records only name, phone and time | Can still be health information for a provider | Treat as yes |
The last row surprises people. For a covered provider, a person’s name linked to an appointment at a named practice can already reveal something about their health. Treat booking tools the same way as intake forms and ask for the agreement.
What the minimum necessary rule means for form fields
HHS summarizes the standard this way: covered entities must "take reasonable steps to limit the use or disclosure of, and requests for, protected health information to the minimum necessary to accomplish the intended purpose".3 Note the word requests. The rule is not only about what you send out. It is about what you ask for.
Applied to a website, that points to a two-stage design:
- A public contact or booking-request form that asks for name, preferred contact method, and a general reason for the visit chosen from a short list, with a line telling people not to include medical details.
- A full intake form, with history, medications and symptoms, sent only after the appointment exists, through a tool covered by a BAA, ideally inside the practice management system’s patient portal.
A free-text box on the home page that says "tell us about your symptoms" invites exactly the detail you do not want in a general inbox. Most people will write far more than the front desk needs to book them.
Security Rule basics for the systems behind the form
The Security Rule requires administrative, physical and technical safeguards for electronic health information, and it starts with a risk analysis: "an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability" of that information.4 Among the technical safeguards are access control, audit controls, authentication, and transmission security, which means protecting information "being transmitted over an electronic network".4
Some specifications are labeled addressable. HHS is explicit that "addressable" does not mean optional: you implement it where reasonable and appropriate, or document an alternative that meets the same purpose.4 For a small practice, the practical steps are an encrypted connection on every form page, individual logins for each staff member, two-step sign-in on the form and email accounts, and a written record of which tools hold patient data and whose BAA covers each one.
A short audit you can run this week
- List every form on the website and every tool that receives its submissions, including notification emails.
- For each tool, find the signed BAA. If there is none, stop sending patient information through it.
- Read each form’s fields and delete any that the next step does not need.
- Add a one-line notice to public forms asking people not to include medical details.
- Check that no analytics or advertising tag fires on the intake pages. Tracking on booking pages is a separate HHS topic and deserves its own review.
Privacy wording matters in public too: the same care applies when you respond to online reviews. Mapping forms, tools and agreements across a site is part of a technical and compliance rebuild. This post explains HHS and FTC guidance as published. It is not legal advice, and a practice unsure whether it is a covered entity should ask a healthcare lawyer.