Is Birdeye HIPAA Compliant? Reviews and Patient Data

Yes, Birdeye can be used in a HIPAA-compliant way, because Birdeye publishes standard HIPAA Business Associate Agreement terms that apply to customers who are covered entities providing protected health information to Birdeye. Confirm your own addendum is actually in place with your account contact rather than assuming it came with the contract. The harder problem is not the BAA at all. Reviews are public by design, and a patient naming their procedure in a five-star review creates an exposure no contract addresses. The advertising layer around it creates another. Curve is the HIPAA-compliant tracking layer for that side, with a signed BAA on every plan.

The direct answer, in more detail

Birdeye is a reputation and patient experience platform: review generation, review monitoring, listings management, surveys, webchat, and two-way patient messaging. Several of those functions touch PHI directly. Sending a review request to a patient after a visit is a disclosure that a specific person received care from a specific provider, which is PHI regardless of whether the message says anything clinical.

Birdeye's published position is that it has standard HIPAA addendum terms for covered entity customers, and it states it has received independent third-party verification of HIPAA compliance. That gives you a documented starting point, which is more than many reputation vendors offer.

What it does not give you is an automatic assumption. Three things are worth confirming for your own account:

• That the addendum is actually attached to your agreement. The terms exist publicly. Whether they are incorporated into your specific contract is a question for your account executive or Birdeye's privacy contact.
• Which products the coverage spans. Birdeye's published terms reference its business and enterprise services. Your deployment may include modules or connected channels worth naming explicitly.
• What your team is actually sending through it. A BAA does not stop staff from typing clinical detail into a text thread or a review response.

If you cannot verify any of these from your own paperwork, verify current terms directly with the vendor before treating Birdeye as covered.

Where Birdeye is genuinely fine

With an addendum in place, the core reputation workflow is a reasonable fit for healthcare. Requesting reviews after a visit, monitoring what patients say across sites, managing location listings for a multi-site group, and running a patient messaging channel are all normal business associate activities.

Multi-location practices get the most out of it, because listings and reviews fragment fast across locations and the manual alternative does not scale. Our piece on the DSO marketing technology stack covers how these tools fit into a group's wider stack.

The important framing: Birdeye handling PHI under a BAA is the easy part. The hard part is that its output is deliberately public, and that its behavior is measured by marketing tools that have signed nothing.

What the BAA does and does not cover here

A BAA binds a vendor to safeguard PHI, limit how it is used and disclosed, report breaches, and return or destroy the data when the relationship ends. Birdeye's published terms include the standard restrictions, including that it may not use or disclose PHI for fundraising or marketing purposes, and that it may not use or disclose PHI in a manner that would violate HIPAA if the covered entity did it.

Inside that coverage: patient contact data you upload, message content in the platform, survey responses, and the records Birdeye holds while delivering the service.

Outside it, and this list is where practices get hurt:

• The review itself, once published. A review posted to Google or another public site is public. Birdeye moved the request. It does not own or control the patient's words.
• Your response to that review. If a staff member confirms a person was a patient, or references their treatment, that is a disclosure made by you, in public, that no vendor contract touches.
• Your website's tracking scripts, including those on the pages where you display review widgets or run webchat.
• Ad platforms. Meta and Google do not sign BAAs for their advertising products, and nothing in a Birdeye addendum changes that.
• Downstream systems you sync to, each of which needs its own business associate assessment.

Say the uncomfortable thing plainly: the single largest HIPAA risk in a reputation platform is not the vendor's security posture. It is your staff replying to a public review in a way that confirms a care relationship. OCR has been explicit that responding to online reviews with patient information is a disclosure, and enforcement in this area has not been theoretical.

Responding to reviews without disclosing

The rule is simple and unpopular. Do not confirm the person is a patient. Do not reference their visit, provider, treatment, or outcome, even to correct something false they wrote. Reply generically, in language you would be comfortable seeing quoted, and move the specifics to a private channel that is actually covered.

A negative review that misstates facts is the hardest case, because the instinct to defend the practice is strong and the correction almost always requires clinical detail. That instinct is the thing to train out of the team. The public reply says the practice takes concerns seriously and gives a way to reach a named contact. Nothing more.

Where the ad tracking problem shows up

Reputation platforms sit in the middle of the marketing funnel, which is exactly where tracking accumulates.

Three patterns create exposure, and all three are common:

1. Review and webchat widgets on service pages. The widget itself may be harmless. The page it sits on usually is not, because the URL names the service line and the ad pixels on that page transmit it along with a persistent browser identifier.
2. Webchat as a conversion event. Teams frequently fire a Meta or Google conversion when a chat opens on a treatment page. That event says an identifiable browser inquired about a named service on a healthcare site.
3. Feeding reputation or patient data into ad platform audiences. Uploading patient contact lists to build custom audiences or lookalikes is a disclosure of PHI to a platform with no BAA. It is also one of the easiest things in the world to do accidentally, because the interfaces make it a two-click operation.

This is the mechanism behind healthcare pixel litigation that has cumulatively crossed $100 million in settlements, including Advocate Aurora at roughly $12.225 million. The plaintiffs' theory does not require a diagnosis in the payload. It requires that an identifiable person's health interest was disclosed to a third party. A service page URL plus a browser identifier does that on its own. Our explainer on why client-side pixels create HIPAA exposure walks through the payload in detail.

The architecture that works

Keep three planes separate and the whole thing gets simpler.

1. The clinical plane. Your EHR and practice management system. PHI lives here and moves only to vendors with signed BAAs.
2. The engagement plane. Birdeye and similar tools, operating under an addendum, holding the minimum patient data needed to send a request or run a conversation.
3. The measurement plane. Ad platforms and analytics. These receive conversion signals and matching keys. They never receive service context, page URLs describing care, or uploaded patient lists.

Two supporting habits make the separation hold. First, generic URLs. A path of /request-appointment carries no clinical meaning; a path naming a procedure carries plenty, and it travels in referrers and analytics whether you intended it or not. Second, a single decision point before anything reaches an ad platform, so the answer to what leaves is a configuration you can read rather than a guess about what a tag does.

For groups tracking performance across many locations, our guide to attribution across multiple practice locations covers how to keep location-level reporting without location-plus-service leakage.

How Curve handles a reputation-heavy funnel

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare. It sits where the pixel used to sit and gives you a place to decide what leaves.

The Curve tracking script installs on your site in place of the Meta Pixel and Google tag. Events go to Curve's US-hosted infrastructure rather than straight to the ad platforms. From there:

• Per-destination field mapping decides what forwards. Only fields you explicitly map reach a given destination, configured separately per destination. Page URLs, chat topics, and query parameters stay behind unless you deliberately map them. The default is that nothing goes.
• Identifiers are SHA-256 hashed to meet each platform's conversion API requirements before forwarding.
• Neutral event aliases keep the service line out of the ad account. A chat start or appointment request forwards as a generic event rather than one naming the treatment, so nobody browsing Ads Manager sees a condition.
• PHI-pattern detection monitors payloads and flags PHI-shaped values such as SSNs, MRN-style identifiers, dates, and long numeric sequences. It is a monitoring layer that tells you when something upstream changed. The protection is the field mapping plus hashing.
• Bridge tokens preserve attribution across click-outs into separate booking or intake tools, so the conversion still credits the right campaign without carrying content across the boundary.
• Incoming webhooks match outcomes back by email, click ID, or bridge token, and incoming data cannot override protected core attribution and contact fields.
• Offline conversion uploads let you push confirmed outcomes from a CRM or practice management system with click-ID matching, so late-confirming conversions still reach the campaign that earned them.

Clean conversions forward server-side to Meta CAPI, Google Ads Enhanced Conversions, TikTok Events API, Microsoft, LinkedIn, and GA4. Because the path is server-side, it is unaffected by ad blockers and browser tracking prevention, which usually raises measured conversion volume rather than lowering it. A signed BAA is included on every Curve plan.

Checklist for a reputation platform in a healthcare practice

1. Confirm your BAA in writing. Ask your account contact for the executed addendum and file it with your compliance records.
2. Name the modules it covers. Messaging, surveys, webchat, listings. Do not assume the coverage is uniform across everything you have turned on.
3. Train the review response policy and enforce it. No confirmation of patient status, no clinical detail, no exceptions for negative reviews.
4. Audit who has access. Front desk staff replying publicly from a shared login is a common weak point.
5. Check what patient data is uploaded and where it syncs. Especially any path that touches an ad platform audience tool.
6. Read your service page URLs as a stranger would. Rename anything naming a condition or treatment.
7. Watch the network tab on a page with a widget installed. Filter to ad platform domains and read what actually leaves. This is the only step that tells you the truth.

Frequently asked questions

Does Birdeye sign a BAA?

Birdeye publishes standard HIPAA business associate terms that apply to covered entity customers providing PHI to its services, and lists a privacy contact for related inquiries. Confirm your own agreement includes the executed addendum rather than relying on the published terms alone.

Is asking a patient for a review a HIPAA issue?

Sending the request through a vendor is fine when a BAA covers it, because the request itself is a business associate activity. The issue is what comes back. A patient can write anything publicly, and you cannot un-publish it or reply to it with detail.

Can we respond to a negative review that gets facts wrong?

Yes, but not with facts about the patient. Confirming someone was seen at your practice is a disclosure. Reply generically, invite a private conversation, and resolve the specifics in a channel that is actually covered.

Does a BAA cover the reviews themselves?

No. Public reviews live on public platforms. A BAA governs the vendor's handling of PHI you provide, not content a patient chooses to publish about their own care.

Can we upload patient lists to build ad audiences?

Not if the list identifies people as patients, which by definition it does. Meta and Google do not sign BAAs for their advertising products, so that upload is a disclosure to an uncovered vendor. Use conversion-based optimization instead.

Is a review widget on our website a tracking risk?

The widget is usually not the risk. The page is. If the page URL names a treatment and your ad pixels are firing on it, the disclosure happens regardless of what the widget does.

What about webchat transcripts?

Treat them as clinical records. They routinely contain symptoms and medication names because patients volunteer them. Make sure the transcript store is covered by your addendum and that nothing from it feeds analytics or ad tooling.

Where to start

Birdeye publishes HIPAA business associate terms for covered entity customers, which makes it usable with patient data once you have confirmed your own addendum. The exposures that remain are the ones a contract cannot solve: public review responses written by staff, and the ad tracking wrapped around the pages where reputation tools live.

Curve handles the second one. Server-side collection, per-destination field mapping, hashed identifiers, neutral event aliases, and bridge-token attribution let you keep running Meta and Google campaigns against real patient acquisition without disclosing what anyone asked for. A signed BAA is included on every plan. Run our free compliance scanner against your site to see what is leaving right now, or visit curvecompliance.com to talk through your stack.

Reviewed August 2026. Vendor BAA policies change. Confirm current terms with the vendor.