Web Analytics and HIPAA: How to Protect Your Site — and Your Users — From HIPAA Violations

Websites are built, for the most part, for humans. They’re designed for human interaction, and created to help communicate to those humans. Yet, the humans who interact with our websites are largely anonymous — that is, unless we provide some kind of user tracking, such as cookies or tracking pixels.

While we depend on this user tracking to help us create more personalized experiences, both though actual personalization and through ongoing improvements based on user traffic, those humans — real humans, with real lives — also have a right to not be tracked. Over the past several years, governments have been working to help protect those rights — including recent changes to how HIPAA-regulated agencies can collect web data.

A policy update to protect against personal information leaks.

Recently, the U.S. Department of Health and Human Services issued a bulletin clarifying how HIPAA-regulated agencies are allowed to make use of user-tracking technologies across the web and apps. Based on the guidelines, many popular free-service analytics systems, like Google Analytics and Facebook tracking pixels, can’t be used without violating a patient’s rights under the Health Insurance Portability and Accountability Act (HIPAA).

The main issue in question — and the reason for the more stringent policy — is that free-service analytics systems subsidize their use by collecting a user’s information. That information is then used to help build a broader profile of their behavior across multiple sites — beyond yours! —with a goal of providing more targeted advertising services to that user.

(It goes beyond free-service analytics, too — even paid services may not provide service terms that meet HIPAA standards for anonymization, data retention, and storage security.)

This provides an obvious conflict of interest. HIPAA-regulated organizations have a mandate to protect private health information (PHI). Yet, running large-service analytics scripts or tracking pixels may leak this information.

For example, imagine a analytics script has been added in a way that it tracks every page — including on a page where patients log in to view health info. Having the user’s identity exposed on the same page as a tracking script creates obvious issues, since the script can read the information on the page and has a direct connection to the person that’s logged in.

Tracking scripts know who you are — beyond the original page.

What may be less obvious is that there’s a risk of exposure even if the user never logs in to your organization’s site. Large service providers, like Facebook and Google, probably already know who the user is based on their use of their own services, or their activity on other sites. 

Consider this example: 

• I go to my local hospital’s website and read a page on knee replacement.
• The hospital uses Google Analytics on their site, and logs this page view as part of analytics tracking.
• Because I’ve logged into Gmail, Google Analytics knows who I am, and now knows that I’ve read about this procedure on the hospital site.
• Google’s algorithms start suggesting knee replacement information on Youtube, and Google Adsense ads now start serving me ads for knee braces and mobility devices.
• Because this is now part of my Adsense profile, a vast number of companies can now be made aware of my potential health condition.

This same scenario is true of Meta/Facebook and their tracking scripts and ad system. In general, these companies provide their analytics service for free in order to get a broad picture of user intent to help them better build customer profiles. Their privacy policies do not differentiate when it comes to health information.

Protecting your site — and users.

Obviously you’d still like to know what’s happening on your site. There are a number of ways to mitigate this issue: 

• The simplest approach may be to remove tracking scripts from key pages with potential transfer of personal information. Remove tracking scripts from any authenticated user page, login page, or any page addressing a specific symptom or condition — including any page that allows users to schedule visits or enter personal info.
• Consider what key information you’re receiving from analytics packages, and whether there might be a different way to get that information.
• Purchase and install an analytics package that you can host and run yourself that doesn’t allow the analytics data to leave your network. Or, work with a tracking provider that’s willing to sign a Business Associate Agreement (BAA).

Fully automated and free services can be both a blessing and a Trojan horse. While marketers have a sense of “set it and forget it” comfort with broad information-gathering analytics tools like Google Analytics, they also open up a lot of risk.

The good thing is that making the adjustment to HIPAA compliance is a positive step toward a better web. It’s a great opportunity to think about what information you really want to collect, and ensure specific measures in place for those key indicators.

While it’s easy to want to collect everything, good optimization programs have always been focused on setting key goals, understanding how to measure for them, and then incrementally and experimentally optimizing for those results. If you need to get your analytics into HIPAA compliance, take a minute and step back to think about your goals in measuring in the first place. You can take a simple compliance job and use it as a way to bootstrap your optimization process.