Security
One permission model. One audit trail.
Twenty-eight modules that share a patient also share how access is granted and how it’s logged.
One permission model Roles granted once apply across all twenty-eight modules. No module-specific back door.
Complete audit trail Every view, edit, message and payment logged against the record and the user.
Patient consent SMS and email consent captured at enrolment and enforced at send time.
Hub access control Invite-only enrolment, email + DOB verification, per-family-member scoping, expiring reset links.
Data residency Practice data isolated per tenant, encrypted in transit and at rest.
Integration scoping Each connected system gets least-privilege credentials you can revoke independently.
How access actually works
Permissions are a per-practice matrix, not a code change. Roles are yours to name; each one gets view and edit granted page by page, and every grant is enforced on the server — not merely hidden in the menu.
- Deny by default. A role with no grant on a page gets a real 403 from the API, not a blank screen with live data behind it.
- View-only means read-only. A role granted view but not edit can open a page and cannot add, change or delete anything on it.
- Only the doctor or office manager can edit the matrix. Everyone else — including staff who can see the settings area — sees it read-only.
- Your practice’s roles are yours. Two offices can use the same role name with entirely different access; nothing is shared between tenants.
Questions we’re happy to answer in writing
Certifications, business-associate agreements and testing cadence get answered directly with current status rather than a badge on a marketing page. Ask and we’ll put it in writing.