Brux
Run free audit

HIPAA Position

Last updated: May 29, 2026

Brux's HIPAA Position

For compliance officers evaluating whether the Brux Testimonial Engine requires a Business Associate Agreement.

Summary

Brux is not a HIPAA Business Associate of dental practices using the Service, and no BAA is required.

This is true because the Testimonial Engine is designed so that no Protected Health Information (PHI) ever enters Brux's systems. The remaining Brux features (AI Visibility Audit, AI Ranking Tracker) operate on the practice's public-facing information, not on patient data.

We will not sign a BAA representing that we handle PHI when we have intentionally designed the Service so that we do not. Asking us to do so would create a false record of how data actually flows.

The legal framing

Under 45 CFR § 160.103, a Business Associate is an entity that "creates, receives, maintains, or transmits" PHI on behalf of a covered entity to perform a covered function.

Under 45 CFR § 164.502(e)(1)(i), a covered entity must obtain "satisfactory assurances" (i.e. a BAA) before disclosing PHI to a Business Associate.

The threshold question is therefore whether Brux receives PHI on the practice's behalf. We do not, by design.

How the Testimonial Engine actually works

The Testimonial Engine is a public, anonymous form. Here is the complete data flow:

  1. You distribute an anonymous link (bruxai.com/r/your-practice-slug) in whatever manner you choose: printed cards, signage, follow-up communications you send from your own systems. Brux does not contact your patients. Brux does not maintain a list of your patients. Brux does not send SMS or email to patients on your behalf.

  2. A patient visits the link. No login is required. No account is created. The patient is not asked for their name, contact information, date of birth, or any other identifier. Brux does not record their IP address, geolocation, device fingerprint, or session identifier.

  3. The patient fills out a form. They select a star rating, choose the dentist they saw from a dropdown of your dentists, choose the service from a list of services you offer, and type free-text answers about what they liked. They are warned on the form not to include medical record numbers or other identifying information.

  4. Brux runs an automated identifier filter on the free-text inputs before they reach the AI provider. Submissions containing medical-record-number-like patterns are rejected, and the patient is asked to revise and resubmit.

  5. Brux sends the cleaned inputs to Anthropic to generate a draft testimonial. Anthropic processes the inputs to produce the draft and returns it. Brux does not authorize Anthropic to train models on these inputs (where opt-out is available).

  6. The draft is returned to the patient's browser. Brux does not store the inputs the patient submitted. Brux does not store the draft. Brux's request body to Anthropic is not logged.

  7. The patient decides what to do with the draft. They can edit it and post it publicly (Google, Yelp, etc.), keep it for themselves, share it privately with your practice through an explicit consent flow, or discard it.

  8. If the patient chooses the consent flow, Brux relays the email via the practice's own outbound SMTP. The patient enters first name, last initial, and email, electronically signs a HIPAA Marketing Authorization, and clicks send. Brux generates the authorization PDF in memory, builds the email body in memory, then opens an SMTP connection to the practice's configured mail server (Gmail, Microsoft 365, custom — the practice provides the credentials in Settings) and relays the message. The email lives in the practice's own Sent folder under the practice's own compliance umbrella. Brux does not write the testimonial content, patient name, patient email, or signed PDF to any database. Brux does not upload the PDF to storage. Brux does not route the message through any third-party email processor (Resend, SendGrid, etc.). Once the SMTP relay completes, every piece of patient data evaporates from memory. The low-star private feedback path (§5.3) uses the same SMTP-relay design.

  9. Brux retains anonymous aggregate counts. For example, "Practice X received 14 testimonial drafts on 2026-05-29" and "Practice X had 3 testimonials authorized on 2026-05-29." These counts are by (practice, event type, calendar date) only — no patient identifiers, no testimonial content, no signed PDFs. They cannot be linked back to any individual patient because Brux never retained the link.

Why this means Brux does not handle PHI

For information to be PHI under 45 CFR § 160.103, it must be (a) individually identifiable health information that (b) relates to past, present, or future health status, payment, or treatment of an individual.

The inputs Brux receives through the Testimonial Engine are not individually identifiable, because:

  • No identifiers are collected. Brux does not request, receive, or store the patient's name, contact information, date of birth, social security number, medical record number, account number, license number, biometric identifier, photograph, IP address, device identifier, or other identifying number listed in 45 CFR § 164.514(b)(2)(i).
  • No combination of stored fields can re-identify the patient. Brux retains only practice-scoped aggregate counts and the AI-drafted text that the patient may or may not post. The aggregate counts are k-anonymous; the AI-drafted text contains only the information the patient chose to share publicly.
  • The identifier filter rejects MRN-like patterns before AI processing, providing defense in depth against accidental inclusion.

The Testimonial Engine therefore qualifies as a service operating on de-identified information under 45 CFR § 164.514, which is not subject to the Privacy Rule's restrictions and does not require a BAA.

What about the other Brux features?

Brux's other features do not involve patient information at all:

  • AI Visibility Audit analyzes the practice's website, public business listings, Google Business Profile, and public review platforms. It does not touch any system containing PHI.
  • AI Ranking Tracker queries AI search engines with searches like "best pediatric dentist in Boca Raton" and records which practices the AI engines name. It does not touch any system containing PHI.
  • Audit-complete email, welcome email, broadcasts, etc. go to the practice account holder, not to patients.

None of these features create, receive, maintain, or transmit PHI.

Practice-side obligations

Even though Brux is not a Business Associate, you (the practice) retain HIPAA obligations in how you distribute the testimonial link to patients:

  • Marketing rule (45 CFR § 164.508(a)(3)): Inviting an existing patient to write a review can be considered a marketing communication. The HIPAA marketing rule generally requires patient authorization for marketing communications that use PHI. If you are using a patient's email or phone number that you collected as part of providing treatment, you should evaluate whether the patient has consented to receiving marketing communications and whether your invitation falls within an exception (face-to-face, treatment-related, etc.). This is your obligation, not Brux's, because Brux does not contact your patients.
  • TCPA / CAN-SPAM: If you send the link via SMS or email through your own systems, comply with those laws independently.
  • Don't re-identify anonymous submissions: Do not associate the link distribution with patient-identifying lists in a way that re-identifies who submitted what. This would defeat the design assumption that makes Brux not-a-BA, and may create PHI on your end.

What to do if you believe PHI has reached Brux

If you believe a specific use of the Service has caused PHI to flow into Brux's systems (for example, a patient typed their full name into the free-text field), contact us immediately at privacy@bruxdentalmarketing.com with the practice slug and approximate date. We will delete the affected aggregate counts and confirm in writing.

For policy questions about this position statement, contact legal@bruxdentalmarketing.com.

Citations

  • 45 CFR § 160.103: Definitions (Business Associate, Protected Health Information)
  • 45 CFR § 164.502(e): Disclosures to Business Associates
  • 45 CFR § 164.508(a)(3): Marketing authorization requirements
  • 45 CFR § 164.514: De-identification of protected health information

This document is provided for informational purposes and is not legal advice. Each practice is responsible for its own HIPAA compliance program and should consult its own counsel.

HIPAA Position | Brux Dental AI Ranking