HIPAA and Business Associate Agreements
If your patients talk to Avren, Avren handles protected health information on your behalf. This page says exactly what that means, who else touches it, and what is actually in place today — including the parts that are not finished.
The short version
Avren acts as a business associate to your practice. You remain the covered entity. We sign a Business Associate Agreement with every practice before any real patient data reaches the system, and we do not begin handling patient conversations until it is executed.
What we do not claim. Avren holds no SOC 2 report, no HITRUST certification and no ISO 27001 certification. We have not commissioned a third-party penetration test. Nobody should read anything on this page as implying otherwise. HIPAA has no certification scheme — any vendor telling you they are “HIPAA certified” is describing something that does not exist.
What information Avren handles
Only what a patient types into the app, and what your practice records in the portal:
- The patient’s name and the email address your practice has on file for them
- The full text of their conversations with the concierge
- Which practice they belong to, and which of your locations
Avren does not receive your clinical notes, your imaging, your billing records or your practice management system’s data. There is no integration that reads them, and the concierge answers only from the treatment menu, hours, team and policies you enter yourself.
The safeguards that exist today
These are engineering facts about the running system rather than intentions. Each one is something you could ask us to demonstrate.
One practice cannot read another’s data
Separation is enforced by 111 row-level security policies in the database, not by application code. Every query the application makes asks for all rows; the database returns only the practice the signed-in person belongs to. A forgotten filter in the application cannot leak another practice’s data, because the application is not what is doing the filtering.
Patient data requires a second factor
Five tables hold anything patient-identifying: patients,
conversations, messages, tool_calls and
attributions. Each carries a restrictive database policy that
returns nothing at all to an account that has not signed in with a second factor. This is a
floor in the database, not a setting in the app, and it cannot be turned off from the portal.
An audit trail that contains no clinical content
Every write to a patient-facing table is recorded: which practice, which staff account, what action, which record, and when. The audit table has no column capable of holding message content, so the log cannot itself become a second copy of the conversation.
Encryption
All traffic runs over TLS. Data at rest is encrypted by our database provider. We rely on Supabase for at-rest encryption rather than implementing our own — that is a deliberate choice, and it means their controls are the ones that apply.
Deletion is deliberate and recorded
Destroying the content of a conversation requires a stated reason of at least ten characters, is not reachable from any signed-in session, and writes one audit entry per destroyed record. Hiding a conversation from your team does not hide it from the patient — their own copy remains visible to them, because it is their conversation too.
Subprocessors — who else touches the data
Every third party that receives any part of it. If this list changes we will update this page.
| Who | What they receive | Where |
|---|---|---|
| Supabase | The database and authentication. Everything above is stored here. | AWS, US East (Ohio) |
| Vercel | Application hosting. Requests pass through, including message text in transit. | United States |
| Anthropic | The language model. Receives the practice’s knowledge base and the text of the conversation in order to answer it. | United States |
| Cloudflare | Domain name resolution only. Cloudflare is not in the traffic path and does not receive request or response content. | Global DNS |
The Avren portal loads no third-party scripts, fonts or trackers at runtime. Everything it needs is served from our own domain. This marketing site does load fonts from Google, which receives visitors’ IP addresses — that is this page, not the product, and no patient data is involved.
Questions your counsel will ask that this page cannot yet answer
We would rather list these than write something that reads well and turns out to be untrue. Ask us directly and you will get a straight answer:
- Whether a Business Associate Agreement is in place with each subprocessor named above
- Our data retention period and deletion timeline once a practice leaves
- Breach notification timelines beyond what the BAA itself specifies
- Whether patient conversation content is used to train any model
- Sub-processor change notification periods
Getting a BAA
Ask, and we will send one before you enter a single patient. Onboarding is manual and always will be at this stage, so there is no path by which a practice starts using Avren with real patients before the paperwork is done.