EHR & Patient Management User Roles & Permissions
Home / Clinical Modules / EHR & Patient Management / Roles & Permissions

EHR & Patient Management User Roles & Permissions

This document defines the role-based access control (RBAC) model for the EHR & Patient Management module. It covers role definitions, granular permissions, role hierarchy, context-based access rules, break-the-glass (BTG) procedures, segregation of duties, and UAE-specific regulatory considerations (Federal Law No. 2 of 2019, UAE PDPL, DOH ADHICS, DHA/NABIDH, DOH/Malaffi).

Role Definitions

Note: “Access scope” below describes the maximum technical capability. Actual access is further constrained by context-based rules (facility, department, treating relationship, BTG).

Registration Clerk

  • Description: Front-desk / registration staff responsible for creating and updating patient registrations and capturing insurance and consent.
  • Typical UAE Job Titles:
  • Registration Clerk
  • Patient Services Representative
  • Front Desk Executive
  • Scope of Access:
  • Patients: All patients registered at their assigned facility; cross-facility search may be allowed for MPI duplicate checking (demographics only).
  • Data:
    • Full demographics (names EN/AR, Emirates ID, passport, contact details, address, emergency contacts).
    • Administrative identifiers (MRN, insurance member ID).
    • Insurance details and eligibility status.
    • High-level clinical flags only (allergy banner, problem list summary) as read-only.
    • Consent status (PDPL data processing, HIE sharing, portal consent).
  • No access to detailed clinical notes, lab results, imaging, or sensitive clinical categories (mental health, HIV, etc.).
  • Reporting Hierarchy:
  • Reports to: Senior Registration Clerk or Patient Access Supervisor.
  • Indirectly to: Revenue Cycle Manager / Operations Manager.

Senior Registration Clerk

  • Description: Experienced registration staff with supervisory and approval responsibilities for critical demographic changes.
  • Typical UAE Job Titles:
  • Senior Registration Officer
  • Patient Access Supervisor
  • Scope of Access:
  • All Registration Clerk access.
  • Approve critical demographic changes (name, DOB, Emirates ID, MRN merges).
  • Manage patient categories (VIP, VVIP, charity, corporate).
  • View and act on demographic change queues.
  • Reporting Hierarchy:
  • Reports to: Patient Access Manager / Revenue Cycle Manager.
  • Supervises: Registration Clerks.

Medical Records Officer (MRO)

  • Description: Health Information Management (HIM) staff responsible for medical records integrity, document management, and MPI quality.
  • Typical UAE Job Titles:
  • Medical Records Officer
  • Health Information Management Officer
  • Medical Records Technician
  • Scope of Access:
  • Patients: All patients across the organization (for records integrity and MPI).
  • Data:
    • Full demographics and identifiers.
    • Document metadata and content (scanned documents, external reports).
    • Clinical notes as needed for coding/records integrity (read-only).
    • Duplicate suspect lists and merge tools.
    • Audit logs related to registration, demographics, and document access.
  • Cannot modify clinical content (problems, allergies, notes) except via defined HIM correction workflows.
  • Reporting Hierarchy:
  • Reports to: HIM Supervisor.
  • Works closely with: Coding team, Quality & Compliance.

HIM Supervisor

  • Description: Senior HIM professional overseeing medical records, MPI, document management, and privacy-related functions.
  • Typical UAE Job Titles:
  • HIM Supervisor
  • Medical Records Supervisor
  • Health Information Manager
  • Scope of Access:
  • All MRO access.
  • Approve patient merges and high-risk MPI actions (dual sign-off).
  • Configure document types, note templates (in coordination with clinical informatics).
  • Manage consent form templates and retention rules (with Legal/Compliance).
  • Perform privacy officer–adjacent functions where a dedicated Privacy Officer is not appointed.
  • Reporting Hierarchy:
  • Reports to: Director of Clinical Support Services / Quality Director.
  • Supervises: Medical Records Officers and Clerks.

Physician

  • Description: Licensed medical doctor providing direct patient care and clinical documentation.
  • Typical UAE Job Titles:
  • Consultant Physician
  • Specialist / Resident
  • General Practitioner
  • Scope of Access:
  • Patients:
    • Full access to patients under their care (encounters where they are attending, consulting, or covering).
    • Read-only or restricted access to other patients via BTG when justified.
  • Data:
    • Full clinical record: problems, allergies, medications, vitals, results, imaging reports, clinical notes, documents.
    • Demographics and identifiers (read-only).
    • Ability to create and sign clinical notes, manage problem list and allergies.
    • View consents and document consent discussions.
  • Reporting Hierarchy:
  • Reports to: Department Head / Medical Director.
  • May supervise: Residents, interns, allied health.

Nurse

  • Description: Licensed nurse providing bedside care and nursing documentation.
  • Typical UAE Job Titles:
  • Registered Nurse
  • Staff Nurse
  • Charge Nurse
  • Scope of Access:
  • Patients:
    • Full access to patients in their assigned ward/clinic and under their nursing care.
    • BTG access for emergencies within facility.
  • Data:
    • Full clinical view similar to Physician, except:
    • Cannot sign physician-type notes (e.g., discharge summaries).
    • Cannot manage problem list (may suggest changes via notes).
    • Can document nursing notes, vitals, care plans, and allergies.
    • Read-only access to demographics and insurance.
  • Reporting Hierarchy:
  • Reports to: Charge Nurse / Nurse Manager.
  • Indirectly to: Nursing Director / CNO.

Allied Health Professional

  • Description: Clinical staff such as physiotherapists, dietitians, occupational therapists, respiratory therapists, etc.
  • Typical UAE Job Titles:
  • Physiotherapist
  • Dietitian
  • Occupational Therapist
  • Respiratory Therapist
  • Scope of Access:
  • Patients:
    • Patients for whom they have active referrals/consults or are assigned in care plans.
  • Data:
    • View relevant clinical record (problems, allergies, medications, results, notes).
    • Create and edit specialty-specific notes (e.g., PT assessment).
    • View orders relevant to their discipline.
    • Limited ability to update allergies (e.g., record reported reaction, pending verification).
  • Reporting Hierarchy:
  • Reports to: Allied Health Supervisor / Department Head.
  • Collaborates with: Physicians and Nurses.

System Administrator

  • Description: IT staff responsible for system configuration, user provisioning, and technical operations.
  • Typical UAE Job Titles:
  • HIS Administrator
  • Application Support Specialist
  • IT Systems Administrator
  • Scope of Access:
  • Data:
    • Manage users, roles, permissions, facilities, departments, and locations.
    • View configuration data and logs.
    • No default right to view clinical content; any such access must be via controlled support workflows and is heavily audited.
  • Patients:
    • Access to patient data only when performing support tasks, ideally on masked or test data; BTG required for production clinical data.
  • Reporting Hierarchy:
  • Reports to: IT Manager / CIO.
  • Works with: Security Officer, HIM Supervisor.

Privacy Officer

  • Description: Designated officer responsible for privacy governance, PDPL compliance, and access audits.
  • Typical UAE Job Titles:
  • Data Protection Officer (DPO)
  • Privacy Officer
  • Compliance Officer – Data Protection
  • Scope of Access:
  • Data:
    • Access to audit logs for all users and patients.
    • Ability to review BTG events, consent configurations, and privacy reports.
    • Read-only access to clinical content when investigating incidents.
  • Cannot modify clinical data; can initiate corrective actions and recommend sanctions.
  • Reporting Hierarchy:
  • Reports to: CEO / Board / Chief Compliance Officer (independent line as per PDPL best practice).
  • Works with: HIM Supervisor, IT Security, Legal.

Patient (Portal)

  • Description: Patient accessing their own record via the patient portal.
  • Typical UAE Context:
  • Adult patients, or parents/guardians for minors (proxy access).
  • Scope of Access:
  • Patients: Self only (and dependents where proxy is granted).
  • Data:
    • View own demographics and limited clinical records (as configured by facility and HIE policies).
    • Update contact information (address, phone, email).
    • Manage own consents (data sharing, portal, HIE, research).
    • Upload personal documents (e.g., external reports).
  • Reporting Hierarchy:
  • Not an employee role; governed by patient portal terms and conditions.

Permission Matrix

Legend:

  • ✅ = Allowed by default
  • ❌ = Not allowed
  • 🔒 = Conditional / context-based (facility, department, treating relationship, BTG, or approval required)

Roles included:

  • RC = Registration Clerk
  • SRC = Senior Registration Clerk
  • MRO = Medical Records Officer
  • HIM = HIM Supervisor
  • PHY = Physician
  • NUR = Nurse
  • AHP = Allied Health Professional
  • ADM = System Administrator
  • PO = Privacy Officer
  • PAT = Patient (Portal)
Permission / Function RC SRC MRO HIM PHY NUR AHP ADM PO PAT
Patient Demographics & Registration
View patient demographics ✅ ✅ ✅ ✅ ✅ ✅ ✅ 🔒 🔒 ✅*
Create new patient registration ✅ ✅ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌
Edit non-critical demographics (address, phone, email) ✅ ✅ 🔒 🔒 ❌ ❌ ❌ ❌ ❌ ✅*
Edit critical demographics (name, DOB, Emirates ID) 🔒 ✅ 🔒 ✅ ❌ ❌ ❌ ❌ ❌ ❌
Approve pending critical demographic changes ❌ ✅ ❌ ✅ ❌ ❌ ❌ ❌ ❌ ❌
Verify Emirates ID format and uniqueness ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌ ❌ ❌
Search patient (MRN, Emirates ID, name, DOB) ✅ ✅ ✅ ✅ ✅ ✅ ✅ 🔒 🔒 🔒*
View patient category (VIP, VVIP, etc.) ✅ ✅ ✅ ✅ ✅ ✅ ✅ 🔒 🔒 ❌
Manage patient category (VIP, charity, etc.) ❌ ✅ 🔒 ✅ ❌ ❌ ❌ ❌ ❌ ❌
Identifiers & MPI
View patient identifiers (MRN, Emirates ID, passport) ✅ ✅ ✅ ✅ ✅ ✅ ✅ 🔒 🔒 ✅*
Add secondary identifiers (passport, visa, etc.) ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌ ❌ ❌
Edit identifiers (non-Emirates ID) ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌ ❌ ❌
Edit Emirates ID 🔒 ✅ 🔒 ✅ ❌ ❌ ❌ ❌ ❌ ❌
View duplicate suspects list ❌ ❌ ✅ ✅ ❌ ❌ ❌ ❌ 🔒 ❌
Perform patient merge (execute) ❌ ❌ 🔒 🔒 ❌ ❌ ❌ ❌ ❌ ❌
Approve patient merge (dual sign-off) ❌ ❌ 🔒 ✅ ❌ ❌ ❌ ❌ 🔒 ❌
Insurance & Eligibility
View insurance information ✅ ✅ ✅ ✅ ✅ ✅ ✅ 🔒 🔒 ✅*
Add / update insurance policy details ✅ ✅ ❌ ❌ ❌ ❌ ❌ ❌ ❌ 🔒*
Run insurance eligibility check (eClaimLink / DOH eClaims) ✅ ✅ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌
Clinical Summary & Chart Access
View patient chart overview (problems, allergies, etc.) 🔒 🔒 🔒 🔒 ✅ ✅ ✅ 🔒 🔒 ✅*
View detailed clinical notes ❌ ❌ 🔒 🔒 ✅ ✅ ✅ 🔒 🔒 ✅*
View sensitive clinical categories (HIV, mental health) ❌ ❌ 🔒 🔒 🔒 🔒 🔒 🔒 🔒 🔒*
Allergies & Problem List
View allergy list 🔒 🔒 ✅ ✅ ✅ ✅ ✅ 🔒 🔒 ✅*
Add / edit allergies ❌ ❌ ❌ ❌ ✅ ✅ 🔒 ❌ ❌ ❌
Mark NKA / NKDA ❌ ❌ ❌ ❌ ✅ ✅ 🔒 ❌ ❌ ❌
View problem list 🔒 🔒 ✅ ✅ ✅ ✅ ✅ 🔒 🔒 ✅*
Add / edit problem list entries ❌ ❌ ❌ ❌ ✅ ❌ 🔒 ❌ ❌ ❌
Resolve / inactivate problems ❌ ❌ ❌ ❌ ✅ ❌ 🔒 ❌ ❌ ❌
Clinical Notes & Documentation
Create clinical note (physician-type) ❌ ❌ ❌ ❌ ✅ ❌ 🔒 ❌ ❌ ❌
Create nursing note ❌ ❌ ❌ ❌ 🔒 ✅ ❌ ❌ ❌ ❌
Create allied health note ❌ ❌ ❌ ❌ 🔒 🔒 ✅ ❌ ❌ ❌
Edit own draft notes ❌ ❌ ❌ ❌ ✅ ✅ ✅ ❌ ❌ ❌
Sign clinical notes ❌ ❌ ❌ ❌ ✅ 🔒 🔒 ❌ ❌ ❌
Co-sign notes (e.g., trainee notes) ❌ ❌ ❌ ❌ ✅ ❌ ❌ ❌ ❌ ❌
Add addendum to signed note ❌ ❌ ❌ ❌ ✅ ✅ ✅ ❌ ❌ ❌
Configure note templates ❌ ❌ ❌ ✅ 🔒 🔒 🔒 ✅ ❌ ❌
Document Management
View patient documents 🔒 🔒 ✅ ✅ ✅ ✅ ✅ 🔒 🔒 ✅*
Scan / upload documents ✅ ✅ ✅ ✅ ✅ ✅ ✅ 🔒 ❌ ✅*
Edit document metadata (type, date, description) ✅ ✅ ✅ ✅ 🔒 🔒 🔒 ❌ ❌ ❌
Delete / purge documents (per retention policy) ❌ ❌ 🔒 ✅ ❌ ❌ ❌ ❌ ❌ ❌
Consent Management
View consent records ✅ ✅ ✅ ✅ ✅ ✅ ✅ 🔒 ✅ ✅*
Capture general treatment consent ✅ ✅ ❌ ❌ ✅ ✅ ❌ ❌ ❌ 🔒*
Capture PDPL data processing consent ✅ ✅ ❌ ❌ ✅ ✅ ❌ ❌ ❌ 🔒*
Capture HIE data sharing consent (NABIDH/Malaffi) ✅ ✅ ❌ ❌ ✅ ✅ ❌ ❌ ❌ 🔒*
Configure consent form templates ❌ ❌ ❌ ✅ ❌ ❌ ❌ ✅ ✅ ❌
Record consent withdrawal 🔒 🔒 ❌ ✅ ✅ ✅ ❌ ❌ ✅ ✅*
User & Role Management
Create / edit user accounts ❌ ❌ ❌ ❌ ❌ ❌ ❌ ✅ ❌ ❌
Assign roles to users ❌ ❌ ❌ ❌ ❌ ❌ ❌ ✅ 🔒 ❌
Configure roles and permissions ❌ ❌ ❌ ❌ ❌ ❌ ❌ ✅ 🔒 ❌
Manage facilities / departments / locations ❌ ❌ ❌ ❌ ❌ ❌ ❌ ✅ ❌ ❌
Audit & Privacy
View own access audit trail ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
View patient-specific access audit log ❌ ❌ 🔒 🔒 🔒 🔒 🔒 🔒 ✅ 🔒*
View system-wide audit logs ❌ ❌ ❌ ❌ ❌ ❌ ❌ 🔒 ✅ ❌
Review BTG events ❌ ❌ ❌ 🔒 ❌ ❌ ❌ 🔒 ✅ ❌
Generate privacy / access reports ❌ ❌ ❌ 🔒 ❌ ❌ ❌ 🔒 ✅ ❌
Break-the-Glass (BTG)
Initiate BTG access to patient record ❌ ❌ ❌ ❌ ✅ ✅ ✅ 🔒 🔒 ❌
Approve BTG override (where approval workflow used) ❌ ❌ ❌ 🔒 🔒 🔒 ❌ 🔒 ✅ ❌
Patient Portal–Specific
View own clinical summary ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ✅
Download own records (PDF / FHIR export) ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ✅
Upload personal documents ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ✅ 

\* PAT permissions are limited to their own record (and authorized dependents) and subject to facility policy and HIE rules.

---

## Role Hierarchy

This diagram shows logical inheritance of **functional scope** (not organizational reporting lines). Higher nodes inherit all permissions of lower nodes plus additional capabilities, except where explicitly restricted for segregation-of-duties.

```mermaid
graph TD
    SA[System Administrator] -->|Manages| RCFG[Role / Config Admin]
    RCFG -->|Supports| HIMSUP[HIM Supervisor]
    HIMSUP -->|Supervises| MRO[Medical Records Officer]

    HIMSUP -->|Approves| SRC[Senior Registration Clerk]
    SRC -->|Supervises| RC[Registration Clerk]

    MEDDIR[Medical Director] --> PHY[Physician]
    NURSMGR[Nurse Manager] --> NUR[Nurse]
    AHSUP[Allied Health Supervisor] --> AHP[Allied Health Professional]

    POFF[Privacy Officer] -->|Oversight| ALL[All Operational Roles]

    PATP[Patient (Portal)]:::patient

    classDef patient fill:#f5f5f5,stroke:#999,stroke-width:1px;

Notes:

  • System Administrator does not inherit clinical viewing rights by default; any clinical access is via BTG and support workflows.
  • HIM Supervisor functionally supersedes MRO and has additional configuration and approval rights.
  • Senior Registration Clerk supersedes Registration Clerk for registration functions.
  • Privacy Officer has oversight, not command; they do not inherit operational permissions but have broad audit visibility.

Context-Based Access Rules

Context-based rules refine the permission matrix to meet UAE regulatory and privacy requirements (Federal Law No. 2 of 2019, UAE PDPL, ADHICS, NABIDH/Malaffi policies).

1. Facility-Based Restrictions (Multi-Facility)

  1. Default rule: Users can access patient records only for facilities where they have an active user_roles assignment.
  2. Cross-facility MPI: - Registration roles (RC, SRC, MRO, HIM) may search demographics across all facilities to avoid duplicates, but:
    • They see demographics only, not clinical data, for patients from other facilities.
  3. Corporate / group view: - Certain roles (HIM Supervisor, Privacy Officer) may have cross-facility access for records integrity and privacy audits, subject to management approval and contractual arrangements.

2. Department-Based Restrictions

  1. Clinical roles (PHY, NUR, AHP) are linked to one or more departments (e.g., Cardiology, ICU).
  2. Access to patient charts is limited to: - Encounters where the patient’s current location or ordering department matches the user’s department(s), or - The user is explicitly assigned as attending/consulting provider or part of the care team.
  3. Department-based restrictions are relaxed in: - Emergency Department (ED) and ICU, where any on-duty clinician in that unit may access all patients in that unit.

3. Patient Relationship Requirements

  1. Treating relationship: - Required for normal access by PHY, NUR, AHP. - System checks:
    • Active encounter where user is attending, consulting, or assigned nurse/therapist, or
    • Active care team assignment record.
  2. Non-treating access: - Blocked by default; user is prompted to use BTG if access is clinically justified (e.g., emergency, on-call consult).
  3. Administrative roles: - Registration and MRO may access demographics without treating relationship, but not detailed clinical content.

4. Time-Based Access (Shift-Based)

  1. User accounts have shift schedules (or at least active/inactive time windows) configured per facility policy.
  2. Outside scheduled shift: - Clinical access is blocked or restricted to BTG with additional justification.
  3. On-call: - On-call rosters can mark users as “on-call” for specific time windows, enabling access to assigned departments/patients.
  4. Session timeouts: - Inactivity timeouts and maximum session durations enforced per ADHICS / NESA guidelines.

5. Emergency / On-Call Overrides

  1. In emergencies (e.g., code blue, mass casualty), clinicians may: - Use BTG to access any patient in the facility.
  2. The system: - Requires reason selection (e.g., “Emergency treatment”, “On-call consult”). - Flags such access for mandatory post-event review by the Privacy Officer.
  3. For on-call consultants: - Access to patients in the on-call specialty is allowed during on-call window, even without prior assignment, but still logged and reviewable.

Break-the-Glass (BTG) Procedures

BTG is required by UAE privacy and health data regulations to balance patient safety with confidentiality (Federal Law No. 2 of 2019, UAE PDPL, ADHICS, NABIDH/Malaffi policies).

1. When BTG Is Required

BTG is required when:

  1. A user attempts to access a patient record and: - They do not have an active treating relationship, or - The patient’s record is marked as restricted (e.g., VIP, staff patient, sensitive clinical category), or - Access occurs outside the user’s assigned facility/department or shift.
  2. Examples: - Physician in ED needs to view a patient normally followed by another department. - Nurse responding to a code in a different ward. - Accessing records of hospital staff or VIPs. - System administrator needs to inspect a live record to troubleshoot a critical issue (should be rare and strongly discouraged).

2. BTG Workflow

  1. Trigger: - User attempts access; system detects violation of normal context rules.
  2. Warning Screen: - System displays a clear warning:
    • “You are attempting to access a record outside your normal privileges. This action will be fully audited and reviewed.”
  3. Justification: - User must:
    1. Select a reason from a controlled list (e.g., “Emergency treatment”, “On-call consult”, “Clinical supervision”, “Technical support”).
    2. Optionally enter free-text details (mandatory for technical support).
  4. Optional Approval (Configurable): - For certain categories (e.g., staff records, VIPs, mental health records), the system may require:
    • Immediate approval by a supervisor or on-call senior (HIM Supervisor / Medical Director), or
    • Retrospective approval within a defined SLA (e.g., 24 hours).
  5. Access Grant: - Upon confirmation (and approval if required), system grants:
    • Time-limited access (e.g., 30–60 minutes).
    • Scope-limited access (only necessary modules/screens).
  6. Session Marking: - All actions in that session are tagged with is_btg = true and the BTG reason.

3. Audit Trail Requirements

For every BTG event, the system must log at minimum:

  • User ID and role.
  • Patient ID and MRN.
  • Timestamp (start and end of BTG session).
  • Reason code and free-text justification.
  • Access channel (workstation ID, IP address, application).
  • Resources accessed (screens, modules, specific records).
  • Any data exports (print, PDF, FHIR export).

These are stored in audit_log with is_btg = true and must be immutable.

4. Post-Access Review Process

  1. Automated Notification: - Privacy Officer (and optionally HIM Supervisor) receives automated alerts for:
    • All BTG events, or
    • BTG events matching high-risk criteria (VIP, staff, sensitive categories).
  2. Review SLA: - BTG events must be reviewed within 24–72 hours, per facility policy.
  3. Review Steps:
  4. Verify that the user’s justification aligns with clinical/operational context (e.g., ED encounter, code event).
  5. Check whether the access volume and duration were proportionate.
  6. Document review outcome (valid, questionable, invalid).
  7. For invalid or suspicious events:
    • Escalate to HR / Medical Director.
    • Consider disciplinary actions and additional training.
  8. Reporting: - Monthly BTG summary reports (counts, reasons, departments) for governance committees. - KPIs: Break-the-Glass Rate (as defined in module KPIs).

5. UAE PDPL & Federal Law No. 2/2019 Implications

  • BTG access is still processing of sensitive personal data under PDPL and Federal Law No. 2/2019.
  • Legal basis:
  • Typically justified under vital interests or healthcare exemption (necessary for diagnosis/treatment).
  • Requirements:
  • Must be necessary and proportionate.
  • Must be logged and reviewable.
  • Must be covered in internal policies and staff training.
  • Patients’ rights:
  • Upon request, patients may be informed of who accessed their records and when, including BTG events, unless disclosure would pose a serious risk (e.g., ongoing investigation).

Segregation of Duties

To reduce fraud, abuse, and privacy risks, certain role combinations and actions require separation and dual control.

1. Conflicting Role Combinations

The system should prevent or flag assignment of the following conflicting role combinations to the same user:

Role A Role B Risk Reason System Control
System Administrator Privacy Officer Admin could alter logs or bypass privacy controls Hard block; require separate individuals
System Administrator Registration Clerk / SRC Admin could create fake patients and manipulate billing data Strongly discouraged; require CIO approval + audit
System Administrator Physician / Nurse Admin could alter own clinical records or access logs Hard block or require explicit exception approval
HIM Supervisor Privacy Officer Concentration of power over records and privacy oversight Allowed only in small facilities with board approval; flagged in audit
Registration Clerk Medical Records Officer Same person could create and manipulate records Discouraged; if allowed, limit MRO functions
Medical Records Officer Billing / Claims roles* Potential for coding and billing manipulation Enforced at enterprise RBAC level

* Billing/Claims roles are defined in RCM modules but must be considered in enterprise RBAC.

2. Dual Sign-Off Requirements

  1. Patient Merge (MPI): - Initiator: MRO. - Approver: HIM Supervisor (or designated senior). - System enforces:
    • Two distinct users with appropriate roles.
    • No self-approval.
  2. Critical Demographic Changes: - Changes to name, DOB, Emirates ID:
    • Initiator: RC / SRC / MRO.
    • Approver: SRC or HIM Supervisor.
  3. Record Purge / Retention Overrides: - Initiator: MRO or HIM Supervisor. - Approver: Privacy Officer or Legal/Compliance delegate.
  4. BTG for Staff / VIP Records: - BTG events involving staff or VIP patients may require:
    • Retrospective approval by Privacy Officer and HR/Medical Director.

The system should provide configuration to define which actions require dual sign-off and enforce that the two signatories are different users with appropriate roles.

UAE Regulatory Compliance

This RBAC model is designed to align with UAE healthcare and data protection regulations:

  1. Federal Law No. 2 of 2019 (Use of ICT in Health Fields): - Requires confidentiality and controlled access to health data. - HIS must implement role-based and context-based access, with comprehensive audit logging. - BTG and sealed-envelope patterns support controlled access to sensitive records.

  2. UAE PDPL (Federal Decree-Law No. 45/2021): - Health data is sensitive personal data. - RBAC and BTG support:

    • Data minimization (only necessary users see necessary data).
    • Purpose limitation (treatment vs. admin vs. research).
    • Data subject rights (audit logs enable access reports to patients).
    • Consent management permissions ensure explicit consent is captured and withdrawal is respected where required.

  3. DOH ADHICS & DHA / NABIDH Security Requirements: - Require:

    • Strong authentication and least-privilege access.
    • Detailed audit trails for all access to health information.
    • Special handling for VIP and staff records.
    • Context-based rules (facility, department, treating relationship) and BTG align with these standards.

  4. NABIDH / Malaffi HIE Policies: - Consent capture and sharing permissions ensure:

    • Only authorized users can view and share data with HIEs.
    • Consent status is visible and enforced.
    • Audit logs support traceability of data shared with HIEs.

  5. Data Residency & Cybersecurity (TDRA/NESA): - While primarily infrastructure-focused, RBAC and BTG contribute to:

    • Access control requirements.
    • Incident detection and response (via audit logs and BTG review).

Implementation teams must ensure that:

  • RBAC configuration is reviewed by IT Security, HIM, and Privacy Officer.
  • Staff are trained on BTG usage and consequences of misuse.
  • Periodic access reviews are conducted (e.g., quarterly) to validate role assignments and detect conflicts.
← Previous EHR & Patient Management Workflows Next → EHR & Patient Management Data Specifications
content/clinical/ehr-patient-mgmt/02-roles-permissions.md Generated 2026-02-20 22:54