Your agency says they can hash the patient data. Can they?

No.

The Federal Trade Commission published a post in July 2024 titled "No, hashing still doesn't make your data anonymous". You do not have to interpret their position. That is the headline.

Your agency is not being reckless, and you should not treat them as though they are. Hashing customer emails before sending them to Meta is standard practice, it is what Meta's own documentation tells advertisers to do, and it works fine for a shoe store. Health is the exception, and most performance agencies have never had to learn it.

Here is what to say on the next call.

Why does hashing feel like it solves the problem?

Because in every other category, it does.

The pattern is universal. You collect an email at checkout, run it through a one-way function so it comes out as a string that means nothing to a human, and send that string to Meta or Google. The platform runs the same function over its own user list, finds the match, and now knows which of its users bought your product. Nobody at Meta ever sees the email. That is Advanced Matching, the Conversions API, Enhanced Conversions: how modern paid media measures itself.

An agency looking at this sees a privacy-preserving technique. The raw identifier never leaves your server. It feels like the responsible version.

The problem is in the last step, and it is not a technical problem. The entire purpose of sending the hash is so that the platform can work out who the person is. That is not a side effect. That is the feature you are paying for.

What did the FTC actually say about this?

They said it in the plainest language a regulator has ever used on the subject, and they said it about a telehealth company.

The FTC's Office of Technology, in the post named above:

"This logic is as old as it is flawed – hashes aren't 'anonymous' and can still be used to identify users, and their misuse can lead to harm. Companies should not act or claim as if hashing personal information renders it anonymized."

And:

"Regardless of what they look like, all user identifiers have the powerful capability to identify and track people over time, therefore the opacity of an identifier cannot be an excuse for improper use or disclosure."

But the sentence that should end the meeting is from the FTC's complaint against BetterHelp, paragraph 49. Read it slowly, because it is describing exactly what your agency has proposed:

"Although Respondent 'hashed' Visitors' and Users' email addresses ... before disclosing them to third parties, the hashing was not meant to conceal the Visitors' and Users' identities from Facebook or the other recipient third parties ... In fact, Respondent knew that third parties such as Facebook were able to, and in fact would, effectively undo the hashing and reveal the email addresses of those Visitors and Users with accounts on the respective third parties' platforms, which is how Facebook matched these email addresses with Facebook user IDs."

The FTC did not accept hashing as a mitigation. It treated hashing as evidence of intent, because the only reason to hash and send is so the recipient can match. BetterHelp paid $7.8 million and is prohibited from sharing consumers' health data for advertising.

The complaint is blunter still about what the disclosure actually was. Not an email address. This:

"each such disclosure of even a Visitor's or User's email address constituted a disclosure of the Visitor's or User's health information."

An email address, sent from a therapy company, is health information. Because the fact that this person is your patient is the health information. You do not need to send a diagnosis to disclose a condition.

Doesn't Meta accept hashed data? Why would they take it if it were not allowed?

They do accept it, and this is the part worth putting in front of your agency, because it comes from Meta rather than from you. Meta's Business Tools Terms describe hashed contact information as existing for one purpose:

"'Contact Information' is information that personally identifies individuals, such as names, email addresses, and phone numbers, that we use for matching purposes only."

And they tell you what you are instructing them to do with it:

"You instruct us to process the Contact Information solely to match the Contact Information against user IDs ('Matched User IDs'), as well as to combine those user IDs with corresponding Event Data."

That is Meta describing, in its own contract, the process the FTC called undoing the hashing. Matching is not a bug in the system. It is the system.

And in the same document, Meta tells you not to send it:

"You represent and warrant that you will not share Business Tool Data with us that ... includes or is based on, directly or otherwise, health information, financial information, consumer report information, or other categories of sensitive information"

Then, in case anyone hoped to solve this by renaming the event:

"The names you choose and criteria you establish for your events, conversions, and any custom audiences you create must not reflect, imply or be based on any category of information described in this Section 1.h."

So the answer to "why would Meta accept it if it were not allowed" is that Meta's systems accept it and Meta's contract forbids it, and the contract puts the liability on you. Their tooling will not stop you. Their terms will not defend you.

Google is more often misstated than Meta, so be precise. Google will sign a business associate agreement. It signs one for Google Cloud, and it tells customers to "disable or otherwise ensure that you do not use Google Cloud Products that are not explicitly covered by the BAA." Google Ads, Google Analytics, and Google Tag Manager are not on that covered-products list. So the accurate sentence is not "Google will not sign a BAA." It is that Google's BAA does not cover the advertising stack, and health is a sensitive interest category where "advertisers promoting products and services that fall within sensitive interest categories are unable to use advertiser-curated audiences."

But a court struck this down. Isn't tracking legal again?

This is where most of the writing on this subject goes wrong, in both directions, and where a telehealth operator is most likely to be misled by a summary.

The ruling is real, and it went against HHS. On June 20, 2024, the Northern District of Texas vacated part of the government's online tracking guidance, the part that said an IP address plus a visit to an unauthenticated page about a health condition amounts to protected health information. The court's line, at page 25, is quotable and about as unhedged as judicial writing gets:

"Simply put, Identity (Person A) + Query (Condition B) ≠ IIHI (Person A has Condition B)."

The government appealed and then dismissed its own appeal on September 4, 2024. The vacatur stands. If you run a hospital website with a static page listing your oncology department, you genuinely got relief.

Now read the sentence the court wrote immediately after:

"If a covered entity's UPW greets visitors with a dropdown box requesting their subjective motive for visiting the page, that would be one thing. The Department can and should remind covered entities that the Privacy Rule would apply in those circumstances."

A page that asks the visitor why they are there is outside the relief. The court said so explicitly, and treated it as an obvious carve-out rather than a close call.

So ask yourself what a telehealth landing page is.

It is a symptom page. It asks what is wrong with you. It has a "start your consult" button, a condition selector, a symptom checker, an intake form. The entire design of direct-to-consumer telehealth is to get the visitor to declare their subjective motive as fast as possible, because that is the conversion. The thing the court carved out is not an edge case in this industry. It is the business model.

Two further limits, and they matter as much:

The vacatur covers unauthenticated pages only. Everything behind the login, the account, the intake, the treatment plan, sits inside HIPAA untouched. HHS's guidance still says so, and it names your category specifically: user-authenticated pages include "a patient or health plan beneficiary portal or a telehealth platform," and tracking technologies on them "generally have access to PHI."

And the court decided a HIPAA question. It said nothing about the FTC, which is where the money has actually been. It said nothing about state wiretapping statutes or health-privacy laws. And it said nothing about the private class actions that continue to be filed under those theories. The seven patterns that regulators actually flag in telehealth marketing sit on top of all of this, and the pixel question is one of them.

One practical warning, because it will confuse someone on your team. HHS added an italic note about the vacatur to the top of its guidance page and did not change the body of the document. The vacated example is still sitting there in the live text. Anyone who reads that page cold today will read a rule a federal court struck down two years ago, presented as current guidance. HHS says it "is evaluating its next steps." That was two years ago.

We're not a HIPAA-covered entity. Doesn't that solve it?

It makes it worse, and this is the trap that catches the companies who think they have found the clever exit.

The FTC's largest early action here was against GoodRx. GoodRx was not a covered entity, and the FTC's complaint says so in as many words:

"In truth and in fact, GoodRx is not a HIPAA-covered entity, and its privacy and information practices did not comply with HIPAA's requirements."

The FTC did not need HIPAA. It used the Health Breach Notification Rule, which exists precisely to reach health companies that sit outside HIPAA. GoodRx paid a $1.5 million civil penalty and is permanently prohibited from disclosing user health information to third parties for advertising.

So there are two doors into this room, and being outside HIPAA only closes one of them. Cerebral drew a similar action: the FTC alleged that by permitting tracking tools on its sites and apps it caused disclosure of sensitive health information to twenty or more third parties, including LinkedIn, Snapchat, and TikTok, and the proposed order required it to pay more than $7 million. That was a settlement, on allegations, without admission.

Three telehealth companies, three enforcement actions, and pixels or trackers in all three.

So what can you actually send them?

Something real, and your agency will be less unhappy than you expect once they hear the whole thing.

Keep the pixels on the marketing domain and off the care pages. Anything behind a login is out. This is not a judgment call. If you are not sure which of your surfaces count as care pages, that is the pixel-and-data-flow question worth working through first.

Capture the click identifier at click time, on the marketing domain, before anyone has told you anything about their health. That token is an advertising artifact, not a patient fact.

Fire the conversion server-side, keyed to that token, with nothing else in it. No email. No phone. No hashed email, hashed phone, or any other hashed identifier, because a hashed identifier is an identifier. No condition, no symptom, no product name that reveals what the person came for. A generic event and a value, and nothing else.

Do not solve this by renaming the event. A conversion called "Consult_Purchased" is not safer than one called "ColdFlu_Consult" in the way people hope. Meta's terms already say your event names "must not reflect, imply or be based on" sensitive information. The name is not the exposure. The identifier plus the health context is the exposure.

And do not let anyone tell you the vendor will strip it on their end. HHS is explicit that this does not work: "it is insufficient for a tracking technology vendor to agree to remove PHI from the information it receives or de-identify the PHI before the vendor saves the information."

Your agency will lose match rates and optimization gets less precise. That is the real cost, worth naming rather than pretending the compliant version performs identically. It does not. It costs you some performance and buys you the ability to keep operating.

One honest caveat I would rather say than bury: even a click-ID conversion is a judgment call, because the platform can map its own click identifier back to a user on its side. Stripping every personal identifier and every health signal from the payload is what makes it defensible. How far to go is a legal risk-tolerance decision, not a marketing one.

What's the better idea your agency hasn't raised?

This is the part that turns the conversation from a fight into a favor, and it is worth leading with rather than ending on. Once you take user-level attribution off the table, you are pushed toward a measurement method most performance teams underuse precisely because pixels made it feel unnecessary: incrementality testing. Hold out a matched geography or audience, run the campaign everywhere else, and measure the difference in actual consults from your own system. No user-level data leaves your walls, it survives every rule on this page, and it answers the question attribution only ever estimated, which is whether the spend caused the growth or just took credit for it.

Pair that with aggregated, modeled conversions for day-to-day optimization, and report results to the agency as cohorts from your own records rather than as matched individuals. You give up user-level attribution and gain a cleaner read on whether the ads work, and you stop handing a regulator the rope. An agency that hears "no pixels" hears a smaller job. An agency that hears "here is how we prove your work with a holdout test" hears a better one.

The hardest part of this is not the law. It is the room: being the least technical person in it, and holding a position anyway.

From Pranay Parikh, MD, founder of Off-Label:

"At the end of the day, you have to remember that you are a specialist. That is what I tell myself: I know the medicine better than anyone else in the room. I have more than ten thousand hours doing the thing."

What don't we know?

I am a physician and a marketer, not a lawyer, and this page is not legal advice.

I do not know your risk tolerance, your corporate structure, which state laws reach you, or what your counsel will say. Everything above is sourced to primary documents so that you can hand them to someone qualified rather than take my word for it. The links go to the FTC's own complaints, the court's own opinion, and the platforms' own contracts. Read them.

What I do know is that the argument your agency is making has already been made, by a telehealth company, to the FTC, and it lost. That is not a prediction. That is the record.

If your agency can show you a primary source that says otherwise, I want to see it, and this page will change.

Frequently asked questions

Can you send hashed emails to Facebook for a healthcare business?

Not safely. The FTC's Office of Technology has stated that "hashes aren't 'anonymous' and can still be used to identify users," and the FTC's BetterHelp complaint found that the company "knew that third parties such as Facebook were able to, and in fact would, effectively undo the hashing." Meta's own terms describe hashed contact information as used "for matching purposes only" while separately prohibiting advertisers from sharing health information.

Is hashing the same as de-identification under HIPAA?

No. De-identification means the data can no longer be tied to a person. Hashing produces a stable, unique token whose entire purpose is to let a third party recognize the same person. If the recipient can match it, it identifies. HHS also states it is "insufficient for a tracking technology vendor to agree to remove PHI from the information it receives or de-identify the PHI before the vendor saves the information."

Didn't a court rule that pixels on health websites are legal?

Partly, and it helps telehealth less than it sounds. In June 2024 a federal court vacated the HHS position that an IP address plus a visit to an unauthenticated condition page is protected health information. But the same opinion says the Privacy Rule would still apply to a page that asks visitors their reason for being there, which describes nearly every telehealth landing page. The ruling also does not touch authenticated pages, the FTC, or state privacy law.

Are we safe if we are not a HIPAA-covered entity?

No, and it can be worse. The FTC brought its GoodRx action under the Health Breach Notification Rule, which exists to reach health companies outside HIPAA. The complaint states plainly that "GoodRx is not a HIPAA-covered entity." GoodRx paid a $1.5 million civil penalty and is permanently barred from sharing user health data for advertising.

What conversion data can we legally send to Meta and Google?

Capture the ad click identifier on your marketing domain before any health context exists, then fire a server-side conversion keyed only to that token, carrying no personal identifier and nothing that reveals the condition. Keep all pixels off authenticated care pages. Expect lower match rates. Have counsel confirm the final design.