How to Make Google Analytics HIPAA Compliant

In this article, you will learn the steps required to ensure Google Analytics 4 complies with the HIPAA rules by de-identifying the data before it gets stored on Google's servers.

There are certain steps we must take to ensure the use of Google Analytics complies with the HIPAA rules. Google Analytics doesn't sign Business Associate Agreements (BAA) with covered entities, which is a requirement under HIPAA when the business associate transfers, stores, or has access to PHI. This means that in order to be compliant, we must ensure that Google's servers do not collect and store identifiers.

Since we can not sign a BAA, by implementing the 10 steps outlined in this article, we can ensure the use of Google Analytics complies with the HIPAA rules.

In this article, I will walk you through the 10 required steps to prevent Personally Identifiable Information from being collected and stored in Google Analytics, even when using Google Tag Manager.

If you're not using Google Tag Manager, the easiest way to redact data is from within Google Analytics 4. Let's start with GA4 without (S)GTM first..

Log into your Google Analytics account and navigate to your Admin section as shown in the screenshot below.

After Step 1, navigate to your Data collection, as shown in Step 2 in the screenshot above.

Now that you're in the Data collection settings, ensure all boxes are unchecked. They are unchecked by default, but they may have been turned on previously by other team members or an agency. These settings allow Google to collect "Signals," primarily based on unique identifiers such as GEO location and other device identifiers.

Google Signals leverages third-party cookies to link user data collected from websites with the user's login information on Google services. As a reporting identity, it enhances cross-browser and cross-device reporting, but of course, this is not compliant with the HIPAA rules, and there are state privacy laws where this could be an issue if misconfigured.

Next, navigate to the Data retention settings on your left, as shown in the screenshot below, and set the Event data retention to the minimum setting of 2 months, and ensure the Reset user data is switched off. Configuring these two settings to the minimum will help comply with the HIPAA Minimum Necessary Standard as part of the HIPAA Privacy Rule.

Next, head back to your Admin dashboard and navigate to the Reporting Identity, as shown in the screenshot below.

Ensure that your setting is set to Device-based inside the Reporting Identity settings, as shown in the screenshot below. This may already be set to Device-based because we turned off Google Signals in the previous steps, but double-check.

After completing Step 1 to 6, navigate back to your Admin dashboard and go to your Data streams, as shown in the screenshot below.

After clicking into your Data Stream, you have to click through one more time to access the settings of your Data Stream, as shown in the screenshot below.

Inside your Data Stream, scroll down to where it says "Redact data," and click to open the settings.

Inside the Redact data settings, you have two main options: enabling the redaction of email addresses, and URL query parameters. To start, toggle on Email redaction so that Google Analytics does not collect and store email addresses. You can read Google's [GA4] Data redaction article for a more detailed explanation.

After enabling the Email redaction, it is time to add query parameters. Please list all those that could contain unique identifiers. Obviously, this is different for every healthcare organization, depending on the type of data they collect. However, a good starting point would be to add first name, last name (or first_name and last_name, depending on your setup), and phone, as shown in the screenshot above. You'll notice that I added the email parameter here again and this is probably overkill, but I use it as a wildcard for "just in case."

Again, if your organization collects additional information in their web forms such as zip code, city, or any registration number fields that could contain unique identifiers, you should list them there too.

As mentioned earlier, every healthcare organization is different and collects different information, but this is equally true for their technology stack.

There are so many different Content Management Systems (CMS) from Wordpress to Duda, Wix, Squarespace, and many others. Whichever CMS you use, there are potential pitfalls to HIPAA compliance, and to learn more about how to build a HIPAA-compliant website, you can read this article by HIPAAjournal.com.

Since Google Analytics 4, by default, doesn't store IP addresses, you don't have to worry about them for now. If your organization assigns user_id in the web browser and stores that in a cookie to be collected by Google Analytics as part of your reporting setup, you must assess whether that data can be used to identify users when it gets stored in GA. If this is the case, you must stop collecting that data to comply with HIPAA. Google Analytics 4 doesn't assign user_id by default, so you don't need to worry about them if your organization isn't setting these cookies manually.

There are various ways of identifying potential harmful URL parameters that Google Analytics 4 may be collecting, and we'll go through one of them now: A PII Redaction Report.

We'll create an Exploration report in Google Analytics 4 to identify URL parameters based on conversion events (form submissions, for example).

I'll walk you through the four steps below.

Log back into your Google Analytics 4 account and navigate to the "Explore" tab on your left, as shown in the screenshot below.

Click into the Explore tab and select a blank canvas to create a new PII Redaction report for one of your conversion events in Google Analytics 4.

In your blank canvas, as shown in the screenshot below, you would need to select the following:

• Dimensions: page_location and event_name.
• Metrics: sessions
• Rows: page_location
• Filters: generate_lead

Look at the screenshot below and add these parameters precisely where I did.

In this instance, I have selected generate_lead as this is the event that is triggered when a user submits a web form on the website. Using a conversion event like generate_lead for this report will show you the URLs and their query parameters sent to Google Analytics upon submitting the web form, which, of course, has the highest likelihood of containing PHI.

Select your date range, whether the last 30 days or the last six months, and look through the list of URLs shown on your right for any parameters containing unique identifiers.

If there aren't any parameters that "potentially" contain unique identifiers, you don't need to do anything else other than the ten steps listed in the first section of this article, and your use of Google Analytics 4 should comply with the HIPAA rules; if you do see parameters that contain unique identifiers, then you would add those individual parameters to the Redact data settings in your Data streams as shown in the first section of this article.

IMPORTANT: Depending on your marketing and website, you may have different websites with different web forms or portals, and different conversion events. If so, you will have to duplicate the PII Redaction report multiple times and change the filter to reflect the other conversion actions or login portal URL's (authenticated) to ensure those actions don't collect any PII in the URL parameters.

Once you have all your reports built out, you should check these reports periodically to ensure no new parameters are sending unique identifiers over to GA4.

Congratulations! While these steps DO NOT GUARANTEE that your Google Analytics 4 setup is HIPAA compliant, you are now in a much better place than before and you shouldn't be too far off.

One thing to note, HIPAA compliance differs from state privacy laws and while your set up may comply with the HIPAA rules, it may not comply with your state's privacy laws just yet. For example, Washington state has recently enacted the most stringent health privacy law, which has a scope much broader than HIPAA, and since HIPAA preempts state law, you'd need to comply with that state law.

If an external agency handles your marketing and analytics, or if you're looking for a HIPAA-compliant marketing agency, I wrote an article on how to find a HIPAA-compliant marketing agency that you may find useful.

But what if I use Google Tag Manager to build a more complex tracking setup and to collect more web data than I can with the standard setup discussed above?

For this, you would need a Google Tag Manager (client-side) setup in combination with a Google Tag Manager Server-Side setup (yes, there are two different versions of Google Tag Manager). No worries, I've got you covered with this too. 

Many healthcare organizations leverage a tag manager solution like Google Tag Manager (client-side) deployed by their in-house marketing team or external marketing agency. Google Tag Manager, in combination with Google Tag Manager Server-Side is the better way of managing website tracking as it allows for much more control and flexibility in tracking various actions and events while staying compliant with HIPAA and other privacy regulations, such as CCPA, CPRA, and GDPR, for example.

We will continue this article by diving deep into Google Tag Manager Server-Side and how we must set this up to ensure no PHI gets collected or stored by Google Analytics 4.

Before we dive into the technical setup of SGTM and the GA4 configuration, I must inform you that the above steps could conflict with the information I will go through below. This is because the GA4 configuration in GTM will exclude the parameters before the GA4 client in SGTM claims the requests, and this may or may not interfere with what you're trying to achieve in SGTM. Of course, you can always TBV (trust but verify) this in preview mode and see whether this is an issue for your particular use case.

A final caveat before diving in: the following strategy is for individuals with a solid foundation of Google Tag Manager. If you have no experience with GTM, you will not understand the following sections, and my recommendation is to learn how to implement a standard GTM tracking setup first. For those familiar with a standard GTM implementation (client-side) but not Server-Side, I recommend taking the Server-Side Tagging in Google Tag Manager by Simo Ahava.

Right, now we've got that out of the way, let's dive in...

The screenshot below shows a URL parameter called ip_override, which collects the IP address. What I've done to prevent this from being sent over to Google Analytics is leveraging a transformation inside of SGTM to hash this value.

For this example, we'll use the ip_override parameter that is showing in the screenshot below, as this is the only unique identifier left in this dataset. You'll see a ton more data in the screenshot below, but none of that data is considered identifiable and, therefore, not protected by HIPAA. Remember, HIPAA only applies when unique identifiers are found in the exact same dataset as healthcare data. Without this combination, there is no PHI (Protected Health Information).

This doesn't look too difficult at first glance. Unfortunately, it is. Hashing that particular parameter is relatively easy, but it requires building a Google Cloud Run server infrastructure to accomplish this little task. While I won't be covering how to build a Google Cloud Run server infrastructure (maybe in a future blog), I will guide you through removing PII/PHI from your dataset using Google Tag Manager Server-Side and its transformations.

Follow the steps below in sequential order. We'll go over the Transformations and all the variables that need to be set up to be able to isolate the individual parameters, and then hashing that data before it gets sent to Google Analytics.

Let's dive in.

Head over to your Variables section in SGTM and add a new User-Defined Variable. The sha256 Hasher isn't listed in the default options, so you will need to click into the Community Template Gallery. Simply type in "hash," and you'll see the variable template appear. Select the sha256 Hasher variable by Simo Ahava as shown in the screenshot below, and add it to your workspace.

The following couple of steps are relatively easy, but they have to be in the exact order for it to work. First, we're going to click into sha256 Hasher variable and clicking into the grey building block, which we'll open another selection of variables, as shown in the screenshot below this one.

Since there is no pre-built Event Data variable, we'll have to create our own by going to the top right corner of your screen and clicking into the +.

Here we select the Event Data variable.

In the Event Data variable, we add the parameter "ip_override," and name this variable: Event Data - ip_override. Then hit the blue save button in the top right corner.

Now you will see your Event Data - ip_override variable show in the sha256 Hasher variable, as shown in the screenshot below. Name this variable: Hash - ip_override and save this variable again.

The Hash - ip_override variable will now show in your transformation below the Augment event, as shown in the screenshot below. Be sure to add ip_override in the Name section, as shown below.

Under the Matching Conditions, you would need to add GA4 equals Client Name, and select the Google Analytics 4 tag under Affected Tags by choosing Some Tags, not all tags.

Again, this SGTM section of the article is based on the assumption that you already have this portion of SGTM up and running.

I will cover this in-depth in my next article. However, that approach would be similar to the SGTM/GA4 setup covered in this article, except you would do the inverse by removing the treatment data (URLs/Titles) from the dataset instead of the unique identifiers in the case of GA4. This is because Google Analytics already has all the URLs and page titles stored, and advertising platforms already have all the unique identifiers on their end, as most people are logged into their services. 

Here's a screenshot of what that could look like:

Ensuring that Google Analytics 4 complies with the HIPAA rules is not an easy undertaking, but with the help of this article and the steps outlined above, it is very doable.

Just remember, as mentioned before, Google Analytics isn't a HIPAA-compliant analytics platform, as it will not sign a business associate agreement. However, you can configure its settings to comply with the HIPAA rules because HIPAA only seeks to protect Protected Health Information (PHI) and not Personally Identifiable Information (PII). PII only becomes PHI when stored in a dataset containing health data, such as specific URLs containing treatment information. Ensuring that both components aren't stored in the same dataset will help comply with the HIPAA Privacy and Security Rule.

I recommend following the steps outlined in this article first, and then engaging with your legal department. They can advise you on any additional steps you may need to take for your unique business compliance requirements, and regarding your obligations under state law, which could differ depending on the state you are located in. This article does not cover any specifics regarding state privacy laws, and you are advised to do your due diligence on that part.

Please book a consulting call with me if you need help implementing the above steps to ensure your use of Google Analytics is HIPAA compliant. I'd be happy to help you with this.

Thank you for taking the time to read this article, and I genuinely hope it will help you on your journey toward HIPAA compliance. If you would like us to manage the entire process from A to Z, please apply to work with us.