The practice website: five pages, no PHI in forms, no stray pixels

What does a compliant practice website need?

A compliant practice website needs five core pages — home, about/credentials, services, a contact or intake page that collects no protected health information, and a notice of privacy practices or privacy policy — built or hosted through a vendor willing to sign a business associate agreement if the site's forms or analytics could ever touch PHI. No web form on the site should ask what brings a visitor in today, request a diagnosis, or collect any clinical detail; name, contact information, and a general reason for reaching out is the practical ceiling for what an intake form should ask before the practice is on a secure, BAA-covered channel.

Third-party advertising and analytics pixels — the small tracking snippets from ad and analytics platforms embedded on most commercial websites — deserve a specific look before adding any of them, since a pixel that sends visitor behavior data to a platform with no BAA can turn an ordinary analytics setup into an unintended disclosure.

The five pages and what belongs on each

A home page introducing the practice and what it treats, an about page naming the clinician's credentials, a services page describing what's offered without promising specific outcomes, a contact page collecting only the minimum information needed to start a conversation, and a privacy or notice-of-privacy-practices page covering how patient information is handled — that's the practical floor sometimes called the five-page website, and additional pages (a blog, a resources page, the faq page answering questions patients most often ask before booking) are additions layered on top of that floor, not replacements for any of the five.

Keeping the contact page's form to name, phone or email, and a general reason for reaching out — never a symptom description, a diagnosis, or a specific clinical detail — is the single highest-leverage decision on the whole site, since it's the one form every visitor sees and the one most likely to accidentally collect something that shouldn't travel over an unsecured web form.

Why an intake form asking about symptoms is a problem

A contact form that asks a visitor to describe what's bringing them in, rather than simply requesting contact information, invites the visitor to type protected health information into a channel that usually isn't covered by a business associate agreement or built with PHI-grade security — the website host or form-builder plugin becomes a business associate the moment it's transmitting that content, whether or not anyone intended it that way 1Ref 1HHS Office for Civil Rights (2026).Business Associates.That a website host, form-builder, or analytics vendor transmitting content that could contain PHI on the practice's behalf is a business associate requiring a signed BAA.. The fix isn't a disclaimer at the bottom of the form; it's redesigning the form itself to never ask the clinical question in the first place.

A separate, properly secured patient portal or intake system — one covered by its own BAA — is the right channel for anything clinical, and the public website's job is routing a visitor there, not collecting that information directly. A contact page should also route anything urgent to the practice line rather than only a web form, since a form has no way to signal that a message needs an immediate response.

The tracking-pixel problem

Advertising and analytics pixels embedded on a practice website send data about what a visitor viewed and clicked back to the platform that built the pixel — and this is exactly what makes the tracking-pixel problem a website compliance issue rather than a forms-only concern. If a visitor is browsing a page describing a specific condition or reaching a scheduling form, the platform receiving that data is effectively learning something about a person's health interest.

That's a disclosure the practice's analytics vendor needs to be covered for under the same business-associate framework as any other vendor touching PHI 1Ref 1HHS Office for Civil Rights (2026).Business Associates.That a website host, form-builder, or analytics vendor transmitting content that could contain PHI on the practice's behalf is a business associate requiring a signed BAA.. Reviewing which third-party scripts are actually running on the site, rather than assuming a popular analytics or advertising platform is automatically fine because everyone else's website uses it too, is worth doing once at launch and again whenever the site is redesigned.

This is a different risk than the intake-form problem, because a visitor never types anything — the exposure comes from simply which pages they viewed, which is exactly why it's easy to add a tracking pixel without ever noticing it's a compliance question at all.

Testimonials, reviews, and using patient information for marketing

Using anything a current or former patient said — a testimonial, a case description, even an anonymized story — for marketing purposes generally requires the patient's authorization first, since HIPAA restricts using protected health information for marketing beyond a narrow set of exceptions, and a testimonial naming or describing a specific patient's treatment falls squarely inside that restriction rather than one of the exceptions 2Ref 2HHS Office for Civil Rights (2026).Marketing.That HIPAA requires patient authorization before using PHI for marketing beyond narrow exceptions, applying to testimonials naming or describing a patient's treatment.. A generic unprompted review a patient posts on a third-party review site is a different situation than the practice itself soliciting or publishing a testimonial describing someone's treatment, and the two shouldn't be treated the same way when deciding what's safe to feature on the site.

The safer default for a solo practice site is describing the clinician's approach and credentials rather than featuring specific patient outcomes at all, which sidesteps the authorization question entirely.

Accessibility isn't optional

Title III of the Americans with Disabilities Act applies to a private healthcare practice as a public accommodation, and that obligation extends to the practice's website, not just the physical office — screen-reader compatibility, sufficient color contrast, and keyboard navigability are the practical baseline a solo practice site should meet 3Ref 3U.S. Department of Justice (2026).The Americans with Disabilities Act.That Title III of the ADA applies to a private healthcare office as a public accommodation, extending to website accessibility.. Most modern website builders include accessibility-checking tools directly in their editor, so meeting this baseline is usually a setting to enable and a few images needing alt text, not a separate development project requiring specialized help.

An inaccessible website is also a straightforward source of legal exposure independent of anything else on this list, since ADA website-accessibility claims against small businesses, healthcare practices included, are a well-established category of litigation rather than a theoretical risk.

Choosing a host and getting the paperwork right

The website host or builder itself needs to be evaluated the same way any other vendor touching PHI would be — confirm a business associate agreement is available and signed before any form, chat widget, or analytics feature capable of touching PHI goes live, not after. ONC and OCR's free Security Risk Assessment tool is sized for exactly this kind of solo-practice review and is worth running through once the site's actual feature set is finalized 4Ref 4Office of the National Coordinator / ASTP (2026).Security Risk Assessment Tool.That ONC/OCR publish a free Security Risk Assessment tool sized for a small practice, usable to review a website's PHI-touching features once finalized., and the Security Rule's safeguards apply to whatever ePHI the site touches the same way they apply to the EHR or practice email, scaled to the practice's size rather than requiring enterprise infrastructure 5Ref 5HHS Office for Civil Rights (2026).Summary of the HIPAA Security Rule.That the Security Rule requires administrative, physical, and technical safeguards for ePHI scaled to practice size, applying to whatever ePHI a website touches..

None of this needs to happen before the site launches in a basic form — a five-page site with no clinical content in its forms and no PHI-touching integrations can go live quickly, with the BAA and accessibility review layered in before any feature that actually touches patient information gets switched on.