Trust · Security
What happens to the data you give us.
Written for the person who has to sign off on this — the controls, how they are enforced, and what your team can verify.
Every read of a patient record is on the record.
Access is written to an append-only log with actor, action, time, and outcome. Entries cannot be edited or deleted afterwards — not by a user, not by an administrator, and not by our own application. The database refuses the write.
Audit log · access to patient records
| Time | Actor | Action | Record | Outcome |
|---|---|---|---|---|
| 09:41:07 | M. Keller, RN | Opened patient record | MRN ····1902 | Recorded |
| 09:41:38 | M. Keller, RN | Read call transcript | Contact of Aug 26 | Recorded |
| 09:44:12 | D. Osei, Care coordination | Ran cohort query | 214 records | Recorded |
| 09:47:03 | Reporting session | Read outside own organization | — | Refused |
| 09:52:41 | Application service | Edit to an audit entry | Entry 88112 | Refused |
Both refusals are the database speaking, not the application. The cross-organization read returned nothing, and the last row is our own software being refused: audit entries are append-only, enforced by a trigger that binds us too.
Three gates that fail closed.
The same philosophy runs through the rest of the software. Where a safeguard matters, it is a refusal in the machine — not a step in a document.
- 01
Agreements before data
The system will not place a patient call until every subprocessor agreement that covers the call is confirmed in configuration. Not a step in an onboarding checklist — a check the software runs before it dials.
- 02
Certification before contact
A clinical program that has not been certified cannot attach to a real patient. The block is a database constraint, so it holds on a bad day exactly as it does on a good one.
- 03
Doubt means stop
If the scheduler cannot confirm a patient is safe to contact, it does not contact them. Every gate on this page fails closed: the absence of a confirmation is treated as a no.
What certification involves clinically is set out on Clinical design. This page cares that the gate cannot be skipped.
Security posture is easy to assert and hard to demonstrate. So this page sticks to controls that can be shown rather than described. A log your own team can read. A constraint that refuses the write. A scheduler that declines to dial. Bring your security review — every control above is testable from your side of the engagement.
For the security reviewer: every control, and where the data physically sits
Controls the software enforces
Not policies that describe intended behavior — constraints the system applies whether or not anyone remembers to.
- HIPAA
- Built to HIPAA requirements: PHI encrypted in transit and at rest, access controlled per user and organization, and every read of a patient record written to an audit log.
- Data isolation between organizations
- Every record belongs to exactly one organization, users authenticate only into their own, and every query is scoped to the caller's organization. No endpoint exposes another customer's data.
- Audit logging
- Access to patient records and clinical content is logged with actor, action, time, address and outcome, and is reviewable after the fact rather than only in the moment.
- Tamper-evident records
- The audit log is append-only, enforced by a database trigger: entries cannot be edited or deleted, including by our own application. Signed clinical notes are made immutable the same way.
- Encryption
- PHI is encrypted at rest under a customer-managed key and in transit. The database sits in private, isolated subnets with no public route to it.
Agreements
What is signed before patient data moves, and what the software does to make sure of it.
- Business Associate Agreement
- We execute a business associate agreement with every customer before any patient data is exchanged.
- Subprocessor agreements
- Every subprocessor that can touch PHI operates under a business associate agreement, and the software enforces it: it will not place a patient call until each agreement is confirmed in configuration.
- Data use and exit
- Your agreement bars us from selling patient data and from using it to train general-purpose models — and defines the exit: a full export in standard formats, then deletion on your schedule, confirmed in writing.
Encrypted under your key, on a network with no front door.
Where patient data physically sits, who can reach it, and what decides.
A customer-managed key
Patient data is encrypted in transit and at rest, and the key at rest is yours to manage. Rotate it on your schedule. Revoke it, and the data is unreadable — including to us.
No public route to the database
The database lives in private, isolated subnets. It has no public address, and the only path to it is the application’s own private network.
Isolation enforced in the data layer
Every record belongs to exactly one organization, and every query is scoped to the caller’s. The rule lives next to the data rather than in the interface, so no screen — ours or a future one — can reach across it.
Access by role
Users authenticate only into their own organization and see what their role grants. A nurse, a billing analyst, and an executive work from different views of the same record, and each read lands in the log above.
The exit is part of the architecture too: because every record belongs to one organization and sits under your key, a full export and a confirmed deletion are defined operations rather than a negotiation. The terms are under Agreements above.
Send us your security questionnaire.
We would rather answer it before a demo than after one, and we answer it ourselves rather than routing it to a portal.
Talk to our team