HIPAA Compliance for Healthcare Websites: What Actually Triggers Requirements

What makes a website subject to HIPAA

The question is not whether the website belongs to a healthcare organization. The question is whether the website handles protected health information.

A static practice website — hours, location, provider bios, service descriptions — does not handle PHI. Visiting a page about back pain treatment is not PHI. The website has not collected anything linked to an individual’s identity.

The trigger is when the site collects, processes, or transmits information that combines a personal identifier with health-related context. Appointment request forms that ask for the patient’s name and reason for the visit create PHI at submission. Contact forms asking “What brings you in?” create PHI. Patient portals where individuals log in to view their records are handling PHI by design. Online symptom checkers that store results with user email addresses produce PHI.

The covered entity is the healthcare organization operating the site. Their obligation to protect PHI extends to the digital infrastructure their patients interact with, including their public website.

The tracking pixel problem

In December 2022, OCR issued a bulletin on tracking technologies that changed how healthcare websites have to think about analytics. The core finding: standard tracking scripts — Meta Pixel, Google Analytics, Google Ads conversion tracking, TikTok Pixel — can capture PHI and transmit it to third-party servers without a BAA.

How? These scripts capture URL paths, query parameters, form field values, and IP addresses. On a healthcare website, a URL path like /services/depression-treatment/contact combined with an IP address is PHI under HIPAA’s definition. A form submission where the user enters their name and describes their symptoms is PHI. When a standard analytics pixel fires during that form submission and captures the data, it transmits PHI to Meta, Google, or TikTok — none of whom provide BAAs for standard analytics products.

Multiple class action lawsuits followed the 2022 OCR bulletin, targeting large health systems and hospital networks that had standard analytics on patient-facing pages. The settlements and legal costs were substantial. This is not a theoretical compliance edge case.

The practical consequence: remove standard analytics pixels from any healthcare website that has patient-facing forms or condition-specific content. This includes the entire domain if you cannot isolate which pages users will navigate from. “We didn’t know the pixel was capturing form data” has not been an effective defense in OCR enforcement or class action litigation.

Forms and patient-facing features

Appointment request forms are the most common compliance gap on practice websites. Most were built by web agencies that used whatever form plugin was cheapest. Those forms often transmit to email inboxes (not a HIPAA-compliant backend), use form services without BAAs (Gravity Forms, WPForms, Typeform free tier), and fire analytics pixels on form submission confirmation pages.

A HIPAA-compliant appointment form requires a form service provider that (1) offers a signed BAA and (2) stores submissions in a HIPAA-compliant environment. Jotform Health offers this at $39/month. Google Workspace forms work if your organization has a signed Workspace BAA and you disable all analytics on the page. Standard WuFoo, Typeform (below Enterprise), and SurveyMonkey free plans do not offer BAAs and cannot be used for patient intake.

Patient portals carry the most significant PHI exposure of any website feature. If you are using a portal built into your practice management system, that system’s vendor should provide a BAA covering the portal. If you built a custom portal or bolted on a third-party authentication system, audit the BAA chain for every component that touches patient records.

HIPAA-compliant analytics alternatives

Replacing Google Analytics on healthcare websites is practical. Several analytics platforms offer HIPAA BAAs, including:

Plausible Analytics — privacy-focused, no personal data collection, no BAA needed because no PHI is collected. Good for aggregate traffic data on pages that don’t handle PHI.

Simple Analytics — similar approach, no cookies, no personal identifiers.

Google Analytics 4 via Business Associate Agreement — Google does not offer a BAA for GA4. This path is closed regardless of configuration settings.

Server-side analytics — logging page views at the server layer with IP addresses stripped or hashed, without any client-side script. Requires engineering time to implement but keeps no third-party scripts on your domain.

The simplest approach for most practices: use a privacy-first analytics tool on your public website and accept that you have less granular conversion data. The alternative is legal exposure that costs more than the analytics insight is worth.

What practices must do now

If your practice website has any patient-facing forms, contact forms that ask health-related questions, or scheduling features, three things should happen before anything else.

Audit your current tracking scripts. Check every page that has a form submission against the list of scripts firing on that page. Tools like browser developer tools, Tag Assistant, or a tag auditing service can show you what’s running. Remove any script that doesn’t have a BAA.

Inventory your form services. For every form on the site, identify the service handling submissions and check whether that vendor has signed a BAA with your practice. If no BAA exists, the form is non-compliant and should be taken down or replaced.

Review your hosting and storage. If form submissions or patient contact data route to a shared email inbox, that inbox must be part of a HIPAA-compliant email environment (Google Workspace with BAA, Microsoft 365 with BAA, or similar). Personal Gmail, standard Outlook accounts, and shared hosting inboxes are not sufficient.

How PHIGuard fits

Website compliance is upstream from what PHIGuard handles. PHIGuard is not a form builder or an analytics platform. Where PHIGuard fits is the internal layer: once a patient submits an appointment request or contact form, the follow-up coordination inside your clinic involves task assignments, staff communication, and administrative workflows that are also PHI-sensitive.

Coordinating follow-ups in standard Slack channels or Asana boards where staff mention patient names and reason-for-visit creates the same BAA gap that non-compliant form tools create. PHIGuard covers that internal coordination layer with a signed BAA included at the $20/month Practice plan.

Think of it as two distinct compliance layers: the patient-facing website (use HIPAA-compliant form tools, remove standard analytics) and the internal clinic workflow (use tools with BAAs for staff coordination). Both need attention.