Do dental patient forms need a business associate agreement?
A name beside a reason for visiting is what creates the obligation, and Webflow's own terms forbid collecting it at all. Here is where the form should live, what the agreement does and does not cover, and the analytics leak that undoes the whole arrangement.
A dental enquiry form collects a name and a reason for visiting. That pairing, not either half on its own, is what turns ordinary form data into protected health information, and it is what a contact form produces by default on almost every practice site we are asked to look at.
The platform may have decided this already
Before any analysis of what counts as protected health information, there is a shorter answer in the contract. Webflow's terms of service, section 3.6, headed HIPAA Non-Compliance, have the site owner agree not to provide, or enable end users to provide, protected health information in connection with the platform. That is an undertaking, not a note about a missing feature, and it settles where the form can live before the design conversation starts. We set it out in full, with what Framer's terms say on the same question, in what the platform terms actually say about health data.
What a business associate agreement actually covers
The working pattern is an embedded form from a vendor that will sign a business associate agreement, so the regulated data never passes through the site builder's own form handling. Jotform states that its Gold and Enterprise plans unlock HIPAA features and a signed agreement; other vendors do the same at their own tiers. Two questions decide the choice, and neither is about the form designer: which plan carries the agreement, and where the submission travels afterwards.
That second question is where most practices come unstuck. The agreement covers the form. It does not cover the notification email landing in a practice inbox, the practice management system the enquiry is copied into, or the spreadsheet somebody exports on a Friday afternoon. Regulated data usually ends up in all three, and none of them was in scope when the form vendor was chosen.
The leak nobody looks for
A form that posts correctly to a compliant vendor and also fires an analytics event carrying the field values has put the data back on the page it was removed from. We find this more often than the missing agreement, because it is added later, usually by somebody improving conversion tracking, and nothing about it looks like a compliance change. Any event parameter carrying a free text field, a treatment name or a reason for visiting is the thing to look for.
None of this makes a dental site hard to build. It makes the order of decisions different: where the regulated flow lives is settled first, and the design is built around it. The vertical version of this, with booking and the insurance question, is on our dental practices page.
