HIPAA compliant website: where patient data actually flows

Does a medical website need to be HIPAA compliant?

The parts that handle patient information do. HIPAA protects "protected health information" (PHI): individually identifiable health information held by a covered entity such as your practice (45 CFR 160.103 (opens in a new tab)). A page describing your Invisalign service contains no PHI. A form where a parent asks about Invisalign for their daughter, with both names and a phone number, does.

So the useful question is narrower: which features of your site collect, store or pass on information that identifies a patient and relates to their care? For the identifiers that count, see what counts as PHI.

Compliance is also shared. A vendor's safeguards don't replace your own risk analysis, policies and staff access rules. The Security Rule makes a risk analysis a required step for your practice (45 CFR 164.308(a)(1)(ii)(A) (opens in a new tab)), whoever hosts your site.

Two guides go deeper:

• HIPAA compliant website hosting: when you need it, what the host must sign, and what drives the price.
• HIPAA website checklist: every website item with the provision behind it and who owns it, practice or vendor.

Where patient information enters your website

The first five are expected and can be covered by BAAs. The sixth is the one practices miss, because the data leaves through a script nobody remembers installing.

Hosting, databases and backups: who stores PHI

If form submissions or chat transcripts are stored on your web server or in a database behind it, the company running that infrastructure maintains PHI for you. Storage alone is enough: the 2013 Omnibus Final Rule preamble says a data storage company "qualifies as a business associate, even if the entity does not view the information" (Federal Register (opens in a new tab)).

That chain usually has three layers. Your website platform, the cloud provider underneath it, and the backup service copying it. Each needs a BAA with the layer above. Backups matter as much as the live server: the Security Rule requires a data backup plan that can "create and maintain retrievable exact copies" of electronic PHI (45 CFR 164.308(a)(7) (opens in a new tab)).

A brochure site that stores nothing, with forms handled entirely by a separate covered tool, is a different case. The hosting guide linked above walks through both.

Forms and email notifications

Forms are where most practice websites first collect PHI. Three checks cover most of the risk:

1. The form tool signs a BAA for the plan you're on, and stores submissions encrypted. See HIPAA compliant forms.
2. The notification email doesn't carry the answers. Many form tools email each submission to the front desk. If the email contains the patient's details, your email provider now holds PHI too and needs a BAA. Microsoft, for example, makes its BAA available "by default" to covered-entity customers through its Data Protection Addendum, with Exchange Online in scope (Microsoft Learn (opens in a new tab)). Safer still: a notification that says "New request — log in to view."
3. Only the right people can open submissions. Shared logins defeat the audit trail.

If you built your site on a general-purpose platform, check whether its forms qualify; our HIPAA checks for website builders cover the common ones.

Tracking pixels, analytics and chat widgets

Tracking scripts are the quietest way patient information leaves a site. A pixel on a booking confirmation page can tell an ad platform that a specific browser just booked a specific service.

The legal picture shifted in 2024. HHS's Office for Civil Rights issued a bulletin on online tracking technologies in December 2022 and revised it on March 18, 2024. On June 20, 2024, in American Hospital Association v. Becerra (opens in a new tab), a federal court in Texas declared one part of that bulletin "UNLAWFUL" and vacated it. That part, which the court called the "Proscribed Combination," treated an IP address plus a visit to a public, unauthenticated page about specific health conditions or providers as protected information.

The ruling was narrow. Its footnote says the vacatur should not be read as "limiting the legal operability of other guidance" in the HHS document. The vacated piece concerned visits to public pages; trackers on patient portals, or scripts that capture what patients type into forms, raise different questions. Status as of October 2026: check HHS's bulletin page for its current notice before relying on any part of it. Our guide to tracking pixels and HIPAA covers the details.

Analytics vendors set their own limits. Google says it "does not offer Business Associate Agreements" for Google Analytics and that HIPAA-regulated customers "must refrain from exposing to Google" any data that may be PHI (Google Analytics Help (opens in a new tab)). Its guidance: no tags on authenticated pages, and none on unauthenticated pages tied to health care services.

Chat widgets are a different case. They're meant to collect patient messages, so treat them like a form: BAA, encrypted storage, access controls, and a clear answer about any AI model behind them.

Business associate agreements for website vendors

Every vendor that creates, receives, stores or transmits PHI through your site needs a BAA before patient data flows (45 CFR 164.502(e) (opens in a new tab)). For a typical practice site, that list is:

• the website platform or host, if it stores submissions;
• the form builder;
• the chat widget vendor;
• the booking tool;
• the email provider, if notifications carry patient details;
• any agency that manages the forms or inbox.

Vendors that never touch PHI, like a designer working on public pages, don't need one. The full vendor-by-vendor guide is at business associate agreements.

Security basics: encryption, access control and audit logs

The Security Rule's technical safeguards in 45 CFR 164.312 (opens in a new tab) translate directly to website features:

"Addressable" doesn't mean optional. Under 45 CFR 164.306(d) (opens in a new tab), you implement the safeguard if it's reasonable and appropriate, or document why not and use an equivalent. A January 2025 proposed rule (opens in a new tab) would make encryption expressly required, with limited exceptions; it was still a proposal when we checked in October 2026.

One website obligation isn't technical at all. If your practice has a website with information about its services, it must "prominently post its notice on the web site" (45 CFR 164.520(c)(3)(i) (opens in a new tab)). That's your notice of privacy practices.

How Medfy handles patient data on practice websites

Medfy rebuilds and hosts your practice website on your own domain, with HIPAA-compliant forms. Patient information from forms, chat and the CRM is stored in separate, encrypted HIPAA databases in the US or Canada, encrypted in transit and at rest. Medfy signs a BAA with your practice before any patient data flows. Staff access uses role-based permissions with an audit log of who saw what.

Marketing uses aggregate numbers only, and ad platforms never receive patient data. Medfy's website analytics are first-party, counting calls, forms, bookings and directions without sending patient details to an ad platform.

The website, hosting, forms and patient inbox are part of the $349/month base plan; the HIPAA AI chat widget is a $49/month add-on covered by the same BAA. See Medfy pricing and how Medfy protects patient data. Your own policies, risk analysis and staff training remain your practice's job.

Not sure what your current site sends where? Start with a free audit — then see a free preview of your rebuilt website. The free marketing audit flags privacy risks such as pixels on patient forms, using public information only.

This is general information, not legal advice. Confirm how it applies to your practice with a qualified advisor.

Frequently asked questions

Does my medical website need to be HIPAA compliant?

HIPAA applies to how your practice handles patient information, so the question is whether your site collects or exposes any. Public pages about services, hours and staff usually hold none. Forms, chat, booking, patient logins and tracking scripts on those features can. If your site touches patient information anywhere, the vendors involved need BAAs and the data needs safeguards. Confirm your setup with your compliance officer.

Is a contact form on a medical website covered by HIPAA?

Usually, yes. When a patient sends your practice their name and contact details along with a reason for the visit, that's individually identifiable health information held by a covered entity. The form tool, the server that stores submissions and any email service carrying them handle PHI and need BAAs. A form that only collects a newsletter address is different. Check edge cases with your compliance officer.

Do I need a BAA with my web hosting company?

You do if the host stores or processes patient information, such as form submissions, chat logs or booking data, even when it never looks at them. The 2013 Omnibus Rule says a company that stores PHI qualifies as a business associate even if it doesn't view it. A host serving only public pages, with submissions handled elsewhere under a BAA, may not. Confirm with your compliance officer.

Can I use Google Analytics on a medical practice website?

Only on pages that don't involve patient information. Google says it doesn't offer BAAs for Google Analytics and that HIPAA-regulated customers must not expose protected health information to it. Its guidance is to keep tags off pages behind a login and off pages tied to health care services. First-party analytics is the usual alternative. Confirm your configuration with your compliance officer.

Is SSL enough to make a website HIPAA compliant?

No. SSL, now called TLS, encrypts data while it travels between the browser and your server, which addresses one Security Rule safeguard, transmission security. It does nothing for where submissions are stored, who can read them, audit logs, third-party scripts, email notifications or BAAs with your vendors. You need all of those, plus your practice's own risk analysis. Confirm details with your compliance officer.