HIPAA Compliance for Healthcare Websites: Forms, Chat, and Patient Portals
A healthcare website is the one part of a covered entity that lives in public, on the patient’s side of the screen. Unlike an EHR sitting behind a login, a public site collects information from people before they are authenticated, and it runs third-party code — analytics, advertising pixels, live-chat widgets — inside the visitor’s browser. That combination is why websites have become one of the most scrutinized HIPAA exposures of the past two years.
When a website actually touches PHI
Not every healthcare website is regulated by HIPAA. A brochure site with no forms and no tracking collects nothing. The rules attach the moment the site gathers individually identifiable health information connected to your organization: an appointment-request form, a “describe your symptoms” contact box, a patient-portal login, a bill-pay page, or a live chat where visitors type health details. At that point the page, its hosting, and any vendor whose code processes that data are inside your compliance boundary.
Online tracking technologies: the biggest recent shift
The sharpest change has come from the HHS Office for Civil Rights (OCR), which warned that tracking technologies — Google Analytics, the Meta Pixel, advertising tags — can transmit protected health information to third parties without a Business Associate Agreement or patient authorization. An IP address paired with a visit to a page about a specific condition, or any identifier captured on an authenticated patient-portal page, can be PHI. Health systems have faced enforcement and litigation over exactly this. The practical rule: never place general-purpose analytics or ad pixels on authenticated portal pages, and configure any tracking on public pages so it cannot capture identifiers tied to a health interest.
Securing forms, chat, and portals
For the parts of the site that legitimately collect PHI, the safeguards are concrete. Serve every page over TLS/SSL so data is encrypted in transit. Route form submissions to an encrypted destination — not an unencrypted email inbox. Put a signed BAA in place with your web host, your form processor, and any live-chat or scheduling widget that can see what visitors type. Apply access controls so only authorized staff can read submissions, and log who views them. For patient portals, layer authentication, session timeouts, and audit logging on top — the same discipline that governs HIPAA compliance for patient portals.
It starts with a Security Risk Analysis
All of this should be driven by a Security Risk Analysis, the foundational requirement at 45 CFR § 164.308(a)(1)(ii)(A). The analysis is where you inventory every page, form, widget, and vendor that touches PHI, map where data flows to third parties, and document the safeguards you have chosen. A website that was never included in the organization’s risk analysis is one of the most common gaps OCR finds. Our HIPAA compliance checklist walks through where the website fits.
The proposed 2026 Security Rule update
Looking ahead, the proposed 2026 update to the HIPAA Security Rule would tighten these expectations. Published as a Notice of Proposed Rulemaking in December 2024, it is not final — it remains a proposal, and once a final rule is published organizations will have a 240-day compliance window. The NPRM signals stronger, more explicit requirements around encryption, asset inventories, and vendor verification, all of which map directly onto how a public website and its third-party code are governed.
How Medcurity helps
Medcurity gives healthcare organizations a guided Security Risk Analysis that captures website forms, portals, tracking technologies, and the vendors behind them in one place, so nothing on your public edge goes unassessed. Plans start at $499/year (about $42/month); larger or multi-site organizations can request a quote.
Frequently Asked Questions
Does a healthcare website need to be HIPAA compliant if it only has a contact form?
If that form collects health information connected to your organization — symptoms, a reason for visit, anything identifiable — then yes. The form, its hosting, and its processor fall under HIPAA, which means encryption in transit, a secure destination, and a BAA with the form vendor.
Can I use Google Analytics or the Meta Pixel on my medical practice website?
Not on authenticated patient-portal pages, and only with caution on public pages. OCR has warned these tools can transmit PHI to third parties without a BAA or authorization. Remove them from logged-in areas and configure public-page tracking so it cannot capture health-related identifiers.
Do I need a Business Associate Agreement with my web hosting company?
If your host stores or transmits PHI — form submissions, portal data, anything identifiable — then yes, a signed BAA is required before that data lives on their servers.
Is a live chat widget a HIPAA risk?
It can be. If visitors can type health details into the chat, the widget vendor is handling PHI and needs a BAA, plus encryption and access controls on the stored transcripts.