Roles, permissions and access control in the clinic
Not everyone in a clinic sees everything, and they should not. In HekimBis a permission is more than a role label: the person's role, the branch they work in, the sensitivity of the data and their care relationship with the patient are evaluated together. Every sensitive access is recorded with who looked, when and why.
What happens in the background when a patient file is opened?
When a user wants to open a patient file, the system asks in order: does your plan include this feature, does your role allow it, do you have a care relationship at this branch and with this patient, and is the data sensitive? If all are in order, the file opens and the access is recorded. If there is no care relationship, an emergency access path exists: a reason, a time limit and extra verification are required.
Audit record
Who looked at which record, when and why: it is written to the log.
- The process is complete here.
All steps
- 01 Request (User) A user wants to open a patient file.
- 02 Role (Role) Does the user's role allow this action?
- 03 Context (Context) Branch membership, data sensitivity, care relationship with the patient and purpose are evaluated together.
- 04 Allowed (Context) If the conditions are met, the file opens; fields are masked according to authority.
- 05 Audit record (Audit) Who looked at which record, when and why: it is written to the log.
Alternative path from 03 Context; it returns to the main flow at 05 Audit record.
- 03a No care relationship: emergency access (Context) The user writes a reason, a duration is set and extra verification is completed; time-limited access opens and a separate audit record is created.
05 Audit record
A permission is more than a label
Having the “physician” role is not enough to look at the file of every patient in the clinic. The server looks together at whether the feature exists in your plan, whether your role allows the action, the branch you work in, the sensitivity of the data and your care relationship with the patient. The rule is enforced on the server, and a violation lands in the audit log.
- Plan
- Says whether the feature is on in the organization; it does not decide who can access what.
- Role
- The role family determines which actions can be taken.
- Branch
- In a multi-branch setup the patient record is organization-wide, but access to a patient at another branch opens through explicit membership, assignment or care relationship.
- Sensitivity
- Sensitive notes are segmented, and fields are masked from unauthorized users. For example, mental-health notes can be protected separately from the general clinical record.
- Care relationship
- The care relationship with the patient and the purpose of the access are evaluated together.
Role families
Role families are a starting orientation; in each organization permissions narrow or widen with membership, branch, data sensitivity and care relationship. Lite includes ready-made small-team roles, Pro adds custom roles and detailed permission definitions, and Clinic adds branch scope and a central role.
- Owner and organization administrator
- Clinical director
- Physician
- Clinical staff (nurse, assistant)
- Front desk and reception
- Finance
- Inventory
- Laboratory and imaging
- Call center
- Compliance and audit
- Read-only user
Emergency access comes with a reason, a time limit and its own audit
In an emergency it may be necessary to look at the file of a patient with whom no care relationship has been established. Access is then neither blocked entirely nor granted silently. The user writes a reason, completes extra verification, and access stays open only for a set time. When the time ends, access closes; the access is written to the audit trail as a record separate from normal access and can be reviewed by the responsible people.
- A reason is required.
- Access opens for a limited time and closes by itself.
- Extra verification is requested.
- A separate audit record is created; the compliance and audit role can review it.
HekimBis support also comes in with permission
To solve a problem, the HekimBis support team may need to look at your data. Support access opens each time tied to a support request, and your organization's administrator approves it. Access is narrow in scope, cannot exceed its time limit, shows masked data by default and requires two-step verification. When the work is done, access is revoked and the session and actions are written to the audit log.
- Opens with a support request and a reason.
- Needs the organization administrator's approval.
- Narrow scope, time limit and masking by default.
- Revocation, and audit of session and actions.
Joining, changing roles and leaving are all on record
A new employee is added by invitation, and their role and branch are assigned; when their duties change, their permissions are updated, and when they leave, access closes immediately. Joining, changing roles and leaving are the three riskiest moments in permission management, and HekimBis records each of them.
The audit log covers sensitive reads, writes, downloads, views, exports and support access: who accessed which record, when and for what reason is written down. The authorized compliance and audit role can review afterwards who looked at a sensitive record. Multi-step verification, session and trusted-device management are part of the system.
Roles and permissions are managed by the owner or the organization administrator. Security, audit and record integrity are not restricted in any plan.
Frequently asked questions
Can a user see only the patients of their own branch?
In a multi-branch setup the patient record is organization-wide, but access to a patient at another branch is not automatic. Access opens by explicit membership, assignment or care relationship and the sensitivity rule. The Clinic plan does not automatically give a user authority at every branch.
Can I define custom roles?
The Lite plan includes ready-made small-team roles; Pro allows custom roles and detailed permission definitions; Clinic adds branch scope and a central role.
When does an employee's access close when they leave?
At the moment of offboarding: the employee's access closes with the leaving action. The action and the accesses made up to that day remain in the audit log.
Are sensitive notes open to everyone?
Sensitive notes are segmented; only an authorized role sees them, and fields are masked from unauthorized users. For example, mental-health notes can be protected separately from the general clinical record.
What is written to the audit log?
Sensitive reads, writes, downloads, views, exports and support access: who accessed which record, when and for what reason is recorded.
Does a plan grant permissions?
A plan determines whether a feature is on; it does not decide who can access what. User permission is always checked on the server by role, branch, care relationship and sensitivity rules.
Is there multi-step verification?
Multi-step verification, session and trusted-device management are part of the system. Extra verification is requested for sensitive actions and for support access.
Can I see afterwards who looked at a sensitive record?
Yes. Sensitive reads, downloads and exports are written to the audit log, and the authorized compliance and audit role can review who looked at which record and when.
Related pages
Features
- Data migrationBringing records from your current software with a preview, a trial import and reconciliation.
- AI assistantStructured drafts, summaries, and suggestions from dictation, all physician-approved.
- Forms, consent, documentsForm builder, separate privacy notice and consent records, and secure sharing.
Specialties
Software guides
Company and support
Guides
- Multi-Branch Clinic Management with Central Control and Local FlexibilityRunning several branches as one operation: shared patient records, branch-level cash and stock, role boundaries and consolidated reporting in a practical framework.
- A Practical KVKK and Health Data Compliance Guide for ClinicsHealth data is special-category personal data. The difference between the privacy notice, explicit consent and clinical consent, access control, data subject requests and breach notification.