Admin Practitioner Privileges and Access - hmislk/hmis GitHub Wiki
Admin — Practitioner Privileges and Access
HMIS uses privileges to gate access to screens and actions. Privileges are attached to a WebUser login, not to a doctor's clinical role. There is no separate "consultant privilege" or "specialist credentialing" concept in the system — clinical credentialing is intentionally not implemented (Practitioner Module Overview). This article lists the privileges relevant to working with practitioner records, payments, and SMS, and gives the recommended sets for common operator roles.
How HMIS privileges work, briefly
Each WebUser belongs to one or more roles; privileges are granted at the role level. The system checks webUserController.hasPrivilege('Name') in every screen and toolbar button — when the check fails, either the whole page renders the message "You are NOT authorized" or the button silently disappears.
Privileges are administered through Administration → Manage Users. Adding a new privilege to the code requires three steps (an enum value, a getCategory() case, and a UserPrivilageController tree node — see the developer-docs Privilege System Guide). For administrators, the set of available privileges is whatever the running build defines.
Privileges relevant to this module
To manage practitioners
| Privilege | Grants access to |
|---|---|
AdminStaff |
The whole Manage Staff index (/admin/staff/admin_manage_staff_index.xhtml) and every screen below it: doctor lists, consultant edit, staff edit, signature management, person-institution linking, bulk delete, uploads. |
AdminManagingUsers |
Manage Users index, including the Link Staff to System User screen (admin_user_staff.xhtml). |
HrAdmin |
The HR admin index, where Staff Category / Designation / Grade catalogs are managed. |
A user who needs to register doctors and consultants typically holds AdminStaff; a separate HR clerk who maintains the supporting catalogs holds HrAdmin. The two can be combined for a small installation.
To run OPD doctor payments
| Privilege | Grants access to |
|---|---|
Opd |
The OPD module shell. Required to see the OPD top-level menu items. |
OpdBilling |
The OPD payment screens including pay_doctor.xhtml, Mark In / Mark Out, Working Times. |
PaymentBilling |
The Initiate Professional Payments action on the OPD Doctor Payment Index, and payment_staff_bill.xhtml. |
PaymentBillSearch |
The reports on the OPD Doctor Payment Index: Miscellaneous Fee/Bill Report, Outstanding Professional Payments search, Completed Professional Payments listing. |
A cashier paying doctors typically needs Opd, OpdBilling, and PaymentBilling. A supervisor who only audits reports needs PaymentBillSearch.
To run channel doctor payments
| Privilege | Grants access to |
|---|---|
ChannellingPaymentPayDoctor |
The Pay Doctor channel screen (see Channel — Paying a Doctor). |
The channelling team owns the precise privilege list for that module; check their navigation guide for additional channel privileges.
To run inward professional payments
| Privilege | Grants access to |
|---|---|
InwardBilling (or local equivalent) |
The Inward menu items. |
PaymentBilling |
Required, as for OPD. |
To view SMS history
| Privilege | Grants access to |
|---|---|
Analytics (or local equivalent) |
The Analytics module that hosts sms_list.xhtml and sms_faild.xhtml. |
Recommended privilege bundles
The exact bundles depend on your staffing model, but the following are common starting points.
Reception / front desk
Opd,OpdBilling— to view OPD patients and register them.Channelling— to take channel bookings.AdminStaffis usually not granted at reception — registering staff and editing doctor profiles is an admin task.
Cashier (OPD and channel)
Opd,OpdBilling,PaymentBilling,PaymentBillSearch.Channelling,ChannellingPaymentPayDoctor.Analyticsif they need to audit SMS dispatch.
HR clerk
HrAdmin— full HR admin.AdminStaff— staff registration and editing.AdminManagingUsers— only if also responsible for matching staff records to user logins.
Practitioner module administrator
AdminStaff,HrAdmin,AdminManagingUsers, plusAdminConfig(or whatever your installation calls the application configuration privilege) — needed to change WHT, payment behaviour, and SMS triggers.
Senior consultant (read-only personal portal)
If a consultant logs in to view their own appointments:
- Bare login privileges plus whatever channel doctor-portal privileges your installation exposes.
- No
AdminStafforPaymentBilling— a consultant should not be editing the master roster or settling their own payments.
Common pitfalls
| Symptom | Cause | Fix |
|---|---|---|
| User cannot see "Manage Staff" under Administration. | Missing AdminStaff. |
Grant AdminStaff. |
| User can see Manage Staff but the Connect-staff-to-user button does not work. | Missing AdminManagingUsers. |
Grant AdminManagingUsers. |
| Cashier sees Process Shift Payments but not Process All Due Payments. | The OPD configuration key is off (OPD Doctor Payments can be given without closing the shift.). |
See Admin — OPD Doctor Payment Behaviour. |
| User sees "You are NOT authorized" on the OPD pay screen. | Missing OpdBilling. |
Grant OpdBilling. |
| User can pay an OPD bill but cannot search past payments. | Missing PaymentBillSearch. |
Grant PaymentBillSearch. |
| User cannot see the SMS analytics screens. | Missing the analytics privilege. | Grant the analytics privilege configured in your installation. |
Audit checklist
| Check | Why |
|---|---|
Every AdminStaff holder is still in role. |
The privilege gives full staff-roster modification. |
Every PaymentBilling holder corresponds to an actual cashier. |
Limits who can settle professional payments. |
Every AdminManagingUsers holder is in IT / system admin. |
Prevents lateral privilege escalation. |
No retired staff still has an enabled WebUser. |
A retired person should not be able to log in. |
Limitations
- Privileges are not effective-dated. Granting a privilege takes effect immediately and remains until revoked.
- There is no privilege specifically for "edit one own profile" — staff cannot edit their own record from the main screens (no self-service workflow); admins do it on their behalf.
- The privilege names are case-sensitive when referenced in XHTML. If you script your own configuration of roles, double-check spelling.