Lead Dedupe Without Patient Identifiers

You deduplicate leads without exposing patient identifiers by generating hashed match keys inside your own infrastructure and resolving identity there, and Curve is the HIPAA-compliant tracking layer built to do that resolution server-side. The rule that governs everything else: identity resolution is your job, never the ad platform's. The moment you upload contact data to a platform to ask whether it recognizes someone, you have made a disclosure, and hashing does not undo it. Deduplication is a normalize, hash, and compare problem, and every step belongs behind your own BAA. Curve includes a signed Business Associate Agreement on every plan.

Duplicates are not an edge case in healthcare marketing. A person researches a treatment on their phone at night, calls the office the next morning, submits a form from a laptop a week later after seeing a retargeting ad, and then books through a third-party scheduling tool. That is one patient and four records. What you do with those four records decides whether your cost per lead means anything.

Duplicates break measurement before they break operations

Intake teams notice duplicates because two coordinators call the same person. That is annoying and it is visible, so it usually gets fixed. The quieter damage is upstream.

If four records become four conversions, your cost per acquisition is a quarter of the truth. Campaigns that generate repeat inquiries from the same shoppers look four times more efficient than campaigns that generate distinct new patients. The ad platform's optimization then follows that signal, because it has no way to know better, and it spends your budget finding more people who inquire repeatedly rather than more people who become patients.

The distortion is worse in service lines with long consideration cycles, which describes most of healthcare. Someone deciding on a surgical procedure will touch your funnel many times. Someone booking a teeth cleaning will touch it once. Left undeduplicated, your reporting will tell you the surgical campaigns are the efficient ones, which is exactly backwards.

The one rule: identity resolution stays inside your perimeter

There is a tempting shortcut here, and it is the thing this article exists to warn against. Ad platforms are very good at identity matching. They offer tools that will take a customer list, match it against their user graph, and tell you a great deal. Used by a retailer, that is ordinary marketing. Used by a healthcare provider on people who inquired about care, it is a disclosure of protected health information to a company that has not signed a BAA and will not sign one for its advertising products.

Hashing does not fix it. A hashed email is still a pointer to a specific human being, which is the entire reason the platforms accept hashes as matching keys. If the context of the upload is "these people contacted our clinic," then the upload communicates health information about identifiable individuals whether the field is hashed or not. Meta and Google do not sign BAAs for advertising products, so there is no path that makes this compliant.

So the design constraint is clean: all matching, merging, and identity decisions happen in systems you control and that are covered by a BAA. What leaves for an ad platform is a neutral conversion event with hashed identifiers used only for click attribution, and it leaves after deduplication, not before.

Building match keys you can actually compare

Deduplication is deterministic matching on normalized values. The hard part is not the comparison, it is the normalization, because the same person submits their details differently every time.

Normalize first, hash second

Hashes amplify inconsistency. "Jane.Smith@Gmail.com " and "jane.smith@gmail.com" are the same person and produce completely different SHA-256 outputs. Normalize before hashing, every time, with the same rules everywhere:

• Email. Trim whitespace, lowercase the whole string. Decide once whether you strip Gmail dots and plus-addressing, and apply that decision consistently, because inconsistency here creates duplicates rather than removing them.
• Phone. Convert to E.164 with the country code, stripping spaces, dashes, parentheses, and leading zeros. Phone is often your best key in healthcare because people give the same number to a form and a call.
• Name. Lowercase, trim, strip punctuation and accents. Names are weak keys on their own and should never be the sole basis for a merge.
• Postal code. Take the first five digits in the United States, since extended codes vary by source.
• Date of birth. Useful in an EHR, but treat it as clinical adjacent and keep it out of any marketing pipeline where you can.

Rank your keys by how much they prove

Not all matches are equally trustworthy. Order them and require a strong key for an automatic merge:

• Bridge token or click ID. The strongest evidence available, because it ties a specific session to a specific downstream action. If a form submission and a booking carry the same token, they are the same journey.
• Normalized email hash. Strong. Shared family addresses exist but are uncommon enough to merge on with a review path.
• Normalized phone hash. Strong, with the caveat of shared household landlines and clinic-provided numbers.
• Name plus postal code. Weak. Suitable for flagging a possible duplicate for a human, never for an automatic merge.
• Device or browser identifiers. Not identity at all, and this is worth being blunt about. A device identifier tells you a browser came back, not that a person did. Households share tablets, waiting rooms have kiosks, and family members use one laptop. Treating a device as a person will silently merge two patients into one record and credit one person's ad click to another person's inquiry.

Salt internal keys, but never the platform ones

This trips people up, so it is worth separating. Match keys you use inside your own systems can and should be salted, so that a leaked hash cannot be reversed with a dictionary of common email addresses. Match keys you send to a platform's conversion API cannot be salted, because the platform hashes its own side with plain SHA-256 and a salted hash will simply never match anything.

These are two different keys derived from the same normalized value, for two different purposes. Keep them separate in your schema so nobody accidentally sends the internal one, and so nobody accidentally stores the platform one as your source of truth.

Deciding what actually counts as a duplicate

Two records with the same email are not automatically one lead. A patient who inquired eight months ago and inquired again yesterday is the same person and two genuine expressions of interest. Merging those hides real demand. Counting them as two new patients overstates it.

The workable model separates the person from the inquiry. Maintain one person record, deduplicated on strong keys, and attach multiple inquiry events to it. Then define a deduplication window for conversion reporting, commonly thirty days, inside which repeat inquiries from the same person roll up to a single countable conversion, and outside which a new inquiry counts fresh.

Two adjacent cases to decide deliberately:

• Same person, different service line. Someone who inquired about one treatment and later about another is one person with two intents. Keep them as one record with two inquiries. Do not encode the service line in anything that leaves for an ad platform.
• Same person, different location. Common in multi-location groups when someone contacts two offices. Merge the person, keep both inquiries, and let the CRM decide ownership. Route deduplication through the group, not through each location separately, or you will never see it.

Deduplicating conversions is a separate job

One clarification prevents a lot of confusion. Person-level deduplication, which this article is about, decides that four records describe one human. Event-level deduplication decides that the same single conversion was reported twice, usually because a browser pixel and a server-side event both fired, and it is handled by sending a shared event ID that the platform collapses on.

You need both, and they solve different problems. Event ID deduplication will not notice that the same person submitted two different forms. Person-level deduplication will not stop one submission from being counted twice by two rails.

How Curve dedupes without exposing identifiers

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare, and identity stitching happens on Curve's US-hosted servers rather than in a browser or an ad platform. That location is the whole point: there is somewhere to resolve identity before anything is forwarded.

Server-side collection. The tracking script installs in place of the Meta Pixel or a raw Google tag, and events go to Curve first. Deduplication therefore happens before forwarding, not after, so what reaches a platform is the deduplicated signal.

Attribution matching on webhook intake. When a CRM, booking tool, or call tracking platform posts an outcome back, Curve matches it to the original session by email, click ID, or bridge token. That is the join that collapses "a form fill on Tuesday" and "a booking on Friday" into one journey. Incoming webhook data cannot override protected core attribution and contact fields, so a noisy upstream system cannot rewrite a record it matched into.

Bridge tokens. When a patient clicks out to a separate booking or intake tool such as IntakeQ, Calendly, or Jane App, a bridge token carries the thread across the handoff. Without it, the booking arrives as an unattributed stranger and becomes a duplicate by default.

SHA-256 hashing to platform specification. Identifiers forwarded for matching are hashed per each platform's conversion API requirements, and only fields you have explicitly mapped for that destination are forwarded at all. The default is that nothing goes.

PHI-pattern detection. Payloads are inspected for PHI-shaped values including MRN-style identifiers, SSNs, dates, and long numeric sequences, and flagged. It is a monitoring layer, not redaction. It is how you learn that someone started passing a patient ID as a match key.

Offline conversion uploads. Deduplicated outcomes from a CRM or EHR can be uploaded in bulk with click ID matching, up to 10,000 rows or 5 MB per file, so the platforms optimize toward real patients rather than raw form fills. For the surrounding setup, see our guides to HIPAA-compliant conversion tracking across Google, Meta, and Microsoft and connecting lead forms to your CRM without PHI.

Setup order

1. Write the normalization rules down and apply them at every entry point. Forms, call tracking, chat, and imports must all normalize identically or they will manufacture duplicates.
2. Generate both key types at intake. A salted internal key for your own matching, and platform-format SHA-256 for forwarding.
3. Capture click IDs and bridge tokens at landing and at every click-out. They are the strongest match keys you will ever have, and they cannot be reconstructed later.
4. Define the merge policy. Which keys auto-merge, which flag for review, and what the reporting deduplication window is.
5. Deduplicate before forwarding, not after. Correcting an inflated conversion count in a platform after the fact is not really possible.
6. Audit merges monthly. Look specifically for over-merging, which is much harder to detect than under-merging and much more damaging.

Frequently asked questions

Can I use a platform's customer list matching to find duplicates?

No. Uploading a list of people who contacted a healthcare provider discloses health information to a vendor without a BAA, and hashing the fields does not change what the upload communicates. Resolve identity inside systems you control.

Is a hashed email safe to store as a match key?

Inside your own environment, yes, and salting it makes it meaningfully safer. Treat it as identifiable data regardless, because it points to one person, and keep it under the same access controls as the raw value.

Should I merge records that share a phone number?

Usually, with a review path. Shared household numbers and workplace lines are real, and merging a spouse into a patient record is a worse outcome than leaving two records open. Auto-merge on strong keys, flag the ambiguous ones.

Does deduplication reduce my conversion volume in the ad platforms?

Reported volume will drop, because the earlier number was counting the same people more than once. Accuracy improves, and so does optimization, because the platform stops chasing repeat inquirers. Sending real downstream outcomes matters far more than raw event count.

How does this relate to event ID deduplication in Meta CAPI?

They are different layers. Event IDs stop one conversion from being counted twice when a browser and a server both report it. Person-level deduplication stops one human from being counted four times across four separate inquiries. Implement both.

Can I dedupe using a device or visitor identifier?

Not as identity. A device identifier proves a browser returned, not that a person did, and shared devices are common. Using one as a person key merges strangers and misattributes clicks. Use it for session continuity only.

How do I find duplicates that already exist?

Run the normalization rules retroactively over your CRM export and count collisions on strong keys, in your own environment. Do not send that export anywhere to be matched. Our free compliance scanner is a separate check, for what is loading on your site.

Where to start

Fix normalization first. Most duplicate problems are not clever identity puzzles, they are a lowercase that never happened and a phone number stored five different ways. Once values are consistent, deterministic matching on strong keys handles the large majority of cases, and the remainder should go to a human rather than to an algorithm that will confidently merge two different patients.

Curve does that resolution server-side, before anything is forwarded, using click IDs, bridge tokens, and hashed identifiers you control. Per-destination field mapping means nothing reaches a platform unless you mapped it, and a signed BAA comes with every plan. See how server-side enhanced conversions are set up without PHI leakage, or visit curvecompliance.com to review your current matching logic.

Reviewed August 2026. Ad platform conversion APIs and healthcare advertising policies change frequently. Verify field-level requirements against current platform documentation before implementation.