A medical practice website needs HIPAA-compliant hosting only if protected health information passes through it. A brochure site with your services, hours and a map doesn't handle patient data, so choosing medical web hosting for it comes down to ordinary security and reliability. Once the site collects symptoms, insurance details or appointment requests, HIPAA applies to that data, and the simplest fix is usually to keep it off the website and use a patient portal or form vendor that signs a business associate agreement (BAA).
This is general information, not legal advice. Your compliance officer or a healthcare attorney should have the final say on your setup.
What counts as patient data on a website
Protected health information, or PHI, is health information that can be tied to a specific person and that a covered entity, or a vendor working for one, creates, receives, stores or sends. Most practices that bill insurance electronically are covered entities. On a website, PHI usually arrives through small things:
- A contact form message that says "I've had chest pain for two weeks, can someone see me this week?"
- An appointment request with a name, date of birth and reason for the visit.
- A new-patient form asking for an insurance member ID or a list of medications.
- A prescription refill request.
Even a name and phone number can count once they're attached to a request for care at your practice, and where that line falls for your forms is a question for your compliance person. A safe working assumption is that anything a patient can type into your site might be PHI.
Brochure sites versus sites that collect patient data
If your website only publishes information such as services, providers, locations and directions, your web host never handles PHI, so there's nothing for a BAA to cover. The site still needs to be secure. A hacked practice site can redirect visitors to scam pages or swap your patient portal link for a lookalike login page, and patients will hold the practice responsible.
Things change once the site collects patient details. Form entries get saved in the WordPress database, copied into every backup and emailed through a mail service. Federal guidance treats a company that stores PHI for you as a business associate, even if nobody there ever opens the data. That means a BAA with your host, your backup storage, your email provider and anyone else in the chain, each with the safeguards HIPAA expects. It can also bring your web designer into scope, if they have admin access to a database full of patient messages.
Keeping PHI off the marketing site
The split most practices settle on looks like this:
- The website carries information and a short general contact form: name, phone or email, and a brief message, with a line asking people not to include medical details.
- Anything clinical, such as booking, intake forms, refill requests and messages to a provider, goes to your EHR's patient portal or to a scheduling or form vendor that signs a BAA. The website links to it with clear buttons.
Linking out is the cleanest version. Embedding the vendor's own form can also work, as long as submissions go straight to the vendor's servers and never pass through WordPress. The setup that causes trouble is a WordPress form plugin collecting the same details the portal would, then emailing them to the front desk.
The split also makes the website easier to run: it can be updated freely, and your designer can work on it without signing anything.
What to check in contact forms and email notifications
Forms tend to pick up new fields over time, so check these once a year:
- Stored entries. Many form plugins save every submission in the database as well as emailing it. Check whether yours does, turn it off if you don't need it, and delete the old entries.
- The fields. Date of birth, insurance, symptoms and "reason for visit" belong in the portal, so remove them from any form on the marketing site.
- Notification emails. A notification that pastes the whole message into an email leaves copies on the mail servers it passes through and in every inbox it reaches. If a form must collect anything sensitive, the notification should only say that a new request arrived and where to view it.
- The inbox. Business email providers generally offer a BAA on some plans, but you have to sign it. It isn't automatic, and a front-desk address that forwards to someone's personal account undoes it.
- Autoreplies. An automatic reply that includes a copy of the message sends the patient's words back out by ordinary email.
- Spam filtering. Some anti-spam services send form contents to a third party for checking. Find out which one your form uses.
If appointment requests depend on email, check that it arrives at all, using the steps in why your forms stopped sending.
Analytics, ad pixels and chat widgets
Any script running on a page can see what happens there, including what visitors click and, depending on the tool, what they type.
- Analytics. A thank-you page whose URL includes a patient's name or condition sends that straight to your analytics account. Keep personal details out of URLs, and keep analytics off booking and intake pages.
- Ad pixels and session recordings. In late 2022, federal regulators warned healthcare providers about tracking technologies on their websites. A 2024 court decision struck down part of that guidance as it applied to public pages, but pages where patients log in, book or describe symptoms remain risky, and hospitals have been sued over pixels on those pages. The big free analytics and advertising tools generally don't sign BAAs.
- Chat widgets. Patients will type symptoms into a chat box whatever the label above it says. If the chat vendor won't sign a BAA, limit the widget to scheduling and general questions, say plainly not to share medical details, and find out what the vendor does with transcripts. The same goes for AI chatbots.
Medical web hosting options, from brochure sites to applications
If you're comparing health care hosting options, they fall into three groups.
- Information-only websites. Good managed hosting with SSL, a firewall, regular updates and off-site backups. No BAA is needed, because there's no PHI.
- A website plus a vendor portal. The same hosting for the website, with patient-facing tools run by a vendor under its own BAA with you. This is the setup we'd recommend to most practices.
- Custom medical applications that store PHI. Your own intake system, telehealth app or patient portal. These need infrastructure covered by a BAA (the large cloud providers offer them for specific services), encryption, access controls, audit logs and a documented risk analysis. That's a software project with compliance work attached.
There's no government certification for HIPAA compliance. When a host advertises itself as HIPAA compliant, the most that can mean is that it will sign a BAA and has the required safeguards in place. Compliance still depends on how your practice uses the service. If you go that route, ask what the BAA covers (backups, logs and email as well as the server), where backups are stored and what happens to your data when you leave.
How Hosterr handles practice websites
We're upfront about the limit: Hosterr doesn't claim HIPAA compliance and doesn't sign BAAs. For practices, we keep PHI off the sites we host, review every form and where its data goes, and document the security setup (SSL, the WAF, hardening and log retention) so you have something to hand an auditor. Anything that needs a BAA stays with a vendor who will sign one. There's more on our hosting for healthcare practices page.
Frequently asked questions
Do I need a BAA with my web host?
Only if the host creates, receives, stores or sends PHI on your behalf. If form submissions containing patient details sit in your WordPress database or its backups, you need either a BAA with the host or different forms.
Is a contact form on a doctor's website a HIPAA violation?
Not by itself. A form that asks for a name, contact details and a short general question, with a note asking people not to share medical information, is common on practice websites. Problems start when a form asks for symptoms, insurance or dates of birth, or when patients describe their condition in the message box and it's stored or emailed through services that haven't signed a BAA.
Can I use Google Analytics on a medical practice website?
On public pages about your services, many practices do, with care: no personal details in page addresses, no tracking of form fields, and nothing on login, booking or intake pages. Google doesn't offer a BAA for Google Analytics, so it shouldn't receive anything that could count as PHI. If you need analytics inside patient-facing flows, use a tool whose vendor will sign one.
