Consent architecture for telehealth: how to track patient acquisition without PHI exposure

A peer-reviewed study published in late 2025 (Oxford/NAS, PMC12687351) found that 66% of US hospital websites were still running pixel tracking despite an enforcement environment that produced over $100 million in penalties, and settlements between 2023 and early 2025. That persistence rate is not ignorance of the legal risk. It reflects how much conversion signal capacity growth teams are unwilling to lose when they remove client-side pixels from a patient acquisition funnel.

The problem is that most available guidance forces a false choice: strip the pixels and lose the signal, or keep them and accept the liability. Neither the compliance checklists nor the vendor marketing collateral from server-side platform providers address what a Head of Growth actually needs to know: which data flows are still permissible after the June 2024 AHA v. Becerra ruling, where the real protected health information (PHI) exposure points live in a telehealth acquisition funnel, and how to recover most of that conversion signal while running data through a scrubbing layer before it reaches Google Ads or Meta's Conversions API (CAPI).

This piece works through all of it, from the specific PHI exposure points in a public-facing funnel to the consent management platform (CMP) configuration that gates tag firing by jurisdiction.

Where PHI enters your acquisition funnel before a patient ever logs in

Most growth teams think of PHI exposure as a patient-portal problem. Authenticated pages, session notes, appointment history: that is where the sensitive data lives, so that is where compliance review focuses. The acquisition funnel, the paid search landing pages, and condition-specific entry points that run before a user ever creates an account, gets treated as a cleaner environment.

It is not.

Consider the specific signal types that carry PHI risk on public-facing telehealth pages:

Condition-specific URL paths. A URL like /anxiety-treatment or /erectile-dysfunction-consultation communicates a health condition. When a client-side pixel fires on that page and passes the full URL to an ad platform alongside a cookie or IP address, that combination is potentially PHI-in-transit, regardless of whether the user has authenticated. The user's browser, IP, and the specific health condition they were researching are now in a third-party system.

Symptom query parameters from paid search. When a user clicks a paid search ad for "online ADHD diagnosis," the landing page URL frequently carries that query string or a mapped parameter. Analytics tooling that captures document.location or referrer data passes that symptom-adjacent string downstream. The user never typed anything into a form. They just clicked a search result.

Appointment request form fields. Even a pre-login appointment request form collects name, email, date of birth, and sometimes a chief complaint or condition selector. If a client-side conversion tag fires on form submission and passes field-level data to an ad platform, that payload contains PHI by any reasonable interpretation.

IP-plus-health-condition combinations. Before the June 2024 AHA v. Becerra ruling, the Office for Civil Rights (OCR) treated an IP address combined with a visit to a page addressing a specific health condition as PHI, even on unauthenticated pages. The ruling changed that position for covered entities in limited circumstances, but state law, particularly Washington's My Health My Data Act (MHMDA), independently regulates this data type regardless of the federal ruling.

The authenticated/unauthenticated page boundary matters, but it is not the clean dividing line many compliance reviews treat it as. The actual dividing line is whether the data combination in a given event payload, URL path, IP address, device identifier, and any health-condition signal, could identify a person, and their health status. That question applies to public pages too.

What the AHA ruling actually changed, and what it did not

On June 20, 2024, a federal district court in Texas vacated the portion of OCR's online tracking guidance that treated an IP address combined with a visit to an unauthenticated public webpage addressing health conditions as PHI. OCR subsequently dropped its appeal in September 2024, leaving the ruling in place. As of September 25, 2026, that ruling is the operative federal position on this specific data combination for unauthenticated pages.

What that means in practical terms: a covered entity running a public-facing telehealth marketing site is no longer in automatic violation of HIPAA solely because a pixel captured an IP address alongside a condition-specific page view. That narrow carve-out is real.

What the ruling did not change is equally important:

Authenticated pages remain fully governed. Any tracking on patient portals, telehealth session pages, appointment confirmation screens, or any page that requires a login is still subject to full HIPAA obligations. Every tool in that data path must operate under a valid Business Associate Agreement (BAA), and patient authorization standards apply. That part of the regulatory framework is unambiguous and unaffected by the ruling.

The ruling is a single district court decision. It is not a circuit court ruling and it is not a Supreme Court decision. It is not binding on courts in other jurisdictions. OCR stated it is evaluating next steps, so the agency's longer-term enforcement posture on unauthenticated-page tracking remains contested as of this writing. Growth teams who treat the ruling as a permanent green light for client-side pixels on public pages are taking a risk the ruling itself does not actually eliminate.

State law fills the gap. Washington's MHMDA effectively neutralizes the AHA ruling's benefit for Washington residents. The MHMDA requires express, prior opt-in consent before any collection, or sharing of consumer health data, full stop. Not before sharing. Before collection. That means a consent gate must fire before any tracking tag on a Washington visitor's browser, regardless of whether the page is authenticated, regardless of the AHA ruling, and regardless of the IP-plus-condition analysis that the federal ruling addressed. For a telehealth platform with any meaningful volume from Washington, the practical effect of the AHA ruling is close to zero.

Nevada's SB 370 (effective March 31, 2024), and Connecticut's health data law impose similar consent and notice requirements. The multi-state legislative pattern is clear: even where OCR has retreated, state attorneys general have not.

Why server-side tracking is not a compliance solution by default

This is the most consequential misconception in the current landscape. Server-side conversion tracking is frequently recommended as the path from non-compliant client-side pixels to a safe measurement architecture. Vendors present it as the solution. In some implementations it is part of the solution. In many implementations it just relocates the problem.

Moving from a client-side Meta Pixel to a server-side CAPI integration does not eliminate PHI exposure. It changes where the exposure occurs. If the server-side router passes a full event payload, including email addresses, phone numbers, appointment-form data, or condition-specific URL parameters, to Meta CAPI without first stripping, or hashing the regulated fields, the PHI has simply traveled one hop further before reaching a third party. The legal exposure is substantially similar.

Specific failure points in typical server-side implementations:

The server-side vendor itself must sign a BAA. Any vendor or platform that processes PHI on behalf of a covered entity is a business associate and must operate under a BAA. Server-side tag manager (sGTM) containers running on Google infrastructure, for instance, are not covered by a Google BAA for analytics purposes. If PHI passes through the sGTM container before being stripped, the container operator needs to have addressed BAA coverage explicitly.

PHI scrubbing must happen before any downstream send. The correct sequence is: CMP confirms consent and jurisdiction, client-side tag fires a sanitized event to the server-side endpoint, the server receives the event, and applies a PHI scrubbing layer that strips or hashes regulated fields, and only the anonymized or hashed conversion token passes to the ad platform. Condition-specific URL parameters must be stripped at this stage, not after. Device identifiers that could be combined with health-condition signals must be hashed or excluded.

Common implementations skip the scrubbing layer entirely. The default behavior of a server-side router is to pass through whatever data it receives. Adding a PHI filter requires deliberate configuration of field-mapping rules that identify and redact regulated fields. Most implementations that claim "server-side" compliance have a server-side container but no data-scrubbing layer between the inbound event and the downstream platform send.

A compliant server-side pipeline for telehealth patient acquisition looks like this:

1. CMP fires on page load, gates all collection tags pending consent, and jurisdiction check
2. Consent confirmed: client-side tag sends a minimal event to the sGTM endpoint (session token, conversion type, hashed email if available, no raw form fields)
3. sGTM receives event; PHI scrubbing filter runs against a field blocklist
4. Enrichment layer adds marketing context (gclid, fbclid, session ID) from a Firestore snapshot captured at browser session start
5. Anonymized conversion payload routes to Google Ads and Meta CAPI
6. Parallel write to BigQuery for warehouse-side attribution

That is materially different from a standard sGTM passthrough, and it requires deliberate architecture decisions at steps 2, 3, and 4.

Consent architecture for the authenticated/unauthenticated boundary

The operational core of a compliant telehealth measurement stack is a two-zone consent model. Zone 1 and Zone 2 are architecturally distinct environments with different tool eligibility requirements and different consent mechanics.

Zone 1: Public marketing pages, unauthenticated

Zone 1 pages are condition-specific landing pages, symptom-focused content, paid search entry points, and any page a user can reach without logging in. After the AHA ruling, covered entities have more flexibility here than before on unauthenticated pages under federal HIPAA analysis. But that flexibility is constrained by state law for any visitor in Washington, Nevada, Connecticut, or any other state with a health data privacy statute.

In Zone 1:

• A BAA-free analytics tool is potentially permissible only if the data it collects reliably excludes PHI combinations and the jurisdiction of the visitor permits that data type without prior opt-in
• Google Analytics is not a compliant choice in Zone 1 for covered entities because Google will not sign a BAA, regardless of what the analytics tool collects (more on that below)
• The CMP must gate Zone 1 tags by jurisdiction: a visitor geolocated to Washington must trigger the express opt-in flow before any collection tag fires, not just before data is shared
• Condition-specific URL paths must be sanitized or excluded from any payload that leaves the first-party environment

Zone 2: Patient portal, telehealth sessions, appointment confirmation

Zone 2 begins the moment a user authenticates or lands on any page where their health data is accessible. In Zone 2:

• Every tool in the data path must operate under a valid BAA. No exceptions
• Google Analytics is categorically excluded: Google does not sign BAAs for GA4 and prohibits PHI from being sent to its platform as a terms-of-service matter. As of September 25, 2026, this is not a configuration problem. It is a contractual constraint that cannot be worked around. HIPAA-compliant alternatives for covered entities include Piwik PRO (BAA available), Adobe Customer Journey Analytics (BAA available), and purpose-built healthcare analytics layers that operate entirely within a BAA-covered cloud environment
• Consent must meet both HIPAA authorization standards and applicable state opt-in requirements. For Washington visitors, express opt-in must have been obtained before any collection fired in Zone 1, meaning the Zone 2 session is already gated by what happened earlier in the funnel

Signal fidelity trade-offs in a compliant two-zone model

The honest version of this architecture includes its costs:

Hashing patient email before sending it to Meta CAPI for customer match degrades match rates. A raw email produces a clean SHA-256 hash that Meta can match; a hashed email in a pre-scrubbed payload that also lacks phone and device identifiers produces a match rate that is measurably lower than what a non-compliant pixel produces. That gap is real. Analytico's experience with server-side GTM configurations in healthcare contexts suggests that a well-configured CAPI implementation with hashed first-party identifiers typically delivers 60% to 75% of the match volume of a raw client-side pixel, depending on the first-party data quality.

Stripping condition URL parameters before the conversion event fires means the ad platform cannot use that context for audience segmentation at the conversion level. You can still track that a conversion happened; you cannot attribute it to the specific condition category that the user converted on, unless that attribution is done inside a BAA-covered warehouse environment, and never passed to the ad platform in raw form.

Both of those signal losses are partially recoverable through higher-quality first-party cohorts in a BAA-covered CDP. When the warehouse join layer connects acquisition source to patient outcome data (within the BAA framework), you can build retrospective cohorts that feed lookalike audiences without passing raw PHI to the ad platform. The signal is slower and requires a warehouse-side attribution workflow, but it is both compliant, and more accurate than optimizing on pixel-fired form completions that never verified whether the patient actually retained.

For a fuller look at HIPAA-compliant measurement architecture in practice, including the identity resolution patterns that make Zone 2 attribution work, the vertical page covers the structural requirements in more detail.

The multi-law stack your CMP must address before a single tag fires

Most consent management platform configurations built for healthcare are calibrated to HIPAA authorization timing. That is necessary but insufficient. The regulatory surface area for a telehealth platform operating across US states in 2026 involves at least four overlapping frameworks, and a CMP that treats them identically will be under-built for several of them.

HIPAA (covered entities and their business associates). The foundational framework for traditional healthcare providers and telehealth platforms that qualify as covered entities. The AHA ruling adjusted the unauthenticated-page analysis. Authenticated pages remain fully governed. BAA requirements apply to every vendor in the Zone 2 data path.

FTC Act Section 5 (non-covered entities). Telehealth platforms that do not qualify as HIPAA-covered entities are not exempt from health data privacy obligations. The FTC's enforcement actions against Cerebral ($7 million), GoodRx ($1.5 million), and BetterHelp ($7.8 million) established that sharing PHI-equivalent data with ad networks via client-side pixels constitutes an unfair or deceptive trade practice. The underlying data-flow risk is structurally identical to what triggers OCR enforcement; only the regulatory mechanism differs.

Washington MHMDA (any business, any threshold). The MHMDA applies to any business that collects any consumer health data in Washington. It has no minimum threshold. A telehealth platform does not need to be a covered entity, does not need a minimum number of Washington users, and does not need to be storing health data in Washington for the MHMDA to apply. The consent requirement is express, prior opt-in before collection fires. The first MHMDA private lawsuit was filed in February 2025 (Maxwell v. Amazon), and a second targeted a Seattle retailer for pixels firing before consent was obtained. Both cases are in early motion practice as of September 2026, which means plaintiff-side theories have not yet been tested by judgment, but the filing pattern signals active litigation risk.

The MHMDA's geofencing prohibition is also worth noting explicitly: regardless of consent status, geofencing around health facilities is banned. A telehealth platform running location-based audience targeting that draws a radius around physical clinics or urgent care facilities to capture competitors' patients is violating the MHMDA on those targeting parameters alone.

Nevada SB 370 and Connecticut's health data law. Both impose consent, notice, and security duties for consumer health data, with provisions that restrict health-facility geofencing. The multi-state wave is real and accelerating. Any CMP that applies a single consent event uniformly to all visitors regardless of jurisdiction is applying the least restrictive standard to visitors from states that require more.

State AG enforcement, not just federal. In December 2024 [CITE: source needed], OCR issued a Notice of Proposed Rulemaking on the HIPAA Security Rule; the final rule has been delayed until at least 2027, and proposed requirements should not be described as currently binding. But state attorneys general have not waited. The Healthline $1.55 million California settlement in 2025 demonstrates that state AGs are enforcing health data privacy against digital health publishers and platforms independently of OCR and FTC action.

What this means for your CMP configuration

A consent flow built for a single regulatory framework will create gaps. The practical requirement is a CMP that:

• Detects or infers visitor jurisdiction at session start, before any collection tag fires
• Applies jurisdiction-specific consent logic: express opt-in for Washington, Nevada, and Connecticut visitors; HIPAA-standard consent for all authenticated sessions regardless of state
• Gates tag firing by consent outcome, not by consent display. A consent banner that has been displayed but not acted on is not equivalent to consent having been obtained
• Logs consent state with a timestamp and jurisdiction signal to a first-party store, so the consent record is auditable independent of the CMP vendor's logs
• Differentiates between Zone 1 and Zone 2 contexts and applies the correct consent standard to each

A single consent event that fires once at the start of a session and unlocks all tags for the remainder of the visit does not satisfy MHMDA's pre-collection requirement for new data types that activate as the user moves deeper into the funnel.

The Teladoc litigation outcome is relevant context here. On June 25, 2025, the Southern District of New York denied Teladoc's motion to dismiss in a website privacy class action, allowing eight of twelve claims to proceed, including federal wiretapping claims under the Electronic Communications Privacy Act, and multiple state privacy violations. Federal wiretapping claims against a telehealth platform for client-side pixel behavior signals litigation risk that exists independently of OCR enforcement and FTC enforcement. That risk does not disappear when a covered entity is operating within HIPAA; it applies through a different legal mechanism to the same underlying data flow.

Building signal fidelity back after the PHI filter

Once the PHI scrubbing layer and the jurisdiction-aware consent architecture are in place, the residual signal deficit is real but addressable. The approaches that actually recover attribution quality in a compliant architecture are not the same as the approaches that work in an unconstrained measurement environment.

Offline conversion imports via hashed first-party identifiers. When a patient completes an appointment booking and later converts to a paid subscription or completes a clinical intake, that downstream event can be imported as an offline conversion to Google Ads, and Meta CAPI using a hashed email or phone number that was collected with proper consent and processed through the BAA-covered pipeline. The ad platform matches the hashed identifier to its own hashed records without either side revealing raw data. This is the signal recovery mechanism that most teams underinvest in because it requires a warehouse join layer to connect acquisition touchpoints to downstream clinical outcomes.

Warehouse-side attribution as the primary attribution method. For healthcare analytics architecture at any scale, the BigQuery, or Snowflake warehouse layer, where GA4 event data, and CRM/EHR patient outcome data join on a governed schedule within a BAA-covered environment, is the only place where full-funnel attribution can be computed accurately. Ad platform attribution dashboards are a lagging indicator in this environment; they are optimizing on the signal you can send them, not on the patient lifetime value signal that actually predicts sustainable growth.

First-party cohort building in a BAA-covered CDP. Rather than sending raw conversion events to ad platforms for lookalike audience generation, a BAA-covered CDP can build first-party cohorts of high-value patients based on clinical outcome data, then export hashed audience lists to ad platforms without exposing the underlying health data. The match rate on a high-quality first-party cohort is often better than the match rate on a pixel-based behavioral audience, and it does not require PHI to leave the BAA-covered environment.

Rebuilding conversion event architecture around predictive downstream events. In subscription health products, the signup, or form-submission event that most measurement stacks treat as the primary conversion is a weak predictor of long-term retention. The events that predict retention are structurally different: first consultation completed, subscription confirmed, second-session attendance. Feeding those events back to ad platforms as offline conversions (within the compliant pipeline) changes what the platforms optimize for at the bid level, and the compliance architecture is often cleaner for these events because they occur in authenticated contexts where the consent state is explicit and the BAA coverage is already in place.

None of this signal recovery is automatic. It requires deliberate measurement architecture decisions that connect the consent layer, the server-side routing layer, the warehouse join layer, and the ad platform feed into a governed pipeline. The Measurement Architecture Assessment is typically where these decisions get mapped before implementation, because retrofitting PHI controls onto an existing stack is significantly more complex than building them in from the start.

Most teams attempting this find that the compliance architecture and the signal quality architecture are the same problem. The scrubbing layer that protects against PHI exposure is also the layer that forces a decision about which signals are genuinely worth preserving versus which ones were convenient proxies that were never measuring what the team actually wanted to know.