Meta Custom Audiences for Healthcare: What HIPAA Actually Allows

In July 2023, the FTC finalized its order against BetterHelp for sharing sensitive health data with advertising platforms. One of the specific practices the FTC cited: BetterHelp had used the fact that users had previously been in therapy to build Facebook lookalike audiences. The company uploaded user data to Meta, and Meta's algorithms used that data to find people who resembled BetterHelp's patients. The audience itself became a disclosure of health information, because the seed list was composed entirely of people who had sought mental health treatment. Source

BetterHelp's case raises a question that most healthcare marketing teams have not confronted: when you upload a customer list to Meta to create a Custom Audience, what are you actually sharing? And does HIPAA allow it?

The answer is more nuanced than a blanket yes or no. It depends on what data is in the list, where the list came from, how it is transmitted, and whether the people on it consented to that specific use. Most healthcare organizations using Custom Audiences today are on the wrong side of at least one of those factors.

How Meta Custom Audiences Work Under the Hood

Understanding the compliance implications requires understanding the mechanics. Meta offers three types of Custom Audiences, and each creates a different data flow.

Customer List Custom Audiences. The advertiser uploads a file containing customer data (email addresses, phone numbers, names, dates of birth, or other identifiers). Meta hashes these identifiers (if not already hashed) and matches them against its user database. Matched users become a targetable audience. The original uploaded data is deleted after matching, according to Meta's documentation.

Website Custom Audiences. Meta Pixel or Conversion API tracks visitors to specific pages on your website. You create an audience of people who visited certain pages within a time window. The audience is built from behavioral data Meta has already collected through its tracking infrastructure.

Engagement Custom Audiences. You create an audience of people who engaged with your content on Meta's platforms: watched a video, interacted with a lead form, or visited your Facebook Page. This data stays entirely within Meta's ecosystem.

Lookalike Audiences. Based on any Custom Audience, Meta can create a Lookalike Audience: a new audience of people who share characteristics with the source audience but are not in it. The algorithm identifies patterns in the source audience and finds similar users across Meta's platform.

Each type creates a distinct compliance exposure. Customer List uploads transmit data to Meta. Website audiences depend on what tracking infrastructure is in place. Engagement audiences involve no data transmission from your systems. Lookalike audiences inherit the compliance status of their source audience.

The Customer List Problem: When Hashing Is Not Enough

Healthcare marketing teams often believe that hashing patient data before uploading it to Meta provides adequate privacy protection. This belief is incorrect for two reasons.

Hashing is not anonymization. A SHA-256 hash of an email address always produces the same output for the same input. Meta hashes its own user database using the same algorithm and matches your hashes against theirs. The hash is a lookup key, not a privacy mechanism. If Meta can match the hash to a specific Facebook user (which is the entire point of the feature), the data is identified, not anonymized.

The source of the data determines its status under HIPAA. If your customer list was exported from an EHR, practice management system, CRM, or any system that manages patient relationships, the people on that list are patients. Transmitting patient identifiers to Meta, even hashed, constitutes a disclosure of PHI to a third party. Meta is not a Business Associate. Meta does not sign BAAs. There is no contractual framework under which this disclosure is permissible under HIPAA.

This is true even if the list contains only email addresses and no clinical data. HIPAA defines PHI as individually identifiable health information. The fact that a person is a patient of your healthcare organization is health information. Their email address, when held by you as a covered entity, is linked to their patient status. Uploading it to Meta discloses the patient relationship to a third party without a BAA.

GoodRx ($1.5M FTC + $25M class action, 2023) configured tracking pixels that shared health conditions and personal identifiers with Facebook, Google, and other ad platforms. GoodRx used health data for targeted advertising without consent. Source While the GoodRx case centered on pixel data rather than customer list uploads, the underlying principle is the same: transmitting patient-linked identifiers to ad platforms without consent and without a BAA creates enforcement exposure.

Website Custom Audiences: The Pixel Dependency

Website Custom Audiences are built from data Meta Pixel collects from your website. If a visitor views your "Joint Replacement" page, and Meta Pixel is installed on that page, Meta knows that the visitor (identified through their Facebook login, browser cookies, or device signals) visited a health-specific page.

Creating a Website Custom Audience of "People who visited /services/joint-replacement in the last 30 days" means Meta holds a list of identified individuals associated with a specific medical interest. This is PHI held by a third party without a BAA.

The compliance issue is not in the audience creation step. It is in the data collection step. If Meta Pixel is on your healthcare website, Meta has already collected the health-contextualized browsing data. Creating a Website Custom Audience simply organizes data Meta already possesses.

Removing Meta Pixel and implementing server-side Conversion API through a healthcare CDP addresses the root cause. When your server sends conversion events to Meta without page URLs containing treatment information, Meta does not have the health context needed to associate users with specific medical interests. Website Custom Audiences built from clean CAPI data contain people who converted on your site, but Meta does not know what health service prompted the conversion.

What HIPAA Actually Permits for Audience Building

HIPAA does not categorically prohibit healthcare organizations from using Meta's advertising platform. It establishes conditions under which patient data can be used for marketing purposes.

Individual authorization. HIPAA allows the use of PHI for marketing when the patient provides individual written authorization. This authorization must describe the marketing use specifically, identify that PHI will be shared with a third party, and explain any financial remuneration the covered entity receives. A general privacy notice or website terms of service does not constitute valid HIPAA authorization.

In practice, obtaining individual HIPAA authorization from every patient before uploading their data to Meta is operationally impractical for most organizations. The authorization requirement was not designed for bulk advertising audiences.

Non-patient data. If your list comes from a source that does not involve patient relationships, it may fall outside HIPAA's scope. Website visitors who filled out a general marketing interest form (not a patient intake form) and who are not existing patients may not be patients under HIPAA. However, the line between "marketing lead" and "patient" is often blurry, and organizations tend to store both in the same systems.

Consented, context-stripped audiences. The compliant path for most healthcare organizations is to build audiences through server-side infrastructure that collects consent for marketing data sharing and strips health context before any data reaches Meta. This approach does not use patient lists from clinical systems. It uses behavioral data from consented website visitors, processed through a healthcare CDP that removes treatment and condition information before transmission.

Building Audiences the Compliant Way

A compliant audience strategy for healthcare uses server-side infrastructure to create optimization signals for Meta without disclosing patient health information.

Step 1: Collect consent for marketing data use. Before any visitor's data can flow to Meta, they must consent to marketing data sharing. This consent must be verified server-side, not through a client-side JavaScript cookie banner that can fail to load or be bypassed.

Step 2: Route behavioral data through your healthcare CDP. The CDP receives conversion events from your website. It strips health context: generic event names replace treatment-specific ones, domain-level URLs replace page-specific ones, and form field data is excluded entirely.

Step 3: Send clean signals to Meta via CAPI. Your CDP sends conversion events to Meta containing a click ID, a hashed email (if consented), a generic event name, and a conversion value. Meta receives enough data to optimize campaigns and build broad audience segments without receiving information about what health services individual users explored.

Step 4: Build audiences from CAPI data, not patient lists. Use Meta's audience tools to create audiences based on the conversion events your server sends. These audiences represent "people who converted on your website" rather than "patients who received specific treatments." The health context that would make these audiences PHI has been removed before the data reaches Meta.

Step 5: Use broad Lookalike Audiences cautiously. Lookalike Audiences built from clean CAPI conversion data are lower risk than those built from patient lists, because the seed audience does not contain health context. However, monitor how Meta uses these audiences and review targeting performance for unexpected patterns.

Consent as the Differentiator

The regulatory landscape is moving toward consent as the primary control mechanism for marketing data use. State privacy laws in California, Colorado, Connecticut, Virginia, and others establish consent requirements for the sale or sharing of personal information with third parties. These requirements apply alongside HIPAA, not instead of it.

Healthcare organizations that build consent into their audience infrastructure now are positioned for this evolving landscape. Server-side consent gating, where data flows to no destination until consent is verified at the infrastructure level, addresses HIPAA authorization requirements, state privacy consent requirements, and Meta's own data use policies simultaneously. This is where healthcare compliance is heading: consent as an architectural layer, not a checkbox.

FAQ

Can I upload my patient email list to Meta for a Custom Audience?

Uploading patient email addresses to Meta transmits PHI to a third party without a BAA. Meta does not sign BAAs and is not a Business Associate under HIPAA. Even though Meta hashes the data during matching and deletes the upload file afterward, the transmission itself constitutes a disclosure. Unless you have obtained individual HIPAA-compliant written authorization from each patient specifically for this marketing use, uploading patient lists to Meta creates compliance exposure.

Is hashing patient data before upload enough for HIPAA compliance?

No. Hashing is a matching mechanism, not a privacy protection. Meta hashes its own user database and matches your hashes against theirs. If a match occurs, the individual is identified. The hash function is deterministic: the same input always produces the same output. HIPAA does not recognize hashing as a method that renders data no longer individually identifiable.

What about using a "clean room" for audience matching?

Data clean rooms offer a more controlled matching environment than direct list uploads, but they do not automatically resolve HIPAA concerns. The core question remains: does patient data leave your infrastructure and reach a third party without a BAA? If the clean room is operated by Meta or another entity that does not sign a BAA, the disclosure issue persists. Evaluate any clean room solution against the same criteria: BAA coverage, data minimization, consent verification, and audit trails.

Can I create a Lookalike Audience from my existing patients?

A Lookalike Audience based on a patient list inherits the compliance issues of the source audience. If the source Custom Audience was created by uploading patient data without HIPAA authorization, the Lookalike Audience is built on an impermissible disclosure. The compliant alternative is to build Lookalike Audiences from consented, context-stripped conversion data sent through server-side CAPI.

How do I reach potential patients on Meta without using patient data?

Use broad demographic and geographic targeting combined with compelling creative rather than audience matching based on patient lists. Optimize campaigns toward clean conversion events sent through server-side CAPI. Meta's algorithms can find high-intent users through broad targeting and conversion optimization without receiving health data about your existing patients. The performance may be slightly different from patient-list-based targeting, but the approach is sustainable under current and evolving regulatory requirements.

Meta Custom Audiences are a powerful advertising tool, but the standard playbook for building them conflicts with healthcare compliance requirements at a fundamental level. If your organization is evaluating how to use Meta's audience tools while protecting patient data, Ours Privacy provides the server-side infrastructure, consent management, and audience building capabilities that keep PHI out of Meta's systems while preserving campaign performance.

Related reading:

• Meta Conversion API for Healthcare: Step-by-Step Server-Side Implementation

• Meta Ads for Healthcare: Navigating the Restricted Category Minefield

• Building Healthcare Audiences Without Violating HIPAA

• HIPAA-Compliant Tools