Consent Mode and HIPAA: Where They Do Not Overlap

Consent Mode and HIPAA do not overlap in the way most clinics assume: Consent Mode is a signal that tells Google whether a visitor agreed to cookies and personalized advertising, while HIPAA asks whether a covered entity may disclose protected health information to a third party at all, and it answers that question with a Business Associate Agreement or a valid patient authorization. A cookie banner is neither of those things. Curve is the HIPAA-compliant tracking, attribution, and analytics platform for healthcare, built around the assumption that consent signals and HIPAA obligations are separate problems that both have to be solved. A signed BAA is included on every plan.

What Consent Mode actually is

Consent Mode is a mechanism for passing a visitor's consent state to Google tags. Your consent platform sets a small number of signals, and Google's tags adjust their behavior accordingly.

The signals cover things like whether advertising storage is permitted, whether analytics storage is permitted, whether user data may be sent for advertising purposes, and whether personalization is allowed. When consent is denied, tags are expected to operate in a restricted way, sending cookieless pings rather than setting identifiers, with Google applying modelling to estimate the conversions it can no longer directly observe.

It exists because European cookie law requires consent before non-essential storage, and because Google needed a standard way for advertisers to communicate that state. It is fundamentally a cookie-and-personalization compliance mechanism with a measurement-recovery feature attached.

Understand what that means for a clinic. Consent Mode governs how Google's tags behave. It does not govern what your website chose to put into those tags in the first place.

What HIPAA actually requires

HIPAA asks a different question with a different structure. If you are a covered entity or a business associate, and you want to disclose protected health information to an outside party, you need a legal basis. For marketing vendors, there are two realistic ones.

A Business Associate Agreement. A contract under which the vendor agrees to safeguard the information, use it only for the permitted purposes, restrict its own subcontractors, report breaches, and accept direct regulatory obligations. This is the normal path for a vendor performing a function on your behalf.

A valid patient authorization. A specific, written permission from the individual. HIPAA is prescriptive about what one contains: a specific description of the information to be disclosed, who is disclosing it, who is receiving it, the purpose, an expiration date or event, the individual's signature and date, a statement of their right to revoke and how, a statement about whether treatment can be conditioned on signing, and a warning that information may be redisclosed by the recipient and lose its protection.

Now look at a cookie banner against that list. It does not identify the individual. It is not signed. It does not describe the specific information disclosed. It does not name the recipient in the required way. It does not carry an expiration event, a revocation statement, or a redisclosure warning. It is not, in any respect, a HIPAA authorization, and no configuration of Consent Mode turns it into one.

The three propositions that follow

Consent does not create a lawful disclosure under HIPAA

This is the spine of the whole issue. If sending identifiable health information to a vendor without a BAA would be an impermissible disclosure, a visitor clicking Accept does not make it permissible. The visitor was not asked the question HIPAA requires them to be asked, in the form HIPAA requires it to be asked in.

Put practically: if your bariatric surgery page fires an advertising tag that transmits a persistent identifier to a platform that has not signed a BAA, the problem is not fixed by the fact that a banner appeared first.

A BAA does not resolve your consent obligations

The reverse is also true and it catches organizations moving in the opposite direction. A vendor with a signed BAA can lawfully receive protected health information from you under HIPAA. That says nothing about whether you were permitted to set non-essential cookies on a visitor's device under state privacy law or European cookie rules.

You can be perfectly correct under HIPAA and still owe a consent mechanism. Both frameworks apply on their own terms.

Consent Mode's denied state is not a HIPAA safeguard

The most technically consequential point. When consent is denied, Google's tags are expected to send cookieless signals rather than nothing at all. Those pings can still carry contextual information, including the page the visitor was on.

On a healthcare site, the page is often the disclosure. A URL path naming a condition or a procedure carries health information about whoever requested it, even without a stored identifier. Treating a denied consent state as an equivalent to "no data leaves" is a misreading that has cost clinics dearly, and it is one of the reasons client-side pixels have generated so much healthcare litigation.

Where they genuinely do interact

The frameworks are separate, not unrelated. Three real interactions are worth knowing.

Consent state can be an input to your tracking decisions. Nothing stops you from treating a denied advertising consent as an instruction to suppress a conversion event entirely, rather than sending a degraded version of it. That is a stricter posture than Consent Mode contemplates, and it is a reasonable one for a healthcare site.

Both produce evidence. A compliance officer reviewing your marketing will want to see consent records and a data flow description. They serve different arguments and they live in the same reporting pack. Our piece on compliant conversion tracking setup covers the flow side.

Both are undermined by the same root cause. Tags you do not control, firing data you did not inventory, to vendors you did not evaluate. Fixing the architecture improves your position under both frameworks at once.

The reasoning that gets clinics into trouble

• "We implemented Consent Mode v2, so we are covered." Covered for what. Consent Mode addresses cookie consent signalling to Google. It does not address whether the disclosure is permissible under HIPAA, and it does nothing at all about non-Google vendors.
• "The patient accepted our cookie banner." They accepted cookies. They did not sign a HIPAA authorization, which requires elements a banner does not have.
• "With consent denied, no data goes to Google." Denied consent restricts storage and personalization. Cookieless pings can still carry context, and on a health site the page path is frequently the sensitive part.
• "We only send hashed emails, so it is de-identified." Hashing is a strong control and it is not the same as de-identification. A hash used specifically to match a person to an advertising profile is functioning as an identifier. Hashing narrows exposure, it does not remove the need for a lawful basis.
• "Our privacy policy discloses it." A privacy policy is notice. HIPAA's authorization requirements are not satisfied by notice, and the elements it demands are specific for exactly this reason.
• "The ad platform's terms say we must not send PHI, so we are protected." That clause protects the platform. It does not protect you, and if your site is sending it anyway, the clause is evidence that you were on notice.

How Curve treats the two frameworks separately

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare, and the design reflects the distinction directly: consent controls what tracking is permitted to happen, and field-level controls determine what may leave regardless of consent state.

The tracking script installs on your clinic site in place of the Meta Pixel and Google tag. Events go to Curve's US-hosted infrastructure rather than directly to ad platforms. That interposition is what makes both controls possible.

• Per-destination field mapping. Only explicitly mapped fields forward to a given destination, and the default is that nothing goes. This is the HIPAA-side control: it is not conditioned on a visitor clicking a button, because a disclosure that requires a BAA is not made lawful by a click.
• Neutral event aliases. The ad platform sees a neutral event name rather than the service line. The page context that Consent Mode's cookieless pings would carry is not part of what forwards.
• SHA-256 identifier hashing. Identifiers are hashed per each platform's conversion API requirements before forwarding, so what arrives is a match key rather than a contact record.
• Built-in consent management. Granular cookie categories, jurisdiction-specific opt-in or opt-out behavior, configurable banner content and expiry, plus consent analytics and audit logs. This is the privacy-law-side control, and it is enforced at collection rather than handed as a hint to a separate tag.
• PHI-pattern detection. A monitoring layer that flags PHI-shaped values arriving in payloads, so a form or integration that starts sending something new is noticed. Detection-only by policy, so it is an alarm rather than a filter.
• Signed BAA on every plan. Which is the actual HIPAA mechanism, and the reason detailed data can sit inside Curve at all.

The result is that a denied consent means the tracking does not happen, and an accepted consent still does not widen what leaves your platform. Neither Meta nor Google will sign a BAA for their advertising products, so the correct engineering answer is to make sure they never receive anything that would require one.

A practical way to think about it

Ask the two questions in order, separately, for every data flow.

1. Am I permitted to make this disclosure at all? A HIPAA question. Answered by a BAA, by a valid authorization, or by the data genuinely not being protected health information. If the answer is no, consent is irrelevant and the flow must not exist.
2. Am I permitted to set this storage and process this personal data for this visitor? A privacy-law question. Answered by your consent mechanism, applied per jurisdiction.

Both must be yes. Neither substitutes for the other. Most bad healthcare tracking configurations come from answering only the second question and assuming it settled the first.

Frequently asked questions

Does Consent Mode make Google Analytics HIPAA compliant?

No. Consent Mode communicates a cookie consent state to Google's tags. Google does not sign a BAA for its advertising products, so no consent configuration creates a lawful basis for disclosing protected health information to them.

If a patient clicks Accept, can I send their data to Meta?

Not on that basis. Clicking Accept on a cookie banner is not a HIPAA authorization, which requires a signed, specific document naming the recipient, the information, the purpose, an expiration, revocation rights, and a redisclosure warning. Meta does not sign BAAs for advertising products either.

Does a signed BAA mean I can skip the cookie banner?

No. A BAA answers the HIPAA question about disclosure to that vendor. It says nothing about state privacy law or European cookie rules governing non-essential storage on a visitor's device. Both obligations stand independently.

What actually happens when consent is denied under Consent Mode?

Google's tags are expected to restrict storage and personalization while still sending cookieless signals, with modelling used to estimate unobserved conversions. That is not the same as sending nothing, which matters on a healthcare site where the page path itself can be the sensitive element.

Is hashing enough to take data outside HIPAA?

Not on its own. Hashing is a meaningful control and it materially narrows exposure, but a hash used to match a person to an advertising profile is still functioning as an identifier. Treat it as a safeguard within a lawful architecture rather than as an exemption from one.

Which framework should we design for first?

HIPAA, because it is the one that can make a data flow impermissible outright. Design so that nothing requiring a BAA ever reaches a platform that will not sign one, then layer consent on top to govern what is permitted to happen at all.

Does this analysis change for a non-covered entity?

The HIPAA question may fall away for an organization that is genuinely neither a covered entity nor a business associate, but consumer health privacy statutes, state privacy laws, and FTC enforcement over health data still apply. The consent obligations do not disappear, and the sensitivity of the data does not either.

Where to start

List every destination receiving data from your clinic site and, for each one, write down which of the two lawful bases you are relying on: a signed BAA, or the fact that nothing requiring one is being sent. If a destination has neither, you have found the flow to fix, and no consent configuration will fix it for you.

Curve keeps the two frameworks separate by design: per-destination field mapping where nothing forwards by default, neutral event aliases, SHA-256 hashed identifiers, and PHI-pattern monitoring on the HIPAA side, plus built-in consent management with granular categories, jurisdiction-specific behavior, and audit logs on the privacy-law side, with a signed BAA on every plan. Run our free compliance scanner to see what your site currently sends, or visit curvecompliance.com. Related reading: whether the Meta Pixel or Conversions API is safe for healthcare.

Reviewed August 2026. Consent frameworks, ad platform requirements, and HIPAA guidance change frequently. This is not legal advice. Verify current requirements with your own counsel before implementation.