Honest, specific, and a little dry on purpose.
Chairwise sells marketing and front-desk AI to dental practices — a market where protected health information is one careless integration away. This page is the short, factual version of what we store, how it is secured, and where the BAA / HIPAA path stands today.
If you are evaluating us against a compliance checklist, the fastest path is to forward this page to your compliance lead and book a 15-minute call with the team.
What client data we collect
Four tables. The fields we actually store.
Compliance posture is easier to defend when the surface is small. Below is the full data catalog the platform writes to — the fields, the table they live in, and what we use them for. We are not aware of any other data class.
Clinic info
Clinic.nameClinic.timezoneClinicMember.roleClinicMember.userId
Identifies the practice and its timezone, and grants each signed-in user a per-clinic role ("owner" or "staff") so the dashboard scopes every read by user.
Leads
Lead.clinicNameLead.locationLead.pmsLead.createdAt
Captured from the /get-started form. Lets the team route inbound sign-ups by state and practice-management system; never reused for marketing.
Bookings
Consultation.scheduledForConsultation.patientNameConsultation.status
Surfaces the upcoming-consultations sidebar inside the dashboard. The patient name is a direct identifier and is the only field on the platform treated as such — see the PHI posture call-out below.
Reviews
Review.ratingReview.sourceReview.snippetReview.occurredAtReviewReply.bodyReviewReply.sourceReviewReply.model
Powers the reviews monitoring view and the AI-suggested reply flow. ReviewReply.provenance flags whether each draft is machine-generated (and which model produced it) versus human-edited.
How it is stored and secured
Three short rows a compliance reviewer can walk line by line.
Every row below is verifiable on the platform today — there is nothing aspirational in this section.
Storage
Managed Postgres, encrypted at rest
Every application table lives in a managed Postgres instance provisioned by the platform. Connections enforce TLS 1.2+ on every endpoint, and the underlying storage is encrypted at rest with rotation handled by the control plane.
Access control
Per-user scoping on every route
Every /api/<resource> handler is gated by requireAuth() and scopes every Prisma read with where: { userId: user.id } (or where: { clinicId } for multi-tenant tables). Admin endpoints additionally call requireAdmin(). Staff sign in through SSO with hardware-key support, and the production plane runs quarterly access reviews.
Audit & monitoring
Immutable logs, segregated from prod
Privileged actions write to immutable audit logs with a retention of more than one year and are exportable on request. Day-to-day request logs, queue events, and error traces are retained for 30 days in a store that is segregated from the production database, so a log query cannot leak a clinical field.
BAA & HIPAA flow
How the BAA lands, and what it covers.
The BAA flow is on the public roadmap. The four-step process below is the same one enterprise contracts use today — we have just written it down so a non-technical reviewer can read it end to end.
- Step 01
Request the template
Email the team with your practice details and the contracting entity. We send back the current BAA template and a one-page summary of the affected sub-processors.
- Step 02
Review with your counsel
Your compliance and legal teams walk the agreement. Most redlines land on sub-processor scope and breach notification timing; we turn redline cycles inside two business days.
- Step 03
Countersign
Once terms align, both sides execute. The active BAA is tied to your clinic record so the coverage travels with the contract, not with an individual account.
- Step 04
Active coverage
After execution, the documented sub-processor list, breach-notification terms, and data-residency commitment are the ones in force for your account — and we notify you at least 30 days before adding a new sub-processor that touches the data plane.
What the BAA covers
Sub-processors
The agreement lists every sub-processor that may touch your data, including the database host, the object storage region, and the model API provider, and commits us to a 30-day notice on any new addition.
Breach notification
Confirmed incidents are contained within one hour of detection. Affected customers are notified within 72 hours with the scope, observable impact, and the remediation already underway.
Data residency
Region pinning (US, EU, additional US regions) is available on enterprise contracts so practices that need a specific residency boundary can pin one. The default region is set per account on signature.
Honest PHI posture
One field qualifies as patient-identifying. The rest is operating metadata.
We do not claim the platform is HIPAA-certified — that wording would overstate what is in place. What we can say accurately: Consultation.patientName is the only direct patient identifier stored anywhere in the system, and is the only field on the platform that begins to qualify as PHI. Clinic metadata, lead intake fields, review ratings and snippets, ad spend, and audit metadata are all operating metadata that does not qualify as PHI.
The BAA above establishes the contractual posture for that single field — including breach notification within 72 hours and a 30-day sub-processor change notice — so a compliance reviewer has a clean read on the boundary, not just the marketing claim.
Frequently asked
The questions a dental compliance lead usually opens with.
If something here does not match the answer your team needs, the fastest path is an email to the team — every FAQ below is answered faster in person.
Still have questions
Forward this page to your compliance lead.
The most useful next step is a 15-minute call with the team — we walk through the data path line by line and answer the specific questionnaire your team is filling out.
Schema-faithful data handling · access gated on every route · BAA available on enterprise contracts.