On this page
Short answer: A practice website is a HIPAA concern wherever it collects or exposes patient health information: forms, booking, chat, portals and tracking technologies such as ad pixels. Make it HIPAA-ready by listing every third-party tool on the site, removing trackers from pages that reveal health information, using BAA-covered vendors for forms and booking, securing hosting, and publishing an accurate privacy notice.
Why websites became a HIPAA risk
For years, practices treated their website as marketing, separate from patient data. Then two things changed. Websites started doing real work, such as booking appointments, collecting intake forms and connecting to patient portals. And marketing tools, especially advertising pixels, began sending detailed visitor data to third parties by default.
In guidance first issued in 2022 and updated in 2024, the HHS Office for Civil Rights explained that tracking technologies on a regulated entity's website or app can disclose protected health information to tracking vendors, and that HIPAA rules apply when they do (HHS OCR). Parts of that guidance about unauthenticated pages were later limited by a federal court decision, so get advice on the current scope, but the core lesson stands: know exactly what your site sends, and to whom.
This checklist is general information, not legal advice. Work with your privacy officer or attorney on your specific situation.
The checklist
1. Inventory every tool on your site
- List every third-party script, pixel, tag, embed and plugin: analytics, ad pixels, chat, booking widgets, video, maps, fonts, heatmaps and A/B testing tools.
- For each, note what data it collects, which pages it runs on and where the data goes.
- Check your tag manager too; tags are often added and forgotten.
- Remove anything nobody can explain or no longer uses.
2. Keep trackers away from health information
- Do not run advertising pixels (such as Meta or other ad platforms) on appointment request pages, patient portal pages, symptom checkers, condition pages linked to booking, or anywhere a visitor enters health information.
- Review analytics settings: limit data collection, avoid capturing form field contents and URL parameters that could contain health information.
- If a tracking vendor will receive protected health information, a BAA and a permitted purpose are required; if the vendor won't sign one, don't send it the data.
- Prefer privacy-respecting, first-party analytics for patient-facing pages.
3. Handle forms safely
- Split general contact forms from patient intake. A general form should say clearly: do not include health information.
- Intake, appointment and medical record request forms should use a vendor that signs a BAA and encrypts data in transit and at rest.
- Never deliver form submissions containing health information to a regular email inbox in plain text.
- Collect only the fields you actually need.
- Add spam protection that doesn't send form contents to unvetted third parties.
4. Booking, chat and portals
- Confirm that your online booking tool, chat widget and patient portal vendors sign BAAs if they handle patient information.
- Link to the portal rather than embedding third-party trackers around it.
- Make sure chat scripts tell visitors not to share health details unless the chat is part of a BAA-covered system.
5. Business Associate Agreements
- Keep a list of every vendor that creates, receives, maintains or transmits patient information for your website, including your web developer or agency if they can access that data.
- Have a signed BAA with each one (HHS on business associate contracts).
- Remember that a vendor's marketing claim of being "HIPAA compliant" is not a BAA.
6. Hosting and security
- Serve the entire site over HTTPS with a valid certificate.
- Keep the CMS, plugins and server software updated, and remove unused plugins.
- Use strong, unique passwords and multi-factor authentication for every admin account.
- Limit admin access to the people who need it, with named accounts.
- Keep regular backups and know how to restore them.
- If the site stores patient information, apply HIPAA Security Rule safeguards to the hosting environment and have a BAA with the host (HHS Security Rule).
7. Privacy notices and consent
- Post your Notice of Privacy Practices and link it in the footer.
- Publish a website privacy policy that accurately describes cookies, analytics and third-party tools.
- Make sure the policy matches reality; an inaccurate privacy policy is a risk on its own.
- Be aware that some health apps and non-HIPAA entities fall under the FTC's Health Breach Notification Rule, and that state privacy laws may add requirements.
8. Reviews and testimonials
- Never confirm in a public review response that someone is a patient or discuss their care; HHS has taken enforcement action over review responses.
- Use testimonials or patient photos only with valid written authorization.
9. Accessibility
- Build and test to WCAG 2.2 AA: keyboard navigation, color contrast, alt text, form labels, captions.
- Note that HHS's Section 1557 rule expects many recipients of federal financial assistance to meet WCAG 2.1 AA for web content and mobile apps, on timelines based on organization size (Federal Register).
10. Review on a schedule
- Re-run the tool inventory at least twice a year and after every redesign, new plugin or new marketing campaign.
- Assign one person to approve any new script before it goes on the site.
Quick reference: what goes where
| Page type | Ad pixels | Privacy-respecting analytics | Forms with health info |
|---|---|---|---|
| Home, about, general service pages | Use with caution; review the HHS guidance and get advice | Yes | No |
| Condition or treatment pages that lead to booking | Avoid | Yes, configured carefully | No |
| Appointment request and booking | No | Limited, no form contents | Only through a BAA-covered vendor |
| Patient portal and login pages | No | No third-party trackers | Portal vendor under BAA |
| Contact form (general) | No | Yes | No; warn visitors not to include health info |
How we build practice websites
Every medical website we build starts with this checklist: no ad pixels where health information could be exposed, BAA-covered tools for patient forms, accessible design and documented hosting security. Read more about our approach on our HIPAA page.
General information, not legal advice. HHS guidance and court decisions in this area continue to change; confirm the current position with your privacy counsel.
Sources
- HHS OCR, Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates hhs.gov
- HHS, Business associate contracts hhs.gov
- HHS, Summary of the HIPAA Security Rule hhs.gov
- FTC, Health Breach Notification Rule ftc.gov
- HHS, Section 1557 final rule (Federal Register, May 6, 2024) federalregister.gov
- W3C, Web Content Accessibility Guidelines 2.2 w3.org
- HHS OCR, HIPAA enforcement hhs.gov
Last reviewed October 1, 2026. Figures are published industry data, not ClaimCoders results.
General information for practice administrators, not legal, coding or financial advice. Payer rules change; check the current source and your advisors before acting.