Online tracking is nothing new. For years, companies have tracked users’ behavior using codes and scripts placed on a website or mobile app. The goal of online tracking has always been to make more informed marketing and communication decisions that will benefit the specific user. When properly implemented and used to provide that custom experience unique to that particular consumer, it’s great for both parties. However, when executed poorly, or when data collected is sold to third parties without consent, it becomes a serious issue on many levels.
In the healthcare space, providers have implemented tracking on consumer-facing products to improve the digital care journey. But tracking for a healthcare organization is more complex than that of an e-commerce store, for example. In the healthcare industry, the data collected often contains sensitive information, or Protected Health Information (PHI). The nature of this data complicates how and when tracking can be used, regardless of the intent.
The constant evolution of consumer needs, how they use and trust digital devices, and the privacy they seek continue to drive change in the rules and regulations around tracking data in healthcare. This is precisely why HIPAA was created in the first place back in 1996, along with the subsequent addition of the Privacy and Security Rules in 2003. As technology usage has increased and the amount of data shared and collected online continues to grow, we are seeing a heightened concern around PHI collection and usage not to mention concerns exacerbated by recent data breaches.
A newly released bulletin from the Department of Health and Human Services outlines the Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates, governing how healthcare organizations (or, as HIPAA refers to healthcare organizations: ‘regulated entities’) should manage digital tracking and measurement.
What do the new guidelines mean for your organization?
The HHS decisively spells out that a ‘regulated entity’ cannot improperly share PHI with a third party:
Regulated entities (note: healthcare organizations = ‘regulated entities’) disclose a variety of information to tracking technology vendors through tracking technologies placed on a regulated entity’s website or mobile app, including individually identifiable health information (IIHI)19 that the individual provides when they use regulated entities’ websites or mobile apps. This information might include an individual’s medical record number, home or email address, or dates of appointments, as well as an individual’s IP address or geographic location, medical device IDs, or any unique identifying code.20 All such IIHI collected on a regulated entity’s website or mobile app generally is PHI, even if the individual does not have an existing relationship with the regulated entity and even if the IIHI, such as IP address or geographic location, does not include specific treatment or billing information like dates and types of health care services.21 This is because, when a regulated entity collects the individual’s IIHI through its website or mobile app, the information connects the individual to the regulated entity (i.e., it is indicative that the individual has received or will receive health care services or benefits from the covered entity), and thus relates to the individual’s past, present, or future health or health care or payment for care.22
In simpler terms, the above excerpt emphasizes that you want to ensure that the ‘regulated entity’ (your healthcare organization) passes information “only in the right way” to third-party vendors or systems. Basically, don’t pass identifiable PHI to a third-party vendor.
Okay, but what about IIHI?
In addition to stating guidelines on PHI collection, the HHS also outlines a wide range of IIHI (Individually Identifiable Health Information) that you should avoid collecting on your digital properties. Someone clicking on a provider profile on your organization’s website, by itself, doesn’t guarantee a problem and is fine to collect.
However, there are two ways that information becomes a problem – in other words, becomes “individually identifiable” – and should not be collected or passed along to a third party: first, if an individual can be reasonably identified (by collecting commonly identifiable information like names, phone numbers, or even IP addresses), and second if that information is passed to third parties.
Want to avoid problems? Avoid collecting IIHI as much as possible.
There are three primary offenders of personal information tracking that make it individually identifiable:
- Precise geolocation
- IP Address or other unique identifiers (think advertising)
- Personal information is entered in text input fields (think a form or login)
What is the best way to ensure we’re not passing identifiable data to third-party vendors?
The bulletin, helpfully, distinguishes three broad categories of digital properties:
- User-Authenticated web pages (requires a user to login, such as MyChart)
- Mobile Applications (delivered by and on behalf of a healthcare organization)
- Unauthenticated web pages (does not require a login, like your standard consumer-facing website)
Let’s break each of these down a bit more with the important information you should know.
User-authenticated web pages:
A user-authenticated web page is something a user must log into with identifiable information to access. In healthcare, MyChart (or other patient portals) instances are the primary example of this kind of property. The easiest way to solve this is simply don’t put third-party tracking on your MyChart or patient portal instance, especially any kind of pixel or session-recording software.
If you do need to get meaningful user behavior tracking from a MyChart instance, consider a secure way to send information within your systems, like an on-premise server using Matomo or similar tool, or a custom tracking implementation (though these are expensive). You can use the free suite of Google Analytics tools, but be sure to talk to an implementation expert to ensure it’s set up in a secure and safe way.
Mobile applications, especially those listed with EPIC or Cerner integrations, have a higher likelihood of exposing PHI. For example: if you are using biometrics to let a user access the application, that is personal health information.
It is important to take the necessary steps to ensure that data cannot be identified BEFORE collection. Cleaning post-collection is not good enough as the third-party vendor can’t filter the field in their database after collection and be able to say ‘great! we’re done!’ De-identification must be done before the point of collection.
How to manage this:
- For mobile applications, GA4 automatically masks IP addresses by default.
- Most mobile applications for healthcare do not log the precise location of a user, but those with wayfinding built-in may be at risk — especially if that wayfinding data is passed to or stored with any third parties.
- Additionally: Advertising should be disabled for mobile applications.
- The guidance mentions DEVICE ID, but to clarify: our understanding is that “device ID” is assigned to the individual phone/laptop/tablet by the manufacturer, not the value reported by Google Analytics. That refers to a unique app installation ID, and one device or individual could have multiple app installation IDs.
If these conditions are met, you can prevent most PHI from being collected as well as prevent identifiable PHI from being passed to third parties.
Unauthenticated web pages:
Unauthenticated web pages are ones that don’t require the user to log in. In other words, your standard-issue, publicly available internet web page. The majority of health system digital properties fall under this category. As the HHS guidance states, as tracking technologies on these unauthenticated webpages generally do not access PHI, HIPAA regulations generally do not apply.
However, HHS does indicate two instances in which IIHI could be exposed or collected:
- The login page of a patient portal, linked to from the main unauthenticated website
- A search for symptoms or an appointment request form that doesn’t require authentication, but does require a user to enter personal information
How to manage these risks:
- Do not allow third parties to collect keystrokes or any information entered on a form, whether via tracking or session recording. (Many organizations use tools like HotJar, CrazyEgg or Inspectlet to record sessions and better understand user behavior. Be extremely mindful of using these tools on healthcare websites. Read the fineprint and understand what these tools do and do not collect – and what they can and cannot be configured to do.)
- Do not collect individual IP addresses. GA4 automatically masks IP addresses by default. If you haven’t upgraded to GA4, develop a plan to do so very soon. Also, once more, turn off the advertising ID for Google Analytics.
Managing these areas can help mitigate risk to avoid collecting IIHI on your digital properties.
Keep your marketing data de-identified.
There is one additional area of considerable risk: your Google Tag Manager account.
Many GTM accounts have years of old and little-examined marketing pixels, custom html tags for specific landing pages for specific campaigns, and other third-party insertions. Look through your existing GTM account and audit your marketing pixels and their configuration. Remove any that are unnecessary, and make sure you understand what they are collecting.
Pixels come with their own configuration and can send information to a third-party vendor that the vendor then controls. Once a third party receives data from a pixel, that third party will do whatever it wants with that data, including reselling it to others. Be extremely mindful of what information these marketing pixels are collecting.
With those points in mind, you should be well set-up to keep your data de-identified.
Use this article as your guide to ensuring your organization is in compliance with the HHS and HIPAA’s latest guidelines surrounding PHI and IIHI.
If you want the TL; DR version or need to share key takeaways with others in your organization, here you go:
- Turn off advertising ID to prevent unique advertising ID sharing.
- Upgrade to GA4. (We recommend this for many reasons, not least of all that older versions of Google Analytics are being sunset July 2023. In this case, the upgrade to GA4 is critical to ensure automatic IP address masking).
- Be extremely mindful of collecting user-entered text or login credentials. If you are using session-recording software, thoroughly review the documentation and configuration of your software to ensure no text or keystroke inputs are being collected, stored, or shared.
- Make sure that third-party tags and pixels in your Google Tag Manager account are in place only to collect the most critical information, and nothing more.