Quick Disclaimer: Let me start this out by saying “I am not a lawyer”. This article is meant to share what is currently happening in actual implementations of ad trackers in digital health, not to give specific recommendations. I’ve spoken to about a dozen companies on this topic and aim to consolidate the logic and tactics they are following. I hope this serves as a helpful framework as you think through your unique context.

First A Little History

For many years, just like any company that does digital marketing, digital health companies have used ad tracking technology to understand the efficacy of their ad campaigns. This has been the standard as digital health companies have grown. Recently, these trackers have come under more scrutiny.

Why the scrutiny? HIPAA wasn’t written in the digital age, and it has been under the microscope because of rapid scaling of digital health companies. Throughout the pandemic digital health companies proliferated and reached much greater scale. Additionally, they were able to offer many more services like remote patient monitoring (RPM), virtual labs, and in home blood draws. Simultaneously, there has been a growing general resentment towards online companies not respecting privacy.

Towards the end of 2022, a series of articles, lawsuits, and an HHS guidance brought the topic of digital health companies using ad trackers front and center for almost all marketers in digital health. Everyone was asking the question: “How can I run Meta/Google ads compliantly?? Can I even??”.

Fast forward to 2023, we are seeing different companies have taken various approaches to tackle the big question. I have spoken to about a dozen companies on this topic. Below, I will share the logic I have seen these companies follow. 

Context Matters

First and foremost, the companies I spoke with exist in different areas of healthcare delivery. Who they are, who they treat, and what they treat is informing their decisions on how they use ad trackers. The key questions that differentiate companies include:

1. How prominent are we?
2. Are we “condition specific”? Do we only treat one medical condition?
3. How sensitive is the condition(s) we treat?

How prominent are we?

Though it doesn’t actually change compliance needs, many smaller, earlier-stage companies see themselves as unlikely targets for regulatory scrutiny or lawsuits. While this is likely practically true today, this may change over time. About 80% of companies cited in one article are Series B or later companies.

It is important to note that many (probably most) less prominent digital health companies have not changed their usage of ad trackers in the last year. In fact, they still use them openly and in likely non-compliant ways.

Do we only treat one medical condition?

The HHS guidance specifically speaks about “Tracking technologies on a regulated entity’s unauthenticated webpage that addresses specific symptoms or health conditions” and how activity on these pages could be considered PHI.

Given this assertion, if you are a company that provides one treatment or treats one condition, then every webpage interaction could be considered PHI. It becomes much more difficult to use ad trackers compliantly.

How sensitive is the condition(s) we treat?

Conditions that are generally considered “more sensitive”, such as STD, abortion, or substance use, are considered to be greater targets of regulatory and PR scrutiny. These areas have been specifically called out in press articles. In addition to HIPAA compliance, there may also be other levels of regulation in these condition areas.

Obviously Bad Things

Before we dive into considerations based on your company’s context, it is worth calling out the more obvious bad practices. 

Some of the early articles on this topic called out companies sending obviously sensitive information to ad networks. Things like exact diagnoses, exact times and reasons for booked appointments, or medications prescribed. I don’t believe the companies had any intention of sharing this information with the network, but they were using the Javascript-based Meta Pixel which would suck up activity happening on the webpage and send it to Meta. Hospital systems that sent this kind of information to Meta with the Javascript pixel are currently the part of many lawsuits.

As I will talk about below, using the Meta Pixel has a handful of drawbacks, one of them being accidentally sending sensitive information. For this reason, many digital health companies have opted to stop using the Javascript pixels.

The most egregious examples of unauthorized data disclosures involved data being shared from within "Patient Portals" on health system websites. No digital health company I spoke with is doing any ad tracking inside of the websites or apps used by their existing patients. All their thinking revolves around the sign-up or enrollment flows. Many are asking questions like: "When does someone turn from a web visitor into a patient?", "Whats the difference between a lead and a patient?" All the below logic and tactics apply to the enrollment context, not established patients.

Evaluating Your Context

The HHS guidance does not say “never send info to ad networks” - rather, it lays out a framework for what interactions would be considered PHI and therefore should not be sent to ad networks.

Below, I will share various interpretations of this framework that I have heard being adopted by about a dozen companies in consultation with their legal teams.

Are you condition specific?

Does interaction with your website imply a diagnosis or treatment?

Not Condition Specific

Examples: Generic mental health provider, telemed urgent or primary care

If people can seek treatment for many conditions on your website, this is the logic I have seen companies follow in order to send data back to ad networks.

1. Usage of your site does not imply a diagnosis or treatment (so not PHI).
2. Deeper funnel conversion events do not imply a diagnosis or treatment (so not PHI). They only imply an interaction with the company, not any specific health information.
3. All events shared need to occur before ‘becoming a patient’, as part of the enrollment flow.
4. As long as you don’t send “actual PHI” like answers to form fills and avoid sending specific identifiers like email, phone, and name, then it is low risk to use client and server side ad trackers for deep enrollment funnel conversion events (e.g., checkout).

This is the simpler case. The simplest implementations are either a client side tracker embedded on a page (with no PHI on it) post checkout/form completion or a server side tracker used via a Customer Data Platform (CDP) (like Segment or Freshpaint). 

Condition Specific

Examples: Eating disorder online clinic, PTSD mental health provider

This is the much more complex case and where a lot of digital health companies find themselves. If using your website or a part of your website could imply a diagnosis or medication prescribed, that website activity could be considered PHI per the latest HHS guidance. Below, I’m going to share four approaches to this problem that I have heard of companies considering.

Approach 1: Obfuscated Server Side Events

The goal of this approach is to send the minimal amount of data in a nondescript way, so no one outside of the digital health organization knows what events users completed.

A “server side event” is conversion event information shared between the advertiser and the ad network via their APIs. Meta and Google both have APIs to share this kind of information with them. This approach is different than using a Javascript Pixel, which is embedded in the webpage of the advertisers site. A server side approach allows for more control over what information is being shared and greater obscurity of what conversion events are being shared.

Using a Customer Data Platform (CDP), like Segment or Freshpaint:

1. Embed the CDP client on every page load.
2. Save the Click ID from the ad network on the first landing. This is either the FBCLID (Meta) or the GCLID (Google).
3. Set up the CDP and the ad network to send the Click ID when the user reaches a specific conversion moment (e.g., checkout).
4. This conversion has a non-descript name like “Event 1”.
5. Set up campaigns to optimize for this conversion “Event 1”.

With this setup, because the conversion event is sent on the backend, no one except the digital health company knows exactly what the event means. The logic of this approach is because the ad network has no way of knowing what this event is, it is not PHI even if coming from a condition specific website. It could be a homepage load, it could be a checkout, it could be a load of the careers page. The logic follows that if you were to consider this nondescript event as PHI, you would also need to count the initial click event as PHI, which means condition specific healthcare organizations would be incapable of advertising on ad networks. 

There is not agreement among companies if this approach is compliant. Some assert the nondescript event is vague enough not to be considered PHI and some believe any additional information sent to the network after the first click indicates interaction with the single-condition company and is therefore PHI.

Approach 2: HIPAA Authorization

Some companies have discussed gathering direct HIPAA authorization asking the user directly if they will allow the disclosure of their PHI to the ad network. I have heard of a few companies considering this, but I’m not aware of any that have actually moved forward with it.

The flow is as follows:

1. Show a HIPAA auth at some point deep in the enrollment funnel.
2. If the user agrees to the auth, then on the page immediately following, embed a javascript or server side tracker.

I have heard from a few teams that they see this approach as “low risk” from a regulatory standpoint. The downside is it is very visible and could be interpreted negatively by the public or media. A few companies that have tested this approach shared 75-90% of people who saw the authorization prompt agreed to the disclosure.

Approach 3: On-Platform Actions

Due to increasing inability for any advertiser to send data back to ad networks because of iOS privacy changes, ad networks are building tools to drive “on-platform” actions so advertisers can optimize campaigns off of these on-platform actions that aren’t impacted by iOS privacy changes. For example, Meta has Instant Forms and Instant Experiences, Tiktok has Instant Forms, Google has Lead Forms (though AFAIK Google doesn’t allow healthcare companies to use them).

I know of some digital health companies using these on-platform actions. It works this way:

1. Ad creative CTA opens the lead form or instant experience on ad network page (FB/IG)
2. The experience is designed to be significantly friction-ful, so only a high intent person would continue through it.
3. After completing the form or clicking through from the instant experience, the user is redirected to the provider’s landing page.
4. Optimize the campaign for lead captures or instant experience CTA clicks.

The logic of this approach is the company is never sending data back to the ad networks and therefore does not need a BAA or HIPAA authorization. All the data collected is collected on the platform. The logic follows that ad networks are already collecting tons of information of the same character (e.g., clicks, engagements, searches, comments, etc.), so adding in an additional interaction is adding to a data trail that already exists.

I have heard of digital health companies considering using Meta Instant Experiences, but haven’t heard of anyone actually doing it and have real data to share. The idea here is you can build a quasi-landing page on-platform, and optimize campaigns towards people who click the CTA on the Instant Experience.

Approach 4: Manual Bidding For Clicks

The goal of all the above approaches is to optimize campaign audiences off of intent signals occurring on the digital health company’s website or on the ad platform. These intent signals allow the network to modify the audiences to be better targeted and look more like people who are taking intentful actions. An alternative approach is to avoid any intent signals, and just pay and optimize for clicks.

Google Search ads have allowed manual bidding from their beginning. Manual bidding is telling Google how much you will pay for clicks on specific keywords. Google tries to push all advertisers now into automated bidding, since it is easier for people to manage and generally leads to greater efficiency of campaigns, but automated bidding is based on conversion data sharing back to Google. In a healthcare environment, a company can avoid sending any data back to Google by opting for manual bidding across target keywords.

Manual bidding takes more work. You’ll need to:

• Come up with all possible keywords for your target population
• Set initial bids
• Set UTM parameters for ad clicks so you can track conversions in an analytics tool
• Using your analytics tool, calculate Cost Per Action (CPA) based on the tracking defined in your UTM parameters
• Add keywords, remove keywords, adjust bids based on what keywords deliver good or bad CPAs.

This strategy works on Google Search, since the keyword itself is a strong signal of intent. Little additional intent tracking is required. Behavioral networks like Meta and Tiktok don’t have this advantage. In the companies I have spoken with, I have not heard of anyone having success with a “click” optimized campaign in social ads. Networks are full of “clicky” users, so optimizing for clicks will get you a bunch of them, not your target audience.

Evolution

What I shared here is my best understanding of the “on the ground” approaches that currently exist as of September 2023 among digital health companies as they balance the importance of using ad platforms with the need to maintain compliance. These approaches have evolved quickly over the last 12 months, and depending on further clarification from regulators will continue to evolve.

Are you working through this problem? I’d love to hear about your thinking and approaches. Reach out at cturitzin@gmail.com.

Thanks to Amanda DiTrolio, Gabe Strauss, Brian Williamson, Phil Esterman, and others for reviewing this article.