Blast Analytics and Marketing

Analytics Blog

Supporting Leaders to EVOLVE
image representing PHI and HIPPA
Category: User Privacy

Evaluating Healthcare Analytics Risks and Removing PHI for HIPAA Compliance

August 3, 2020

In my previous blog post on Navigating Healthcare Analytics Risks with HIPAA, I provided an overview of the constraints that healthcare organizations face when leveraging digital analytics platforms such as Adobe Analytics and Google Analytics 360. If you’re landing on this blog post, I encourage you to read my previous one first.

As a reminder, Protected Health Information (PHI) is not permitted to be stored in Adobe Analytics and Google Analytics 360. This doesn’t mean healthcare organizations can’t use these platforms, but it certainly means the implementation must be adjusted to remove PHI through the Safe Harbor de-identification process prior to the data being collected by the digital analytics platform.

Evaluate Your Organization’s Risk

Assessing compliance risk for your organization starts with an audit to understand what you’re doing today (assuming that you may be using Adobe Analytics or Google Analytics 360 already). This audit will need to assess and answer questions such as:

  • What data are you sending to the digital analytics platform?
  • What data is exposed in URLs and query string parameters?
  • How is data sent to the digital analytics platform?
  • Are any identifiers collected in the digital analytics platform (intentionally or not)?
  • Expanding beyond digital analytics, what other marketing tags and third-party tools are collecting data on the site?
  • What data is sent to the marketing tags, and how do they leverage the data collected?
  • How is the collected marketing data in a third-party used to target your users?

Once you’ve completed an audit, you’ll need to begin having conversations with your privacy and legal teams to discuss compliance. It’s not abnormal to have to educate these teams on what the digital analytics tool is doing (and what’s being collected). These conversations will lead to more questions and reviews of the chosen technologies. The privacy and legal teams will begin to assess risk. The level of risk may vary from organization to organization. For example, is this primarily a concern just for a patient portal or any other logged in state where it’s confirmed that the user is a patient? Or are there concerns with the entire website, knowing that your patients are browsing this website to find information related to their medical needs? These questions and more will help shape the approach to compliance.

Rather than completely removing digital analytics from the website altogether (easy to say, but there’s obviously massive impacts to the organization), you’ll want to be prepared with how to approach compliance. Often, compliance takes many steps, and it’s best to build a compliance roadmap that prioritizes the risks and helps enable a structured and methodical approach to reaching full compliance.

…compliance takes many steps, and it’s best to build a compliance roadmap that prioritizes the risks and helps enable a structured and methodical approach to reaching full compliance.

PHI Removal for Compliance

image representing healthcare analytics

Let’s review and discuss the list of primary PHI concerns that I shared in my previous blog post :

  • Geographic Data
  • Email addresses
  • Account numbers
  • Web URLs
  • Device identifiers and serial numbers
  • IP addresses

Below we’ll talk through some of the more challenging PHI data and our recommendations for compliance.

IP Adress

Internet Protocol (IP) Address

IP addresses are foundational to how the internet works. For example, when a client-side beacon is sent from your website to another endpoint, the IP address is always transmitted; you can’t get around this behavior on a client-side request. Both Adobe Analytics and Google Analytics allow you to turn on IP Anonymization, which removes the last octet of the IP address before the data is fully written to disk or used for geolocation (more on geolocation later). This is certainly an option to discuss with your privacy team, but there are still risks since you are technically still sending the user’s IP (which is PHI) to another provider of which you don’t have a Business Associate Agreement (BAA) relationship. You may need to investigate sending data server-to-server (server-side) to avoid this risk.

Geo Location

Geographic Data

Geolocation with specificity more granular than State is considered PHI. If you prevent full IP address transmission to satisfy the de-identification requirements, then you’ll need to visit geolocation lookup processes in your digital analytics tool. There are creative options here, such as performing geolocation in a compliant way (with a compliant provider), and then sending in just the State and Country values to your digital analytics tool.

Account Numbers

Account Numbers, Email Address, and Device Identifiers

These data types are simple to address: don’t perform any data collection against these to keep safe. Be on the lookout if your website appends these values to the URL via a querystring parameter or otherwise. It’s best to perform a privacy audit to understand these risks ahead of time.

Web URL

Web URLs

Web URLs are trickier to address. While you could make the blanket decision to simply not collect any Web URLs, this is somewhat foundational to how digital analytics tools generally work (behavioral pathing, landing page analysis, etc.). My recommendation is to assess whether a specific URL can be used to link a medical condition to an individual and, for those URLs, pass in a numeric page identifier instead of the full URL (don’t upload a lookup table in your digital analytics tool in this case, however).

Google Analytics 360 also automatically collects the Page Title, so you’ll have to address that issue as well.

Further, be cautious about querystring parameters, which often include search terms or other potential identifiers that should not be collected. Search terms are specifically hazardous due to the nature of a user searching for their medical condition or pasting in their account numbers, etc. Avoid the risk by just not collecting this data.

image representing protected health information

Take the Proactive Approach

In a digital analytics implementation, there are easier fields than others to solve for the PHI concerns. For example, you can adjust the behavior of how URLs are captured to prevent PHI data collection, but when it comes to IP addresses, this is where things get very tricky.

As mentioned earlier in this post, the internet works in a way where client-side requests must send the user’s IP address to the endpoint that’s collecting the data; you can’t get around how this works. Thus, as you approach compliance, you’ll need to investigate either a pure server-to-server implementation or a private cloud solution, such as Tealium Private Cloud, which can enable a hybrid deployment that still enables the benefits of a client-side deployment but the compliance of a server-side deployment (hybrid). Tealium’s solution has the useful advantage of providing a clear path towards a fully compliant Customer Data Platform (CDP), as well as a method to send data in a compliant server-to-server method for both digital analytics tools and supported marketing tags. As you look for a compliant technology stack that can accelerate your organization’s desire to improve the customer experience, definitely explore what Tealium offers.

Respecting the privacy of your customers and anonymous visitors to your websites and apps is paramount. By taking a proactive approach towards compliance, you’ll build trust and avoid the costly risks associated with non-compliance. Privacy and security are part of a successful data governance program. It’s extremely important to have a plan in place to continually audit your own compliance. Most often, we see a combination of automated and manual audits that are scheduled at a regular cadence.

Respecting the privacy of your customers and anonymous visitors to your websites and apps is paramount.

As you approach compliance in the healthcare industry with your digital analytics and marketing solutions, please reach out to us if you need advice, have questions, or want our assistance.

Disclaimer: I’m not a lawyer, and this blog post is based on my own research and interpretation of the Healthcare Insurance Portability and Accountability Act (HIPAA). You’re advised to seek legal counsel that specializes in HIPAA to ensure that your organization conforms to this law. If you have questions or suggested clarifications, please comment and provide sources, as appropriate.

Joe Christopher
About the Author

As Vice President of Analytics at Blast Analytics, Joe leads a team of talented analytics consultants responsible for helping clients understand and take action on their vast amounts of data, to continuously improve and EVOLVE their organizations. With over 20 years of experience in analytics and digital marketing, Joe offers a high-level of knowledge and guidance to clients across all industries. He is an expert in all major analytics platforms including Google Analytics and Adobe Analytics, as well as various tag management systems such as Tealium and Adobe Launch. He also consults on data visualization, data governance, and data quality strategies. Having extensive expertise in many areas, has enabled Joe to become a well known thought leader and speak at industry events such as Tealium’s Digital Velocity series. Joe remains on the pulse of various information technology, programming languages, tools and services, keeping Blast and its clients on the leading edge.

Connect with Joe on LinkedIn. Joe Christopher has written on the Blast Digital Customer Experience and Analytics Blog.