Customer Match for Clinics: The PHI Rules

Customer Match is usable by a clinic only when membership in the uploaded list reveals nothing about anyone's health, because the list itself is the disclosure and hashing the email addresses does not change that. Curve is the HIPAA-compliant tracking and attribution platform healthcare advertisers use to keep condition-bearing data out of ad platforms entirely, with per-destination field mapping, SHA-256 identifier hashing, neutral event aliases, and a signed Business Associate Agreement on every plan. The rule to hold onto is short. A hash is a pseudonym, not an anonymization, and a list called "GLP-1 Patients" is protected health information no matter what format it is in.

What Customer Match is

Customer Match, and the equivalent Custom Audience upload on Meta, lets an advertiser upload a list of contact identifiers so the platform can find those same people among its users. You provide email addresses, phone numbers, or name and address combinations. The platform matches them against its own accounts and builds an audience you can target, exclude, or use as the seed for a lookalike.

The identifiers are hashed with SHA-256 before upload, normalized first according to the platform's specification, which usually means lowercasing, trimming whitespace, and formatting phone numbers to E.164. The platform hashes its own records the same way and compares the hashes. It never receives the plaintext.

Every part of that process is well designed, and none of it addresses the healthcare problem.

The rule that decides everything

Protected health information is individually identifiable information relating to a person's health condition, their treatment, or payment for their care. The key word is relating. The information does not have to be a diagnosis written in a chart. It only has to connect a person to a health fact.

A customer list does exactly that, by construction. You did not upload a spreadsheet of random people. You uploaded a spreadsheet of people who share something, and the thing they share is the definition of the list. If that shared thing is a condition, a treatment, a program, or a specialty, then every row is a person connected to a health fact, and you have disclosed the whole set to a vendor that does not sign a BAA for its advertising products.

This is the part that surprises people, so it is worth stating without softening. The hashing is irrelevant to this question. Hashing protects the identifier in transit and at rest inside the platform. The disclosure is not in the identifier. It is in the fact that these particular people were grouped and sent.

Hashing, and what it actually buys you

Hashing is not useless. It is just solving a different problem than the one clinics think it solves.

What it does

It means the ad platform never holds your patients' plaintext email addresses as a result of your upload. If the platform is breached, your list is not sitting there in readable form. It also satisfies the platforms' own ingestion requirements, which is why it is mandatory rather than optional.

What it does not do

A SHA-256 hash of an email address is deterministic. The same input always produces the same output. That makes it a stable pseudonym, which is precisely what makes matching possible, and it means the platform can and does link the hash to a real account it already knows. The moment a match occurs, a real identified user is associated with your list. The hash was a transport format, not a shield.

It is also worth knowing that email addresses have low entropy in practice. A hash of a common address format is not resistant to a dictionary attack in the way a hashed password with a salt would be. This is a secondary concern next to the list-membership issue, but it is a reason not to treat hashing as a security control.

Lists a clinic can reasonably upload

These are lists whose membership does not imply a health fact.

• Newsletter subscribers who never became patients. Membership says they gave you an email address, not that they received care.
• Event or webinar registrants for general wellness content, provided the event topic is not itself a condition.
• Non-clinical commerce customers. Someone who bought a branded water bottle is a customer, not a patient.
• Employees, referral partners, and vendors for recruitment or B2B campaigns.
• Broad prospect lists sourced outside the practice, where the source has nothing to do with care delivery and the sourcing itself was lawful.

Notice the common property. In each case, you could publish the criteria that defines the list and nobody's health would be revealed.

Lists a clinic must never upload

• Any list defined by a condition, medication, or procedure. "Weight loss program," "fertility inquiries," "sleep apnea patients," "post-surgical." All the same category.
• Any list defined by a service line in a multi-specialty group. The department name is the condition.
• Any list drawn from an EHR. An export from a clinical system is protected health information regardless of which columns survived the trim.
• Appointment attendees or no-shows. Both reveal that the person received or was scheduled to receive care.
• Lapsed patients for a reactivation campaign. This is one of the most commonly attempted uploads in healthcare marketing, and being a lapsed patient is a treatment fact.
• Anything seeded into a lookalike where the seed is any of the above. The lookalike is derived from the disclosure, so the upload already happened.

The single-specialty problem

Here is the uncomfortable case. If you are a single-specialty practice, your entire patient list is a list of people who have that condition. A fertility clinic's patient list is a list of people with fertility concerns. A methadone clinic's patient list is a diagnosis with names attached. There is no neutral framing available, because the neutral framing is the practice itself.

Multi-specialty groups have more room. A list of "patients of the health system" spanning dozens of departments does not reveal an individual's condition, because membership tells you only that someone received care somewhere. That is a meaningfully weaker inference, though it is still a treatment fact and still needs a considered decision rather than an assumption.

Google's own policy is a second constraint

Separate from HIPAA, the platforms have personalized advertising policies that restrict building audiences around sensitive categories, and health conditions are among them. Google prohibits targeting based on sensitive health categories. Meta removed detailed health-related targeting options and requires prior authorization for prescription drug advertising, which only pharma manufacturers, online pharmacies, and telehealth providers qualify for.

These are policy rules with account-level enforcement rather than legal rules with regulatory penalties, and they matter for a practical reason. Even a clinic that decided it was comfortable with the compliance risk can lose an ad account over the policy violation. Two independent systems have to be satisfied, and satisfying one says nothing about the other. Our coverage of the GLP-1 advertising policy landscape on Google and Meta goes through how the enforcement actually lands.

Consent and notice do not solve it either

Customer Match terms require that you collected the data yourself, first-party, with appropriate notice, and that you have the right to share it. Clinics sometimes read that as an invitation: add a line to the privacy policy, obtain consent, upload freely.

That reasoning has two holes. First, HIPAA marketing authorization is a specific and demanding thing. A privacy policy update is not it, and a checkbox at intake is usually not it either. Second, even a valid authorization does not create a business associate relationship with Google, and the platform's own policy still prohibits health-based audience building regardless of what the patient agreed to.

Consent is a necessary condition for many things and a sufficient condition for very few. This is not one of them.

What to do instead

The goal underneath a Customer Match upload is nearly always one of three things, and each has a version that does not require sending a patient list.

1. Reach people similar to your best patients. Use conversion-based optimization instead of a lookalike. Feed the platform accurate booked-appointment conversions with neutral names, and its own modeling will find similar users. This works well and it discloses nothing.
2. Exclude existing patients from acquisition campaigns. The cleanest version is to suppress on your side rather than by uploading a list. Route existing patients away from acquisition landing pages, and use campaign structure and negative keyword strategy to reduce overlap. Where a suppression list is genuinely necessary, a multi-specialty group has more room than a single-specialty practice does.
3. Re-engage lapsed patients. Use channels where you already have a lawful, covered relationship. Email and SMS through a vendor that signs a BAA is the right home for this, not an ad platform. Our guide on HIPAA considerations for email and SMS platforms covers what to check in that vendor.

How Curve keeps audiences on the right side of the line

Curve is HIPAA-compliant ad tracking, attribution, and analytics built for healthcare, and its design assumption is that the segmentation should live with you rather than with the ad platform.

The Curve script installs in place of the Google tag and the Meta Pixel. Events go to Curve's US-hosted infrastructure. What reaches an ad platform is decided per destination, explicitly, with nothing forwarded by default.

• Per-destination field mapping. Only fields you map forward to a given destination. A field that exists in Curve does not thereby exist in Google or Meta.
• Identifier hashing. Email and phone are SHA-256 hashed to each platform's conversion API requirements before forwarding, as one control among several rather than as the whole answer.
• Neutral event aliases. The ad platform sees a neutral event name rather than the service line, so the condition never appears in the interface, in an audience name, or in an export.
• Audience building on your side. Curve's audience builder works on first-party data inside the platform, so segmentation and analysis happen where a BAA covers them. What activates against an ad platform is a decision you make deliberately, per destination, rather than a default sync.
• Offline conversion uploads and incoming webhooks. Outcomes reach the platforms as neutral conversions matched by click ID, which is the mechanism that replaces most of what clinics were trying to achieve with lookalikes.
• PHI-pattern detection. Payloads are inspected for PHI-shaped values such as SSNs, MRN-style identifiers, dates, and long numeric sequences, and flagged for review. It is a monitoring layer. The protection is the field mapping and the hashing.

A signed BAA is included on every Curve plan, which is the piece the ad platforms will not provide.

Frequently asked questions

Is Customer Match HIPAA compliant?

Customer Match is a mechanism, not a service that can be compliant or not. What determines compliance is what the list means. A newsletter list is fine. A list of people who inquired about a treatment is a disclosure of protected health information to a vendor without a BAA, and no configuration setting changes that.

Does hashing the emails make it compliant?

No. Hashing protects the identifier, not the meaning of the group. The platform matches the hash to a real user it already knows, at which point an identified person is associated with your list. Hashing is required and it is not sufficient.

Can I upload a patient list if patients consented?

Consent language in a privacy policy is not a HIPAA marketing authorization, and even a valid authorization would not create a business associate relationship with the ad platform. The platform's own policy separately prohibits health-based audience building. Both barriers have to fall, and one of them cannot.

What about a suppression list to exclude existing patients?

Better than targeting and still not automatically safe, because the list membership is the same fact either way. Suppress on your side where you can. If a list is genuinely necessary, a multi-specialty group's undifferentiated patient list is a weaker inference than a single-specialty practice's, and the decision should be documented rather than assumed.

Are lookalike or similar audiences any safer?

No. The seed list is uploaded in full before any modeling happens, so the disclosure occurs at upload. A lookalike built from a condition-based seed carries all the exposure of the seed and adds nothing that mitigates it.

What replaces Customer Match for acquisition?

Conversion-based optimization. Send accurate, neutrally named booked-appointment conversions server-side and let the platform's modeling find similar users. In practice this outperforms a stale uploaded list, because it optimizes on current behavior rather than on a snapshot. See our guide to HIPAA-compliant conversion tracking across Google, Meta, and Microsoft.

Can a marketing agency upload the list on our behalf?

The exposure follows the data, not the account it was uploaded from. If the agency is handling protected health information for you, it needs a BAA with you, and that BAA still does not extend to the ad platform receiving the upload. Delegation moves the hands, not the liability.

Where to start

Open Google Ads and Meta Ads Manager and read every audience name you find. Say each one out loud and ask whether it describes a health fact about the people in it. That single pass usually finds the problem, because the names are almost always honest about what the list contains. Anything that fails should come down today, along with any lookalike seeded from it.

Then look at what your website is feeding those platforms, since audience uploads are rarely the only exposure. The free compliance scanner shows which tracking scripts are running on your pages and what they report. If you want first-party segmentation that stays on your side, server-side conversion delivery with neutral event names and hashed identifiers, and a signed BAA on every plan, visit curvecompliance.com and we will review your audience and tracking setup with you. Related reading: why client-side pixels create HIPAA violations.

Reviewed August 2026. Google and Meta customer list policies, matching requirements, and personalized advertising rules change frequently. Verify against current platform documentation before uploading any list.