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.
  • AdminStaff is 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.
  • Analytics if 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, plus AdminConfig (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 AdminStaff or PaymentBilling — 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.

Related articles

Back to Admin — Practitioner Module Configuration Overview