HIPAA-safe by design, not by accident.
Chairwise was built around one hard product constraint: the platform never ingests, stores, or displays patient-identifiable data. Reviews, ads, bookings, and marketing analytics all run on operating metadata — not records of care — which keeps the standard per-chair retainer outside HIPAA Business Associate scope.
If you are a solo dentist evaluating us before signing, this is the short version of why that constraint holds. The field-by-field catalog and the enterprise BAA path live on the security page.
What the no-PII boundary actually means
Reviews, ads, and bookings are operating metadata — not records of care.
The line that keeps Chairwise outside Business Associate scope runs through the data the platform will and will not touch. Below is the plain-English read of that line — one card per channel.
Reviews are aggregates
A review is a star rating and a snippet. We never see the patient name attached to it — only the aggregate signal the practice uses to spot a trend or trigger a draft reply. The same boundary holds for AI-suggested replies: the model sees the snippet, not the author.
Ad data is campaign- and keyword-level
Performance Max and Smart Bidding data is kept at the campaign and keyword level — impressions, spend, conversions. We do not ingest patient demographics, lookalike audiences built from patient lists, or any patient-level targeting input.
Bookings are the appointment slot only
A booking is a time, a chair, and the patient name shown to your front desk. We never see clinical notes, diagnoses, treatment plans, chart fields, insurance, or anything that would normally sit in your PMS or EHR — the booking sidebar is the boundary, not a window.
No BAA required
Why this keeps Chairwise outside HIPAA Business Associate scope.
The HIPAA Business Associate definition (45 CFR §164.502(e) and §164.504(e)) applies to a vendor that creates, receives, maintains, or transmits protected health information on behalf of a covered entity. Because the platform never touches PHI on the standard per-chair retainer, it does not meet that definition — and the practice does not need a BAA to use it.
Standard retainer
A Business Associate Agreement is not part of the standard contract — because the standard contract has no PHI in it.
Reviews, ads, generative-engine SEO, and the booking sidebar all run on operating metadata. None of that qualifies as protected health information under HIPAA, so there is no business-associate relationship to paper over with a BAA — that is not an evasion, it is what the regulation predicts for a vendor that stays on the right side of the data line.
One field on the platform — Consultation.patientName on the booking sidebar — begins to qualify as a patient identifier, and its BAA posture is documented separately on the security page. Standard retainers do not see that field used in any HIPAA-relevant way.
This is a product framing, not legal advice. Run it past your counsel before you sign anything.
What we never see
The four things the platform does not have.
The shortest version of this page, for the stressed-dentist skim.
We don’t store patient names on reviews, ads, or SEO data — only aggregates and snippets.
Dates of birth are not in the platform. Not on intake, not in the model, not in storage.
We never see insurance, payer, or coverage details — those live in your PMS, not here.
Not in the platform: treatment records, clinical notes, and chart fields of any kind.
Ready when you are
Priced per chair. HIPAA-safe by design. No BAA on the standard retainer.
The fastest path from this page to a signed contract is the per-chair math on the pricing page. Send the technical security page to your compliance lead alongside it and the whole conversation usually closes inside a week.
Operating metadata only · outside Business Associate scope · enterprise BAA available on request.