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 necessarily being reckless. Hashing customer emails before sending them to an ad platform is a common matching technique in ordinary ecommerce. Health data changes the risk, and many performance teams have not had to separate those cases.

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.

Why can a platform accept a hash if sending it is still risky?

Technical acceptance is not legal clearance. A platform can match a stable identifier because that is what the identifier was built to do. The FTC's BetterHelp complaint describes Facebook matching hashed emails back to user IDs and treats the disclosure as health information. The receiving system working as designed is the reason the hash does not solve the underlying problem.

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.

The court decided a narrow HIPAA question. It did not declare tracking lawful across other page types or data flows, and it said nothing about the FTC or state privacy law. The five patterns in the telehealth advertising compliance record sit on top of this question rather than disappearing because of one vacatur.

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.

What should your technical review test?

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

Separate marketing and care surfaces. Inventory every page, form, event, and vendor. Treat intake and authenticated surfaces as high risk. Do not place advertising technology there unless counsel approves the exact flow. If you are not sure which surfaces count as care pages, start with the pixel-and-data-flow review.

Minimize identifiers and context. One architecture to evaluate is capturing a click identifier on a general marketing surface before the visitor shares health information, then keeping condition, symptom, product, email, and phone data out of the advertising flow.

Review any server-side conversion as a complete flow. A generic event can still identify someone when it is joined to a platform click identifier. Removing fields narrows the disclosure; it does not create automatic clearance.

Do not solve this by renaming the event. A neutral label cannot repair a flow that still links a person to health context. Review what the recipient can infer, not just what the event is called.

One caveat matters: even a click-ID conversion can let the platform map its own identifier back to a user. Removing personal identifiers and health signals narrows the disclosure, but it does not create automatic legal clearance. Counsel should decide whether the remaining flow fits the company's obligations and risk tolerance.

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

This is the part that turns the conversation from a fight into a favor. Once user-level attribution is reduced, incrementality testing becomes more useful. Hold out a matched geography or audience, run the campaign everywhere else, and measure the difference in actual consults from your own system. That reduces the need to disclose user-level data and answers the causal question attribution only estimates: whether the spend created growth or took credit for it.

Pair the holdout test with the paid-ads preflight and cohort reporting from your own systems. You give up some user-level attribution and gain a cleaner read on whether the ads work. An agency that hears "no pixels" hears a smaller job. An agency that hears "here is how we test whether your work caused growth" 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?

This page is marketing guidance, not legal advice. The right answer depends on the company's structure, applicable state laws, exact data flow, and counsel's risk analysis. The links go to the FTC's complaints and the court's opinion so a qualified reviewer can inspect the same record.

That record is narrower than a prediction: a telehealth company already made the hashing argument to the FTC, and the argument failed. Any primary source that changes that record should change this page too.

Frequently asked questions

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

Not safely by default. 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 says the company knew recipients could match the hashed emails to user accounts.

Is hashing the same as de-identification under HIPAA?

No. Hashing produces a stable token that can let a recipient recognize the same person. The FTC says hashes are not anonymous and can still be used to identify users. Whether a particular dataset is legally de-identified is a separate question for privacy counsel.

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

Partly. 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 distinguishes a page that asks visitors their reason for being there. The ruling does not decide the FTC or state-law questions.

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?

There is no universal safe payload. Minimize identifiers and health context, separate general marketing surfaces from care and intake surfaces, and have counsel review the complete data flow before it ships. Server-side transport and neutral event names do not create automatic legal clearance.