Physician Portal & Mobile App User Roles & Permissions

This document defines role-based and context-based access control for the Physician Portal & Mobile App (physician-portal) in UAE hospitals. It is designed for implementation of RBAC, authorization middleware, and administrative configuration screens, aligned with UAE regulations (Federal Law No. 2/2019, UAE PDPL, DOH ADHICS, DHA/NABIDH).

Role Definitions

For all roles below, user identity and base employment/credential data come from users and providers in ehr-patient-mgmt. The portal module adds channel-specific permissions and constraints.

1. Physician

• Description
  Licensed physician with full clinical use of the portal/mobile app for patient care, including orders, documentation, results review, messaging, handoff, and task management.

• Typical UAE Job Titles

• Consultant Physician
• Specialist / Senior Specialist
• General Practitioner (Hospital-based)

• Staff Physician

• Scope of Access

• Patients
  • All patients where the physician is:
  • Attending/consulting provider on the encounter care team, or
  • On-call/covering provider for the relevant service, or
  • Explicitly assigned via scheduling (clinic lists, inpatient census).
  • 🔒 Context-based extensions:
  • ED/on-call: any patient in ED or assigned on-call panel.
  • BTG: emergency access to non-panel patients with justification.

• Data Types

  • Full clinical chart for in-scope patients: demographics, allergies, problems, meds, labs, imaging, notes, orders, vitals, care team.
  • Secure messaging (patient and provider), handoff records, task lists.
  • Own schedule and assigned patient lists.
  • No direct access to billing/claims or administrative HR data from this module.

• Reporting Hierarchy

• Reports clinically to Department Head / Chief Medical Officer (CMO).
• Operationally overseen by Medical Staff Office and Clinical Informatics for portal usage.
• Portal permissions managed by Portal Administrator under CMO governance.

2. Nurse Practitioner / Physician Assistant (NP/PA)

• Description
  Advanced practice provider with ordering and documentation privileges within defined scope of practice and collaborative agreements.

• Typical UAE Job Titles

• Nurse Practitioner
• Physician Assistant

• Advanced Practice Nurse

• Scope of Access

• Patients
  • Patients on panels/encounters where NP/PA is:
  • Listed as primary or secondary provider, or
  • Linked via collaborative agreement to supervising physician on the encounter, or
  • On-call/covering for the service.

• Data Types

  • Same clinical views as Physician for in-scope patients.
  • Order entry and documentation limited to scope-of-practice rules configured per specialty (e.g., some high-risk orders blocked).
  • Messaging, task management, and handoff similar to Physician.

• Reporting Hierarchy

• Clinically reports to supervising physician(s) and Department Head.
• Credentialing and scope-of-practice maintained by Medical Staff Office.
• Portal access managed by Portal Administrator with approval from supervising physician/department.

3. Nurse (Portal Context)

• Description
  Registered nurse or charge nurse using the portal/mobile app primarily for communication, task management, and limited chart review while away from ward workstations.

• Typical UAE Job Titles

• Registered Nurse (RN)
• Charge Nurse

• Senior Staff Nurse

• Scope of Access

• Patients
  • Patients assigned to the nurse’s ward/unit and shift (from scheduling/bed management).
  • Patients explicitly delegated by physicians for follow-up via tasks or messages.

• Data Types

  • Read-only access to key clinical summary: demographics, allergies, problems, meds list, vitals, results summary, active orders.
  • Secure messaging with providers and patients (where delegated).
  • Task lists (own and delegated tasks).
  • No ability to sign physician notes or independently sign orders via this module.

• Reporting Hierarchy

• Reports to Nurse Manager / Nursing Director.
• Clinical access governed by Chief Nursing Officer (CNO) policies.
• Portal role assignment approved by Nursing leadership and configured by Portal Administrator.

4. Specialist Consultant

• Description
  External or internal specialist providing consultative services, often cross-facility or via telehealth, with focused access to referred patients.

• Typical UAE Job Titles

• Visiting Consultant
• External Specialist (e.g., Cardiologist, Neurologist)

• Teleconsultant Physician

• Scope of Access

• Patients
  • Patients for whom:
  • A consult order has been placed to this consultant or their group, or
  • A referral has been accepted and scheduled, or
  • They are explicitly added to the care team.
  • 🔒 No general census access; no browsing of unrelated patients.

• Data Types

  • Full clinical chart for referred encounters.
  • Ability to enter consult notes, recommendations, and orders within agreed scope.
  • Messaging with referring providers and, if allowed, with patients.
  • Limited schedule view (consult slots, referred patients only).

• Reporting Hierarchy

• Contractually linked to the facility; clinically accountable to the relevant Department Head / CMO.
• Portal access approved by Medical Staff Office and CMO; configured by Portal Administrator.

5. Chief Medical Officer / Department Head

• Description
  Senior clinical leadership with oversight of clinical quality, safety, and portal adoption. Has extended visibility and supervisory capabilities.

• Typical UAE Job Titles

• Chief Medical Officer (CMO)
• Medical Director

• Department Head / Chair

• Scope of Access

• Patients
  • Read access to clinical data for:
  • Patients within their department(s) or service lines, and
  • Any patient where supervisory review is required (e.g., incident review, quality audits).
  • 🔒 BTG access for cross-department review with justification.

• Data Types

  • All clinical data for in-scope patients.
  • Department-level dashboards: portal usage, task completion, result acknowledgment metrics.
  • Ability to manage provider access within their department (approve/disable).
  • No direct claims/billing configuration via this module.

• Reporting Hierarchy

• Reports to CEO/Medical Board.
• Oversees physicians and advanced practice providers in their departments.
• Works with Portal Administrator and Clinical Informatics to define role policies.

6. Portal Administrator

• Description
  Non-clinical or clinical-IT role responsible for configuration, account lifecycle management, and monitoring of the physician portal/mobile app.

• Typical UAE Job Titles

• HIS Administrator
• Clinical Applications Specialist
• Health Informatics Officer

• IT Systems Administrator (Clinical Systems)

• Scope of Access

• Patients
  • No routine access to clinical content.
  • 🔒 May have BTG-like technical access for troubleshooting, but by default:
  • Only sees pseudonymised or masked data in admin tools where possible.

• Data Types

  • Full access to portal configuration: notification rules, role templates, feature toggles.
  • Account management: create/activate/deactivate portal accounts, reset MFA, manage device tokens.
  • Usage analytics and audit logs (aggregated and per-user).
  • No ability to enter clinical orders or documentation.

• Reporting Hierarchy

• Reports to IT Director / CIO, with dotted-line to CMO for clinical governance.
• Operates under policies approved by Data Protection Officer (if appointed) and Information Security Officer, in line with ADHICS/NESA and PDPL.

Permission Matrix

Legend:

• ✅ = Allowed by default
• ❌ = Not allowed
• 🔒 = Conditional / context-based (requires additional conditions, configuration, or BTG)

Roles (columns):

• PHY = Physician
• NPPA = Nurse Practitioner / PA
• NUR = Nurse (portal context)
• CONS = Specialist Consultant
• CMO = CMO / Department Head
• PORTAL-ADM = Portal Administrator

**Implementation notes:**

- 🔒 permissions must be enforced via:
  - Role configuration (e.g., NP/PA scope-of-practice),  
  - Context checks (patient relationship, facility, time, location), and  
  - BTG workflows where applicable.
- Portal Administrator should have a configuration UI to toggle certain 🔒 permissions per facility/department, subject to governance.

---

## Role Hierarchy

Permissions inherit downward where indicated; higher roles may have all permissions of lower roles plus additional supervisory capabilities. Inheritance should be implemented via role groups or composite roles.

```mermaid
graph TD
    CMO[Chief Medical Officer / Medical Director] --> DH[Department Head / Chair]
    DH --> PHY[Physician]
    DH --> NPPA[Nurse Practitioner / PA]
    DH --> CONS[Specialist Consultant]
    CNO[Chief Nursing Officer] --> NM[Nurse Manager]
    NM --> NUR[Nurse (Portal Context)]
    ITD[IT Director / CIO] --> PADM[Portal Administrator]

    CMO -. governance .- ITD
    CMO -. clinical governance .- CNO

    %% Inheritance notes
    PHY:::role
    NPPA:::role
    NUR:::role
    CONS:::role
    DH:::role
    CMO:::role
    PADM:::role

    classDef role fill:#e8f4ff,stroke:#2b6cb0,stroke-width:1px;

Inheritance semantics (for implementation):

• Department Head inherits all Physician permissions for their department +:
• Department-wide analytics, BTG review, provider access management.
• CMO inherits all Department Head permissions across all departments +:
• Cross-department BTG review, policy-level configuration approvals.
• Nurse Manager (not explicitly modeled as a separate portal role here) may be implemented as NUR + delegated admin flags if needed.
• Portal Administrator is separate: no clinical inheritance; only technical/admin permissions.

Context-Based Access Rules

These rules must be enforced in addition to RBAC, using attributes such as facility, department, encounter, time, and relationship. They are critical for compliance with Federal Law No. 2/2019, UAE PDPL, DOH ADHICS, and DHA/NABIDH.

1. Facility-Based Restrictions (Multi-Facility)

• Each physician_portal_account is linked to one or more facilities via providers and facilities relationships.
• Default rule:
  A user may only:
• View patients registered in facilities where they have active privileges, and
• Access schedules, census, and handoffs for those facilities.
• Multi-emirate groups (e.g., Dubai + Abu Dhabi):
• Facility-level flags indicate whether data is shared across the group or restricted per emirate.
• For DOH (Abu Dhabi) facilities, Malaffi integration rules apply; for DHA (Dubai), NABIDH rules apply. Portal must respect facility-level consent flags from those HIEs.

2. Department-Based Restrictions

• Department membership (from providers.department_id and departments) limits:
• Access to department-specific patient lists and schedules.
• Visibility of department metrics and analytics.
• Examples:
• A Cardiologist sees cardiology inpatients and clinics; cannot see Psychiatry patients unless formally on the care team.
• CMO can see all departments; Department Head can see only their department(s).

3. Patient Relationship Requirements

• Treating Relationship Check (core rule):
• Access to full chart is allowed only if at least one of the following is true:
  1. User is on the encounter care team (attending, consulting, primary nurse, etc.).
  2. User is on-call for the service covering that patient (based on on-call roster).
  3. User has an active consult/referral order assigned to them or their group.
  4. User has been delegated access via handoff or task assignment.
• If none of the above, only:
• Minimal demographic verification (if allowed by policy), or
• No access, unless BTG is invoked.

4. Time-Based Access (Shift & On-Call)

• Nurses:
• Access to unit patient lists limited to active shift window (e.g., 30 minutes before shift start to 30 minutes after shift end).
• Outside shift, only limited access to patients with explicit delegation (e.g., follow-up tasks).
• Physicians / NP/PA / Consultants:
• On-call coverage windows define when they can see broader on-call panels.
• After on-call period, access reverts to their own panel and active consults.
• Session Timeouts:
• Mobile sessions auto-timeout after configurable inactivity (e.g., 5–15 minutes) per ADHICS.
• Extended sessions require re-authentication (biometric or MFA).

5. Location-Based Access

• Inside hospital network:
• Standard MFA (password + biometric or OTP) for portal access.
• Outside hospital network / remote:
• Mandatory MFA (e.g., OTP + biometric) and device trust checks.
• Certain high-risk actions may be blocked or restricted:
  • E.g., configuration to block high-risk medication orders from remote sessions.
• Device-based controls:
• Jailbroken/rooted devices may be blocked.
• Offline caching limited to minimal necessary data and only for assigned patients.

6. Emergency / On-Call Overrides

• During declared emergency (e.g., mass casualty) or ED on-call:
• Facility may temporarily widen access scope for designated roles (e.g., ED physicians can see all ED-registered patients).
• Such modes must be:
  • Explicitly flagged in the system (emergency mode on/off).
  • Fully audited, with post-event review.

Break-the-Glass (BTG) Procedures

BTG is required when a user needs access to a patient record that is outside their normal treating relationship or departmental scope, but access is necessary for urgent clinical care.

1. When BTG is Required

• Provider attempts to open a patient chart where:
• No active care team relationship, AND
• No on-call coverage relationship, AND
• No delegation/handoff/task-based relationship.
• Access to restricted clinical data (e.g., mental health, HIV/STI, reproductive health) where sealed-envelope rules apply, even if the user is on the care team, may also require BTG justification depending on facility policy.

2. BTG Workflow

1. Trigger - User attempts to access a restricted chart or sealed record. - System detects lack of standard access rights.

2. Warning & Justification - System displays a modal:

   • “You are requesting emergency access to this patient’s record. This action will be fully audited and reviewed. Proceed only if necessary for immediate care.”
   • User must:
   • Select a reason from a controlled list (e.g., “Emergency treatment”, “Code Blue”, “Cross-coverage in emergency”, “Public health emergency”), and
   • Optionally enter free-text justification.

3. Access Grant - On confirmation:

   • System grants temporary access to the requested record.
   • Scope may be:
   • Entire chart, or
   • Only specific sections (e.g., ED summary) depending on configuration.
   • BTG session is time-limited (e.g., 30–60 minutes) and patient-specific.

4. Audit Logging - For each BTG event, log at minimum:

   • user_id, provider_id, role
   • patient_id, encounter_id (if applicable)
   • Timestamp (start/end of BTG session)
   • Reason code and free-text justification
   • Source device, IP, location (if available)
   • Sections accessed (e.g., notes, labs, imaging)
   • Store logs in immutable audit store per ADHICS/NESA guidance.

5. Post-Access Review - Automated daily report of BTG events sent to:

   • Data Protection Officer (if appointed),
   • CMO / Department Heads for clinical review,
   • Information Security for anomaly detection.
   • Each BTG event must be:
   • Classified as justified or unjustified.
   • Documented in the patient’s record if clinically relevant (e.g., “Emergency access used during resuscitation”).
   • Unjustified or suspicious BTG usage triggers:
   • Access suspension or role review,
   • Possible disciplinary process per facility policy.

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

• BTG processing is justified under:
• Healthcare exemption for diagnosis/treatment (PDPL Art. 10) and
• Vital interests of the data subject.
• Nevertheless:
• Access must be necessary and proportionate.
• Data minimization applies: only access what is needed for the emergency.
• BTG logs support accountability and demonstrate compliance in case of regulator inquiry (UAE Data Office, DOH, DHA).

Segregation of Duties

To reduce risk of misuse and ensure robust internal controls, certain role combinations and actions must be restricted or require dual sign-off.

1. Conflicting Role Combinations

The following combinations should not be assigned to the same user_id:

• Physician (or NP/PA) + Portal Administrator
• Risk: Ability to both perform clinical actions and manipulate audit/configuration.

• Policy: Clinical roles and technical admin roles must be separated.

• CMO / Department Head + Portal Administrator

• Risk: Unchecked access to both clinical data and system configuration.

• Policy: CMO may have supervisory access but not technical admin rights.

• Nurse + Portal Administrator

• Risk: Nursing staff could modify access rights and logs for their own unit.
• Policy: Nursing leadership may participate in governance but not in technical admin.

If a small facility requires combined responsibilities, implement:

• Separate named accounts:
• One clinical account (e.g., dr.ahmed.clinical),
• One admin account (e.g., dr.ahmed.admin),
• With strict policy that admin account is used only for configuration, not clinical care.

2. Dual Sign-Off / Approval Requirements

• High-Risk Configuration Changes
• Examples:
  • Enabling/disabling BTG,
  • Changing default access scopes,
  • Modifying audit retention settings,
  • Changing notification rules for critical results.
• Require:
  • Initiation by Portal Administrator, and
  • Approval by CMO or designated clinical governance committee.

• System should:

  • Record both initiator and approver in configuration audit logs.

• Provider Access Management

• Activation/deactivation of portal accounts for physicians and NP/PA:
  • Initiated by Portal Administrator,
  • Approved by Medical Staff Office or Department Head.

• Role changes (e.g., upgrading from NUR to NP/PA):

  • Must be backed by updated credentialing records.

• BTG Policy Changes

• Any change to BTG reason codes, time limits, or scope:
  • Requires joint approval from:
  • Data Protection Officer (or equivalent), and
  • CMO / Information Security Officer.

UAE Regulatory Compliance

This module’s roles and permissions must be implemented in alignment with UAE-specific regulations:

1. Federal Law No. 2 of 2019 (Use of ICT in Health Fields)

• Requires:
• Confidentiality of health data,
• Controlled access based on professional need,
• Auditability of all access.
• Implementation in this module:
• RBAC + context-based access (treating relationship, facility, department).
• Comprehensive audit logs for chart access, BTG, result acknowledgment, and messaging.
• Role definitions aligned with licensed healthcare professions.

2. UAE PDPL (Federal Decree-Law No. 45/2021)

• Health data is sensitive personal data.
• Clinical processing for treatment is exempt from consent but still requires:
• Data minimization,
• Purpose limitation,
• Security and audit controls,
• Support for data subject rights where compatible with clinical retention.
• Implementation:
• Portal only exposes data necessary for clinical workflows.
• BTG and context-based access enforce necessity and proportionality.
• Audit logs support accountability and breach investigations.

3. DOH ADHICS & DHA/NABIDH

• ADHICS and NABIDH require:
• Strong authentication (MFA, biometric),
• Role-based and attribute-based access control,
• Detailed logging and monitoring,
• Data residency within UAE.
• Implementation:
• Biometric/PIN + MFA for mobile access.
• Facility/department/patient relationship checks for every access.
• Logs retained per ADHICS/NABIDH retention guidance.
• No cross-border data transfer from this module unless covered by approved infrastructure and DPAs.

4. Cybersecurity (TDRA/NESA)

• Portal and mobile app must:
• Use secure protocols (TLS 1.2+),
• Implement least-privilege access,
• Support incident detection (e.g., anomalous BTG usage).
• Implementation:
• RBAC and context-based rules enforce least privilege.
• BTG and admin actions integrated with SIEM for monitoring.

This roles & permissions specification should be used by:

• Backend teams to implement authorization middleware and audit logging.
• Frontend/mobile teams to conditionally render UI elements based on permissions.
• DevOps/security teams to configure monitoring and alerting for BTG and admin actions.
• Clinical governance to define facility-specific policies on top of this baseline.