If you are a healthcare organization operating in the United States, you are likely aware of the significant increase in the focus on the privacy of health data over the past year. The shift started in December 2022 with a bulletin issued by the Office for Civil Rights (OCR) at the U.S. Department of Health and Human Services that highlights obligations of the Health Insurance Portability and Accountability Act of 1996 (HIPAA) that organizations must meet when leveraging online tracking technologies.
This bulletin and the associated rise in enforcement activities focused on tracking technologies have a significant impact on the compliance risk HIPAA-covered entities face when using third-party tracking platforms.
If you are a HIPAA-covered entity that conducts advertising and measures site engagement and conversions within an analytics platform, you might be wondering what impact this has on how you collect analytics data and want to understand how to navigate this regulated environment moving forward.
Some Key Definitions Regarding HIPAA
Before we dive into the details of your analytics platforms and considerations as they pertain to the use of tracking technology, it’s important to understand some of the key areas and terms surrounding HIPAA. We will touch on two key terms lightly here, but if you are not familiar I highly recommend you read this post on the InfoTrust blog as a prerequisite as it goes into the granular details.
- HIPAA applies to any organization that is a covered entity as defined in the law. Covered entities are generally classified as the following:
- health plans
- healthcare clearinghouses
- healthcare providers
- HIPAA applies to any organization that is a covered entity as defined in the law. Covered entities are generally classified as the following:
- Protected Health Information (PHI):
- PHI is information that is transmitted or maintained by a HIPAA-covered entity and relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual and either identifies the individual or there is a reasonable basis to believe the information can be used to identify the individual.
- Electronically Protected Health Information (ePHI): Essentially, this is PHI when found in an electronic form. This is PHI that is transmitted, maintained, or simply saved.
So what does this mean for us?
Put simply: if dealing with health data on a HIPAA-covered entity website, assume it is PHI unless there is explicit documentation available that it can not be used to identify an individual or if none of the listed data points are included in the dataset that can be associated with the health data in question.
Analytics Platforms: What You Should Know
If you are a HIPAA-covered entity, it’s important to note that Google and Adobe Analytics make no representation that they satisfy HIPAA requirements. In fact, Google recommends that entities using Google Analytics “must refrain from exposing to Google any data that may be considered Protected Health Information (PHI), even if not expressly described as PII in Google’s contracts and policies.”
PHI is only allowed to be collected as long as it is passed to a business associate. Unfortunately, that business associate must sign a Business Associate Agreement (BAA) with the covered entity, which is something that both Google Analytics and Abobe Analytics are unwilling to complete at the time of this article.
Next Steps for Analytics
Our first recommendation for any client in this space is to ensure their legal team is in the loop and aware of the above HIPAA rules vs. what marketing technology is in place. From there, it’s important to take an inventory of the data being collected by your analytics tool as well as how that data is being used across all areas of the site.
Some key considerations:
- What data configurations do I have in place and to what platforms is data being sent?
- If you are using Google Analytics (GA) or Adobe Analytics, do you have them integrated with other GA/Adobe platforms? For example, GA can be connected to products within the Google Marketing Platform such as Google Ads, BigQuery, Search Ads 360, etc. The same thing goes for Adobe.
- Am I bringing in any custom information that might be considered PHI?
- Where am I collecting this information? Many healthcare patients have patient portals behind logged-in pages, which are much more sensitive than other pages.
- How do I collect this information? Is your analytics tool hardcoded on the site or is it deployed via a tag management system such as Google Tag Manager? If you are using a third-party scheduling tool, what information are they collecting and do you have inventory of that data? (Consider our proprietary tool, Tag Inspector, which can scan your site quickly to determine what data is being sent from different platforms and how it’s sent.)
- Are you leveraging your analytics for any type of retargeting? If so, are you retargeting based on user information that may be sensitive?
- Are you collecting data on any form submissions on your website? Forms usually contain personal information and are deemed sensitive.
- App tracking: Usually all behind a login and contain PHI.
The above considerations need to be taken into account, and the removal of any data that could be considered PHI is crucial as part of risk mitigation due to the uptick in enforcement for HIPAA and tracking technologies.
For many organizations, there is still a need to collect and analyze more granular data as well as understand user interactions that occur on sensitive pages. There are platforms out there that were built based on satisfying HIPAA requirements in that they will sign a BAA and have mechanisms in place to prevent any violations as it pertains to HIPAA, but through working with clients, we have found this holds some challenges.
Here’s a short list of some of these challenges:
- The reporting is not granular enough to meet the KPIs of the business.
- The reporting model is different and not as flexible as that of Google Analytics and Adobe Analyics.
- There is often a lot of up-front technical debt to deploying a new tool to match business needs.
- Training and upskill teams to leverage new tools is not ideal.
- Historical reporting all in GA/Adobe.
- Integrations with other products of your current tool will no longer be possible to leverage.
- Many of our clients have spent years customizing the architecture of GA in a way that meets their unique business needs. They don’t want to have to start from square one due to the above legislation.
{{Insert}} Project PandA
When you think of a panda, you are likely thinking of the black-and-white bear that is native to eastern Asia and hangs out in trees most of the day. Given our love for pandas at InfoTrust, we decided to dedicate our solution to the above issues our clients are facing with this wonderful creature.
“PandA” in the context of how it relates to this post, stands for “Privacy and Analytics”—see what we did there? We needed to work with our clients to find a solution that would allow them to continue to leverage their existing analytics event architecture and be able to do so in a way that would reduce compliance risk.
The solution we found involves leveraging Server-Side Google Tag Manager (GTM) to be able to collect the data, identify sensitive data (PHI), remove it, and then stream only that which is appropriate to third-party platforms. Due to third-party cookie deprecation as well as the ability to block analytics via browser tools, a lot of our clients are moving to a first-party data architecture via server-side, which makes this solution aligned with priorities outside HIPAA.
The PandA solution gives us the ability to remove sensitive data (PHI) and enhance data based on business needs before sending it to another platform such as Google Analytics 4 (GA4) or Google BigQuery.
For platforms like GA4 that are not covered under a BAA, we only send macro-level (non-sensitive) data to reduce compliance risk while still powering GA4 analysis. For data that could be considered sensitive, if there is a business use case which requires the data, it can be sent to another platform, such as Google Cloud (BigQuery), which is a platform that is willing to sign a BAA. Doing so can reduce the risk of being in violation of HIPAA while also allowing the business to continue to use user data for business use cases.
PandA also includes an architecture within Google BigQuery that structures tables in a way that mimics the GA4 reporting model to ensure that data remains consistent even while being outside GA4. Finally, we have architected a data visualization component on top of that (Looker Studio, etc.) to allow us to have user-friendly reporting that is directly correlated to the KPIs of your business all in one place.
This solution allows for our clients to continue to leverage GA4 as needed in a compliant way, but also ensure that we are able to collect sensitive information in a compliant way that can be used for marketing analysis.
What’s Next?
Over the past year, there has been an industry-wide shift in the way that healthcare organizations have been collecting and leveraging data for marketing and analysis. If you are a healthcare organization, it’s important to understand how the ongoing protections for health data impact your business to ensure your marketing technology is working in a compliant way. There are solutions out there to make sure that your analytics and marketing tools remain in tact—it’s just a matter of understanding what works best for your business.
