What protects patient data
- Included
Encryption
Transport security is enforced on every connection by a two-year HSTS policy, and data is encrypted at rest by the platform. Patient identifiers never appear in a URL — record addresses carry an opaque identifier and nothing else — and raw error detail is stripped before anything is logged.
- Included
Access control in the database
Row-level policies decide what each role can read, generated from a single declared manifest rather than written by hand, and tested by an allow-and-deny matrix that runs against the database itself.
- Included
Minimum necessary by default
A technician can reach only the clients they are assigned to, and can read back only the notes they authored. That is enforced at the data layer, so it holds whether the request comes from the interface or from the API.
- Included
Append-only audit log
Written by database triggers rather than application code, hash-chained per organization so tampering is evident, verified nightly by a scheduled job, and retained for six years. Update, delete and truncate are revoked at the database level.
- Included
Multi-factor authentication for staff
Time-based one-time codes, enrolled per staff account, promoting the session only once the code is verified. Org-wide enforcement and a per-user status view for practice owners are not built yet — today enrolment is per person, from Settings.
- Included
Offboarding that ends access immediately
Removing someone takes effect on their very next database statement rather than when their session happens to expire. There is no window in which a departed staff member can still read a record.
- Roadmap · M6
Backup and restore
Point-in-time recovery, with a documented restore drill completed before any real patient data is accepted rather than after an incident. The drill is what makes this a control rather than a setting, and it has not been run yet.
Sub-processors
These are the outside services that hold or move data on our behalf. The list is published rather than available on request, because a practice signing a business associate agreement accepts our vendors along with us and needs to see them before signing.
- Supabase — database, file storage and sign-in. This is the one that holds the records: clients, notes, documents and staff accounts.
- Vercel — hosting and delivery for this site and for the application itself. Serves the files that make up the interface; the records stay in the database.
- Resend — transactional email. Staff invitations, portal invitations and any reminder sent by email. Holds the recipient address and the message text.
- Twilio — SMS delivery, for practices that switch reminders on. Holds the recipient number and the message text.
- Lunastric — subscription billing. Card details are entered on their hosted checkout and never reach our servers; we receive the result and a customer reference.
- Cloudflare — DNS for our domains, and routing for mail sent to us. Not in the path of practice data.
The reminder vendors deserve two specific notes, because they carry a message to a patient’s phone. Message text is rendered before it reaches the delivery provider and carries the appointment time and practice name only, never a reason for the visit — a reminder is read on a lock screen by whoever is holding the phone. Neither the destination nor the message body is written to our logs.
Customers are notified of any addition to this list rather than left to find it here, and no sub-processor receives real patient data before an agreement covering it is in place.
The controls that map to specific HIPAA safeguards are set out in HIPAA compliance, and the surfaces a patient’s own data passes through are covered in intake and the patient portal.