Clarity for HIPAA Compliance From OCR’s Updated Guidance on Online Tracking
Two weeks ago, the Office of Civil Rights at HHS updated their guidance regarding the use of online tracking technologies by HIPAA covered entities and business associates. It’s fair to say the first guidance they provided in November of 2022 mainly cause frustration and panic, but I found this updated guidance, this most recent guidance, to be helpful in clarifying. In fact, it confirmed a lot of things that covered entities, their compliance teams, their attorneys, and partners like us have been left to deduce on our own.
This new guidance is welcome and addresses several important topics, including consent management, tracking on authenticated pages, tracking on unauthenticated pages, tracking within mobile apps, and whether de-identification of data before sharing it with partners who aren’t under BAA is acceptable and satisfies the requirements of HIPAA. Prior to November 2022, HIPAA had been understood and interpreted to apply to patient relationships and patient data to healthcare records. The November 2022 guidance expanded HIPAA coverage to prospective patients, so visitors to a covered entity site who were prospective patients and not known to that covered entity. In addition, that same guidance declared that the collection and sharing of data that enables the identification of a visitor, notably IP address, is PHI, and any data related to “the past, present, or future health, healthcare treatment, or payment for health care is PHI.” So, a visitor visiting a URL or a page that has information related to a health care, condition treatment of that health care, scheduling an appointment looking for a physician who might provide that treatment, that now is PHI, even for instances in which that visitor is unknown to that covered entity.
The net effect was to render virtually all third-party trackers in violation of HIPAA. Why? Well because virtually all third-party trackers collect PHI by default, for example, IP address. They send information directly to those third parties, and they’re controlled by those third parties. In fact, the data collection rules governing those trackers can be unilaterally updated by those third parties. And in general, third-party marketing platforms and partners will not sign a business associate agreement, which is the only way that PHI could be shared with them.
The updated guidance from the OCR adds details and examples to their November 2022 guidance. It also confirms what they consider to be acceptable and unacceptable approaches to achieving HIPAA compliance for digital tracking. Let’s go over those five areas that I mentioned at the top.
Cookie Consent Management
I’ll just give you the quote directly from the updated guidance; it’s very clear.
Cookie consent management, while a good practice and the right thing to do, does not create HIPAA compliance.
Tracking on Authenticated Web Pages
The guidance is clear. You can not use third-party trackers from entities not under BAA to track authenticated pages. That means no default implementation of analytics platforms, no advertising tracking, no martech tracking. Why? Well, because those tracking technologies on those pages are generally going to have access to PHI. By definition, if you’re on an authenticated page, you have logged in, and so it’s possible if not likely that information available to those trackers would include name or email address, health and healthcare information, all of which is absolutely PHI to say nothing of IP address.
Tracking on Unauthenticated Pages
There’s a helpful clarification in the guidance around this particular use case and situations where you actually can continue to use third-party tracking, including collecting IP address and URLs. For example, let’s say you have a visitor to a site looking at a hospital’s job posting or looking at visiting hours. In those instances, you could continue to use third-party trackers that collect IP address and the URL visited by that visitor. That’s helpful to the covered entity and could have real practical value for some larger healthcare organizations who might have a microsite or a job portal for recruiting. The second example that’s cited in the OCR guidance is kind of an academic allowance, but I’m not sure there’s a lot of practical application. The literal example that’s cited is a student who’s writing a term paper on the changes in availability of oncology services before and after COVID. In that instance, you can technically continue to use third-party tracking. Practically though, I’m not sure how you would know that that’s a student visiting a page on oncology as opposed to a prospective patient who is seeking information related to their treatment or prospective treatment. You can’t know, and so really, I think it’s better to assume that all visitors to these kinds of pages are prospective patients and to use no third-party tracking in those instances.
Tracking in Mobile Apps
Because of the data that mobile apps generally track by default – device ID, geographic location, app usage information in great detail – that information is generally considered to be PHI and it can’t be shared in full with third parties. That’s a pretty clear statement in this guidance.
De-identification of Data
How about if a tracking technology vendor agrees or promises to remove PHI or to de-identify information it receives before saving it? Is that acceptable? The answer here is really clear in this guidance. No, that’s not acceptable. Just the act of collection of PHI by a third-party, not under BAA, even if that PHI is not saved, is still a HIPAA violation. The overwhelming majority of advertising, MarTech, and analytics platforms aren’t going to sign BAA, so what’s the path forward? Well, again, very helpfully, the OCR also provides clear guidance here. If a third-party won’t sign a BAA, then a covered entity can engage with a third-party that is under BAA, and that third-party can provide a technology or a solution that de-identifies data before it is shared with third parties not under BAA. So, you can de-identify, you can cleanse that data before it is shared with third parties under BAA.
We’ve implemented a solution like this for years for our clients. The key elements of this kind of solution and what makes it HIPAA compliant are several. First, you have to control data collection. We do this by replacing all third-party trackers with a single private client ID and custom data libraries that govern data collection. There are no more third-party trackers, and the data that is collected is governed by rules that are developed in concert with the marketing and compliance teams that our client organizations. Then we implement a HIPAA compliant data hub, and using that data hub, we can do all sorts of things with data. We could provide full fidelity data to internal systems, say an internal data warehouse, and we can cleanse and de-identify data before sharing it with a third-party that is not under BAA. Don’t want to collect IP address? Well, you’re in control of that. We can establish data rules in the data library that ensure that IP address isn’t ever collected. If you want to collect IP address though, for your own system, but ensure that you never share it with another entity that isn’t under BAA, you also have that control.
The OCR also mentions a CDP is an example of how data might be de-identified before sharing, and that could be a good solution for healthcare providers that are looking for a CDP. But, a CDP is a major investment, and so this also runs the risk of being a little bit of the tail wagging the dog. Our perspective is that the best HIPAA compliant data solution should fit within and support an organization’s existing infrastructure. A CDP is a good and valid approach, but it’s also an approach with a pretty major organizational and IT implication, and should be considered in that light.
GA4 Implementation
One final note, we are seeing some companies using this most recent guidance to continue to insist that GA4 can’t be implemented in a HIPAA compliant manner. This isn’t true; we’ve done it. It is true that a default client site implementation of GA4 won’t be HIPAA compliant. PHI absolutely will be collected, at a minimum in the form of IP address. In their terms of service, Google does claim not to save this information, but as we’ve just reviewed, just collecting information is a violation of PHI; it’s not sufficient to declare that you’re not going to save it.
GA4 can be implemented in a HIPAA compliant manner, and here’s how. First, you implement GA4 server side, you replace the Google tracker with a private client ID, just as I described a minute or so ago, and with custom data collection libraries, and so now you have full control over what is and isn’t collected. You define what is and isn’t collected. You implement Google Tag Manager, but not in a default implementation, not in the Google Cloud, you implement it in a private HIPAA compliant cloud instance. We’ve used both Azure and AWS for this. Doing this isolates Google Tag Manager from Google, making it simply a private tag management service. Then, you can cleanse and de-identify data used before sharing via API with any marketing partners not under BAA. This wasn’t possible previously, but the introduction of transformations in Google Tag Manager in the second half of last year changed the game and made it possible to implement GA4 in a HIPAA compliant manner.
Final Thoughts
Well, this most recent guidance from OCR actually is helpful and clarifying. I hope that this summary and distillation of that guidance was helpful for you.
Related Links
Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates
Questions or comments
Please let us know if you have questions or suggestions for other topics that would be valuable for us to cover in this area by emailing Grace Johnson at grace@wheelhousedmg.com.
