Google Lead Form Extensions: PHI-Safe Routing

You can run Google lead form assets in healthcare without creating a HIPAA disclosure, but only by controlling the questions rather than the data flow, because Google hosts the form and receives every answer before you do. Curve is the HIPAA-compliant tracking and attribution layer that handles the rest: leads reach your CRM through a path covered by a Business Associate Agreement, and conversions return to Google Ads as neutral, hashed, server-side events with click ID matching. A signed BAA is included on every Curve plan.

Google's lead form assets (still widely called lead form extensions) attach a form directly to a Search, YouTube, Display, or Demand Gen placement. The patient taps the ad, a form opens inside Google's surface, and the submission lands in Google's systems. It converts well, it is fast to launch, and it has the same structural problem as Meta's native Instant Forms. There is no point in the flow where you get to inspect a submission and decide what continues onward.

The form is Google's, not yours

Every compliance question about this format resolves back to one fact. The rendering, the submission, and the storage all happen on Google infrastructure. Your systems become involved only after Google already holds the answers.

That has three consequences worth stating plainly:

• You cannot filter what Google receives. Server-side field mapping, sanitization, redaction, and every other technical control operate on data that has reached your infrastructure. A lead form asset never gives you that opportunity.
• Google does not sign a BAA for its advertising products. Google Cloud signs BAAs for covered services. Google Ads is not one of them, and lead form assets live in Google Ads.
• The submitter is frequently identified to Google already. Forms pre-fill from the signed-in Google account, so the answer arrives attached to a known person rather than an anonymous session.

Put those together and the rule falls out. Any clinical question on a Google lead form is a disclosure of health information about an identifiable individual to a vendor with no BAA, made at the moment of submission. Nothing you build downstream reverses it.

This is uncomfortable because the format is genuinely good at generating volume, and because Google's own question library invites the mistake. The picker offers ready-made qualifying questions grouped by vertical, and some of them are exactly the questions a clinic would want to ask.

What you actually control

You control three things: the questions, the ad and campaign context around them, and where the lead goes after Google hands it over. That is the entire surface area. Design within it.

Questions that are generally safe to ask

• First name and last name
• Email address
• Phone number
• Postal code, city, or preferred location, provided the location list is not condition-specific
• Preferred contact time or general availability
• Whether the person is a new or returning customer, stated in neutral commercial terms
• Consent and disclosure acknowledgements

Questions that disclose a condition

• Reason for visit, symptom, or condition, in any phrasing
• Current medications, dosage, or treatment history
• Procedure or treatment of interest
• Insurance carrier, plan type, or coverage status, which signals both payment for care and often the care itself
• Preferred provider, wherever providers map to specialties
• Date of birth, which is a strong identifier and rarely necessary at the lead stage
• Any free-response field, because patients volunteer clinical detail without being asked

The traps are the questions that encode a condition without naming one. A location dropdown that lists a fertility centre next to three general practices has communicated a specialty for anyone who picks the first option. A "which programme are you interested in" question with weight management as one option is a clinical question wearing commercial clothes. Read your own option lists the way a plaintiff's lawyer would.

The campaign around the form counts too

Even a contact-only form sits inside a context. If the ad group, the ad copy, and the keyword all point at one treatment, then a submission from that ad group carries the treatment interest whether or not a field says so. Google holds the campaign structure and the lead together.

Where a funnel is unavoidably condition-specific, the honest answer is that the lead form asset is the wrong format for it. Send the click to a landing page on infrastructure you control, where qualification can happen behind a boundary you own. Our guide to connecting lead forms to your CRM without PHI covers that architecture in detail.

Getting the lead out of Google

Google offers three delivery paths, and they carry different amounts of risk.

Webhook delivery. Google posts each lead to an HTTPS endpoint you specify, with a shared key you set in the asset configuration so your endpoint can verify the call came from Google. This is the best option for a healthcare advertiser. The lead moves once, into infrastructure you own, and you decide everything after that. Your endpoint must return quickly and must be reachable, or Google will consider the delivery failed.

CRM connectors. Some CRMs and middleware tools pull leads from Google Ads on your behalf. Convenient, and acceptable only when that vendor has signed a BAA covering the data it will hold. Automation platforms are the usual weak link here, since they retain payloads in run histories and logs long after the lead has moved on. Our verdict on whether Zapier is HIPAA compliant for healthcare marketing applies directly.

CSV download. Google makes submitted leads available for manual download from the Assets interface for a limited window. Treat this as an emergency fallback, not a workflow. Downloaded lead files land in inboxes, laptops, and shared drives with no BAA, no access control, and no retention rule. If your only delivery method is a person exporting a spreadsheet, you have a compliance problem regardless of what the form asks.

Whichever path you use, remember that anyone with access to the Google Ads account can download the leads. Agencies, freelancers, and former staff with lingering permissions all count. Review account access on the same schedule you review the forms themselves.

The return path: conversions back to Google Ads

Delivering the lead is half the job. Google needs a conversion signal to optimize bidding, and this is where healthcare advertisers create a second, entirely avoidable exposure.

The failure modes are familiar. A conversion action named after the service line, sitting permanently in the Google Ads interface. Enhanced conversions configured to pass whatever the form returned, including a free-text field. A browser tag on a thank-you page carrying a URL that names the treatment. Each of these sends condition-bearing data to a platform with no BAA, which is the same mechanism behind the healthcare pixel settlements that have now cumulatively crossed $100 million.

What Google actually needs is narrow. A conversion action name, a timestamp, the gclid from the original click, and hashed contact fields for Enhanced Conversions where the click ID is missing. None of that requires clinical content. Attribution is a matching problem, not a content problem.

Two mechanics matter for lead form assets specifically. First, capture the click identifier at the moment the click happens, because you cannot reconstruct it later. Second, the conversions that matter commercially happen after the lead leaves Google entirely, when someone books, attends, or starts treatment. Those live in your CRM and have to travel back through a server-side path. Google's offline conversion import and Enhanced Conversions for leads exist for exactly this, and we cover the mechanics in our guide to server-side Enhanced Conversions setup without PHI leakage.

How Curve routes Google lead form leads

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare, and it owns everything from the moment the lead reaches infrastructure you control.

• Server-side collection. Events go to Curve's US-hosted infrastructure rather than directly to an ad platform. That is the structural change that creates a decision point before data leaves.
• Per-destination field mapping. Only fields you explicitly map forward to a given destination. The default is that nothing goes. A field somebody added to a form last month does not silently start travelling to Google.
• Identifier hashing. Contact identifiers are SHA-256 hashed to match Google's conversion API requirements before they leave.
• Neutral event aliases. The conversion action Google records carries a neutral name, so the service line never appears in the Google Ads interface or in any report exported from it.
• Incoming webhooks with attribution matching. Your CRM, booking tool, or call tracking platform posts outcomes back to Curve, matched by email, click ID, or bridge token. Incoming data cannot override protected core attribution and contact fields, so a misconfigured upstream system cannot corrupt the record.
• Offline conversion uploads. Bulk upload of booked and attended appointments from a CRM or EHR export, matched on click ID (up to 10,000 rows or 5MB per upload).
• PHI-pattern detection. Payloads containing PHI-shaped values such as SSNs, MRN-style identifiers, dates, and long numeric sequences are flagged. This is a monitoring layer that tells you when a form changed, not the protection itself. The protection is the field mapping.
• Bridge tokens. When a lead clicks out to a separate booking or intake tool, attribution survives the handoff instead of breaking at the point it becomes valuable.

A signed BAA comes with every plan.

Setup order that avoids rework

1. Audit every live lead form asset question by question. Include the option lists, not just the question text.
2. Remove anything clinical, then reread the campaign context. If the ad group only makes sense for one condition, move that funnel to a landing page.
3. Switch delivery to a webhook into infrastructure you control. Set the shared key and verify it on receipt.
4. Confirm BAA coverage for every system the full lead touches. CRM, middleware, hosting, and any inbox that receives a notification copy.
5. Define neutral conversion action names before you create them. Renaming later means losing history in Google Ads.
6. Capture and store the click identifier at landing. Everything downstream depends on it.
7. Wire CRM outcomes back through offline import or webhooks. Booked and attended beat submitted every time.
8. Inspect the actual outbound payload. A configuration screen states intent. The payload is the fact.

Frequently asked questions

Does Google's healthcare and medicines policy make lead form assets compliant?

No. Google's advertising policies restrict certain targeting, claims, and creative. That is a separate regime from HIPAA. Policy compliance is not a BAA, and only a BAA permits a covered entity to disclose protected health information to a vendor.

Can I delete leads from Google after my webhook receives them?

Deleting a record afterwards does not undo the disclosure. Google received and processed the submission at the moment the patient tapped submit. Deletion is good hygiene and a reasonable retention practice, but it is not a remedy.

Are lead form assets on YouTube or Demand Gen treated differently?

No. The surface changes, the hosting does not. The form still renders and submits inside Google's infrastructure, so the same question discipline applies across Search, YouTube, Display, and Demand Gen.

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

Then the fields are fine, and your attention moves to the campaign context. A contact-only form attached to an ad group built entirely around one treatment still ties an identified person to that treatment interest inside Google's systems.

Will neutral conversion names hurt Smart Bidding?

No. Smart Bidding optimizes on conversion counts, values, and timing, not on what the conversion action is called. The name is a label for humans. What genuinely improves bidding is feeding back real downstream outcomes rather than raw form fills, which is a change worth making anyway.

Can I send hashed email to Google for Enhanced Conversions if the lead came from a condition-specific campaign?

Hashing protects the identifier in transit; it does not change the meaning of the disclosure. Keep the conversion action neutral so the event itself does not communicate a condition, and the hashed identifier is doing only the matching job it was designed for.

How do I tell whether my current setup is leaking?

Submit a test lead and inspect the actual outbound conversion payload, including the conversion action name and every custom parameter. Then check what your CRM wrote into its source fields, since campaign and ad names frequently carry the service line into every downstream system. Our free compliance scanner will also flag risky tracking across your site.

Where to start

Take the question list first. It is the only part of a Google lead form asset you control, and it is where the disclosure is made or avoided. Strip anything clinical, reread the option lists, then look at the campaign context around the form and move genuinely condition-specific funnels to a landing page you own.

Then fix the return path, which is usually where the larger and more persistent exposure sits. Curve routes those conversions server-side to Google Ads with per-destination field mapping, SHA-256 hashed identifiers, neutral conversion aliases, click ID matching, and offline outcome uploads, with a signed BAA on every plan. See how the same pattern applies across platforms in our guide to HIPAA-compliant conversion tracking for Google, Meta, and Microsoft, or visit curvecompliance.com to walk through your current setup.

Reviewed August 2026. Google Ads asset formats, lead delivery options, and conversion API requirements change frequently. Verify current behavior against Google's documentation before implementation.