Most healthcare organizations think their HIPAA compliance stops at the EHR. The servers are locked down, the staff did their annual training, and the IT team runs penetration tests. Then someone in marketing drops a Meta Pixel on the appointment booking page and nobody thinks twice about it.
That is how Blue Shield of California ended up disclosing protected health information for 4.7 million members through Google Analytics. It is how Novant Health got hit with a $6.6 million class action over a Facebook tracking pixel running inside their patient portal. These were not sophisticated attacks. They were standard marketing tools doing exactly what they were designed to do, on pages where they should never have been.
The Office for Civil Rights has settled or imposed penalties in over 150 cases totaling more than $144 million since HIPAA enforcement began [1]. And in December 2022, OCR issued specific guidance on tracking technologies, making it clear that pixels, analytics, and session replay tools on patient-facing pages can create HIPAA violations even if no one intended to collect protected health information [2].
Here are 12 mistakes we see on healthcare websites all the time. Some carry six-figure penalties. Others are free to fix this afternoon.
1. Running Google Analytics on patient-facing pages
Google Analytics is not HIPAA-eligible. Google will not sign a Business Associate Agreement for standard GA4. That means any protected health information that flows through it, even unintentionally, is an impermissible disclosure to a non-covered vendor.
The problem is that GA4 collects more than most people realize. With Enhanced Measurement turned on (the default), it logs page URLs, form interactions, scroll depth, and outbound clicks. If your appointment booking URL contains a patient name or condition, or if someone navigates from a mental health page to a contact form, that context travels to Google [3].
Blue Shield of California discovered this the hard way when they found GA had been transmitting member health plan data to Google for nearly three years. The fix is straightforward: remove GA from any page where patients log in, submit forms, or view condition-specific content. If you need analytics on those pages, use a HIPAA-compliant alternative that will sign a BAA.
2. Meta Pixel on condition-specific pages
The Meta Pixel tracks every page view and sends it back to Facebook. When that pixel runs on your oncology page, your fertility clinic landing page, or your substance abuse treatment section, it is effectively telling Meta that a specific browser (often tied to a logged-in Facebook user) has a particular health condition. Meta will not sign a BAA [3].
Novant Health learned this when a class action lawsuit revealed their Meta Pixel was firing inside the patient portal, transmitting appointment types, provider names, and other details to Facebook. The settlement cost $6.6 million.
Remove the Meta Pixel from any page that implies a diagnosis, treatment, or health condition. If your marketing team needs conversion tracking for ad campaigns, use offline conversion imports or server-side events that strip all health context before anything reaches Meta.
3. Unencrypted contact forms collecting health information
A surprising number of healthcare websites still use basic contact forms that transmit data without encryption, or send form submissions via unencrypted email to staff inboxes. If a patient types their symptoms, medication list, or insurance information into a form that sends a plain-text email to your front desk, that is PHI in transit without the safeguards HIPAA requires.
The HIPAA Security Rule mandates encryption for electronic PHI both in transit and at rest. Your forms need TLS encryption at minimum, and the data should be stored in an encrypted database rather than sitting in someone’s email inbox. The form processor also needs to sign a BAA with your organization [4].
Related: HIPAA compliant website design for healthcare practices4. Session replay tools in patient portals
Session replay tools like Hotjar, FullStory, and LogRocket record everything a user does on your website: mouse movements, clicks, scrolling, and keystrokes. When a UX designer turns one of these on inside a patient portal to study navigation patterns, the tool records patients typing medical history, viewing lab results, and messaging their providers. Those recordings get stored on the vendor’s servers.
Most session replay vendors will not sign a BAA, and even the ones that offer HIPAA-compliant tiers require careful configuration to mask sensitive fields. The safest approach is to keep session replay out of authenticated areas entirely. If you need UX data from the portal, use aggregate analytics (funnel completion rates, page timing) rather than individual session recordings [3].
5. Missing Business Associate Agreements
Every vendor that touches PHI on your behalf needs a signed BAA. That includes your web hosting provider, your email service, your form processor, your CRM, your chat widget, and your analytics platform. If any of these vendors can access, store, or transmit PHI and you do not have a BAA in place, you are in violation of HIPAA regardless of whether a breach actually occurs [5].
This is one of the most common findings in OCR audits. Organizations often have BAAs with their EHR vendor and their cloud provider but forget about the dozen other tools running on their website. Make a list of every third-party service your website loads (check your tag manager), then verify which ones can access patient data and whether you have a current BAA on file.
6. PHI in URL parameters
Developers sometimes build appointment booking links or form redirects that include patient information in the URL. Something like /book?name=Jane+Doe&reason=cardiology or /confirm?patient_id=12345&dept=oncology. Those URLs get logged by web servers, captured by analytics tools, stored in browser history, and potentially cached by CDNs and proxies.
Even if your analytics platform is HIPAA-compliant, URL parameters are visible to every tool and service that processes web requests. The fix is to send sensitive data via POST requests (in the request body, not the URL) and to add server-side filters that strip any parameters that might contain PHI from your logs [3].
7. Live chat and AI chatbots without HIPAA safeguards
Chat widgets feel helpful and low-risk. A patient asks about office hours, someone on staff responds, no big deal. But the moment a patient describes symptoms, mentions a medication, or shares insurance details in a chat window, that conversation becomes PHI. And most chat vendors, including popular options like Intercom, Drift, and generic AI chatbot plugins, store those transcripts on their own servers without HIPAA protections.
If you offer live chat or an AI symptom checker on your website, the vendor needs to sign a BAA, the transcripts need to be encrypted, and your staff needs training on what information they can and cannot discuss through chat. Better yet, configure the chat to redirect health-related questions to a secure patient portal rather than handling them in an unprotected channel [3].
8. No SSL certificate or mixed content warnings
This should be a solved problem by now, but we still see healthcare websites with pages that load over HTTP instead of HTTPS, or that serve “mixed content” where the main page is encrypted but some images, scripts, or stylesheets load over an unencrypted connection. Both situations mean data in transit is not fully protected.
HIPAA requires encryption for ePHI in transit. If any page on your site where patients interact (forms, portals, booking) is not fully encrypted, that is a technical safeguard failure. Get an SSL certificate for your entire domain, force HTTPS redirects, and fix any mixed content warnings. Most hosting providers include SSL certificates at no extra cost [4].
9. No website privacy policy or an outdated one
HIPAA requires covered entities to provide a Notice of Privacy Practices, and your website privacy policy needs to accurately describe how you collect, use, and protect patient information online. A generic privacy policy template that mentions cookies but says nothing about health data collection, form submissions, or third-party tracking is not sufficient.
Your privacy policy should specifically address what health information your website collects, which third parties receive that data, how it is protected, and what rights patients have regarding their information. Review it at least annually and update it whenever you add new tools or change how you handle patient data [6].
Tip: Pull up your website privacy policy right now. Does it mention Google Analytics, Meta Pixel, or any other tracking tool by name? Does it explain what health information your forms collect? If the answer to either question is no, the policy needs updating.
10. Third-party fonts and scripts loading unchecked
Your website probably loads Google Fonts, Font Awesome icons, jQuery from a CDN, and half a dozen other external resources. Each one of those is a third-party connection that can potentially log visitor data, including IP addresses and page context. Google Fonts specifically was the subject of a German court ruling that found loading fonts from Google servers without consent violated GDPR because it transmitted visitor IP addresses to Google.
For healthcare websites, the concern is that any third-party script can change its behavior without your knowledge. A font provider could start collecting analytics data. A CDN could add tracking. Review every external resource your website loads, self-host fonts and scripts where possible, and use Content Security Policy headers to restrict what external domains your site can connect to [7].
11. No regular security risk assessment
The HIPAA Security Rule requires covered entities to conduct a thorough risk assessment of their information systems, and that includes your website. OCR has repeatedly stated that failure to perform a risk analysis is the single most common HIPAA violation they find during audits and investigations [5].
A website risk assessment should document every place PHI enters, moves through, or is stored on your site. It should identify which third-party tools have access to that data, whether BAAs are in place, and what technical safeguards protect the information. This is not a one-time exercise. The proposed 2025 HIPAA Security Rule updates would require compliance audits at least every 12 months [8].
12. Staff access to the website backend without training
The person updating your blog posts and the person managing patient forms might have the same WordPress admin access. If a staff member without HIPAA training can view form submissions, access patient data stored in a plugin, or install new tracking tools on the website, that is a workforce security gap.
Limit website backend access based on job function. Content editors do not need access to form submission data. Marketing staff should not be able to install tracking pixels without compliance review. Use role-based access controls in your CMS and include website-specific scenarios in your HIPAA training program [9].
When to bring in outside help
If you read through this list and found more than two or three items that apply to your website, you are not alone. Most healthcare organizations built their websites with marketing and patient experience in mind, not HIPAA compliance. The tracking tools, chat widgets, and analytics platforms that make websites useful are the same ones that create compliance risks.
A HIPAA-focused website audit from a healthcare web agency can identify every compliance gap in a few hours. The cost of that audit is a rounding error compared to the $141 to $2.13 million per violation category that OCR can impose, or the class action lawsuits that follow a tracking technology disclosure [10].
FAQ
Does HIPAA apply to my healthcare website?
Yes, if your website collects, transmits, or displays protected health information. That includes contact forms where patients describe symptoms, appointment booking systems, patient portals, and any page where a tracking tool can link a visitor to a health condition. The OCR tracking technology guidance issued in December 2022 made this explicit.
Is Google Analytics HIPAA-compliant?
No. Google will not sign a Business Associate Agreement for standard Google Analytics (GA4). Google Analytics 360 can be made HIPAA-eligible when used through Google Cloud Platform with a signed BAA, but the standard free version that most websites use is not compliant. If you run GA on pages where patients interact with health content, you have a compliance gap.
What is a Business Associate Agreement and do I need one?
A BAA is a contract between a covered entity (your healthcare organization) and any vendor that creates, receives, maintains, or transmits protected health information on your behalf. You need one with every third-party service that can access patient data through your website, including your hosting provider, form processor, email service, CRM, and any analytics or marketing tools that run on patient-facing pages.
How much can HIPAA fines cost for website violations?
HIPAA penalties range from $141 to $2,134,831 per violation category per year, depending on the level of negligence. Website violations can multiply fast because a single misconfigured tracking pixel can affect thousands of patients simultaneously. Beyond OCR fines, state attorneys general can bring additional penalties, and class action lawsuits like the Novant Health case can add millions more.
How often should I audit my healthcare website for HIPAA compliance?
At minimum, conduct a full website compliance audit annually. The proposed 2025 HIPAA Security Rule updates would formalize this as a requirement. You should also review compliance whenever you add a new tool or plugin to your website, change hosting providers, update your patient portal, or modify how forms collect and process data.
