RBAC in a Multi-Specialty Clinic: Permission Matrix

Why a clinic needs roles and least-privilege

In a private clinic, dozens of people pass through the same system every day: physicians, nurses, front-desk staff, billing, an administrator, and sometimes external contractors. Everyone touches patient data, but not everyone should see the same things. When every user has full access to everything, any human error or compromised account becomes a system-wide incident. The industry answer is RBAC — Role-Based Access Control.

The idea is simple: instead of attaching permissions to each individual, you define roles, attach every permission to a role, and assign each employee to the right role. A new hire receives a role and instantly has exactly the right access, no more and no less. A complementary principle is least-privilege: each role is granted the minimum needed to do the job, and nothing beyond it. Together these two principles shrink the attack surface, simplify auditing, and make it easier to meet the privacy expectations that surround health data.

Core roles in a clinic

Before building a matrix, map the typical roles. These are a starting point, not a fixed list — every clinic adapts them to its own reality:

• Physician / practitioner — reads and writes the clinical chart, opens visits, writes prescriptions, orders tests.
• Nurse — records vital signs, prepares the visit, manages medications and immunizations, usually with a narrower clinical scope than the physician.
• Front desk / reception — manages appointments, demographics and communication, without deep clinical content.
• Billing / finance — works with invoices, claims, payments and balances, and needs only the justifying diagnosis rather than the full clinical record.
• Administrator — configures the system, roles and permissions, but does not necessarily enter day-to-day clinical content.
• External user — a consultant, auditor or vendor with scoped, time-limited access only.

What a permission matrix is

A permission matrix is a two-dimensional table: roles in the rows, access objects (the types of data and actions) in the columns, and in each cell the permission level — no access, read only, read and write, or manage. The matrix turns a vague question (“who can touch what?”) into an explicit document you can review, maintain and explain. It is also the contract against which every unusual access request is measured.

Example matrix

Object / Role	Physician	Nurse	Reception	Billing	Admin	External
Appointments	Read/Write	Read/Write	Read/Write	Read	Configure	Scoped
Patient chart	Full	Clinical, narrow	Demographics only	Limited	None	Scoped
Visits and forms	Write	Partial write	None	Read for coding	None	Scoped read
Prescriptions	Write	Read	None	None	None	None
Finances	Read	None	Read	Full	Read	None
Admin and permissions	None	None	None	None	Full	None

This table is only a starting point. In a real clinic the number of objects is much larger — each form type, each module and each sensitive action can be its own separate object.

Permissions at the form and field level

Module-level control alone is not always enough. Two roles may both be able to “write a visit,” yet only one should touch a sensitive psychosocial form or an internal note. Mature control therefore allows permissions at the level of the individual form, and sometimes the individual field: a field visible to one role and hidden from another. This granularity lets you open most of the system to the broad team while locking down only the most sensitive parts, without duplicating screens.

Audit log and spotting anomalies

A good matrix defines what is allowed; an audit log records what actually happened. Every view, edit, export or print of sensitive information is recorded: who, when, which record and which action. The value of the log depends on its integrity — if it can be quietly edited, it is meaningless. That is why the rows are typically protected against retroactive change.

To catch anomalies, look for patterns: an employee accessing a chart they have no care relationship with, an unusual volume of views in a short window, activity outside working hours, or a large data export. A periodic review of the log turns it from a passive archive into an active detection tool.

Break-glass — emergency access as a concept

Sometimes urgent access is needed to information the normal role does not permit — for example a patient in an emergency who is not the current physician’s regular patient. A break-glass mechanism is the idea of “breaking the glass”: the system permits a controlled exception, but requires an explicit justification, flags the access as unusual, and generates an alert and heightened after-the-fact review. Break-glass is a well-established design concept worth knowing; confirm with your vendor exactly how any given system handles emergency access, rather than assuming it exists by default.

Employee departure or role change

Permissions are not static. When an employee changes roles, update their assignment and remove old permissions — otherwise you accumulate “permission creep,” where people collect access from every role they have ever held. When an employee leaves, revoke access immediately, not a week later. Keep in mind that revoking access does not erase the audit trail: the user’s historical actions are preserved for review even after the account itself is disabled.

Permission setup checklist

• Map all real roles, including external and temporary ones.
• Define the minimum permission each role needs (least-privilege).
• Build an explicit permission matrix and document it.
• Lock down sensitive forms and fields at the role level.
• Ensure the audit log is active and protected from tampering.
• Establish a procedure for emergency (break-glass) access with your vendor.
• Define a clear process for departures and role changes, with immediate access revocation.
• Schedule periodic reviews of permissions and the audit log.

What is confirmed in CareOS

The CareOS administration module includes a permission matrix of 65 access objects across 6 roles, alongside 492 configuration settings by domain and a form designer that requires no development (F-M10). Permissions do not stop at the module level: they can be set at the level of the individual form inside a visit (F-M3). The audit log is recorded with an integrity signature on every line (F-M10), and treatment recording includes a full access log to the record — who viewed it and when (F-M8). CareOS was designed with the privacy requirements for health data in Israel in mind, but does not claim any standard or certification.

Conclusion

A good permission matrix is not a one-time project but an ongoing practice: define roles clearly, give each role the minimum, document everything in an explicit matrix, back it with a trustworthy audit log, and review continuously. That is how a clinic protects patient data without paralyzing the work of its team.

Want to see what a permission matrix looks like in practice? Book a CareOS demo and we will walk through roles, form-level permissions and the audit log for your clinic together.

Back to the blog