Medical Intake Forms and Tracking: Where Telehealth Funnels Leak Health Information

The medical intake form is the highest-risk page in a telehealth funnel, and it leaks health information in six predictable places: values inside form-submission events, URL query parameters, thank-you and confirmation page paths, automatic capture features in analytics tools, session replay recording keystrokes, and third-party form embeds that load their own trackers. Each one is fixable, and each one survives a normal marketing review because the tag reports a clean conversion either way.

Curve is a HIPAA-compliant conversion tracking platform that strips protected health information out of intake and conversion events on the server before anything reaches Google, Meta, Microsoft, or any other ad platform, so telehealth advertisers keep measurement without exporting what a patient just disclosed.

Intake pages deserve fresh scrutiny because of the FTC complaint filed on July 29, 2026 against Hims & Hers Health, Inc. in the Northern District of California, case number 3:26-cv-7871, brought alongside the People of the State of California and the Utah Division of Consumer Protection. At paragraph 67 the complaint defines the allegedly shared data as "Events," meaning "the actions of website visitors on Hims' website." An intake form is nothing but visitor actions, and on that page those actions are the medical history.

Hims & Hers has denied the allegations, has said its privacy policy makes clear that users may choose how their data is used, and intends to defend the case. Nothing has been proven. What is useful to everyone else is the map the complaint draws of where regulators now look.

The Short Version

• The intake form is where a visitor becomes a patient, so every tracker on the page inherits the sensitivity of what was just submitted.
• The complaint defines the allegedly shared data as visitor actions on the site. On an intake page, visitor actions are clinical facts.
• Six leak points cover nearly every real case: event payloads, URL parameters, confirmation paths, auto-capture, session replay, and embedded forms.
• Server-side tracking fixes none of them by itself. Paragraph 70 names the Meta Conversions API alongside the Pixel, describing the server-to-server mechanism accurately before pleading it as a vector anyway.
• Remediation is per leak point, not per platform. Cleaning the pixel while leaving the confirmation URL intact fixes nothing.
• The test is not "did the tag fire" but "what left the browser, and what did the platform learn about this person."

Why the Intake Page Is Not Like Your Other Pages

On a homepage, a tracker learns only that a device visited a healthcare brand, which is ambiguous. The intake form removes the ambiguity. Once someone is answering questions about symptoms, medications, dosage history, pregnancy status, mental health, or sexual health, there is no innocent reading left. The person is seeking care, the site knows what kind, and it is about to learn their name, email, phone, and date of birth. Identity and condition arrive within seconds of each other, and that pairing turns a marketing tag into a disclosure.

The complaint sharpens this at paragraph 74, alleging that Hims "was only able to create audiences with such specificity because it flouted the promises it made to its users about treating their medical conditions 'privately' or keeping their health information private." Audience specificity is the tell: if a team can retarget people who started one condition's intake flow, the ad platform received enough to distinguish that group from everyone else. Paragraph 66 lists the promises the FTC says ran in parallel, including "100% online, private, and secure" and "totally private," repeated in TV, radio, and podcast advertising. Most telehealth sites say something similar, and the gap between that copy and what the intake page transmits is where a Section 5 theory lives, independent of HIPAA.

How a Curve-Style Setup Handles Intake Pages

Curve sits between the intake page and the ad platforms instead of letting each platform's script read the page directly. Events are captured first-party, then sanitized server-side before egress, so field values, condition identifiers, and raw URLs are removed or replaced with non-clinical tokens before anything is forwarded. What reaches Google, Meta, Microsoft, Reddit, TikTok, or Pinterest is a conversion signal plus the matching keys that destination needs, configured per platform rather than as one firehose.

Two properties matter most here. Protected health information never reaches the ad platform, because removal happens before the outbound call is made rather than in a browser script a future tag edit can undo. And a BAA is available, the baseline any covered entity or business associate needs before routing patient-adjacent data through a vendor.

Leak Point 1: Field Values Riding Inside Form-Submission Events

The most direct leak is also the most common. A tag manager listens for a form submit, reads the inputs, and packs them into the event payload as custom parameters. Sometimes that is deliberate, because a marketer wanted conversions segmented by condition. Sometimes it is a generic "capture all form fields" recipe from a tutorial.

The resulting event carries a condition slug, a medication of interest, a BMI value, or a free-text box where the patient described their symptoms. Through a pixel, that becomes ad platform data. Through a server-to-server connection, it still becomes ad platform data, just without the browser network tab where an auditor would have caught it.

Remediation. Move to an allowlist. Define the exact parameters a conversion event may carry, reject everything else by default, and enforce the rule server-side. If the business needs value segmentation, map conditions to opaque internal identifiers held on your own infrastructure. Never forward free-text fields to an external destination.

Leak Point 2: URL Query Parameters

Query strings are the quiet version of the same problem. Intake flows routinely prefill or branch on parameters naming the condition, the product, or the dose, and many brands let campaigns carry the condition in a UTM value that persists across the session.

Every tracker on the page reads the URL. Pixels send the full page location by default, analytics tools store it as the page path dimension, and the browser attaches the intake URL as the Referer header on every third-party request, so a tracker that never touches your dataLayer still learns the condition from the header alone.

Remediation. Keep clinical routing out of the URL, using POST bodies, session state, or opaque flow identifiers instead of readable condition slugs. Where legacy URLs cannot change quickly, redact by position rather than by vocabulary, replacing the segment that structurally holds the condition instead of maintaining a blocklist of drug names that will always be incomplete. Set a restrictive referrer policy on intake routes, then confirm with a network capture that the sanitized value is what leaves. A structured pixel audit for PHI leakage surfaces the parameters nobody remembered.

Leak Point 3: Thank-You and Confirmation Pages

Conversion tags concentrate on the page whose URL is most likely to describe what was requested. Paths ending in a product line or condition are conventional, developer-friendly, and among the most damaging strings a healthcare site can transmit.

The page title compounds it. Analytics tools and several ad platform tags send document.title alongside the location, so a heading naming the treatment travels even when the path is clean. Confirmation pages also render the prescription name in the DOM, which matters for any tool with auto-capture or replay enabled.

Remediation. Standardize one neutral confirmation route across all product lines and pass an internal order identifier rather than the product. Rewrite the document title to something generic before any tag loads, not after. If revenue reporting needs product granularity, join it in your own warehouse from that identifier.

Leak Point 4: Auto-Capture, Autotrack, and Enhanced Measurement

This leak point survives every manual review, because nobody configured it. It is on by default.

Product analytics tools with autocapture record every click, focus, and form interaction along with the element's text, label, name attribute, and CSS selector. On an intake form the selector itself is often clinical: a button reading "Yes, I have been prescribed this before," or a radio input named for pregnancy status, carries meaning even when the value is stripped. Enhanced measurement in GA4 emits form interaction events with no tag added by anyone. Automatic advanced matching in some pixels scrapes visible fields for email and phone, which is precisely the identity half of the pair you were trying to avoid creating.

Remediation. Treat every automatic feature as opt-out on medical pages. Disable autocapture and enhanced measurement on intake and confirmation routes specifically, so the rest of the site keeps its instrumentation, and turn off automatic advanced matching wherever a pixel offers it. Rename input attributes and button labels so the DOM is not itself a clinical record. If GA4 runs near patient flows, our analysis of whether GA4 can be made HIPAA compliant lays out which defaults have to change.

Leak Point 5: Session Replay Capturing Keystrokes

Session replay on an intake form is a recording of a patient completing a medical history. Most tools mask password fields by default and offer broader input masking, but the defaults rarely cover what matters here.

The gaps to check: textareas describing symptoms are often unmasked while single-line inputs are masked; custom widgets built from divs and ARIA roles fall outside rules that target native input elements; masking covers typed values but not label text or the option rendered in a dropdown; canvas recording can capture uploaded lab results or photos; and validation errors sometimes echo the submitted value back into the DOM after masking ran. Uploaded photos in dermatology and sexual health flows are the worst case, because the image is the diagnosis.

Remediation. Block recording outright on clinical intake steps rather than masking your way through them, and resume on non-clinical pages. Where replay is retained, mask by default and allowlist what may be recorded, the inverse of how most tools ship, and verify against your real custom components rather than a demo form. The full configuration is in what makes session replay HIPAA compliant.

Leak Point 6: Third-Party Form Embeds

Many telehealth funnels do not own their intake form. It is a hosted form builder in an iframe, a scheduling widget, a chat qualifier, or a lead form inside the ad platform itself.

Each embed brings its own network behavior. The vendor receives responses directly, which makes them a business associate whether or not anyone signed paperwork. The embed script often loads its own analytics, the parent URL is passed in as a referrer or parameter, and when the widget posts a completion message back, it frequently contains the full response set for any tag on the parent page to read and forward. In-platform lead forms are a separate case, because responses are stored by the ad platform by design, which makes PHI-safe lead form configuration a different discipline from web form hygiene.

Remediation. Inventory every embed on intake routes and document what each receives. Require a BAA from any vendor touching responses, strip clinical parameters from the URL you pass in, and audit the postMessage handler so the parent forwards only a completion flag and an internal identifier. Where a vendor cannot meet the bar, bring the form in-house.

The Cross-Cutting Mistake: Assuming Server-Side Solves It

The most consequential detail for engineering teams sits at paragraph 70. The FTC names both the Meta Pixel and the Conversions API, describing the latter as operating differently "to the extent it creates a direct connection between the advertiser's server, website, app or other internal software and Meta's systems." The agency understood the architecture, described it correctly, and pled it as a sharing vector anyway. Paragraph 77 lists further server-side vectors among the trackers alleged to have been present, including a Google Ads S2S pixel and TikTok s2s.

The lesson is narrow and important. Moving a call from the browser to your server changes who makes the request, not what the request contains. Sanitization has to happen inside the server-side layer, before egress, which is the argument laid out in server-side tracking alone is not HIPAA compliance.

A Practical Intake Page Review

Run this with a network inspector open, submitting a test intake the way an ordinary user would:

• List every outbound request from the intake and confirmation pages, then read each payload in full rather than checking that the event name looks right.
• Search those payloads for condition names, drug names, dosages, and free text, including inside encoded parameters, since several tags base64-encode nested objects.
• Check the Referer header on third-party requests, not just the deliberate payloads.
• Confirm the confirmation URL and document title are neutral before any tag executes.
• Account for every script on the page, since trackers accumulate across agency handoffs and rarely get removed.
• Repeat on mobile web, in-app webviews, and after every funnel change.

Frequently Asked Questions

Is it safe to fire a conversion event when someone completes a medical intake form?

Yes, if the event carries no clinical content. A signal saying a qualified lead was created, with an internal identifier and a value, is ordinary marketing measurement. The risk comes from the extra parameters teams attach to enrich reporting, and from the URL it fires on.

Does the FTC complaint against Hims & Hers mean intake forms cannot be tracked anymore?

No. The complaint alleges sensitive health information was shared with advertising platforms while the company publicly promised privacy, and Hims & Hers has denied the allegations, has said its privacy policy makes clear that users may choose how their data is used, and intends to defend the case. Nothing has been decided. What the filing shows is that regulators now read actual event payloads, so the safe posture is making sure yours contain nothing clinical.

If a visitor accepts all cookies, can I track the intake form normally?

Consent under a privacy law and HIPAA authorization are different instruments with different requirements, and a banner click is not authorization to disclose protected health information to an advertiser. Consent tooling is worth having, but it does not convert a clinical payload into a permitted one. The distinction is covered in consent management versus HIPAA authorization.

How does campaign optimization survive stripping all of this out?

Send the platforms a clean conversion event with a value and the matching keys they need, and keep the clinical dimension in your own reporting layer. Optimization algorithms need volume and accurate timing far more than they need the condition, and most telehealth advertisers find performance holds once sanitized events are complete and deduplicated.

This article reflects the public record as of July 2026. The Hims & Hers matter is an active, unproven complaint in federal court, and everything above is an allegation by the FTC and its co-plaintiffs.

If you run paid acquisition into a telehealth intake flow and cannot say what each tracker on that page transmits, that is the gap worth closing. Curve was built for it: sanitized, server-side conversion tracking with a BAA, configured per destination. See how it works at curvecompliance.com.