Every account should see exactly as much as its job requires
A clinic with one shared front-desk password has already made its decision: convenient on day one, and unaccountable by month three, because nothing in the system can say which of the three people using it actually opened a given file.
The fastest way to set up a new clinic account is one login for the front desk, shared by whoever is on shift. It works, for a while. Then a patient's balance is quietly adjusted, or a file is opened that had no reason to be, and the honest answer to "who did this" turns out to be a shrug — because the system was never told there were three different people behind that one login.
The instinct is to treat this as a password problem and hand out separate logins. That is necessary, but it is not the whole fix. A named login attached to an account that can still see every patient's full record, every branch's numbers, and every setting in the system has solved authentication and left authorization exactly where it started.
What each role actually needs to see
Most of the work in a clinic falls into a small number of roles, and each one genuinely needs a different slice of the system — not less access for its own sake, but access scoped to the job:
| Role | Needs to see | Should not need |
|---|---|---|
| Front desk | Bookings, check-in, contact details, invoices | Full clinical notes |
| Doctor or nurse | Full clinical documentation for their own patients | Billing settings, other branches' data |
| Branch manager | Everything within their branch, including reports | Other branches' patients or numbers |
| Owner or admin | Every branch, plus plan and billing settings | — |
A named login is the foundation permissions sit on
Permissions only mean something once every action traces back to one real person. A role that is correctly scoped but attached to a login four people share has not actually restricted anything in practice — it has just described, on paper, an intention nobody can verify.
This is the same problem covered from the authentication side in patient data security and two-factor authentication: a stolen or shared password is a way in, and the fix for "who got in" and the fix for "what could they see once inside" have to be solved together, not one instead of the other.
Branch separation is permission at a bigger scale
A clinic running three branches under one account faces the same question at a larger scale: should a receptionist at branch A be able to open branch B's patient list by scrolling far enough? The answer that actually protects patients is no, by default, regardless of how many locations sit under the same company and the same subscription.
The audit trail is what makes 'who did this' answerable
Correctly scoped roles and named logins solve most of the problem before it happens. The audit trail is what answers the question after it happens: who opened this file, who edited that invoice, and when. Without it, even a well-designed permission scheme cannot answer the one question that actually gets asked once something goes wrong.
Permissions nobody reviews drift back to everyone-sees-everything
A role scheme set up carefully at go-live and never revisited tends to grow generous over time — an exception here for a busy week, a temporary account that outlives the reason it was created. Reviewing who has access to what is not a one-time setup task.
What to check before you trust a system with staff accounts
- Can a role be scoped narrower than "staff" out of the box, or is it all-or-nothing?
- Does every login stay tied to one named person, with no account meant to be shared?
- Is a multi-branch clinic's data separated by default, not left to staff discipline?
- Does the audit trail survive an account being deleted, or does the history disappear with it?
See how roles and permissions work
Set up a front-desk account and a clinical account side by side, and see exactly what each one can and cannot open.
See what the system does