Patient Portal & Mobile App User Roles & Permissions

This document defines role-based and context-based access control for the Patient Portal & Mobile App (patient-portal) module. It focuses on patient-facing and portal-administration roles, ensuring compliance with UAE regulations (Federal Law No. 2 of 2019, UAE PDPL, DOH/DHA rules, ADHICS/NESA).

Role Definitions

1. Patient

• Description
  Individual patient accessing their own health information and services via web or mobile app.

• Typical UAE Titles / Profiles

• Outpatient / inpatient at a UAE hospital or clinic

• Insured or self-pay patient (THIQA, Daman, Oman Insurance, etc.)

• Scope of Access

• Patients:
  • Own patient record only (patient_id linked to portal_accounts.account_id).
  • No access to other patients unless granted via proxy workflow.
• Data Types (read-only unless stated):
  • Demographics (name, DOB, gender, contact details, address).
  • Insurance and payer details (policy numbers, coverage).
  • Appointments (past and upcoming).
  • Lab results, radiology reports, clinical notes (subject to release rules).
  • Medications, allergies, problems, immunizations.
  • Billing statements, balances, payment history.
  • Telehealth session links and visit summaries.
  • Own consents and digital forms.
  • Own portal preferences and notification settings (read/write).

• Actions:

  • Book/reschedule/cancel appointments for self.
  • Send/receive secure messages with providers.
  • Submit prescription refill requests.
  • Make online payments.
  • Complete and sign digital forms and consents.
  • Manage own profile, language, and notification preferences.
  • Export own data (PDF/FHIR export).

• Reporting Hierarchy

• Not part of internal org chart.
• Operationally supported by: Registration/Patient Access team, Call Center, and Portal Administrator for account issues.

2. Parent/Guardian (Proxy)

• Description
  Adult acting on behalf of a dependent (typically child <18 or dependent adult) with proxy access granted via proxy_access_grants.

• Typical UAE Titles / Profiles

• Parent or legal guardian of minor patient.
• Sponsor of dependent (e.g., family visa holder).

• Court-appointed guardian for incapacitated adult.

• Scope of Access

• Patients:
  • Own record (as Patient role) plus dependent(s) where:
  • proxy_access_grants.proxy_account_id = their portal_accounts.account_id, and
  • proxy_access_grants.is_active = true and within granted_datetime–expiry_datetime.
• Data Types (for dependents, subject to access level):
  • Access levels (configured per facility policy and age):
  • view_only: view dependent’s records, no changes.
  • view_and_schedule: view + manage appointments.
  • full_care_management: view + schedule + messaging + refill requests + forms/consents (where legally allowed).
  • For minors approaching majority (e.g., 15–18), sensitive categories (sexual health, mental health, etc.) may be restricted per DOH/DHA policy.

• Actions:

  • Manage appointments for dependent (book/reschedule/cancel).
  • View dependent’s lab results, reports, and visit summaries (subject to rules).
  • Message providers on behalf of dependent (clearly tagged as proxy).
  • Submit refill requests for dependent.
  • Complete pre-registration forms and consents where legally permitted.
  • Manage proxy relationship (request, renew, revoke) for their dependents.

• Reporting Hierarchy

• Not staff; similar support path as Patient.
• Proxy relationships may require validation by Registration/Medical Records (e.g., Emirates ID, birth certificate, court order).

3. Portal Administrator

• Description
  Internal staff responsible for configuration, content, and operational management of the patient portal and mobile app.

• Typical UAE Job Titles

• Health Information Systems Administrator
• Patient Portal Administrator
• Digital Health Coordinator

• IT Applications Specialist (Patient Engagement)

• Scope of Access

• Patients:
  • All portal accounts across all facilities (multi-facility scope).
  • No default access to clinical content; can see limited demographics and account metadata for support.
• Data Types:
  • Portal account data (activation status, login history, MFA, UAE Pass linkage).
  • Portal preferences and notification settings.
  • Portal content (FAQs, help pages, notification templates).
  • Result release rules and configuration.
  • Aggregated analytics and KPIs (de-identified where possible).

• Actions:

  • Create/activate/deactivate portal accounts (e.g., after in-person verification).
  • Reset passwords and MFA (following identity verification SOP).
  • Manage portal content and form templates.
  • Configure notification templates and channels.
  • Configure result release delays and sensitive-result rules (with clinical governance approval).
  • View portal usage analytics and feedback.
  • Manage proxy access workflows (approve/reject high-risk cases).
  • Manage integration settings (UAE Pass, push notification providers) in coordination with IT security.

• Reporting Hierarchy

• Typically reports to:
  • Head of IT Applications / CIO, or
  • Health Information Management (HIM) Manager, or
  • Digital Transformation / Patient Experience Director.
• Subject to oversight by Data Protection Officer (DPO) or equivalent for PDPL compliance.

4. Provider (in Portal Context)

• Description
  Licensed clinician using the provider-facing portal/physician portal but interacting with patient portal features (messaging, telehealth, refill approvals).

• Typical UAE Job Titles

• Consultant / Specialist Physician
• General Practitioner
• Resident / Medical Officer

• Nurse Practitioner / Clinical Nurse Specialist (if allowed to respond to messages/telehealth per scope).

• Scope of Access

• Patients:
  • Patients assigned to them or their department/service, or associated with encounters where they are a treating provider.
  • For messaging: patients who have messaged them or their clinic, or are on their panel.
  • For telehealth: patients with scheduled telehealth appointments they are assigned to.
• Data Types:
  • Patient messages and attachments.
  • Telehealth session metadata and visit summaries.
  • Refill requests and related medication lists.
  • Limited portal metadata (e.g., whether patient has portal account, last login) for engagement.

• Actions:

  • Read and respond to patient messages.
  • View and manage appointment requests (accept/redirect/decline per workflow).
  • Approve/deny/modify refill requests.
  • Conduct telehealth visits and complete documentation in EHR.
  • Trigger patient-facing messages (e.g., follow-up instructions) via portal.

• Reporting Hierarchy

• Follows clinical hierarchy:
  • Provider → Department Head / Medical Director → Chief Medical Officer.
• Portal-related performance (e.g., message response time) may be monitored by Clinical Operations or Patient Experience.

Permission Matrix

Legend:

• ✅ = Allowed
• ❌ = Not allowed
• 🔒 = Conditional / context-based (e.g., age, facility policy, treating relationship, access level)

Roles in this module:

• PAT = Patient
• PRX = Parent/Guardian (Proxy)
• PADM = Portal Administrator
• PROV = Provider (portal context)

**Footnotes (conditions)**  
1. PADM can create accounts for patients who cannot self-register (e.g., elderly, no smartphone) after identity verification.  
2. PADM can assist with UAE Pass linking only via official UAE Pass flows; cannot see UAE Pass credentials.  
3. Requires strong identity verification (e.g., Emirates ID, security questions, call-back) per facility policy and PDPL.  
4. PAT/PRX can request deactivation; PADM executes deactivation after confirming identity and explaining implications.  
5. PADM sees limited demographics strictly for support (no clinical data).  
6. PROV sees demographics for patients under their care only.  
7. Clinical governance approval required; PADM implements configuration.  
8. PADM can create proxy relationships based on validated legal documents.  
9. Changes to access level may require clinical/legal approval (e.g., for adolescents).  
10. PROV can search slots for their own schedule or department for triage purposes.  
11. Only for dependents where proxy relationship is active and access level permits scheduling.  
12. Some facilities may centralize approval in scheduling; then PROV only views requests.  
13. PROV sees clinical data via EHR; portal context only exposes what is already in EHR for their patients.  
14. Subject to age and sensitivity rules; some results may be hidden from proxies (e.g., reproductive health).  
15. PROV sees only messages for patients they are assigned to or that are routed to their team.  
16. Only for dependents with active proxy grant and appropriate access level.  
17. Only within same department/service; reassignment is audited.  
18. Subject to financial consent and local policy (e.g., sponsor paying for dependent).  
19. PROV sees logs for their own sessions; PADM sees aggregated logs.  
20. Only where law allows guardian consent; certain consents may require in-person or additional verification.  
21. PROV may see forms that are clinically relevant (e.g., medical history, consent) in the EHR, not as raw portal artifacts.  
22. PADM sees technical audit logs; access to clinical content logs may be restricted to DPO/compliance.  
23. PROV may see per-patient access history within the chart (who viewed what, when) but not full system logs.  
24. BTG via portal is rare; typically used by on-call providers when patient has sealed/restricted records.  
25. BTG policies must be approved by Compliance/DPO and align with Federal Law No. 2/2019 and PDPL.

---

## Role Hierarchy

This diagram shows logical privilege relationships for the patient-portal context (not the full hospital org chart).

```mermaid
graph TD
    A[Board / Executive Leadership] --> B[Chief Information Officer / Digital Health Director]
    B --> C[Portal Administrator]
    B --> D[Chief Medical Officer]
    D --> E[Department Heads / Clinical Leads]
    E --> F[Provider (Portal Context)]

    subgraph Patient & Proxy (External Users)
        G[Patient]
        H[Parent/Guardian (Proxy)]
    end

    C -. support & onboarding .-> G
    C -. support & proxy validation .-> H
    F -. clinical communication & telehealth .-> G
    F -. clinical communication & telehealth .-> H

Inheritance Notes

• Portal Administrator does not inherit clinical privileges; their scope is configuration and support.
• Provider inherits clinical privileges from core EHR roles (see ../physician-portal/02-roles-permissions.md) but only a subset is exposed in the patient-portal context.
• Patient and Parent/Guardian have no administrative privileges beyond their own accounts and authorized dependents.

Context-Based Access Rules

Context-based controls are critical to comply with Federal Law No. 2 of 2019, UAE PDPL, DOH ADHICS, and DHA NABIDH requirements.

1. Facility-Based Restrictions (Multi-Facility)

• Facility scoping
• Portal accounts are global to the organization, but data access is limited to facilities where the patient has encounters or registrations.

• For multi-emirate groups, facility-level flags determine which records are visible in the portal (e.g., some facilities may opt out of portal exposure initially).

• Provider access

• Providers see portal-related data only for patients treated at their facility or network, as defined in encounters and appointments.
• Cross-facility access requires explicit organizational policy and is fully audited.

2. Department-Based Restrictions

• Messaging routing
• Messages are routed to departments (e.g., Cardiology, Pediatrics) based on patient selection; only providers in that department can view/respond.

• Department-based queues ensure that a provider in one specialty cannot see messages intended for another specialty unless explicitly reassigned.

• Telehealth

• Telehealth sessions are associated with a department/service; only providers assigned to that department and session can join.

3. Patient Relationship Requirements

• Patient role
• Access limited to patient_id linked to their portal_accounts.account_id.

• Any attempt to access another patient’s data is blocked and logged as a security event.

• Proxy role

• Access requires active proxy_access_grants record with valid relationship, access_level, and non-expired dates.
• Age-based rules:
  • For minors under a configurable age threshold (e.g., 15), full proxy access may be allowed.
  • For adolescents, sensitive categories (sexual/reproductive health, mental health, substance use) may be hidden from proxies depending on DOH/DHA guidance and facility policy.

• When a patient reaches majority age (e.g., 18), system automatically:

  • Expires existing proxy grants (or downgrades to limited view) and
  • Notifies both patient and proxy to re-establish access under adult consent.

• Provider relationship

• Provider access via portal features is limited to:
  • Patients with active or recent encounters where provider is part of the care team, or
  • Patients assigned to provider’s panel or clinic, or
  • Patients who initiated messaging to that provider/department.
• Relationship is validated against EHR and scheduling data.

4. Time-Based Access (Shift-Based / Temporal)

• Provider access windows
• Access to portal messaging and telehealth queues is aligned with provider schedules (e.g., on-call, clinic hours).

• Off-shift providers may have read-only access for continuity but cannot initiate new telehealth sessions or accept new portal messages unless on-call.

• Result release timing

• Lab and radiology results are released to patients after configurable delays (e.g., 24–72 hours) to allow provider review, per facility policy and DOH/DHA guidance.

• Certain critical results may be held until provider confirms communication with patient.

• Session timeouts

• Portal sessions auto-timeout after inactivity (e.g., 15 minutes for mobile, 10 minutes for web) per ADHICS/NESA requirements.
• Telehealth sessions have maximum duration and auto-disconnect rules.

5. Emergency / On-Call Overrides

• Emergency access
• In genuine emergencies (e.g., unconscious patient in ED), providers may need to access portal-linked information (e.g., patient-uploaded documents, consents) even if normal relationship checks fail.

• Such access is handled via BTG (see next section) and is strictly audited.

• On-call providers

• On-call providers may be granted temporary access to portal messaging and telehealth for patients assigned to their service during the on-call period.
• Access is automatically revoked at end of on-call window.

Break-the-Glass (BTG) Procedures

BTG is a controlled override mechanism for exceptional situations where normal access rules would prevent necessary access to patient data. It must align with Federal Law No. 2 of 2019 (health data confidentiality) and UAE PDPL (data protection and accountability).

1. When BTG is Required

• Provider attempts to access:
• A patient’s portal-linked record where no treating relationship exists but there is an emergency (e.g., patient presents to ED with no prior assignment).
• Restricted or “sealed” data categories (e.g., mental health notes, sensitive consents) that are normally hidden even from treating providers.
• BTG is not available to Patients or Proxies.
• BTG is rarely needed in the patient-portal UI itself; it is primarily an EHR function, but the portal module must respect BTG flags and log any BTG-driven access to portal-originated data (e.g., patient-uploaded documents).

2. BTG Workflow

1. Trigger
   - Provider attempts to open restricted patient data via portal-related interface (e.g., viewing patient-uploaded document flagged as restricted).

2. Warning & Justification
   - System displays a clear warning:

   • “You are requesting emergency access to restricted patient data. This action will be fully audited and reviewed. Proceed only if necessary for immediate patient care.”
   • Provider must select a reason from a controlled list (e.g., “Emergency treatment”, “Patient unconscious”, “Life-threatening condition”) and optionally add free-text justification.

3. Access Grant
   - Upon confirmation, system:

   • Grants temporary access to the specific restricted data set (least privilege).
   • Sets a BTG session window (e.g., 15–30 minutes) after which access reverts to normal.

4. Audit Trail
   - Every BTG event is logged with:

   • user_id / provider identity
   • patient_id
   • Timestamp (start and end)
   • Reason code and free-text justification
   • Data categories accessed (e.g., “restricted mental health notes”, “sealed consent”)
   • Source system (EHR vs portal) and client IP/device.

5. Notification & Review
   - Automated notification to:

   • Compliance / HIM / DPO (per facility policy).
   • Daily or weekly BTG report generated for review.

3. Post-Access Review Process

• Initial review (within 24–72 hours):

• Compliance/HIM reviews BTG events to confirm:

  • Emergency context was plausible.
  • Access was limited to necessary data.
  • No pattern of misuse.

• Escalation

• Suspicious or unjustified BTG uses escalated to:

  • Medical Director / CMO,
  • HR, and potentially
  • UAE Data Office if it constitutes a personal data breach under PDPL.

• Documentation

• Valid BTG uses may be documented in the patient’s record (e.g., “Emergency access used to retrieve prior consent and allergy information”).

4. UAE PDPL Implications

• BTG processing must still comply with PDPL principles:
• Lawfulness: Emergency treatment and vital interests are recognized bases for processing without consent.
• Data minimization: Only the minimum necessary data is exposed during BTG.
• Accountability: Detailed logs and reviews demonstrate compliance.
• If BTG misuse leads to unauthorized disclosure, it may constitute a reportable personal data breach; breach notification obligations apply (to UAE Data Office and possibly affected patients).

Segregation of Duties

Segregation of duties reduces risk of fraud, misuse, and privacy violations.

1. Conflicting Role Combinations

The following combinations must not be assigned to the same individual in the IAM/roles system:

2. Dual Sign-Off Requirements

• Proxy Access for High-Risk Cases
• For complex guardianship (e.g., court-appointed, adult with diminished capacity), creation of proxy_access_grants requires:
  • Verification by Registration/HIM, and
  • Approval by a Supervisor or Legal/Compliance.

• System should support a dual-approval workflow (two distinct users).

• Result Release Rule Changes

• Changes to sensitive result release rules (e.g., psychiatric results, genetic tests) require:
  • Proposal by Portal Administrator or IT, and
  • Approval by Medical Director or designated clinical governance committee.

• System logs both proposer and approver.

• BTG Policy Changes

• Any change to BTG configuration (who can BTG, time window, data categories) requires:

  • Approval by DPO/Compliance and CIO/CMO (two independent roles).

• Payment Gateway Configuration

• Changes to payment gateway keys or endpoints require dual control (e.g., IT + Finance) and must not be performed solely by Portal Administrator.

UAE Regulatory Compliance

This module must be implemented in alignment with UAE-specific regulations:

• Federal Law No. 2 of 2019 (Use of ICT in Health Fields)
• Ensures confidentiality and integrity of health data; portal access is an extension of EHR access and must enforce treating relationship and minimum necessary principles.

• Portal must support secure authentication (including MFA and UAE Pass) and strong audit logging.

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

• Portal registration and patient-initiated data sharing require explicit, informed consent.
• Patients must be able to:
  • Access their data (via portal views and export).
  • Request corrections to demographics.
  • Withdraw consent for non-essential processing (e.g., marketing notifications).

• Audit logs and BTG records support accountability and breach investigation.

• DOH (Abu Dhabi) / DHA (Dubai) Requirements

• ADHICS and NABIDH/Malaffi policies require:
  • Strong authentication and session management.
  • Role-based and context-based access control.
  • Comprehensive audit trails for all patient data access.

• Result release rules must respect emirate-level guidance on sensitive results and patient communication.

• TDRA/NESA Cybersecurity

• Portal and mobile app must use secure protocols (TLS 1.2+), MFA, and secure coding practices.
• Access control and logging must integrate with enterprise security monitoring (SIEM).

By implementing the roles, permissions, context rules, BTG procedures, and segregation of duties described above, the Patient Portal & Mobile App module will support secure, patient-centric access while meeting UAE regulatory expectations for health data protection and governance.