Scheduling & Bed/OR Management User Roles & Permissions
This document defines role-based and context-based access control for the Scheduling & Bed/OR Management (scheduling) module, including outpatient appointments, bed management, OR scheduling, and encounter lifecycle. It is designed for UAE hospitals and must be implemented in alignment with UAE PDPL, Federal Law No. 2/2019 (ICT in health fields), DOH/DHA rules, and ADHICS/NESA security principles.
Role Definitions
Note: Authentication, identity lifecycle, and global role records are owned by
ehr-patient-mgmt(users,roles,permissions). This module defines module-specific capabilities and scope rules for those roles.
1. Scheduling Clerk
- Description: Front-desk / call-centre staff responsible for outpatient appointment booking, rescheduling, and basic waitlist management.
- Typical UAE Job Titles:
- Registration & Scheduling Clerk
- Call Centre Agent – Appointments
- OPD Receptionist
- Scope of Access:
- Patients: All patients of assigned facility; optionally restricted to assigned departments (e.g., OPD clinics).
- Data:
- View demographics, insurance summary, and appointment history.
- Create/update appointments, waitlist entries (non-clinical fields only).
- No access to clinical notes, diagnoses, or orders.
- Reporting Hierarchy:
- Reports to: Scheduling Supervisor / Patient Access Supervisor.
- Operational oversight by: Scheduling Administrator and Department Managers.
2. Senior Scheduling Clerk
- Description: Experienced scheduler with authority to override certain scheduling rules, manage complex bookings, and handle escalations.
- Typical UAE Job Titles:
- Senior Scheduling Officer
- Senior Patient Access Representative
- Scope of Access:
- All Scheduling Clerk capabilities.
- Can override specific scheduling_rules (e.g., lead time, overbooking) within configured limits.
- Can handle multi-provider, multi-resource bookings (e.g., combined clinic + procedure).
- Reporting Hierarchy:
- Reports to: Scheduling Administrator / Patient Access Manager.
- Provides guidance to: Scheduling Clerks.
3. Bed Management Coordinator
- Description: Central bed control staff managing inpatient admissions, bed assignments, transfers, and discharge bed releases.
- Typical UAE Job Titles:
- Bed Management Coordinator
- Admission & Bed Control Officer
- Patient Flow Coordinator
- Scope of Access:
- Patients: All inpatients and ED patients awaiting admission in assigned facilities.
- Data:
- Full access to bed board, beds, bed_assignments, bed_transfers, and encounters (administrative fields only).
- Can create/update encounters (admission/discharge dates, class, location), but cannot edit clinical diagnoses (those are owned by clinical modules).
- Can trigger ADT events (A01/A02/A03/A04) via this module.
- Reporting Hierarchy:
- Reports to: Patient Flow Manager / Nursing Administration / Operations Manager.
- Works closely with: Charge Nurses, Admission Office, ED leadership.
4. OR Scheduler
- Description: Staff responsible for operating room schedule creation, OR block management, and surgical case booking coordination.
- Typical UAE Job Titles:
- OR Scheduler
- Theatre Booking Coordinator
- Surgical Services Coordinator
- Scope of Access:
- Patients: Patients with planned or active surgical encounters in assigned facilities.
- Data:
- Manage or_rooms, or_schedules, or_cases (non-clinical scheduling fields).
- View limited clinical pre-op status flags (e.g., “pre-op clearance complete”, “consent verified” as boolean/status only).
- No access to detailed operative notes or anesthesia records.
- Reporting Hierarchy:
- Reports to: OR Manager / Surgical Services Manager.
- Coordinates with: Surgeons, Anesthesiologists, Bed Management, PIS team.
5. Charge Nurse
- Description: Senior nurse on a ward/unit responsible for patient flow, bed status updates, and discharge readiness.
- Typical UAE Job Titles:
- Charge Nurse
- Unit In-Charge
- Ward Supervisor
- Scope of Access:
- Patients: Patients admitted to their ward/department; may have read-only view of other wards for transfer coordination.
- Data:
- View bed board for own ward; update bed_status, cleaning_status (where allowed).
- Approve bed_transfers for patients under their ward.
- View and update discharge checklist status (administrative flags).
- No authority to change global scheduling rules or OR blocks.
- Reporting Hierarchy:
- Reports to: Nurse Manager / Nursing Director.
- Collaborates with: Bed Management Coordinator, Physicians, Discharge Coordinators.
6. Physician
- Description: Licensed physician using scheduling module to request appointments, admissions, transfers, discharges, and OR time for their patients.
- Typical UAE Job Titles:
- Consultant / Specialist / General Practitioner
- Resident / Fellow (with appropriate privileges configured centrally)
- Scope of Access:
- Patients: Patients under their care (encounter attending/admitting/referring) or on-call coverage lists.
- Data:
- Request appointments, admissions, transfers, discharges, and OR cases.
- View own clinic schedule and OR schedule.
- Read-only view of bed board for patients under their care.
- Cannot directly override scheduling rules or bed allocation rules (except via configured clinical override workflows).
- Reporting Hierarchy:
- Reports to: Department Chair / Medical Director.
- Works with: Scheduling Clerks, OR Scheduler, Bed Management Coordinator.
7. Patient (Portal/Kiosk)
- Description: Patient or authorised representative accessing scheduling features via portal or self-service kiosk.
- Typical UAE Context:
- Patient with verified identity (Emirates ID, MRN, mobile OTP).
- Proxy access for parent/guardian or legal representative as per facility policy.
- Scope of Access:
- Patients: Self (and dependents where proxy is configured).
- Data:
- View own appointments and limited encounter metadata (date, location, provider).
- Book/cancel/reschedule own appointments within allowed rules.
- Join waitlist for selected services.
- No access to bed board, OR schedule, or other patients’ data.
- Reporting Hierarchy:
- Not an employee role; governed by patient portal policies and PDPL consent records.
8. Scheduling Administrator
- Description: Power user responsible for configuration of scheduling master data and rules, and for utilisation reporting.
- Typical UAE Job Titles:
- Scheduling Administrator
- Patient Access Manager
- Operations Analyst – Scheduling
- Scope of Access:
- Patients: Read-only access to appointment and encounter metadata across facilities (subject to facility-level assignment).
- Data:
- Manage appointment_types, scheduling_rules, provider_schedules, scheduling_templates, appointment_slots.
- View utilisation dashboards (appointments, bed occupancy, OR utilisation).
- Typically no authority to change clinical data or discharge orders.
- Reporting Hierarchy:
- Reports to: Director of Patient Access / COO / Operations Director.
- Provides configuration support to: Department Heads, OR Manager, Bed Management.
Permission Matrix
Legend:
- ✅ = Allowed
- ❌ = Not allowed
- 🔒 = Conditional / context-based (e.g., facility, department, treating relationship, time, or configuration)
Columns:
- SC = Scheduling Clerk
- SSC = Senior Scheduling Clerk
- BMC = Bed Management Coordinator
- ORS = OR Scheduler
- CN = Charge Nurse
- PHY = Physician
- PAT = Patient (Portal/Kiosk)
- SA = Scheduling Administrator
| Permission / Function | SC | SSC | BMC | ORS | CN | PHY | PAT | SA |
|---|---|---|---|---|---|---|---|---|
| Patient & Encounter Access | ||||||||
| View basic patient demographics (name, DOB, MRN, contact) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅* | ✅ |
| View insurance summary (payer, plan, validity dates) | ✅ | ✅ | ✅ | 🔒 | 🔒 | 🔒 | ✅* | ✅ |
| View encounter administrative data (type, class, dates, location) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅* | ✅ |
| Edit encounter administrative data (class, admission/discharge datetime, location) | ❌ | ❌ | ✅ | 🔒 | 🔒 | 🔒 | ❌ | 🔒 |
| View clinical diagnosis fields on encounter | ❌ | ❌ | 🔒 | 🔒 | 🔒 | ✅ | ❌ | 🔒 |
| Outpatient Appointment Management | ||||||||
| Search appointments by patient / provider / date | ✅ | ✅ | 🔒 | 🔒 | 🔒 | ✅ | ✅* | ✅ |
| Create new outpatient appointment | ✅ | ✅ | ❌ | ❌ | ❌ | 🔒 | ✅* | ✅ |
| Book appointment with encounter shell creation | ✅ | ✅ | ❌ | ❌ | ❌ | 🔒 | ✅* | ✅ |
| Reschedule existing appointment | ✅ | ✅ | ❌ | ❌ | ❌ | 🔒 | ✅* | ✅ |
| Cancel appointment (with reason capture) | ✅ | ✅ | ❌ | ❌ | ❌ | 🔒 | ✅* | ✅ |
| Mark appointment as no-show | ✅ | ✅ | ❌ | ❌ | 🔒 | 🔒 | ❌ | ✅ |
| Check-in patient for appointment (change status to Checked-In) | ✅ | ✅ | ❌ | ❌ | 🔒 | 🔒 | ✅* | ✅ |
| View clinic queue board (SCR-SCH-009) | ✅ | ✅ | ❌ | ❌ | ✅ | ✅ | 🔒 | ✅ |
| Override scheduling rules (lead time, double-booking) | ❌ | 🔒 | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ |
| Approve overbooking beyond standard limits | ❌ | 🔒 | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ |
| Waitlist Management | ||||||||
| Add patient to appointment waitlist | ✅ | ✅ | ❌ | ❌ | ❌ | 🔒 | ✅* | ✅ |
| Update waitlist entry (priority, preferred dates) | ✅ | ✅ | ❌ | ❌ | ❌ | 🔒 | ✅* | ✅ |
| Resolve waitlist entry (booked / cancelled / declined) | ✅ | ✅ | ❌ | ❌ | ❌ | 🔒 | 🔒 | ✅ |
| Configure auto-offer rules for waitlist | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ |
| Bed Board & Inpatient Flow | ||||||||
| View bed board (facility-wide) | ❌ | ❌ | ✅ | 🔒 | 🔒 | 🔒 | ❌ | ✅ |
| View bed board (own ward/department only) | ❌ | ❌ | ✅ | 🔒 | ✅ | 🔒 | ❌ | ✅ |
| Assign bed on admission (create bed_assignment) | ❌ | ❌ | ✅ | ❌ | ❌ | 🔒 | ❌ | 🔒 |
| Update bed status (occupied, vacant, blocked) | ❌ | ❌ | ✅ | ❌ | ✅ | 🔒 | ❌ | ✅ |
| Update bed cleaning_status (pending, in-progress, ready) | ❌ | ❌ | ✅ | ❌ | ✅ | ❌ | ❌ | ✅ |
| Initiate bed-to-bed transfer request | ❌ | ❌ | ✅ | ❌ | ✅ | ✅ | ❌ | 🔒 |
| Approve bed transfer | ❌ | ❌ | ✅ | ❌ | ✅ | 🔒 | ❌ | 🔒 |
| Execute transfer (update bed_assignments, bed_transfers) | ❌ | ❌ | ✅ | ❌ | 🔒 | 🔒 | ❌ | 🔒 |
| Release bed on discharge | ❌ | ❌ | ✅ | ❌ | ✅ | 🔒 | ❌ | 🔒 |
| Admission / Discharge / Transfer (ADT) | ||||||||
| Create inpatient encounter from admission order | ❌ | ❌ | ✅ | ❌ | ❌ | 🔒 | ❌ | 🔒 |
| Update expected length of stay | ❌ | ❌ | ✅ | ❌ | 🔒 | 🔒 | ❌ | 🔒 |
| Trigger ADT A01 (Admit) message | ❌ | ❌ | ✅ | ❌ | ❌ | 🔒 | ❌ | 🔒 |
| Trigger ADT A02 (Transfer) message | ❌ | ❌ | ✅ | ❌ | 🔒 | 🔒 | ❌ | 🔒 |
| Trigger ADT A03 (Discharge) message | ❌ | ❌ | ✅ | ❌ | 🔒 | 🔒 | ❌ | 🔒 |
| Trigger ADT A04 (Registration / pre-admit) | ✅ | ✅ | 🔒 | ❌ | ❌ | 🔒 | 🔒 | ✅ |
| OR Scheduling & Cases | ||||||||
| View OR schedule board (SCR-SCH-006) | ❌ | ❌ | 🔒 | ✅ | 🔒 | ✅ | ❌ | ✅ |
| Book OR case (create or_case linked to schedule) | ❌ | ❌ | ❌ | ✅ | ❌ | ✅ | ❌ | ✅ |
| Assign OR room and time block | ❌ | ❌ | ❌ | ✅ | ❌ | 🔒 | ❌ | ✅ |
| Assign surgical team (surgeon, anesthesiologist, support staff) | ❌ | ❌ | ❌ | ✅ | ❌ | 🔒 | ❌ | ✅ |
| Manage OR blocks (block/unblock time for services/providers) | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ | ✅ |
| Update OR case status (scheduled, in-progress, completed, cancelled) | ❌ | ❌ | ❌ | ✅ | 🔒 | 🔒 | ❌ | ✅ |
| View OR utilisation reports | ❌ | ❌ | 🔒 | ✅ | 🔒 | 🔒 | ❌ | ✅ |
| Configuration & Master Data | ||||||||
| Manage appointment types | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ |
| Manage scheduling rules (lead times, cancellation policies, overbooking limits) | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ |
| Manage provider schedules (create/update provider_schedules) | ❌ | ❌ | ❌ | ❌ | ❌ | 🔒 | ❌ | ✅ |
| Manage scheduling templates (scheduling_templates) | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ |
| Generate appointment slots from templates | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ |
| Analytics & Reporting | ||||||||
| View scheduling analytics dashboard (SCR-SCH-010) | 🔒 | 🔒 | 🔒 | 🔒 | 🔒 | 🔒 | ❌ | ✅ |
| Export operational reports (appointments, bed occupancy, OR utilisation) | ❌ | ❌ | 🔒 | 🔒 | 🔒 | 🔒 | ❌ | ✅ |
| View detailed audit logs for scheduling actions | ❌ | ❌ | 🔒 | 🔒 | 🔒 | 🔒 | ❌ | ✅ |
| Security & Special Access | ||||||||
| Break-the-glass access to restricted scheduling/bed data | ❌ | ❌ | 🔒 | 🔒 | 🔒 | 🔒 | ❌ | 🔒 |
| Cross-facility access (multi-hospital view) | 🔒 | 🔒 | 🔒 | 🔒 | 🔒 | 🔒 | ❌ | 🔒 |
\* Patient access is always limited to **own record / dependents** and to a subset of fields appropriate for portal use.
🔒 Conditional permissions must be enforced via **context-based rules** described below (facility, department, treating relationship, time, and configuration).
---
## Role Hierarchy
Permissions are **not automatically inherited** by job title; inheritance is implemented via role groups in `ehr-patient-mgmt`. The following diagram shows typical organisational hierarchy and logical permission “supersets” for this module.
```mermaid
graph TD
COO[COO / Operations Director] --> PA[Patient Access Manager / Scheduling Administrator]
COO --> NM[Nursing Director]
COO --> ORMD[OR / Surgical Services Manager]
PA --> SSC[Senior Scheduling Clerk]
SSC --> SC[Scheduling Clerk]
NM --> CN[Charge Nurse]
CN --> BMC[Bed Management Coordinator]
ORMD --> ORS[OR Scheduler]
MDIR[Medical Director / Dept Chair] --> PHY[Physicians]
subgraph Portal Users
PAT[Patient (Portal/Kiosk)]
end
PA -.config oversight.-> BMC
PA -.config oversight.-> ORS
Logical permission relationships (within this module):
- Senior Scheduling Clerk ⊇ Scheduling Clerk (all SC permissions plus limited overrides).
- Scheduling Administrator ⊇ Senior Scheduling Clerk (for configuration and reporting) but does not automatically gain clinical override powers.
- Bed Management Coordinator and Charge Nurse have overlapping but distinct bed/ADT capabilities; neither should automatically inherit the other (see Segregation of Duties).
- Physician has request/clinical-context permissions but not configuration or operational override powers.
Context-Based Access Rules
Context-based rules are critical to comply with Federal Law No. 2/2019, UAE PDPL, DOH ADHICS, and DHA/NABIDH requirements.
1. Facility-Based Restrictions (Multi-Facility)
- Each user is assigned one or more facility_ids in
users_facilities(owned byehr-patient-mgmt). -
The scheduling module must enforce:
-
Default rule: User can only:
- View appointments, encounters, beds, OR schedules, and waitlists for their assigned facilities.
- Create/modify records where
facility_idis in their allowed list.
-
Cross-facility access (🔒):
- Granted only to specific roles (e.g., corporate Scheduling Administrator, central Bed Management) via configuration.
- Must be logged with facility context in audit logs.
-
HIE alignment:
- Facilities in Abu Dhabi vs Dubai may have different ADT routing (Malaffi vs NABIDH). Users must not be able to mis-route ADT messages by selecting facilities they are not authorised for.
2. Department-Based Restrictions
- Users may be restricted to specific department_ids (e.g., Cardiology OPD, Orthopedics, ICU).
- Enforcement examples:
- Scheduling Clerks assigned to “Pediatrics OPD” can only book appointments where
department_id= Pediatrics (unless explicitly granted cross-department rights). - OR Scheduler may be limited to certain surgical specialties.
- Charge Nurse can only update bed status for beds whose
department_idmatches their ward. - Department restrictions must be configurable per user and per role, and evaluated on every create/update/read operation.
3. Patient Relationship Requirements
To comply with PDPL’s data minimisation and Federal Law No. 2/2019 confidentiality:
- Physicians:
- Can view and act on scheduling/bed data only for:
- Patients where they are
attending_provider_id,admitting_provider_id, orreferring_provider_idon the active encounter; or - Patients assigned to them via on-call/coverage rosters; or
- Emergency cases in ED where they are on duty (location-based override).
- Patients where they are
- Charge Nurses:
- Can view and update bed board only for patients physically located in their ward/department.
- Bed Management Coordinators:
- May have facility-wide visibility due to central bed control function, but must not see detailed clinical content (only administrative fields).
- Scheduling Clerks:
- Can search and view patients for scheduling purposes but must not see sensitive clinical information (e.g., mental health flags, HIV status).
The system must implement treating-relationship checks before showing patient details beyond minimal scheduling data.
4. Time-Based Access (Shift-Based)
- Users have configured shift schedules (from HR or local configuration) or at least “on-duty” flags.
- Time-based rules:
- Bed Management Coordinator and Charge Nurse:
- Can perform transfers and bed assignments only while on duty (within shift window), except in BTG scenarios.
- OR Scheduler:
- Can modify same-day OR schedule outside normal hours only if flagged as “on-call” or with supervisor override.
- Night-shift operations:
- High-risk actions (e.g., overriding scheduling rules, cross-facility transfers) performed between 22:00–06:00 must be flagged in audit logs for next-day review.
5. Emergency / On-Call Overrides
- In emergencies (e.g., mass casualty, code blue, ED surge):
- On-call Bed Management Coordinator and Charge Nurse may be granted temporary facility-wide bed board access and transfer rights.
- On-call Physicians may receive broader scheduling visibility for triage purposes.
- Implementation:
- Emergency mode flag (per facility) can be toggled by authorised operations leadership.
- While emergency mode is active:
- Certain context restrictions (department-only, shift-only) may be relaxed.
- All such accesses are tagged with
context = emergencyin audit logs.
- Emergency mode changes must be logged and time-limited.
Break-the-Glass (BTG) Procedures
BTG is required to access or modify scheduling/bed/OR data beyond normal context-based restrictions, particularly where access may reveal sensitive health information indirectly (e.g., isolation beds, mental health wards).
1. When BTG is Required
Examples:
- Patient in another department/facility where the user has no standard access, but immediate scheduling/bed action is required to prevent harm (e.g., ICU transfer from another hospital building).
- Restricted wards (e.g., psychiatric, VIP, isolation) where bed board and encounter details are sealed by default.
- Cross-facility OR scheduling in urgent life-saving surgery when normal OR scheduler is unavailable.
- System misconfiguration temporarily blocking legitimate access (e.g., provider not yet linked to new department).
BTG must never be used for convenience or curiosity.
2. BTG Workflow
-
Trigger: - User attempts an action and is blocked by context-based rule (facility/department/patient relationship). - System displays BTG prompt: “Access restricted. Emergency override (‘Break-the-Glass’) is available only for genuine emergencies and will be fully audited.”
-
User Confirmation & Justification: - User must:
- Re-authenticate (password or MFA) to confirm identity.
- Select reason from a controlled list (e.g., “Emergency transfer”, “Life-threatening condition”, “System configuration error”).
- Enter free-text justification (min length enforced).
-
Access Grant: - System grants time-limited expanded access (e.g., 15–30 minutes) only for the specific patient and function requested, not global unrestricted access. - Scope example:
- View and update bed assignments for that patient.
- Book urgent OR case for that patient.
-
Audit Trail Requirements: - For each BTG event, log:
- User ID, role, and department.
- Patient ID and encounter ID.
- Timestamp (start and end of BTG session).
- Reason code and free-text justification.
- Actions performed (CRUD operations on appointments, encounters, beds, OR cases).
- Workstation ID / IP address.
- Logs must be immutable and retained per facility policy (typically ≥ 10 years, aligned with clinical record retention).
-
Notification & Post-Access Review: - Automatic notification to:
- Data Protection Officer / Compliance Officer.
- Relevant department head (e.g., Nursing Director, OR Manager).
- Daily or weekly BTG review:
- Confirm that BTG use was justified and consistent with Federal Law No. 2/2019 and PDPL.
- Document outcome (valid / questionable / misuse).
- For misuse, trigger disciplinary process and potential role restriction.
3. UAE PDPL Implications
- Health data is sensitive personal data under PDPL; BTG constitutes high-risk processing.
- BTG logs support:
- Accountability and record of processing obligations.
- Demonstration of data minimisation and purpose limitation (BTG only when necessary for treatment or vital interest).
- BTG design must:
- Ensure access is patient-specific and time-limited.
- Ensure BTG is no easier than standard access (requires extra steps).
- Be included in the facility’s Data Protection Impact Assessment (DPIA) for the HIS.
Segregation of Duties
To reduce fraud, error, and privacy risk, certain role combinations and actions must be segregated.
1. Conflicting Role Combinations
The following combinations must not be assigned to the same user account (or must be explicitly justified and approved by compliance if unavoidable):
-
Scheduling Administrator + Bed Management Coordinator - Risk: Same user could configure rules and manipulate bed assignments to favour specific patients or providers. - Control: Separate configuration (SA) from operational bed control (BMC).
-
Scheduling Administrator + OR Scheduler - Risk: User could create OR blocks and assign cases, potentially bypassing prioritisation and fairness. - Control: OR block configuration and day-to-day case scheduling should be separated or require dual oversight.
-
Senior Scheduling Clerk + Scheduling Administrator - Risk: Over-concentration of power to override rules and change configuration. - Control: Senior Scheduling Clerk focuses on operations; SA on configuration and reporting.
-
Bed Management Coordinator + Charge Nurse for same ward - Risk: Single user could both request and approve transfers and bed assignments. - Control: BMC handles central allocation; Charge Nurse approves transfers for their ward.
-
Physician + Scheduling Administrator - Risk: Physician could alter scheduling rules to favour own clinic or OR time. - Control: Physicians provide input; SA implements with governance approval.
-
OR Scheduler + Bed Management Coordinator - Risk: Single user could manipulate both OR and bed allocations, affecting patient flow and fairness. - Control: Keep OR scheduling and bed management roles distinct.
2. Dual Sign-Off Requirements
Certain high-impact actions should require dual approval or at least dual visibility:
-
Overbooking beyond defined threshold: - Initiator: Senior Scheduling Clerk. - Approver: Scheduling Administrator or Department Manager. - System: Enforce workflow where overbooking > configured limit cannot be finalised without second approval.
-
Cross-ward or cross-facility transfer of critical patients (ICU, HDU): - Initiator: Bed Management Coordinator. - Approver: Charge Nurse (origin and/or destination ward) or Physician. - System: Require electronic approval before finalising transfer and sending ADT A02.
-
Changes to global scheduling rules (e.g., cancellation penalties, lead times): - Initiator: Scheduling Administrator. - Approver: Operations Director / Patient Access Manager. - System: Maintain versioned history of rules with who-approved metadata.
-
OR block allocation changes for high-demand rooms: - Initiator: OR Scheduler. - Approver: OR Manager / Surgical Services Director. - System: Log all block changes and require approval for long-term block adjustments.
-
Emergency mode activation (facility-wide override): - Initiator: Operations Director / On-call Administrator. - Approver: Second senior leader (e.g., Medical Director or Nursing Director). - System: Record both approvals and time window; automatically revert after configured duration.
UAE Regulatory Compliance
This module’s roles and permissions must be implemented in a way that supports compliance with UAE healthcare and data protection regulations.
1. Federal Law No. 2 of 2019 (ICT in Health Fields)
- Requires confidentiality and controlled access to health data.
- Scheduling & bed/OR data, while operational, can reveal sensitive information (e.g., admission to psychiatric ward, isolation status).
- Role-based and context-based controls ensure that only authorised staff can see and act on such data.
- ADT messages (A01/A02/A03/A04) must be sent only by authorised roles (BMC, SA under strict controls) and logged.
2. UAE PDPL (Federal Decree-Law No. 45/2021)
- Health data is sensitive personal data; processing is allowed without consent for treatment and health system management, but must follow:
- Data minimisation: Clerks see only what is needed for scheduling; clinical details are restricted.
- Purpose limitation: Scheduling data is not reused for marketing or unrelated analytics without additional legal basis.
- Access logging: All access and changes to appointments, encounters, bed assignments, and OR cases are logged with user, timestamp, and purpose.
- BTG and emergency overrides are treated as high-risk processing and must be covered in the facility’s DPIA.
3. DOH (Abu Dhabi) / DHA (Dubai) Requirements
- Malaffi / NABIDH:
- ADT messages must be generated only by authorised roles and must accurately reflect encounter status and location.
- Role-based controls prevent unauthorised creation or modification of encounters that would lead to incorrect HIE data.
- ADHICS / DHA Security Standards:
- Require strong access control, least privilege, and audit logging.
- Multi-factor authentication and network controls (implemented at platform level) complement module-level RBAC.
- Time-based and location-based restrictions support ADHICS principles for critical operations (e.g., bed transfers, OR scheduling).
4. Insurance & Operational Governance
- Appointment and encounter data feed Billing & Claims and Policy & Contract Management modules.
- Segregation of duties and dual sign-off reduce risk of:
- Fraudulent admissions or discharges.
- Manipulation of OR or bed allocations for financial gain.
- Audit logs from this module must be available to internal audit and compliance teams for investigations and regulatory inspections.
This roles & permissions specification must be implemented in coordination with the global RBAC framework defined in ../ehr-patient-mgmt/02-roles-permissions.md, ensuring consistent user identity, role assignment, and audit logging across the HIS.