What a Defensible Healthcare Tracking Setup Looks Like in Late 2026

A defensible healthcare tracking setup is one where you can show, from your own records, exactly what left your systems, where it went, and why nothing in it identified a person's health condition. That is the whole definition. Not "we do not think we send PHI," but "here is the payload log, here is the field allowlist that produced it, here is the BAA with the vendor that handled it." Curve is a HIPAA-compliant conversion tracking platform that gives healthcare advertisers that record, sanitizing event data server-side before it reaches Google, Meta, Microsoft, TikTok, or any other destination, so campaign measurement continues without protected health information crossing the boundary.

Being precise about this now matters because the older definition of defensible has quietly been retired. For several years the working assumption was that moving tracking server-side solved the problem. The FTC's complaint against Hims & Hers Health, Inc., filed July 29, 2026 in the Northern District of California as Case No. 3:26-cv-7871, tests that assumption directly. Paragraph 70 names the Meta Pixel and the Conversions API together, describes the Conversions API as creating a direct connection between the advertiser's server, website, app, or internal software and Meta's systems, and pleads it as a sharing vector anyway. Paragraph 77 separately lists a Google Ads S2S Pixel and TikTok s2s. These are allegations, nothing has been proven, and Hims has denied them, stating that its privacy policy makes clear that users may choose how their data is used and that it intends to defend the case. The drafting choice is instructive regardless of outcome: the agency understood server-side and did not treat it as a cure.

What follows is the architecture that does hold up, and the honest cost of building it. The choice healthcare advertisers keep being offered, measure well or comply well, is a false one, but getting both takes a specific design.

The Short Version

• Defensibility is evidentiary, not aspirational. If you cannot reconstruct what you sent last Tuesday, you are not defensible.
• Sanitize before egress, not after. Filtering at the destination is unverifiable, because the data already crossed the boundary to get there.
• The event payload is the control point, where every question that matters gets answered.
• Keep a BAA with any vendor that touches the data, and configure each destination deliberately rather than accepting defaults.
• Log what was sent. The log turns a policy into a defense.
• You keep conversion optimization, bidding signal, and campaign measurement. You lose some match rate, some audience granularity, and some view-through visibility. Anyone promising no tradeoffs is selling something.

What "Defensible" Actually Means

Two organizations can have identical tracking configurations and completely different exposure, because one can prove its configuration and the other can only describe it.

Think about what a regulator, a plaintiff's firm, or your own board will ask. Not "what is your policy." The questions are what data left, to whom, over what period, and how you know. A screenshot of a vendor dashboard setting answers something else. A payload log covering the period, a field allowlist showing what was permitted to leave, and a signed agreement with the processor, is evidence.

Architecture matters more than intent because intent produces a policy document and architecture produces records. Paragraph 78 alleges Hims had notice of privacy and consumer-protection regulatory risk in SEC filings from 2021, and that the FTC issued a Civil Investigative Demand in October 2023. Whatever the merits, the shape of the claim is a reminder that the period under examination is usually historical. You cannot retroactively generate a payload log for 2024. You can only have started keeping one.

Principle One: Decide What Must Never Leave, in Writing, First

Most tracking setups grow by accretion. Someone adds a parameter to improve match rate, someone else adds a content name because reporting looked thin, and two years later nobody can state the rule because there never was one. Write it first, as an explicit list, and treat it as the specification the implementation must satisfy.

• Direct identifiers: name, email, phone, postal address, account number, member ID, hashed or not. Hashing is a matching technique, not a de-identification one, because the point of submitting a hash is that the recipient can match it to a person.
• Condition-revealing strings: URL path, page title, referrer, content name, product name, and any parameter naming a service line, medication, symptom, or specialty.
• Free text of any kind: on-site search terms, form comments, chat transcripts. It cannot be validated in advance, so it cannot be permitted.
• Values precise enough to identify in combination, such as an exact appointment timestamp paired with a location.

Principle Two: Sanitize Before Egress, Not After

This is the load-bearing principle, and where most setups that call themselves compliant fail.

Filtering at the destination means the data left your control, arrived at a third party, and was handled per that third party's configuration. Ad platforms do offer health-data filtering and it is worth enabling, but it is a backstop, not a control. You cannot audit it, and the request that carried the data across the boundary already happened.

Sanitizing before egress means the outbound request never contains the field. In the first case your evidence is a vendor's assurance. In the second it is your own outbound log, which contains no such field because code you control removed it before the request was built.

Implement it as an allowlist rather than a blocklist. A blocklist enumerates what to strip and fails open the moment a platform adds a default parameter or a developer adds a field to chase match rate. An allowlist enumerates what may pass and fails closed, the correct failure mode when the downside is a regulatory filing. That is the difference between a real server-side setup and a relocated one, and it is why server-side tracking alone is not HIPAA compliance.

How Curve Implements This

Curve is built on the two principles above. Events are collected first-party from your own domain, passed to Curve's server, sanitized there against a field allowlist, and only then forwarded, so protected health information never reaches Google, Meta, Microsoft, TikTok, Reddit, or any other destination. Where URLs are concerned, sanitization is positional rather than vocabulary-based, which matters because a blocklist of condition words will always be incomplete while a rule about which URL segments may egress will not be. Destinations are configured per platform rather than fanned out identically, because each accepts different fields and degrades differently when one is withheld. A BAA is available covering the data Curve handles, and because forwarding runs through a layer you control there is an outbound record of what was sent, which is the artifact that turns all of the above into something you can show rather than assert. None of it is exotic: it is what a competent team would build in-house given six months and a dedicated engineer. The reason to buy it is that tracking each platform's parameter changes across a dozen destinations is permanent work nobody budgets for in year two.

Principle Three: Treat the Event Payload as the Control Point

Paragraph 67 of the complaint defines the alleged sharing mechanism as "Events," described as "the actions of website visitors on Hims' website." That is a useful abstraction to adopt, because it names the single layer where every question converges. Control the payload and you control the answer to all of them at once: what identifiers left, whether a condition was inferable, which destination received it, whether consent had been given, whether the send was recorded. Without that control, each becomes a separate investigation in a separate system.

A defensible event schema looks like this:

• An event name from a fixed, reviewed vocabulary. Not a dynamically constructed string, because that is how service names end up inside event names.
• A conversion value and currency, where the value is a real business number rather than a proxy for what was purchased.
• Click identifiers connecting the event to an ad interaction, such as gclid and fbclid. These identify an ad click, not a health status, and they are what makes optimization work.
• A timestamp, at the precision the platform requires and no more.
• Nothing else, unless it has been reviewed against Principle One and added to the allowlist by name.

The discipline is that adding a field is a decision with a reviewer, not a config change someone makes on a Thursday.

Principle Four: A BAA With Anyone Who Touches the Data

If a vendor receives event data that has not yet been sanitized, it is handling data that may include PHI, which makes the agreement a prerequisite. Ad platforms generally do not sign BAAs for advertising data and their terms typically prohibit sending health information, which is why sanitization has to happen upstream of them.

Two cautions. A BAA is a contract, not a control: it allocates responsibility, it does not stop a payload from containing a diagnosis, and the Security Rule obligations around it are separate work, as covered in why a BAA is not enough on its own. Scope also varies between vendors, so what a given BAA actually includes is worth answering in writing before you rely on it.

Principle Five: Configure Destinations Per Platform, Deliberately

The lazy pattern is one sanitized event fanned out identically everywhere. It leaves real performance on the table, because platforms differ in what they accept and how they behave when a field is absent.

• Google Ads treats enhanced conversions and offline conversion imports as distinct pathways with distinct field expectations, with server-side requirements covered in setting up enhanced conversions without PHI leakage.
• Meta weighs event match quality heavily, which is exactly why teams are tempted to add identifiers. The right response is to maximize the legitimate signals, click identifiers and event timing, rather than add prohibited ones.
• Microsoft Advertising's UET and offline conversion behavior differs enough from Google's that a copied configuration underperforms.
• Newer destinations, including Reddit and the growing set of AI and commerce placements, each have their own accepted field sets.

Deliberate configuration also means deciding what a conversion means per platform. If Meta optimizes toward a mid-funnel event and Google toward a completed purchase, that should be a choice you made rather than an artifact of who set up which account.

Principle Six: Log What You Sent

Keep an outbound record: event name, destination, timestamp, and the field names present. You do not need to retain the values indefinitely and usually should not. The field list, plus the allowlist version in force at the time, answers the question that gets asked. Retain it long enough to cover the periods anyone will ask about, which is longer than most teams assume, and review a sample on a schedule rather than only during incidents. A monthly sample catches the parameter a platform SDK started adding by default. An annual review does not.

Principle Seven: Consent, Handled as What It Is

Consent is necessary and not sufficient, and the two failure modes are opposite. Some teams treat a cookie banner as though it authorizes health data sharing, which it does not, because consent under privacy law and authorization under HIPAA are different instruments. Others treat the banner as the whole program and never wire the signal through to the systems that act on it.

A defensible implementation collects the signal, propagates it to the server-side layer so suppression happens before egress rather than in the browser, and honors it in list uploads and audience syncs, where suppression is most often skipped because those run on a schedule outside the request path. The distinction between the two instruments is worked through in consent management versus HIPAA authorization.

What You Can Still Do Well

The persistent fear is that a compliant setup means flying blind. It does not, because the signals platforms actually optimize on are mostly not the ones you are removing.

• Conversion optimization works. Smart Bidding and Meta's conversion optimization need to know a click led to a conversion, with a value and a timestamp. A click identifier plus a conversion event delivers that. The algorithm does not need the patient's condition; it needs to know which click converted.
• Bidding signal quality can be high. Match rate is driven substantially by click identifier coverage and prompt delivery. A well-built server-side path often improves both against a browser pixel losing events to ad blockers, tracking prevention, and page abandonment.
• Campaign measurement is intact. Channel, campaign, ad group, and creative performance all sit above the layer where PHI would live. Report ROAS, cost per acquisition, and incrementality without a single prohibited field.
• Audience building remains possible when seeded from behavioral and in-market signals rather than clinical attributes. Paragraph 74 alleges Hims could create audiences with such specificity only because it flouted its own privacy promises, a claim about the seed criterion. The alternative is covered in seeding lookalikes from in-market segments.

The Honest Tradeoffs

• Match rates are lower than an identifier-rich setup. Not catastrophically, and often less than expected once click identifier coverage improves, but the ceiling is lower and the platform's event quality score will say so.
• Audience granularity drops. You cannot build the condition-specific segment. Broader in-market seeds work, often well, but not to the precision of a segment you are not permitted to build.
• Platform-native reporting loses depth. Because condition and product names do not egress, the platform's own breakdowns are coarser. You get that granularity back in your own analytics, but analysts work in two places.
• Attribution windows behave differently. View-through and cross-device attribution lean on identity resolution you are deliberately not feeding. Modeled conversions fill part of the gap, and modeled is not measured.
• There is real operational overhead. Allowlists need review when platforms change, new pages need checking, and someone has to own it. Ongoing work, not a project with an end date.
• Some tactics are off the table. Certain retargeting patterns, list upload strategies, and affiliate arrangements. Plan the channel mix around that rather than discover it mid-review.

Weigh those against the alternative, which is not a costless status quo. It is a setup whose answer to "what did you send" is a shrug, at a moment when the FTC is litigating rather than settling and two state authorities joined the caption.

Frequently Asked Questions

Is server-side tracking enough to be HIPAA compliant?

No. Paragraph 70 names the Conversions API alongside the Meta Pixel and describes the server-side mechanism accurately before pleading it as a sharing vector, and paragraph 77 separately names a Google Ads S2S Pixel and TikTok s2s. Moving the request from browser to server changes who sends the data, not what it contains. Server-side is a precondition for doing this well, because it gives you somewhere to sanitize, but the sanitization is the part that matters.

Can I still run effective paid campaigns without sending identifiers to ad platforms?

Yes, with a lower ceiling on match rate and audience granularity. Conversion optimization, automated bidding, and campaign-level measurement all run on click identifiers, conversion values, and timestamps, none of which reveal a health condition. Advertisers who transition properly usually land within range of prior performance, sometimes better, because server-side delivery recovers events browser pixels were losing.

Do I need a BAA with Google or Meta?

They generally will not sign one for advertising data, and their terms typically prohibit sending health information. That is not a loophole, it is the reason the architecture puts sanitization upstream of them. The BAA you need is with whatever vendor handles your event data before it is sanitized.

How does the Hims case change what I should do?

It sharpens the standard rather than changing it. The case is at the pleading stage, everything in the complaint is an allegation, nothing has been proven, and Hims has denied the allegations, says its privacy policy makes clear that users may choose how their data is used, and intends to defend the case. What is new is the escalation: GoodRx settled in February 2023 and BetterHelp in March 2023, while this one is being litigated with civil penalties sought and California and Utah as co-plaintiffs. The practical implication is that assertions are worth less than records.

This article reflects the record as of July 2026. It describes an architecture, not legal advice, and the case discussed remains unproven at the pleading stage.

If your current setup cannot produce a record of what it sent, that is the gap worth closing first, and it is the gap Curve was built to close: first-party collection, server-side sanitization against a field allowlist before egress, per-platform destination configuration, a BAA covering the data handled, and an outbound record you can show. See how it fits your stack at curvecompliance.com.