On December 1st, 2022, the HHS Office for Civil Rights issued a bulletin related to the use of online tracking technologies by HIPAA covered entities. This bulletin seemed to be intended to provide some clarity on the obligations of HIPAA covered entities (organizations) when using online tracking technologies on their websites and mobile apps. Though this guidance seems to cover all tracking technologies, they made sure to specifically mention Google Analytics (GA) and the Meta Pixel in their announcement.
In this post, we explore considerations for organizations who are running, or planned to run GA (specifically GA4) on their public facing website and/or app.
The subjects covered here ultimately come down to questions that should be answered by your legal counsel. We are not a law firm and this should not be used as legal advice. We strongly recommend seeking guidance from your legal counsel and all other relevant stakeholders such as privacy, analytics, marketing and others.
Additionally, this is a topic with many considerations and options, and the best path forward will be unique to each organization. Consider this post an educational resource and not a list of the paths that are best for your organization. If you have any questions about how we can help provide you with specific analytics guidance, reach out to email@example.com.
Though the bulletin was released almost a year ago, the subject is complicated and has taken quite some time for impacted organizations to work through many questions that arose such as:
At this point, most organizations have started to reach the latter questions, including the assessment of their options for moving forward.
While there are many critical legal, privacy, and other considerations, we specifically have been exploring the analytics considerations contained in the bulletin. I have spoken with many impacted organizations, and we have navigated through several of the options & next steps listed at the end of the document. This post relays some of my experiences from these discussions and engagements.
Specifically, there are 3 considerations to focus on from an analytics perspective for organizations that are running, or planned to run GA (specifically GA4) on their public facing website and/or app.
User-authenticated generally refers to pages that require a user login to access, such as a patient portal. GA should never have been employed behind user-authenticated web pages or app screens. This is because the GA terms of service state that you should not collect any personally identifiable information. Additionally, GA has never been considered HIPAA compliant and therefore shouldn’t be used on pages that are tied to a specific user. While you should validate if your implementation is in conflict with this, most organizations we’ve worked with haven’t faced this issue as they never placed tracking on user-authenticated webpages.
This section contains relatively “new” guidance and interpretations on what constitutes health information (HI), personally identifiable information (PII), and the combination resulting in personally identifiable health information (PHI).
Specifically, it states that (bold and underline styles added by me):
“The login page of a regulated entity’s patient portal (which may be the website’s homepage or a separate, dedicated login page), or a user registration webpage where an individual creates a login for the patient portal, generally are unauthenticated because the individual did not provide credentials to be able to navigate to those webpages. However, if the individual enters credential information on that login webpage or enters registration information (e.g., name, email address) on that registration page, such information is PHI.29 Therefore, if tracking technologies on a regulated entity’s patient portal login page or registration page collect an individual’s login information or registration information, that information is PHI and is protected by the HIPAA Rules.”
In the example above, though the tracking occurs on an unauthenticated web page, the tracking technology is capturing PHI. As stated in the last section, GA should never (even according to their own Terms of Service) be used to capture PII. So, this is not something that should be occurring or a strategy employed in your use of GA.
However, the next section is very insightful as it specifically mentions email address and IP address tied to an individual i.e. that this could be considered PII. This is important to those who focus on analytics since those are two data points (or “dimensions”) we want to be mindful of. Specifically, if GA is capturing values for either of those two dimensions, and if so, how they’re being captured, sent, and stored (bold and underline styles added by me):
“Tracking technologies on a regulated entity’s unauthenticated webpage that addresses specific symptoms or health conditions, such as pregnancy or miscarriage, or that permits individuals to search for doctors or schedule appointments without entering credentials may have access to PHI in certain circumstances. For example, tracking technologies could collect an individual’s email address and/or IP address when the individual visits a regulated entity’s webpage to search for available appointments with a health care provider. In this example, the regulated entity is disclosing PHI to the tracking technology vendor, and thus the HIPAA Rules apply.”
As previously stated, no organization should be capturing email addresses in GA since that is PII and against Googles Terms of Service. However, this section brings up an important question on IP addresses. While GA4 does not provide access to user IP addresses, there is some confusion around specifically how IP addresses are technically used by GA4 and whether or not that is in conflict with their obligations. While that decision is up to the organization, there are paths to eliminate this as a concern listed at the end of this post.
This section is far too long to summarize here, though I recommend reading it in full on the HHS website. However, from an analytics perspective, this section brings up a few questions to us, including:
Based on those questions, and your organization’s legal, privacy, and other stakeholders decisions, you may need to consider alternatives to the “standard” implementation of GA4. While there are several paths that can be taken, this graphic represents some of the status on decision making by many organizations I’ve spoken to:
The good news is that there are a myriad of options for you to consider. The bad news is that all of them come with trade-offs. As mentioned in the disclaimer the best path forward will be unique to each organization and may be listed below, or not in this list at all (as these are some of the more common approaches being taken).
As shown above, the three most common paths are to either:
This is the ultimate question and requires deep thought, conversation, and communication across stakeholders (legal, privacy, marketing, analytics, etc.) to reach a decision that is in the organization’s overall best interest. There is no “one size fits all solution” here.
That being said, I will leave you with a few additional considerations to keep in mind:
We have been helping many organizations work through the analytics side of this challenge. If you could use more support to reach the best decision for your organization, please reach out to firstname.lastname@example.org.