Here is the sentence that gets practices in trouble: "Our web host said the site is HIPAA compliant." There is no such thing as a HIPAA-compliant website you can buy off a shelf, no certificate that makes the problem go away. HIPAA compliance is not a product. It is a set of ongoing decisions about how your site collects, moves, and stores patient information, and most of those decisions are made, or missed, during design.
This guide explains, in plain English, what actually makes a healthcare website HIPAA compliant, where ordinary features quietly break the rules, and what to check before you launch. It is the compliance companion to our broader guide on medical website design.
The short version
HIPAA only cares about protected health information (PHI). A website triggers it the moment a patient types identifiable health details into a form, chat, or scheduler. Compliance means encrypting that data, using vendors who will sign a Business Associate Agreement, keeping tracking pixels away from PHI, and controlling who can see submissions. No product is "HIPAA certified", it is how you build and operate that counts.
What a "HIPAA-Compliant Website" Actually Means
PHI is the only thing HIPAA cares about
HIPAA governs protected health information: any detail that could identify a person combined with something about their health, care, or payment for care. A name next to a requested appointment for an oncology consult is PHI. An anonymous page view of your services is not. This single distinction decides almost everything. If a part of your site never touches identifiable health information, HIPAA largely leaves it alone. The moment a part does, the full weight of the Privacy and Security Rules applies to it.
When a website triggers HIPAA, and when it doesn't
A purely informational site, hours, directions, service descriptions, with no way to submit personal details carries little HIPAA exposure. Add a contact form that asks "what brings you in?", a symptom checker, an intake form, a chat widget, or online scheduling, and you are now collecting PHI. That feature, and every tool connected to it, must meet HIPAA's requirements. Practices get caught because the trigger is a small, ordinary form nobody flagged as a compliance decision.
The Myth of a "HIPAA-Certified" Website
Why no certification exists
The US Department of Health and Human Services does not certify websites, platforms, or vendors as HIPAA compliant. Any company claiming to sell you a "HIPAA-certified" website is, at best, describing their own self-assessment. Compliance is a state you maintain through correct configuration and operation, not a badge you earn once. Treat "certified" as a marketing word, and read what the vendor will actually put in writing.
What a Business Associate Agreement is, and why you need one
When a third party, your form provider, hosting company, email service, or scheduler, handles PHI on your behalf, HIPAA requires a signed Business Associate Agreement (BAA). In it, the vendor legally commits to protecting that data and accepts liability for their part. The rule is blunt: if a tool touches PHI and the vendor will not sign a BAA, you cannot use it for that purpose. The BAA, not a logo, is the real test of whether a vendor belongs anywhere near patient data.
Not sure whether your current vendors will sign a BAA, or whether they should?
The Design and Build Requirements
Encryption everywhere
Every page should load over HTTPS, and any data a patient submits must be encrypted in transit and at rest. An SSL certificate that turns the padlock on is necessary, but it is only the transport layer. It does not, on its own, make a form or a database compliant, a point worth remembering when someone waves the padlock as proof of compliance.
Secure forms, not plain email
Where intake forms go wrong. The most common breach hiding in plain sight is a contact or intake form that emails submissions to the front desk as plain text. Standard email is not secure and is not HIPAA compliant for PHI. The patient's details travel and sit in inboxes with no protection.
Encrypted form vendors and BAAs. The fix is a form and intake tool built for healthcare that encrypts submissions, stores them securely, restricts access, and, critically, will sign a BAA. General-purpose form builders can be fine for a newsletter signup and wrong for an intake form; the deciding factor is whether PHI is involved and whether there is a BAA in place.
The tracking-pixel problem
The enforcement wave. In late 2022, the HHS Office for Civil Rights issued a bulletin warning that online tracking technologies, third-party pixels and analytics scripts like those from ad platforms, can transmit PHI to the companies behind them, and that doing so without authorization violates HIPAA. A series of enforcement actions and settlements followed. Hospitals and practices discovered that a marketing pixel on a page about a condition, or on a scheduling page, had been sending identifiable data to an advertising network for years.
Analytics you can actually use safely. You do not have to go blind. The safe pattern is to keep third-party tracking off any page or flow that handles PHI, and to use analytics configured not to capture identifiable health data, ideally under a BAA. Measure marketing pages freely; treat symptom, scheduling, and portal pages as off-limits to advertising trackers.
Chatbots, scheduling, and third-party embeds
Every embedded tool that can receive a patient's message is a potential PHI channel: live chat, AI chatbots, scheduling widgets, review pop-ups. Each needs the same test, does it handle PHI, is it configured securely, and is there a BAA. An embed you dropped in for convenience can quietly become your largest exposure. The same discipline extends to any patient-facing app or portal, where healthcare UX design and compliance have to be solved together.
Not sure which of your forms, chat tools, or trackers are touching PHI?
Access, Storage, and the Human Side
Who can see form submissions
Compliance is not only technical. HIPAA expects that only the people who need PHI to do their jobs can reach it. That means named accounts rather than a shared login, permissions scoped to roles, and an end to the habit of forwarding patient emails around the office. The tidiest encrypted form still leaks if its inbox is open to everyone.
Data retention and breach response
Decide, in advance, how long you keep submissions, where they live, and what happens if something goes wrong. HIPAA sets breach-notification obligations, and having a plan before an incident is the difference between a contained problem and a crisis. Retention is a design decision too: data you no longer hold cannot be breached.
Want these controls designed into your site instead of bolted on later?
A Practical HIPAA Website Checklist
Before you launch
- HTTPS on every page, valid certificate
- Every form, chat, and scheduler that collects PHI uses a HIPAA-ready vendor with a signed BAA
- No advertising or analytics trackers on pages or flows that handle PHI
- Access to submissions limited to named accounts with role-based permissions
- Privacy policy that reflects what you actually collect and how it is handled
Ongoing
- Review embedded tools whenever you add one, treat every new widget as a compliance decision
- Keep BAAs current as vendors change
- Re-check tracking after any marketing or site update
- Have a written breach-response and data-retention plan, and follow it
A Note From Experience
We are a design studio, not a law firm, and HIPAA compliance ultimately rests with your practice and your legal counsel. But the decisions that create or prevent most problems, where forms send data, which vendors handle it, what loads on a sensitive page, are made at the design and build stage. When we designed Manasara AI, a compliance-checking product for the building industry, the whole challenge was designing around a strict regulatory framework without making the product feel heavy or hostile. Healthcare sites need the same instinct: treat compliance as a design constraint from day one, not a checkbox at the end. It is how we approach website design for every client working in a regulated field.
Build it compliant the first time.
Tell us what your site needs to do, and we'll design the forms, flows, and privacy into it from the start.
