Patient data, handled with care.
This page is written for the billing lead doing the BAA conversation and for the security reviewer doing diligence. Both should walk away with enough information to make a decision.
Patient names never reach our application logs.
The @dentabill/logger package redacts patient names, dates of birth, member IDs, and Social Security numbers before any log line leaves the runtime. The redaction is applied at the transport layer, so an application engineer who forgets cannot leak PHI through a stray console.log.
Patient dates of birth are hashed with a per-organisation secret before they leave the dashboard. The DOB never touches our database in plain text. We use the hash for IVR identity verification with the payer; we cannot reverse it.
Every database read is org-scoped at a layer below the application. Cross-tenant access is a build-time error, not a code review heuristic. A developer cannot accidentally read another organisation's data even if the application code is wrong.
Call recordings are encrypted at rest with AES-256 and access-logged. They are retained for the period your BAA specifies and are purgeable on request within seven days.
We sign a BAA with every customer.
DentaBill is a HIPAA Business Associate. We sign a BAA before any production data touches our system. Our standard BAA is based on the OCR Sample Business Associate Agreement and is available for legal review on request.
We do not gate features behind tier on the BAA. Starter, Professional, and Enterprise customers all have the same BAA available. The Enterprise tier adds the option of mutual NDA and a customer-redlined version.
To request a draft BAA, write to our legal contact form. We respond within one business day.
The vendors we share data with, and what they do with it.
We update this list at least 30 days before a new sub-processor begins handling production data. Subscribe to our contact form to be notified.
| Vendor | Purpose | Region |
|---|---|---|
| Clerk | Authentication and organisation management | United States |
| Neon (Postgres) | Primary application database | United States |
| Upstash (Redis) | Job queue and rate limiting | United States |
| Retell AI | Voice synthesis and speech-to-text | United States |
| Anthropic | Post-call summarisation | United States |
| AWS S3 | Encrypted call recording storage | us-east-1 |
| Stripe | Payment processing (no PHI) | United States |
| Resend | Transactional email (no PHI) | United States |
| Sentry | Error monitoring (PHI-redacted) | United States |
Found something? Tell us first, in writing.
Send security findings to our contact form. We acknowledge within one business day and aim to resolve high-severity findings within seven days.
We do not run a public bug bounty yet. We do credit researchers in our release notes (with permission) and respect responsible disclosure. We will not pursue legal action against good-faith researchers operating within the scope below.
In scope: dentabill.example, the application at app.dentabill.example, and the API at api.dentabill.example. Out of scope: social engineering, denial of service, or any test that touches a customer's real PHI.
Where we are on SOC 2 and the public status page.
SOC 2 Type II is in progress with an external auditor. We expect a Type I letter in the next quarter and a Type II report after a 6-month observation window. We are happy to share our control narrative under NDA in the interim.
A public status page lands with the production deployment in Phase 5. Until then, incident communication runs through the email address in your BAA contact block.
If you are a security reviewer, ask us anything.
We will set up a call with whichever engineer wrote the part of the system you have questions about. Architecture, threat model, audit log, deletion paths.