Does Your Medical Practice Website Need to Be HIPAA Compliant?

Home  ›  Blog

Author

Sara MacQueen

Date

July 20, 2026

Share

Does Your Medical Practice Website Need to Be HIPAA Compliant?

If you manage a medical practice and you've searched for whether your website needs to be HIPAA compliant, you've probably found a pile of alarming checklists:


  • Encrypted hosting
  • Compliant forms
  • Business associate agreements with your web platform
  • Six-figure fines if you get it wrong


Look closely at who published those articles. Most of them are companies selling compliance products.


Here's the answer they won't lead with:


There is no official certification for a "HIPAA compliant" website.


The U.S. Department of Health and Human Services (HHS) doesn't certify websites or software. HIPAA regulates healthcare organizations and how they handle patient information, not the software itself.


Once you understand that distinction, protecting your practice becomes much simpler than many checklists suggest.


A quick note before we dig in: this article is general information, not legal advice. For questions about your specific situation, talk to a healthcare attorney or compliance professional.


The short answer


HIPAA applies to covered entities (healthcare providers, health plans, and clearinghouses) and to the business associates that handle patient data on their behalf.


It governs how those organizations create, receive, store, and transmit protected health information, or PHI.


Notice what's missing from the list of what HIPAA applies to: websites.


Software can support compliance with features like encryption, access controls, and audit logs. But compliance itself lives in your organization's policies, procedures, and training.


While a vendor can sell you a compliant component. No vendor can sell you compliance.


So set aside
"is my website HIPAA compliant?" and ask the question that actually matters:


Does my website ever create, receive, store, or transmit PHI?


For a well-designed practice website, the answer should be no. And when the answer is no, most of what those scary checklists demand simply doesn't apply to you.


I explain all of this below, let's dive in.


What HIPAA actually requires, in plain English


Does HIPAA require a Business Associate Agreement?


PHI is individually identifiable health information: anything that connects a specific person to their health status, care, or payment for care.


A name alone isn't PHI. A name attached to an appointment request for a specific condition is.


When a vendor creates, receives, maintains, or transmits PHI on your behalf, that vendor becomes a business associate, and HIPAA requires a signed
business associate agreement (BAA) spelling out how they'll protect the data.


Your EHR vendor signs one. Your billing service signs one. Your website platform only needs one if PHI flows through your website.


That's the crux of it. If your website never touches PHI, your website platform is not your business associate, and no BAA is needed.


Does HIPAA require a privacy policy?


There is one genuine HIPAA requirement that applies to nearly every practice website: if you maintain a website describing your services, you
must prominently post your Notice of Privacy Practices on it.


That's a real rule, it's easy to satisfy, and it has nothing to do with compliant hosting or encrypted forms.


The architecture that keeps your website out of HIPAA's scope


The cleanest way to handle HIPAA on your website is to design the website so that patient information never touches it. In practice, that means giving each system one job.


1. Your EHR and patient portal handle everything involving health information

Appointment scheduling, new patient intake, health questionnaires, prescription refill requests, messages about care.


Your EHR vendor should already have a signed BAA with your practice. Their systems are built for PHI, with the encryption, access controls, and audit logging HIPAA's Security Rule expects.


When a patient clicks "Book an Appointment" on your website, that button should take them into the patient portal.


2. Your website handles marketing and education

It tells your story, explains your services, showcases your providers, publishes helpful content, and makes it easy for people to contact you.


None of that requires collecting a single piece of health information.


This split puts patient data in the system designed to protect it and keeps your public-facing site free of compliance overhead.


It also answers the question of whether your website platform vendor needs to sign a BAA. Most website platforms don't sign BAAs; and that's fine when your website is designed so it isn't intended to collect or handle PHI in the first place.


"But what about our contact form?"


A general contact form that collects a name, email address, phone number, and a message is not collecting PHI by design.


Anyone might be filling it out: a job applicant, a pharmaceutical rep, a journalist.


Nothing about the form asks for health information, and name and contact details on their own don't constitute PHI.


The risk comes from what you ask and what patients volunteer. Handle both deliberately:


1. Don't ask for health information


Your contact form shouldn't request a date of birth, a "reason for visit," symptoms, insurance details, or anything else that invites health information into a system that isn't built for it.


Keep the fields to name, contact information, and a message.


2. Include a note


Add a short note near the form.
Something like: "Please don't include medical or health information in this form. For appointment requests and medical questions, use our patient portal or call our office."


This steers patients to the right channel and shows you've taken reasonable steps to prevent PHI from arriving here.


For your specific situation, run the note you plan to use by your compliance officer.


3. Train staff on a procedure and document it


Have a procedure for when PHI arrives anyway.


Some patients will type health details into a message box even when you ask them not to. By itself, that doesn't automatically mean your practice has violated HIPAA. What matters is what your staff does next.


Here is a simple procedure as an example, but please create yours with your compliance officer:


  1. Move the relevant information into your EHR
  2. Delete the submission from your website's form dashboard
  3. Delete the notification email (and delete it from your Trash folder)
  4. Never reply with health details over regular email


Document your procedure in the employee manual and train your front desk on it. HIPAA expects reasonable safeguards, and having a documented procedure is an important part of that.


What if we use a "HIPAA compliant" form?


Here's the part the checklist articles skip: a paid "HIPAA compliant" form doesn't remove any of the above obligations.


If your staff copies a secure form's contents into a regular email thread, the chain is broken regardless of what the form vendor promised.


The procedure protects you. The product, at best, assists.


When you actually do need HIPAA-eligible tools


To be fair to the other side of this argument, there are cases where a website feature does handle PHI, and then the rules change:


  • Telehealth visits conducted through your website


  • Online intake or screening forms that ask health questions before a patient is in your EHR


  • Live chat where staff discuss symptoms, conditions, or care


If you truly need one of these on your website itself, then yes, you need a vendor that will sign a BAA and offers appropriate infrastructure for that specific feature.


That's a legitimate use case for HIPAA-focused form and chat products.


Before you buy one, though, ask a simpler question:
does our EHR already offer this feature?


Most modern EHRs include portal-based scheduling, digital intake, secure messaging, and increasingly telehealth.


Routing those workflows through the portal is usually better for patients (one login, one record) and better for you (one vendor, one BAA, no duplicate data to reconcile).


About those tracking pixels


If you researched this topic between 2022 and 2024, you probably encountered warnings that running Google Analytics, cookies, or a Meta pixel on a medical website violated HIPAA.


That guidance came from a bulletin issued by the HHS Office for Civil Rights, and it caused real panic across healthcare marketing.


The legal landscape has since changed.


In June 2024, a federal court vacated the bulletin's position on public-facing web pages, ruling that HHS had exceeded its authority by treating a visitor's IP address combined with a visit to a public health-related page as protected information.


HHS initially appealed, then withdrew the appeal in August 2024, leaving the ruling in place.


The practical takeaway: while this ruling doesn't prevent someone from filing a lawsuit, it should make them significantly less attractive to plaintiffs.


Caution still applies behind logins. Tracking technologies have no place on authenticated portal pages or anywhere a user's identity connects to their care.


And state privacy laws are their own topic, with several states regulating consumer health data independently of HIPAA.


Be aware that many articles ranking for this topic, including some from major platforms, still cite the vacated guidance as if it were current. Check the date on anything you read, including this article.


What to ask your website developer


If you're evaluating a website developer for your healthcare practice, a few questions will tell you quickly whether they understand any of this:


1. Where does appointment booking happen?

The right answer routes patients into your EHR or portal, not into a basic website contact form, or appointment booking plugin.


2. What does the contact form collect?

The right answer is contact information and a message, with a note steering health questions elsewhere, and nothing that solicits health details.


3. What happens when a patient submits health information anyway?

The right answer is a documented handling procedure, not a blank stare.


4. Do we need a BAA with the website platform?

If your website isn't handling PHI, the answer is usually no. A vendor who insists you need compliant hosting for a purely marketing website is selling you something.


A healthcare website done well gives patients a clear path to care, gives your practice a professional presence, and makes your compliance officer's job a whole lot easier.


That outcome comes from smart architecture and sound procedures. No product can give you 100% HIPAA compliance, and once you know that, you can stop being scared of your own website.


Bonfire Studio designs and builds
websites for healthcare organizations, with the architecture questions above baked in from the start. Start the conversation today if you'd like to discuss a new website for your organization or medical practice.


Sara - Founder at Bonfire Studio

About the Author: Sara MacQueen

Sara MacQueen is the founder of Bonfire Studio, a boutique web design studio that builds custom websites for established businesses in complex and regulated industries. With over 20 years of experience spanning design, marketing, and software development, she brings an unusually broad foundation to the work.

Duda vs WordPress comparison graphic for complex business websites, with laptop logos on blue background
By Sara MacQueen July 8, 2026
Is Duda a good platform for complex websites? Here's an honest comparison of WordPress vs Duda to help you choose the right platform for your large or complex business.
How to Optimize Service Pages for Google AI Overviews
By Sara MacQueen July 1, 2026
Here's how to format your service pages so they actually get cited in Google's AI overviews and other AI-generated answers.
AEO for Duda Websites: How to Get Cited in AI Search Results
By Sara MacQueen June 30, 2026
A practical guide to AEO for Duda websites: how to get your site cited, and recommended by AI search tools like ChatGPT, Perplexity, and Google's AI overviews.