01Web Design · 7 min
Most practices discover HIPAA matters to their website at the worst possible moment: after a form has already collected something it shouldn't have. The confusion is understandable, because the rule does not say "medical websites must be HIPAA compliant." It says covered entities and their business associates must protect protected health information (PHI). Whether that touches your site depends entirely on what your site collects.
When a website actually falls under HIPAA
A purely informational site — services, bios, location, a phone number — generally handles no PHI and sits outside the rule. HIPAA obligations attach the moment the site starts collecting information that identifies a patient and relates to their health, care, or payment for care.
In practice, that threshold is crossed by:
- A contact form with a "what brings you in?" or "describe your symptoms" field
- Online appointment booking tied to a named person and a service type
- A patient portal, intake questionnaire, or document upload
- Live chat where visitors describe a condition
- Insurance or billing information collected before a visit
Note how ordinary those are. A "request an appointment" form with a free-text message box is the single most common way a practice site quietly starts handling PHI.
What compliance requires from the website itself
The Security Rule is written around safeguards rather than specific technologies, but for a website it consistently comes down to four things.
Encryption in transit and at rest
TLS across the whole site, not just the page holding the form, and encrypted storage wherever submissions land. A form that posts over HTTPS into an unencrypted database has solved half the problem.
A signed BAA with every vendor in the path
This is the step most often missed. Your host, form processor, booking tool, chat widget, CRM, and backup provider all need one. A vendor that will not sign a Business Associate Agreement cannot be in the path of PHI — which in practice rules out a number of popular form and chat tools.
Access controls, logging, and no PHI in email
Unique logins, least privilege, and a record of who accessed what. The related failure is the standard form-to-email notification: the submission travels through unencrypted mail and lands in an inbox nobody has secured, which quietly undoes every other safeguard.
A breach notification path
Decided before you need it, not during. Who is notified, in what order, and within what window.
The mistake that catches the most practices: tracking scripts
Analytics and advertising pixels have been a specific area of regulatory attention, and the scope of that guidance has been contested in court — so treat this as an area to review with counsel rather than a settled checklist. The underlying risk is straightforward, though: a third-party script on a page where a patient is booking a named appointment for a named service can transmit that combination to a vendor who has signed nothing.
The practical posture most practices land on is to keep marketing tags on genuinely public pages, keep them off booking, intake, and portal pages, and confirm that whatever remains is covered by a BAA or is not receiving identifiable data at all.
A short pre-launch checklist
- List every field on every form and ask whether it can elicit health information
- Trace where each submission goes — form processor, email, CRM, spreadsheet
- Confirm a signed BAA for every vendor in that path
- Remove free-text "tell us about your issue" boxes unless the pipeline is secured
- Audit which scripts load on booking and intake pages
- Force TLS sitewide and verify no mixed content
- Set a retention policy — PHI you no longer hold cannot be breached
The design consequence
The strongest move is usually architectural rather than technical: decide deliberately how much PHI the website should touch at all. A site that hands off to a compliant scheduling or portal system, rather than collecting clinical detail itself, has a dramatically smaller surface to secure — and is easier to keep compliant as the practice grows.
That decision belongs at the start of a project, not after launch. It shapes the intake flow, the form design, the vendor stack, and the analytics plan all at once. It is one of the first things we work through on clinic and medical practice websites, and it is far cheaper to get right before the build than to retrofit afterwards.
This article is general information about how HIPAA interacts with website design. It is not legal advice. Compliance decisions should be reviewed with counsel or a qualified compliance professional familiar with your practice.
