Patient Access User Roles & Permissions

This document defines roles, permissions, and access-control rules for the Patient Access (patient-access) module, covering eligibility verification, prior authorization, referrals, cost estimation, financial counseling, and pre-registration. It is tailored for UAE hospitals and must be implemented in alignment with UAE PDPL, Federal Law No. 2/2019 (ICT in health fields), DOH/DHA regulations, and ADHICS/NESA security principles.

Role Definitions

Registration Clerk

• Description: Front-desk / call-centre staff responsible for patient registration, insurance capture, eligibility verification, and basic financial clearance.
• Typical UAE Job Titles:
• Registration Clerk
• Patient Registration Officer
• Front Desk Executive
• Call Centre Registration Agent
• Scope of Access:
• Patients:
  • All patients scheduled or presenting to their assigned facility/department.
  • Search across enterprise for duplicates, but detailed financial data limited to encounters at their facility.
• Data:
  • View: demographics, insurance details, eligibility checks, basic referral status, cost estimates summary, pre-registration status.
  • Edit: demographics (where allowed by policy), insurance details, initiate eligibility checks, create pre-registration records.
  • No access to detailed clinical data beyond what is needed to select service types (e.g., procedure name, not full notes).
• Reporting Hierarchy:
• Reports to: Patient Access Supervisor
• Indirectly to: Patient Access Manager
• Collaborates with: Financial Counselors, Authorization Specialists, Scheduling staff.

Authorization Specialist

• Description: Staff responsible for obtaining and tracking prior authorizations and payer-required referrals.
• Typical UAE Job Titles:
• Authorization Officer
• Prior Authorization Coordinator
• Insurance Coordinator (Authorizations)
• Scope of Access:
• Patients:
  • All patients for whom services requiring authorization are scheduled or ordered, across assigned facilities.
• Data:
  • View: demographics, insurance, eligibility results, orders/services requiring auth, referral records, cost estimates (read-only), basic clinical justification fields supplied from CPOE/EHR.
  • Edit: prior_authorizations, prior_auth_requests, referrals, payer communication notes.
  • No access to full clinical notes beyond fields explicitly shared for auth (diagnosis codes, procedure codes, brief justification).
• Reporting Hierarchy:
• Reports to: Patient Access Supervisor or Authorization Team Lead
• Indirectly to: Patient Access Manager
• Clinical escalation to: Ordering Physician / Department Head.

Financial Counselor

• Description: Specialist who explains financial obligations, sets up payment plans, and manages charity/financial assistance processes.
• Typical UAE Job Titles:
• Financial Counselor
• Patient Financial Services Officer
• Revenue Cycle Counselor
• Scope of Access:
• Patients:
  • Patients flagged as self-pay, high out-of-pocket (OOP), uninsured/underinsured, or referred for financial counseling.
• Data:
  • View: demographics, insurance, eligibility, cost estimates (full breakdown), patient account balances (via billing), financial_counseling_records, payment plans, charity applications.
  • Edit: financial_counseling_records, payment plan setup fields, charity application metadata (not clinical data), notes on financial situation.
  • No access to detailed clinical notes beyond what is necessary to understand service type and timing.
• Reporting Hierarchy:
• Reports to: Patient Access Supervisor or Financial Counseling Supervisor
• Indirectly to: Patient Access Manager and Finance Director.

Patient Access Manager

• Description: Department head responsible for overall patient access operations, staffing, KPIs, and configuration.
• Typical UAE Job Titles:
• Patient Access Manager
• Revenue Cycle – Front Office Manager
• Registration & Admissions Manager
• Scope of Access:
• Patients:
  • All patients across the organization (for administrative/operational purposes).
• Data:
  • Full read access to all patient-access data: eligibility, authorizations, referrals, cost estimates, financial counseling records, pre-registration records, and analytics.
  • Configuration: payer connectivity, work queues, master data (pre-registration question sets, payment plan templates, etc.).
  • Limited clinical data only as surfaced in patient-access screens (no full chart access by default).
• Reporting Hierarchy:
• Reports to: Revenue Cycle Director / Finance Director
• Supervises: Patient Access Supervisors, Registration Clerks, Authorization Specialists, Financial Counselors.

Patient Access Supervisor

• Description: Operational lead overseeing daily work queues, staff performance, and exception handling.
• Typical UAE Job Titles:
• Patient Access Supervisor
• Registration Supervisor
• Authorization & Eligibility Supervisor
• Scope of Access:
• Patients:
  • All patients within assigned facilities/departments.
• Data:
  • Same as Registration Clerk + Authorization Specialist + Financial Counselor within their scope, with additional override capabilities:
  • Override certain eligibility holds (per policy).
  • Approve financial exceptions within limits.
  • Manage work queues and reassign tasks.
  • Read-only access to analytics dashboards for their area.
• Reporting Hierarchy:
• Reports to: Patient Access Manager
• Supervises: Registration Clerks, Authorization Specialists, Financial Counselors (where applicable).

Physician (External Role)

• Description: Licensed physician whose primary role is clinical, but who interacts with patient access for referrals and clinical documentation for authorizations.
• Typical UAE Job Titles:
• Consultant Physician
• Specialist / General Practitioner
• Scope of Access:
• Patients:
  • Patients under their care (encounters where they are attending/referring provider).
• Data:
  • View: referral status, authorization status for their orders, cost estimate summary for their patients, pre-registration status.
  • Edit: initiate referrals, upload/approve clinical documentation for auth, respond to peer-review requests, add clinical justification text.
  • No access to financial counseling notes or detailed payment plans (unless also assigned a financial role, which is generally prohibited by segregation-of-duties rules).
• Reporting Hierarchy:
• Reports to: Clinical Department Head / Medical Director (outside this module).
• Collaborates with: Authorization Specialists, Registration Clerks.

Permission Matrix

Legend:

• ✅ = Allowed
• ❌ = Not allowed
• 🔒 = Conditional / limited (requires context, approval, or configuration)

Roles in this module:

• RC = Registration Clerk
• AS = Authorization Specialist
• FC = Financial Counselor
• PAM = Patient Access Manager
• PAS = Patient Access Supervisor
• PHYS = Physician (external role)

**Notes on 🔒 (conditional) permissions** (to be enforced via configuration and policy):

1. **Edit demographics** by RC: allowed only for non-identity-critical fields (e.g., phone, address); Emirates ID changes may require supervisor approval.
2. **Edit insurance details** by AS: typically limited to adding auth-related payer references; primary policy changes should be done by RC or PAS.
3. **Eligibility override**: PAS/PAM may override holds only with documented reason and within defined thresholds (e.g., emergency, VIP, internal policy).
4. **Clinical justification editing by AS/PAS/PAM**: may be restricted so that only physicians can change clinical content; non-clinical staff can only add administrative comments.
5. **View financial counseling records** by RC: allowed only to see high-level flags (e.g., “payment plan active”) without detailed notes.
6. **Break-the-glass**: see BTG section; requires justification and post-hoc review.

---

## Role Hierarchy

Role inheritance is **additive**: higher roles inherit all permissions of subordinate roles within their scope, except where explicitly restricted by segregation-of-duties rules.

```mermaid
graph TD
    CEO[Hospital CEO / COO] --> RCD[Revenue Cycle Director / Finance Director]
    RCD --> PAM[Patient Access Manager]
    PAM --> PAS[Patient Access Supervisor]
    PAS --> RC[Registration Clerk]
    PAS --> AS[Authorization Specialist]
    PAS --> FC[Financial Counselor]

    MD[Medical Director] --> PHYS[Physician (Ordering / Referring)]

    %% Inheritance notes
    PAM -.inherits.-> PAS
    PAS -.inherits.-> RC
    PAS -.inherits.-> AS
    PAS -.inherits.-> FC

• Patient Access Manager (PAM):
• Inherits all PAS, RC, AS, FC permissions (subject to segregation-of-duties constraints).
• Adds configuration, analytics, and high-level approval capabilities.
• Patient Access Supervisor (PAS):
• Inherits RC, AS, FC permissions for their facilities/departments.
• Adds override and queue-management capabilities.
• Physician:
• Separate clinical hierarchy; only a limited subset of patient-access permissions (referral initiation, auth documentation) and does not inherit any financial override capabilities.

Context-Based Access Rules

Context-based controls must be enforced in addition to role-based permissions, in line with UAE PDPL, Federal Law No. 2/2019, DOH ADHICS, and DHA NABIDH principles of minimum necessary access.

1. Facility-Based Restrictions (Multi-Facility)

• Each user is assigned one or more facilities and optionally service locations.
• Registration Clerk / Authorization Specialist / Financial Counselor:
• Can access patient-access records (eligibility, auth, referrals, estimates, counseling, pre-registration) only for encounters at their assigned facilities.
• Cross-facility search may show that a patient exists (for duplicate prevention) but not expose detailed financial or auth data from other facilities.
• Patient Access Supervisor:
• Access limited to facilities they supervise.
• Patient Access Manager:
• May have enterprise-wide access if their role is corporate; otherwise, restricted similarly to PAS.

Implementation:

• All owned tables (eligibility_checks, prior_authorizations, referrals, cost_estimates, financial_counseling_records, pre_registration_records) must include facility_id (FK to facilities.facility_id) and access filters must enforce user.facility_scope.

2. Department-Based Restrictions

• Within a facility, access can be restricted by department (e.g., Outpatient Clinics, Emergency, Inpatient Admissions, Day Surgery).
• Example:
• A Registration Clerk assigned to Emergency Department can view and edit patient-access records only for ED encounters.
• A Financial Counselor assigned to Oncology may see cost estimates and counseling records only for oncology-related encounters.
• Department scope is derived from:
• encounters.department_id
• appointments.department_id
• User’s department_scope mapping.

3. Patient Relationship Requirements

• Access to patient-access data must be tied to a legitimate relationship:
• Active or scheduled encounter at the user’s facility/department.
• Explicit referral or authorization task assigned to the user or their queue.
• Financial counseling referral from billing or clinical team.
• Examples:
• A Financial Counselor can open a patient’s record only if:
  • The patient has a current or recent encounter flagged as needing counseling, or
  • The patient is on a counseling worklist assigned to that counselor.
• A Physician can view auth/referral status only for patients where they are:
  • Attending provider, or
  • Referring provider, or
  • Specialist receiving the referral.

4. Time-Based Access (Shift-Based)

• Users have defined shift schedules; access may be restricted outside active shifts except for on-call roles.
• Rules:
• RC/AS/FC:
  • Full edit rights only during scheduled shift times.
  • Outside shift, system may allow read-only access for in-progress tasks (configurable) or block access entirely.
• PAS/PAM:
  • May have extended access for supervisory duties but still subject to audit.
• Night-shift considerations:
• High-risk actions (e.g., overriding eligibility holds, approving charity care) performed between 22:00–06:00 should be flagged for next-day review.

5. Emergency / On-Call Overrides

• In emergencies (e.g., patient in critical condition, system downtime at payer), certain restrictions may be temporarily relaxed:
• PAS/PAM may override eligibility holds to allow service, with mandatory reason and documentation.
• On-call Authorization Specialist may access records outside normal facility scope if covering multiple sites.
• All such overrides must:
• Be time-limited (e.g., session-based).
• Require explicit confirmation and justification.
• Be fully audited and included in exception reports.

Break-the-Glass (BTG) Procedures

BTG in patient access is primarily relevant for restricted financial notes and sensitive administrative flags (e.g., legal cases, VIP status, domestic violence indicators) that are not normally visible to all staff.

1. When BTG Is Required

BTG is required when:

1. A user attempts to access: - Financial counseling notes marked as restricted (e.g., legal disputes, sensitive social circumstances). - Special financial arrangements for VIP or protected patients.
2. The user’s role would normally not have access, but: - There is an urgent need to proceed with care (e.g., patient in ED requiring immediate financial clearance for life-saving procedure). - The designated counselor/manager is unavailable and delay would harm the patient’s interests or hospital’s legal obligations.

BTG is not a substitute for normal role assignment and must not be used for routine curiosity or convenience.

2. BTG Workflow

1. Access Attempt: - User tries to open a restricted financial record or sensitive flag.
2. Warning Dialog: - System displays a clear warning:
   • “You are requesting emergency access to restricted financial information. This action will be fully audited and reviewed. Proceed only if necessary to protect the patient’s vital interests or comply with legal obligations.”
3. Justification Entry: - User must select a reason from a controlled list (e.g., “Emergency treatment – ED”, “System outage – designated counselor unavailable”) and enter free-text justification.
4. Optional Approval Step (configurable): - For certain categories (e.g., VIP records), system may require:
   • Supervisor (PAS) or Manager (PAM) approval before granting access, or
   • Automatic notification to PAS/PAM with real-time alert.
5. Temporary Access Grant: - System grants access only to the specific record(s) requested. - Access is time-limited (e.g., 15–30 minutes) and session-bound.
6. Audit Logging: - System records:
   • User ID, role, facility, department
   • Patient ID
   • Resource accessed (table, record ID)
   • Timestamp (start/end)
   • BTG reason code and free-text justification
   • Workstation/IP and channel (web, mobile, VPN)
7. Post-Access Review: - Compliance or Patient Access Manager receives a BTG report. - Review must occur within a defined SLA (e.g., 24–48 hours). - Reviewer classifies BTG as:
   • Justified (no further action)
   • Questionable (user counseling/training)
   • Unjustified (potential disciplinary action, access restriction)

3. Audit Trail Requirements

In line with UAE PDPL and Federal Law No. 2/2019:

• All BTG events must be:
• Immutable (append-only logs).
• Retained for at least the same duration as the underlying patient record retention period.
• Audit log fields (minimum):
• btg_event_id, user_id, role_id, patient_id, record_type, record_id, timestamp_start, timestamp_end, facility_id, department_id, reason_code, reason_text, review_status, reviewed_by, reviewed_at.
• BTG reports must be available to:
• Data Protection Officer (if appointed).
• Compliance / Internal Audit.
• DOH/DHA inspectors upon request.

4. UAE PDPL Implications

• BTG must be justified under lawful bases:
• Vital interests of the data subject (e.g., emergency care).
• Legal obligation (e.g., ensuring coverage for mandated services).
• BTG usage must respect:
• Data minimization: only the minimum necessary financial information is exposed.
• Purpose limitation: BTG access cannot be used for unrelated purposes (e.g., curiosity about a VIP).
• Repeated unjustified BTG events may indicate systemic issues and must trigger:
• Additional training.
• Possible role redesign or technical tightening of access controls.
• Reporting to the UAE Data Office if they result in a personal data breach.

Segregation of Duties

To reduce fraud risk and ensure compliance with UAE financial governance and PDPL principles, certain role combinations and actions must be segregated.

1. Conflicting Role Combinations

The IAM system must prevent or flag assignment of the following conflicting roles to the same user account:

The system should support role conflict rules that block assignment or require explicit override by a higher authority (e.g., CIO/Compliance).

2. Dual Sign-Off Requirements

For high-risk actions, dual approval is required:

Implementation notes:

• Dual sign-off should be implemented as workflow states (e.g., pending_approval, approved_by_role_X, approved_by_role_Y) with clear audit trails.
• The system must prevent the same user from fulfilling both approval steps.

UAE Regulatory Compliance

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

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

• Requires confidentiality and integrity of health data and mandates that health data be stored and processed within the UAE.
• Patient Access module must:
• Ensure all eligibility, authorization, and financial counseling data is stored on UAE-based infrastructure.
• Support secure integrations with eClaimLink (DHA) and DOH eClaims/Shafafiya using encrypted channels and authentication.

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

• Data Minimization & Purpose Limitation:
• Roles are designed so that:
  • Registration Clerks see only administrative and financial data needed for registration.
  • Authorization Specialists see only clinical snippets needed for auth (codes, brief justification), not full clinical notes.
  • Financial Counselors see financial and limited service information, not full clinical history.
• Access Control & Audit:
• RBAC + context-based access + BTG auditing satisfy PDPL requirements for security and accountability.
• All access to sensitive financial and insurance data must be logged and reviewable.
• Data Subject Rights:
• Patient Access must support:
  • Correction of administrative data (e.g., demographics, insurance).
  • Export of billing-related information upon patient request (coordinated with Billing & Claims module).

3. DOH (Abu Dhabi) & DHA (Dubai) Requirements

• ADHICS (DOH) and NABIDH Security:
• Require strong access controls, least privilege, and detailed audit trails.
• Remote access to Patient Access functions must use MFA and secure VPN where applicable.
• Insurance & Claims (eClaimLink / DOH eClaims):
• Only authorized roles (Authorization Specialists, PAS, PAM) may submit or modify prior authorization requests.
• System must ensure that payer identifiers and auth numbers are handled securely and not exposed to unauthorized staff.

4. Financial Governance & Anti-Fraud

• Segregation of duties and dual sign-off requirements support:
• Internal control frameworks used by UAE hospitals and private groups.
• External audits (e.g., by DOH/DHA, insurers, or corporate auditors).

This roles & permissions specification must be implemented together with the global IAM model defined in ../ehr-patient-mgmt/02-roles-permissions.md and the billing/claims roles defined in ../billing-claims/02-roles-permissions.md. All deviations or local policy customizations should be documented and approved by the facility’s Data Protection Officer (if appointed) and Revenue Cycle leadership.