Connect Lead Forms to Your CRM Without PHI

You can connect website lead forms and Facebook Lead Ads to a patient CRM without sending protected health information to any ad platform, and Curve is the HIPAA-compliant tracking layer built to do it. The method is to stop treating the lead form as a pixel event and start treating it as a server-side handoff: the form posts to infrastructure you control, Curve hashes a small set of non-clinical identifiers, and only a mapped conversion signal continues to Meta, Google, or Microsoft. The patient's name, phone number, message, and clinical answers never reach an ad platform. The ad platform receives proof that a lead happened, which is all it needs to optimize. Curve includes a signed Business Associate Agreement on every plan.

Most healthcare marketing teams get this wrong in the same place. They install a lead form, connect it to a CRM with a native integration, and then add a conversion pixel on the thank-you page. Each of those three steps is reasonable. Together they create a path where form field values, page URLs containing service names, and browser identifiers reach a vendor that has not signed a Business Associate Agreement. That is the disclosure that pixel lawsuits are built on.

What actually counts as PHI in a lead form

The confusion usually starts here, because marketers apply an intuition that does not match the rule. PHI is not only a diagnosis. Under HIPAA, individually identifiable health information is any information that relates to a person's health condition, care, or payment for care, and that identifies the person or could reasonably be used to identify them.

A lead form that asks for a name and an email address is not automatically PHI. The same form becomes PHI the moment it is tied to a health context. That context is almost always present in healthcare advertising, and it usually arrives through one of these channels:

• The form's own fields. Reason for visit, symptom description, medication currently taken, insurance carrier, preferred provider, procedure of interest.
• The page the form sits on. A submission from a page about a specific treatment carries the condition in its URL and title, even when the form asks nothing clinical.
• The campaign that delivered the visitor. UTM parameters and ad names frequently contain the service line, which is the same signal in a different wrapper.
• The routing destination. Sending a lead to a provider-specific inbox or a condition-specific pipeline stage encodes the condition in the routing itself.

This is why "we do not collect any health information on the form" is rarely a complete defense. If a person submits an interest form on a page about a particular treatment, the combination of their identity and that page is health information about them, whatever the form fields say.

What ad platforms actually need

Here is the part that makes compliant routing possible, and the assumption Curve is built on. Meta, Google, Microsoft, and TikTok do not need to know why the lead is valuable. They need to know three things: that a conversion happened, roughly when, and which ad click it belongs to.

Attribution is a matching problem, not a content problem. The platforms match conversions to clicks using identifiers they issued themselves, primarily click IDs such as fbclid, gclid, msclkid, and li_fat_id, plus hashed contact fields as a fallback when the click ID is missing. None of those matching keys require clinical content. A conversion payload can be complete and useful while containing nothing about the patient's condition.

Once you internalize that, the design becomes obvious. The CRM gets the full lead because the CRM is where care coordination happens and, in a properly papered stack, the CRM vendor has signed a BAA. The ad platform gets a hashed identifier and an event name. Two destinations, two very different payloads, from one form submission.

The three-lane pattern

Every compliant lead routing setup we have seen resolves into the same three lanes, and Curve is designed to run all three from one event. Draw these before you configure anything.

Lane one: the full lead goes to the CRM

The form posts to your server or to a form handler you control, and the complete submission is written to the CRM. This lane carries everything: name, contact details, free-text message, clinical answers, source page, campaign. It is the record of care interest, and it needs to be complete for the intake team to do their job.

The compliance requirement in this lane is contractual rather than technical. Your CRM, your form vendor, your automation middleware, and your hosting all touch this data, so each one needs a signed BAA. This is where a lot of stacks quietly fail. Teams check the CRM and forget the form builder or the automation tool sitting between them. If you are evaluating those tools, we have written separately on whether HubSpot is HIPAA compliant for clinic marketing and on where Zapier sits in a healthcare automation chain.

Lane two: a mapped conversion goes to the ad platforms

The same submission triggers a server-side conversion event. This lane is deliberately thin. It carries the event name, a timestamp, the click ID captured when the visitor first arrived, and hashed versions of the identifiers each platform's conversion API expects. It carries no free text, no clinical fields, and no descriptive event name that reveals the service line.

That last point deserves emphasis, because it is the most common leak in otherwise careful setups. An event named fertility_consult_request discloses a condition in the event name itself, and it sits in the ad platform's interface forever. Neutral aliases exist for exactly this reason. The intake team can call it whatever they need in the CRM; the ad platform sees a neutral label.

Lane three: outcomes come back later

A lead is not a patient. The event that matters commercially happens days or weeks later, when the lead books, shows up, or starts treatment. That outcome lives in the CRM, not on your website, so it has to travel back into the measurement layer through a server-side path rather than a browser one.

This is what separates a stack that optimizes well from one that merely records form fills. If you only send form submissions, the ad platforms optimize toward people who fill in forms, which is not the same population as people who become patients.

Which fields can travel to an ad platform

A practical rule: a field may go to an ad platform only if it is an identifier the platform uses for matching, it is hashed before it leaves your infrastructure where the platform's API expects hashing, and it carries no clinical meaning on its own.

Generally safe to send, hashed, as matching keys:

• Email address
• Phone number, normalized to E.164 before hashing
• First and last name
• City, state, postal code, country
• Click IDs captured at landing, passed through unhashed because the platform issued them

Never send to an ad platform:

• Reason for visit, symptoms, diagnosis, medications, insurance details
• Free-text message or notes fields, which are unbounded and frequently contain clinical detail
• Full page URLs or referrers that name a condition or treatment
• Appointment type, provider name, department, or pipeline stage that implies a condition
• Medical record numbers or any internal patient identifier
• Descriptive event names that encode the service line

The unbounded fields are the ones that bite. A message box is a blank cheque written by the patient, and patients write remarkably specific things in them. There is no reliable way to sanitize free text at scale, so the correct handling is to exclude it from the conversion lane entirely rather than attempt to clean it.

How Curve implements this

Curve is HIPAA-compliant ad tracking, attribution, and analytics built for healthcare, and lead routing is one of the flows it was designed around. The tracking script installs on your site in place of the Meta Pixel or a raw Google tag. Events go to Curve's US-hosted servers rather than directly to ad platforms, which is the structural change that makes everything else possible: there is a place to make decisions before data leaves.

Three mechanisms do the work in this particular flow.

Field mapping. Only fields you explicitly map are forwarded to a given destination, and mapping is configured per destination. Identifiers are SHA-256 hashed to match each platform's conversion API requirements. Anything unmapped stays put. This is a deliberate default: the safe behavior is what happens when nobody configures anything.

PHI-pattern detection. Curve inspects payloads for PHI-shaped values such as SSNs, MRN-style identifiers, dates, and long numeric sequences, and flags them. This is a monitoring layer, not the protection itself. The protection is the field mapping above. Detection tells you when a form has started sending something it should not, which is usually how you find out that someone added a field to a form three weeks ago.

Incoming webhooks with attribution matching. Your CRM, booking tool, or call tracking platform posts outcome events back to Curve, and Curve matches them to the original session by email, click ID, or bridge token. Bridge tokens exist for the case where the patient leaves your website entirely for a separate booking or intake experience, which otherwise breaks the attribution chain at exactly the moment it becomes valuable. Incoming webhook data cannot override protected core attribution and contact fields, so a misconfigured upstream system cannot corrupt the record.

Curve forwards clean conversions server-side to Meta CAPI, Google Ads Enhanced Conversions, TikTok Events API, Microsoft, LinkedIn, and others. A BAA is included on every plan. For the wider setup around this flow, see our guide to HIPAA-compliant conversion tracking setup across Google, Meta, and Microsoft.

Facebook Lead Ads are a different problem

Native Lead Ads deserve their own treatment, because the form lives on Meta's infrastructure rather than yours. The patient never reaches your site, so there is no point at which you can intercept the submission before Meta sees it.

This changes what you control. You cannot filter what Meta receives, so the only lever is what you ask. Every question on a native Lead Ad form is a question whose answer Meta will hold. That makes qualifying questions about symptoms, conditions, or treatments a disclosure by design, no matter how the downstream routing is built.

Two workable approaches. Keep the native form strictly non-clinical, collecting contact details only, and do all qualification after the lead lands in your CRM. Or use a click-to-website objective so the form sits on infrastructure you control and the three-lane pattern applies normally. We go deeper on the field-level choices in our guide to PHI-safe Facebook Lead Ads form configuration.

Setup order that avoids rework

1. Inventory every form and every field. Include forms nobody remembers owning. Mark each field as identifier, operational, or clinical.
2. Confirm BAA coverage across lane one. Form builder, CRM, automation middleware, hosting, and any inbox that receives submissions.
3. Capture click IDs at landing. Attribution is impossible to reconstruct later if the click ID was never stored in the first place.
4. Define neutral event names before building anything. Renaming events after they are live means losing history in the ad platforms.
5. Map the conversion lane explicitly. List the fields that may travel per destination. Everything else is excluded by default.
6. Wire outcome webhooks from the CRM. Booked, attended, and started treatment matter more than submitted.
7. Verify what left, not what you configured. Inspect the actual outbound payload. A configuration screen is a statement of intent; the payload is the fact.

Step seven is the one teams skip, and the one that catches real problems. Repeat it whenever anyone edits a form.

Frequently asked questions

Can I send a hashed email to Meta if the person filled out a form about a specific condition?

Hashing protects the identifier in transit, but it does not change what the disclosure means. If the event itself communicates that this person enquired about a specific condition, you have disclosed health information about an identifiable person, because Meta can match that hash to a known user. Keep the event neutral and the concern mostly resolves.

Does a BAA with my CRM cover the ad platform too?

No. A BAA covers only the party that signed it. Meta and Google do not sign BAAs for their advertising products, which is precisely why the conversion lane has to be stripped down rather than papered over.

What if my form only asks for name, email, and phone?

Then the form fields are fine, and your attention should move to the page it sits on and the campaign that delivered the visitor. A contact-only form on a treatment-specific landing page still produces a health-context disclosure if the page URL travels with the event.

Will removing data from the conversion payload hurt ad performance?

In practice server-side conversions with click ID matching usually improve measured performance rather than degrade it, because they are not affected by ad blockers, tracking prevention, or cookie expiry the way browser pixels are. The clinical fields you remove were never used for optimization. What matters is match rate and outcome quality, and both improve when you send real downstream outcomes instead of raw form fills.

How do I handle a free-text message field?

Route it to the CRM and exclude it from the conversion lane entirely. Do not attempt to sanitize it. Free text cannot be reliably cleaned at scale, and a single missed pattern is a disclosure.

What about leads that arrive by phone instead of a form?

Same three lanes, different entry point. Call tracking platforms post outcomes back through a webhook and match on click ID or bridge token. The rule is unchanged: call recordings and transcripts stay in systems covered by a BAA, and only the neutral conversion signal continues onward.

How do I know whether my current setup is leaking?

Open your site with the browser network tab filtered to your ad platform domains and submit a test lead. Look at what is actually in the outbound requests, including the page URL and any custom parameters. Our free compliance scanner will also flag risky tracking on any healthcare site.

Where to start

If you take one thing from this: the ad platform and the CRM need different payloads from the same event, and almost every leak comes from sending one payload to both. Separate the lanes, keep clinical content in the lane that has a BAA behind it, and send the ad platforms a neutral, hashed, matched signal.

Curve was built to make that separation the default rather than a configuration you have to remember. Server-side collection, per-destination field mapping, PHI-pattern monitoring, and webhook attribution matching are the pieces, and a signed BAA comes with every plan. See how lead routing works from ad click to CRM, or visit curvecompliance.com to talk through your current setup.

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