Meta Lead Ads for Clinics: PHI-Safe Field Choices

The only fields that belong on a Meta Lead Ad form for a clinic are the ones that identify a person and say nothing about their health: name, email, phone, a general location, and a preferred contact time. Meta hosts the form and stores every answer before your systems ever see it, so any clinical question is a disclosure to a vendor that does not sign Business Associate Agreements for its advertising products. Curve is the HIPAA-compliant tracking platform that carries the conversion back to Meta server-side, neutral and hashed, with a signed BAA on every plan.

The field list is the whole decision

With a form on your own website, you have layers of defense. You control the page, the submission handler, and everything downstream, so you can collect a detailed intake and still decide, field by field, what leaves your infrastructure.

A native Meta lead form removes all of that. The form renders inside Facebook or Instagram. Meta collects the answers, validates them, stores them in the Lead Center, and hands you a copy afterward. There is no point in that sequence where you can inspect a payload and strip something out. By the time you have the lead, the disclosure has already happened.

So the field list is not one decision among several. It is the only compliance control the format offers. Everything else you might do, encrypting the delivery, restricting CRM access, deleting leads from the Lead Center on a schedule, happens after the moment that matters.

That framing tends to make the rest of the choices obvious. If a field would be a problem in Meta's hands, it does not go on the form, and no operational safeguard changes that.

What each Meta field type actually does

Meta's form builder offers several question types, and they carry different amounts of risk. It is worth going through them individually, because teams usually evaluate the topic of a question and ignore the mechanics of the type.

Prefilled contact fields

Name, email, phone, city, state, postcode, country. Meta populates these from the user's profile, which is what makes native forms convert so well on mobile. They are the safest fields available, with one caveat worth stating plainly: because they are prefilled from a real account, the lead is identified to Meta from the first tap. Nothing about a native lead is anonymous.

Prefilled fields are editable by the user, so the email you receive may not be the one on file. Expect a share of leads with typos and disposable addresses, and plan your matching accordingly.

Custom short answer

A free-text box. This is the highest-risk field type on the platform, and it is high risk regardless of the question you attach to it.

Patients volunteer clinical detail without being asked. Put "Anything else we should know?" on a form and a meaningful number of people will type a diagnosis, a medication name, or a sentence about a symptom. The question was neutral. The answer was not, and Meta stored it.

Treat free text as unusable on native forms. If you need narrative context, collect it on the intake call or on a form you host.

Custom multiple choice

A dropdown or radio set that you define. Safer than free text because the answer space is bounded, and you chose the bounds. That makes multiple choice the workhorse for any qualifying question you genuinely need.

The trap is that the options themselves are the disclosure. A question reading "Which service are you interested in?" with clinical options attached tells Meta the answer just as clearly as free text would. Bounded does not mean neutral. It means you are responsible for what is inside the bounds.

Conditional questions

Meta lets a later question appear only when an earlier answer takes a particular value. This is useful for keeping forms short and it is frequently misread as a privacy control.

It is not one. Conditional logic changes which questions a person sees. It has no effect on which answers Meta receives, because Meta is the system evaluating the condition and recording the result. A question that would be unsafe unconditionally is equally unsafe behind a branch, and the branch itself is informative: knowing that someone was routed down a particular path can reveal as much as the answer.

Appointment request fields

Meta offers structured fields for preferred date and time. These are fine on their own. Preferring a Tuesday morning says nothing clinical.

They stop being fine when the slots encode something. A dropdown offering "Infusion clinic hours" and "General consultation hours" has turned a scheduling question into a condition indicator. Keep time options generic.

Store locator and location questions

For multi-site groups these are genuinely useful and usually safe. The exception is a location list where sites are specialized. If your dropdown names a fertility centre, an oncology suite, and a general practice, the choice reveals the reason for the visit.

Where that is your real estate footprint, use a postcode field and route the lead internally rather than asking the patient to pick the specialized site by name.

Consent checkboxes, disclaimers, and the privacy policy link

Meta requires a privacy policy link and supports custom disclaimers and consent checkboxes. Use them. They cost nothing and they do work that the rest of the form cannot.

Your disclaimer should say who is collecting the information, what you will use it for, and how you will contact them. If you intend to call or text, get an explicit opt-in checkbox for it, because the telephone consumer rules are a separate exposure from HIPAA and lead forms are a common failure point for both.

A three-question test for any field

Before adding a question, run it through these in order. If any answer is wrong, the field does not go on a native form.

1. Would this answer, attached to a named person, tell a stranger something about their health? That is the HIPAA test in plain terms. Condition, symptom, medication, treatment, provider specialty, and insurance status all fail it.
2. Can the answer space be bounded, and is every option in it neutral? Read the full option list as a stranger would. If any single option identifies a condition, the whole question is a disclosure for the people who pick it.
3. Would the question survive being read out loud with the campaign name attached? Form fields do not sit in isolation. The ad creative, the campaign name, and the form context travel with the lead.

That third test catches the case teams miss most often. A form asking only for name and phone is still condition-bearing when it hangs off an ad set whose entire audience was built around one treatment. The field list is necessary, not sufficient, and where a campaign is unavoidably specific the right answer is to send traffic to a page you host instead.

The fields that encode a condition without naming it

The obvious failures get caught in review. These are the ones that get shipped.

• Provider selection. Choosing a named clinician communicates their specialty. This is the single most common quiet disclosure on clinic forms.
• Age or date of birth on a service with an age-gated indication. Combined with a targeted campaign, the birth date is doing more work than it looks like.
• Insurance carrier or plan. Coverage status is health information under HIPAA, and plan names frequently indicate the coverage category.
• Referral source, when the options are clinical. "Referred by my endocrinologist" is a diagnosis in a dropdown.
• Urgency questions. "How soon do you need to be seen?" reads as scheduling and functions as severity.
• Height and weight, or anything computed from them. These are clinical measurements, and on weight-related campaigns they are the diagnosis itself.
• Photo or file upload prompts. Not offered natively, and worth naming because teams try to reach them through a link in the disclaimer.

Read your live forms with this list open. Most clinics find at least one field they had never classified as clinical.

Getting lead quality without clinical questions

The objection to a stripped-down form is always the same. Fewer qualifying questions means more leads and worse ones, and someone has to work through the volume.

That is real. It is also solvable without putting clinical questions in Meta's database, and the solutions are mostly form design rather than form content.

Use the higher intent form option. Meta offers a form type that adds a review step before submission. It reduces accidental taps materially, which is where a large share of junk leads on native forms comes from. The cost is a lower raw conversion rate and a better one downstream.

Do the qualifying in the creative. The ad and the form's context card can state price ranges, eligibility criteria, and what the appointment involves. Someone who reads that and still submits is self-selected. Creative-level qualification carries no disclosure risk at all, because nobody is answering anything.

Ask non-clinical qualifiers. Preferred location, preferred contact time, and whether the person has visited the practice before are all bounded, neutral, and genuinely predictive of whether a lead books.

Use the completion screen. Meta lets you send a submitter to a website, a phone dialer, or a download after the form. Pointing them at a booking page turns a lead form into a booking funnel, and the people who continue are the ones worth calling first.

Feed real outcomes back. This is the highest-leverage item on the list. If Meta only ever hears "lead submitted", it optimizes for people who submit forms. Send back the booked appointment and the attended appointment as separate events and the algorithm starts finding people who become patients. Once that loop runs, the pressure to qualify on the form mostly disappears.

How Curve handles everything after the submit

Choosing safe fields protects the inbound path. The outbound path, the conversion signal that goes back to Meta so the campaign can optimize, is where the second exposure lives, and it is the part Curve is built for.

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare. Events reach Curve's US-hosted infrastructure rather than going straight to Meta from a browser, and Curve controls what leaves:

• Per-destination field mapping. Only fields you explicitly map forward to a given destination. The default is that nothing goes, so a form answer or a page URL cannot reach Meta by accident.
• Hashed identifiers. Email, phone, and name are SHA-256 hashed to Meta's Conversions API requirements before they are sent.
• Neutral event aliases. Meta records a neutral event name rather than the service line, so the treatment never appears in Events Manager.
• Incoming webhooks. Your CRM posts outcomes back and Curve matches them by email, click ID, or bridge token. Incoming data cannot override protected core attribution and contact fields.
• Offline conversion uploads. Bulk upload booked and attended appointments from a CRM or EHR export with automatic click ID matching.
• PHI-pattern detection. Payloads are inspected for PHI-shaped values such as SSNs, MRN-style identifiers, and long numeric sequences, and flagged for review. This is a monitoring layer, so you find out when an upstream form changed. The protection itself is the field mapping plus hashing.

A signed BAA is included on every Curve plan. For the routing side, see our guide to HIPAA-compliant lead routing from ad click to CRM, and for the deeper form configuration reference, PHI-safe Facebook Lead Ads form configuration.

Frequently asked questions

Can I ask which service someone is interested in?

Only if every option is genuinely non-clinical, which is rare on a clinic form. "Consultation" and "Follow-up" are fine. Naming treatments is not. If you need service-level routing, ask on the call or use separate campaigns with neutral forms and infer the service from the campaign internally.

Does a consent checkbox make a clinical question acceptable?

No. Patient authorization has a specific form under HIPAA and a checkbox on a Meta form does not meet it. More practically, consent governs your disclosure, and the vendor receiving the data still has no BAA in place.

Are Instant Forms different from Lead Ads?

Instant Forms is Meta's current name for the native lead form format. Same infrastructure, same constraints, same field decisions.

What about a hidden field with the campaign name?

Hidden fields are useful for routing and they are as risky as their contents. If your ad sets are named after the conditions they target, that name is now written into every downstream system that records the lead source. Use neutral internal codes.

How many fields should a clinic form have?

Four to six. Contact details, one location or timing question, and a consent checkbox. Every additional question reduces completion and, on this format, adds risk without adding a control you could not exercise later.

Can we ask clinical questions if we delete the leads from Meta quickly?

No. The disclosure happens at submission. Deleting the record afterward is good hygiene and does not undo the transmission. Retention rules are worth setting anyway, including for the copies that scatter into notification emails and exports.

Where to start

Open every live lead form and read the fields in order, including the option lists inside each dropdown. Remove free text entirely. Remove anything clinical, and then remove the quiet disclosures: provider pickers, insurance questions, specialized location names, urgency scales. Replace the qualification you lose with creative that states the criteria and a completion screen that pushes serious leads toward booking.

Then fix the return path, because a clean form with a browser pixel behind it solves half the problem. Curve replaces that pixel with server-side collection, per-destination field mapping, hashed identifiers, neutral event aliases, and webhook or offline matching for real appointment outcomes, with a signed BAA on every plan. Run the free compliance scanner to see what your site currently sends Meta, read our breakdown for med spa consultation request campaigns, or visit curvecompliance.com to review your form and event setup with us.

Reviewed August 2026. Meta's lead form field types, policies, and Conversions API specifications change regularly. Verify current requirements before implementation.