Analytics Blog
Navigating Healthcare Analytics Risks for HIPAA Compliance
Joe Christopher
Healthcare organizations in the United States are subjected to HIPAA (Health Insurance Portability and Accountability Act). While there are many aspects of HIPAA, let’s focus specifically on the potential impacts it has on healthcare analytics. Much like GDPR, CCPA, and other data privacy regulations, healthcare organizations must protect consumer health information under HIPAA.
There are significant risks to healthcare organizations that fail to comply with HIPAA. The result can be substantial fines, civil action lawsuits, and even criminal charges. Fines for non-compliance will be issued even if the violation was inadvertent or unintentional. Even more devastating than the fines, you’re eroding trust with your patients, which is difficult to recover once lost.
Even more devastating than the fines, you’re eroding trust with your patients, which is difficult to recover once lost. Click & Tweet!
As of today, using either Google Analytics 360 or Adobe Analytics “out of the box” doesn’t satisfy HIPAA requirements, unless you make radical adjustments in its implementation to avoid sending in Protected Health Information (PHI). The most radical adjustment is to move from sending data to the analytics platform from a client-side process to a server-side process. Google is very transparent with this by stating in its documentation that Google “makes no representations that Google Analytics satisfies HIPAA compliance requirements” and that “you may not use Google Analytics for any purpose or in any manner involving Protected Health Information.” Put simply, Google does NOT want healthcare organizations to send any data to it that could be considered PHI.
If you’re a healthcare organization, there are compliant ways to navigate and use these best-in-class digital analytics platforms that both respect the law and data privacy of your customers and provide for the necessary digital insights.
What Data is Considered Protected Health Information (PHI)?
The HIPAA Journal provides an easy-to-consume list of the 18 identifiers that make health information PHI. Of these, there are six key identifiers that often connect to the usage of digital analytics tools:
- Geographic data (specifically location data about the user that narrows at a more granular level than State)
- Email addresses
- Account numbers
- Web URLs (specifically those that contain information about a medical condition or other PHI data)
- Device identifiers and serial numbers
- Internet protocol addresses (IP addresses)
Why Can’t I Collect PHI in my Digital Analytics Tool?
If you’re already familiar with Google’s Terms of Service for Google Analytics and Google Analytics 360, you’re aware that no personally identifiable information (PII) can be sent to Google. This isn’t the case with Adobe Analytics, as you‘re able to send PII securely to the platform (though we recommend avoiding it in most cases).
PII isn’t the same as PHI. You can think of PHI as being even more strict than PII, but it‘s specifically in the context of health information. Data is only considered PHI in the context of health information and the relationship that a consumer has with a covered entity (health plans, health care providers, etc.) and business associates (contractors and agencies) working for the covered entity.
When it comes to PHI, there’s an additional level of seriousness and data protection obligations. For a third-party to store this information, there are architectural requirements regarding security and data separation. At least as of today, both Google and Adobe do NOT allow you to store PHI data in their platforms; neither are set up to handle the additional security requirements.
When it comes to PHI, there’s an additional level of seriousness and data protection obligations. Click & Tweet!
The third-party providers that do allow you to store this data go through extensive architectural and security requirements to build an environment that satisfies this type of data storage. These providers will enter what’s called a Business Associate Agreement (BAA) with the healthcare organization. The Business Associate has its own obligations around security and data usage that must be followed. Again, as of today, both Google and Adobe will not enter a BAA contract with a healthcare organization for their digital analytics platforms. As a result, if you wish to use their products, then you’ll have to proceed with a process of de-identification to completely remove PHI.
If you use a digital analytics tool that’s on-premise or one in which you own and provision the architecture, then, with the right security and architecture, you can store this PHI. Examples of digital analytics tools that support on-premise and HIPAA-compliant data hosting are both Snowplow Analytics and Piwik PRO. Both solutions provide methods for deploying the solution to your owned-infrastructure in cloud environments such as Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure.
De-Identification Process to Remove PHI
By removing and no longer sending PHI, you can work towards the compliant usage of your healthcare analytics tool. Through the process of de-identification, the identifiers can be removed from the data set to mitigate data privacy risks. Per the U.S. Department of Health & Human Services, the Privacy Rule provides two de-identification methods:
- Expert Determination method
- Safe Harbor method
Expert Determination Method
The first method, Expert Determination, has specific requirements that require documentation by a person with appropriate knowledge and experience with statistical and scientific principles to make the claim that the data cannot identify an individual, even when combined with other reasonably available information.
Safe Harbor Method
The second method, Safe Harbor, refers to the removal of this information from the data set, which is the method we’ll be recommending that allows for the usage of Adobe Analytics or Google Analytics 360. The approach may differ depending on the specific PHI. For example, for geographic identifiers, you can collect data down to the State level, but anything more granular isn’t permitted. While guidance isn’t directly given on IP address, it‘s generally acceptable to remove the last octet of the address to remove the specificity that can potentially tie the data to an individual. While both Adobe Analytics and Google Analytics provide for this “last octet” removal on their platforms, any client-side process of sending that data still transmits the entire IP address, which may be a concern that needs to be addressed. Other identifiers, such as email address, shouldn’t be collected.
To summarize, if you remove the PHI (Safe Harbor method), then this de-identification action ensures that the data set is no longer considered protected health information.
What about Marketing Tags, Optimization Platforms, and Customer Data Platforms (CDPs)?
As you start to look at all of the other third-party vendors that you’re not allowed to send PHI to, it can be overwhelming. Instead of solving for just your healthcare analytics tool, you also have to either use a similar approach for every vendor OR explore an easier way to manage this data flow HIPAA compliance.
For many platforms (but certainly not all), there are server-side deployment options that’ll allow you to control the flow of data in a compliant way. This is a lot of work to both manage and deploy, so this is where a tag management system (TMS) that supports server-side will be a lot of help. Google Tag Manager 360, Adobe Launch with Adobe Experience Platform, and Tealium iQ + EventStream all offer varying degrees of support for server-side deployments.
Just remember that with all of these TMS options, you’ll need to tightly control the data before it’s sent in to the server-side TMS by removing PHI. The exception to this is if you have a solution such as Tealium’s Private Cloud. Tealium’s Private Cloud is worthwhile to leverage if you’re in the healthcare industry, as it’ll greatly accelerate your control and HIPAA compliance. Tealium’s dedicated single-tenant environment enables a compliant method to both collect and store PHI. You’re also able to upload other PHI data to your Tealium Private Cloud and leverage it as a Customer Data Platform (CDP) that’ll help your organization powerfully activate on data in a compliant method that respects the law and the data privacy of your customers.
Reduce Risk and Protect Your Customer’s Health Data Privacy
Architecting a solution roadmap that’s compliant with HIPAA for your healthcare analytics and marketing platforms is a challenge that many healthcare organizations are facing. From the risks of sending IP addresses to preventing data collection of other protected data such as search queries, there are a lot of requirements to reduce risk and do the right thing by protecting your customer’s health data and relationship.
At Blast, we’ve supported healthcare organizations to architect solution roadmaps of what we’ve outlined in this blog post, as well as other innovative solutions to complex challenges related to HIPAA. I encourage you to reach out to our experienced team to get the guidance you need to successfully navigate HIPAA compliance.
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.
Related Insights
User Privacy
User Privacy
If you have questions or you’re ready to discuss how Blast can help you EVOLVE your organization, talk to an Analytics Consultant today.
Call 1 (888) 252-7866 or contact us below.
Check out our other articles on BlastX!