Denial Analysis User Roles & Permissions

This document defines roles, permissions, and access-control rules for the Denial Analysis (denial-analysis) module of the Gates Group HIS, aligned with UAE regulations (MOH, DOH, DHA, UAE PDPL, ADHICS/NESA). It is intended for developers implementing RBAC and auditors validating access controls.

Role Definitions

Shared entities (users, roles, permissions) are owned by ehr-patient-mgmt. This module defines role profiles and module-specific permissions that will be attached to global roles.

Denial Analyst

• Description: Operational staff responsible for day-to-day denial worklists, categorization, root cause documentation, and appeal preparation/submission.
• Typical UAE Job Titles:
• Denial Analyst
• Claims Denial Officer
• RCM Denial Executive
• Scope of Access:
• Patients: All patients whose claims are processed by the facility and have associated denial records; filtered by facility and payer assignment where configured.
• Data Types:
  • Full access (view/edit) to denial_records, denial_root_causes, appeals, appeal_outcomes for assigned items.
  • Read-only access to linked claim headers/lines, payer details, and limited patient demographics (name, DOB, MRN, insurance, encounter info). No access to detailed clinical notes beyond what is embedded in claim/authorization attachments.
• Facilities:
  • Default: Limited to one facility or facility group as per HR assignment (multi-facility configuration).
• Reporting Hierarchy:
• Reports to: Senior Denial Analyst or Denial Manager.
• May receive work assignments from: Denial Manager, Revenue Cycle Manager.

Senior Denial Analyst

• Description: Experienced analyst handling complex denials, mentoring staff, managing payer escalations, and coordinating clinical appeals.
• Typical UAE Job Titles:
• Senior Denial Analyst
• Denial Team Lead
• Senior RCM Analyst (Denials)
• Scope of Access:
• Inherits all Denial Analyst access.
• Can view and reassign denial workloads across analysts within their facility/department.
• Elevated access to complex appeals (multi-level, high-value) and payer escalation notes.
• Can view more detailed claim and contract context (from billing-claims and policy-contract-mgmt) where integrated.
• Reporting Hierarchy:
• Reports to: Denial Manager.
• Supervises: Denial Analysts (functional supervision).

Denial Manager

• Description: Manager responsible for denial strategy, configuration of rules, analytics, prevention plans, and write-off approvals within defined thresholds.
• Typical UAE Job Titles:
• Denial Manager
• Manager – Denials & Appeals
• RCM Denial & Recovery Manager
• Scope of Access:
• Inherits all Senior Denial Analyst access.
• Full module-wide view of all denial_records, appeals, denial_trends, denial_prevention_actions, payer_denial_scorecards for assigned facilities.
• Can configure denial categories, root cause taxonomies, appeal deadline rules, write-off thresholds (within finance policy limits).
• Can approve write-offs up to configured financial limits (above which dual sign-off with Finance/Revenue Cycle Manager is required).
• Reporting Hierarchy:
• Reports to: Revenue Cycle Manager or Director of Revenue Cycle.
• Manages: Senior Denial Analysts, Denial Analysts.

Coding Specialist (Denial Support)

• Description: Clinical coding professional supporting denial resolution by reviewing coding-related denials and recommending corrected codes.
• Typical UAE Job Titles:
• Clinical Coder
• Coding Specialist
• DRG / Inpatient Coder
• Scope of Access:
• Read-only access to denial_records flagged as coding-related and their associated claim lines.
• Can add coding review notes, recommended corrected codes, and coding rationale to denial/appeal records.
• No ability to change denial status, assign analysts, or approve write-offs.
• Access limited to facilities/departments they code for (e.g., inpatient, outpatient, specialty clinics).
• Reporting Hierarchy:
• Reports to: Coding Manager / Health Information Management (HIM) Manager.
• Matrix collaboration with: Denial Manager.

Revenue Cycle Manager

• Description: Senior leader overseeing end-to-end revenue cycle performance, including denial trends, payer performance, and strategic planning.
• Typical UAE Job Titles:
• Revenue Cycle Manager
• Director – Revenue Cycle
• Head of Billing & Collections
• Scope of Access:
• Read-only access to all denial analytics, trends, scorecards, and prevention action summaries across all facilities under their remit.
• No direct edit rights on individual denial records or appeals (to maintain segregation of duties), except for strategic notes and approval of prevention plans.
• Can approve high-impact prevention plans and high-value write-offs (dual sign-off with Finance where configured).
• Reporting Hierarchy:
• Reports to: Chief Financial Officer (CFO) or Chief Operating Officer (COO).
• Oversees: Denial Manager, Billing & Claims Manager, Patient Access Manager (organizationally, not via system roles).

Physician Advisor

• Description: Licensed physician providing clinical support for medical necessity denials, peer-to-peer reviews, and documentation improvement guidance.
• Typical UAE Job Titles:
• Physician Advisor – Utilization Management
• Medical Director – Clinical Documentation Improvement
• Consultant Physician (Denial Support)
• Scope of Access:
• Read-only access to denial records and appeals where medical necessity or clinical documentation is the primary category.
• Can upload or author medical necessity letters, peer review notes, and clinical documentation guidance attached to appeals.
• Access to relevant clinical context via EHR integration (problem list, key labs, imaging summaries) limited to patients whose denials they are supporting.
• Reporting Hierarchy:
• Reports to: Medical Director / Chief Medical Officer with dotted line to Revenue Cycle Manager.
• Collaborates with: Denial Manager, Coding Manager.

Permission Matrix

Legend:

• ✅ = Allowed
• ❌ = Not allowed
• 🔒 = Conditional (depends on configuration, facility, or context)

Roles in this module:

• DA = Denial Analyst
• SDA = Senior Denial Analyst
• DM = Denial Manager
• CS = Coding Specialist (denial support)
• RCM = Revenue Cycle Manager
• PA = Physician Advisor

**Notes (for implementation):**

1. 🔒 **Conditional** permissions are controlled by:
   - Facility configuration (e.g., whether Denial Analysts can see all denials vs. only assigned).
   - Financial thresholds (e.g., DM can approve write-offs up to AED X).
   - Emirate-specific policies (e.g., who can submit appeals via eClaimLink vs. DOH eClaims).
2. Access to **clinical context** must respect EHR module rules and UAE PDPL / Federal Law No. 2 of 2019; by default, denial staff see only what is necessary for billing/appeal purposes.

---

## Role Hierarchy

This diagram shows logical permission inheritance within the **denial-analysis** module. It does not override enterprise-wide admin roles defined in `ehr-patient-mgmt`.

```mermaid
graph TD
    RCM[Revenue Cycle Manager] --> DM[Denial Manager]
    DM --> SDA[Senior Denial Analyst]
    SDA --> DA[Denial Analyst]

    HIM[HIM / Coding Manager] --> CS[Coding Specialist (Denial Support)]
    CMO[Chief Medical Officer] --> PA[Physician Advisor]

    %% Permission inheritance (module-level)
    DM -.inherits.-> SDA
    SDA -.inherits.-> DA

    %% CS and PA are support roles with limited, non-hierarchical access

• Inheritance semantics:
• Denial Manager includes all Senior Denial Analyst and Denial Analyst permissions plus configuration and approval rights.
• Senior Denial Analyst includes all Denial Analyst permissions plus team coordination and some analytics.
• Coding Specialist and Physician Advisor are side roles: they do not inherit denial operational permissions; they have focused, limited 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 of 2019, ADHICS, and facility policies.

1. Facility-Based Restrictions (Multi-Facility)

• Each user is associated with one or more facilities in the master users profile.
• Denial module queries must filter by facility_id on:
• denial_records
• appeals
• denial_trends
• payer_denial_scorecards
• Rules: 1. Denial Analysts and Senior Denial Analysts can only access denials for facilities they are assigned to. 2. Denial Managers may have multi-facility access if their management scope spans multiple hospitals/clinics. 3. Revenue Cycle Managers may have cross-facility analytics access but no edit rights on individual records. 4. Cross-emirate deployments (e.g., Abu Dhabi + Dubai) must allow configuration so that:
  • Abu Dhabi-specific data is available for DOH/Malaffi reporting.
  • Dubai-specific data is available for DHA/NABIDH and eClaimLink reporting.
  • Cross-facility analytics are aggregated without exposing identifiable patient data where not necessary.

2. Department-Based Restrictions

• Denials are tagged with a responsible department (e.g., Patient Access, Coding, Billing, Clinical Department).
• Rules: 1. Coding Specialists see only denials where denial_category or root_cause is coding-related and responsible_department matches their coding scope. 2. Physician Advisors see only denials where denial_category is medical necessity/clinical documentation and the clinical department matches their advisory assignment. 3. Department heads (outside this module) may receive aggregated reports but not necessarily record-level access unless they have a denial role.

3. Patient Relationship Requirements

• Denial staff are not direct care providers; their access is justified under:
• Treatment and health system management basis (Federal Law No. 2 of 2019 and PDPL healthcare exemption).
• Rules: 1. Denial Analysts may access patient identifiers and claim-related clinical snippets only for patients with active or historical claims processed by the facility. 2. Physician Advisors may access broader clinical context only for patients whose denials they are actively supporting (linked via appeal_id or denial_id). 3. Access to sensitive clinical details unrelated to the denial (e.g., mental health notes when denial is for eligibility) must be blocked or masked.

4. Time-Based Access (Shift-Based)

• User profiles include optional shift schedules or working hours.
• Rules: 1. Optional configuration: restrict denial worklist access to active shift times; outside shift, users can log in but cannot open detailed denial records. 2. High-risk actions (write-off approvals, configuration changes) may require:
  • Additional confirmation if performed outside business hours (e.g., 20:00–06:00).
  • Automatic flagging for next-day managerial review. 3. Appeal submission deadlines:
  • System must display days remaining to appeal; access to overdue appeals may trigger warnings and require justification for late submission.

5. Emergency / On-Call Overrides

Denial analysis is rarely life-critical, but on-call scenarios may require broader access (e.g., for urgent high-value payer audits).

• Rules: 1. On-call Denial Manager or Senior Denial Analyst may be granted temporary cross-facility access during designated on-call windows. 2. Such overrides must:
  • Be time-bound (e.g., 8–12 hours).
  • Be logged with reason (e.g., “Payer audit – urgent response”).
  • Be subject to post-event review by the Revenue Cycle Manager or Data Protection Officer (DPO).

Break-the-Glass Procedures

Although BTG is more common in clinical modules, denial analysis may require BTG when restricted clinical information is needed to support an appeal (e.g., mental health or HIV-related diagnoses that are sealed by default).

1. When BTG is Required

• Denial staff attempt to access:
• Clinical documents or diagnoses classified as Clinical — Restricted (e.g., mental health, HIV/STI, substance abuse) that are normally sealed.
• EHR notes beyond the standard billing/claims view, where the EHR has sealed-envelope protections.
• Typical scenarios: 1. Payer requests detailed clinical justification for a denial related to a restricted condition. 2. Legal/complaint case where denial decision is being challenged and full clinical context is required.

2. BTG Workflow

1. User (typically Denial Manager or Physician Advisor) clicks “Request Restricted Clinical Details” from the denial or appeal screen.
2. System displays a warning: - “You are requesting access to restricted clinical information. This action is logged and subject to review under UAE PDPL and Federal Law No. 2 of 2019. Proceed only if strictly necessary for treatment, legal obligation, or payer appeal.”
3. User must: - Select justification from a controlled list (e.g., “Payer appeal – medical necessity”, “Legal complaint”, “Regulatory audit”). - Enter free-text explanation.
4. System checks: - Role eligibility (only PA, DM, and designated SDA may BTG). - Whether a supervisor approval is required (configurable; e.g., DM approval for SDA BTG).
5. If approved: - System grants time-limited access (e.g., 30–60 minutes) to specific restricted data elements relevant to the denial. - Access scope is limited to the current patient and denial case.
6. All BTG events are: - Logged in an immutable audit log. - Flagged for DPO/compliance review.

3. Audit Trail Requirements

For each BTG event, the system must record at minimum:

• User ID and role
• Patient ID and denial/appeal IDs
• Timestamp (start and end of BTG session)
• Justification code and free-text reason
• Data elements accessed (e.g., specific documents, diagnoses)
• Any exports/prints performed during BTG session

Audit logs must be:

• Read-only and tamper-evident.
• Retained per facility policy and UAE legal requirements (typically aligned with clinical record retention).

4. Post-Access Review

• Compliance / DPO or designated privacy officer must: 1. Review all BTG events within a defined SLA (e.g., 7 days). 2. Classify each event as justified or unjustified. 3. For unjustified access:
  • Trigger incident management and potential disciplinary action.
  • Consider notification obligations under UAE PDPL (if risk to patient rights is high).
• The system should provide:
• A BTG Review Dashboard (could be part of a central audit module) with filters by user, date, patient, and justification.
• Exportable reports for internal and regulator audits.

5. UAE PDPL Implications

• Health data is sensitive personal data; BTG is a high-risk processing activity.
• BTG must be:
• Minimized (only when necessary).
• Proportionate (limited in scope and time).
• Transparent (documented in internal policies; patients may be informed via privacy notice).
• Facilities should conduct a Data Protection Impact Assessment (DPIA) for BTG workflows, as recommended under PDPL and ADHICS.

Segregation of Duties

To reduce fraud, abuse, and conflicts of interest, the system must support and enforce segregation-of-duties (SoD) rules in the denial-analysis context.

1. Conflicting Role Combinations

The following combinations must not be assigned to the same user account (or must be flagged and require explicit risk acceptance):

1. Denial Manager + Billing & Claims Cash Posting Role - Risk: Same user could manipulate denials and payment postings to conceal misappropriation. - Control: System should prevent assigning both roles or require DPO/Finance approval.

2. Denial Analyst + Payer Contract Configuration Role (policy-contract-mgmt) - Risk: User could adjust contract terms to justify denial patterns or manipulate KPIs. - Control: Keep contract configuration in a separate team; read-only access to contract summaries is acceptable.

3. Denial Analyst + Patient Access Registration Supervisor Role - Risk: User could alter registration/eligibility data to mask front-end errors that caused denials. - Control: Allow read-only view of registration data; no edit rights for denial staff.

4. Coding Specialist + Denial Manager - Risk: Same person could both code and approve denial-related write-offs, reducing independent review. - Control: Coding Specialists should not have write-off approval rights.

5. Physician Advisor + Treating Physician for Same Patient (in context of appeals) - Risk: Self-review of clinical decisions in appeals. - Control: Where feasible, assign Physician Advisor reviews to a different physician than the treating consultant.

2. Dual Sign-Off Requirements

Certain high-risk actions must require dual approval:

1. High-Value Write-Offs - Threshold configurable (e.g., > AED 25,000 per denial or per case). - Workflow:

   1. Denial Analyst proposes write-off with justification.
   2. Denial Manager reviews and approves.
   3. Revenue Cycle Manager or Finance Manager provides second approval. - System must: - Enforce that approvers are different users. - Log both approvals with timestamps and comments.

2. Changes to Write-Off Approval Thresholds - Must require:

   • Denial Manager proposal.
   • Finance Director or CFO approval.
   • Changes must be versioned and auditable.

3. Changes to Appeal Deadline Rules (per payer) - Must require:

   • Denial Manager edit.
   • Revenue Cycle Manager or Contract Manager approval.
   • Rationale: Incorrect deadlines could intentionally or unintentionally increase preventable denials.

4. Creation of High-Impact Prevention Actions with Significant Cost - For actions with estimated cost above a configured amount (e.g., AED 100,000):

   • Denial Manager creates action.
   • Revenue Cycle Manager and possibly CFO approve.

The system should provide a generic dual-approval framework that can be reused across RCM modules, with clear status indicators (e.g., “Pending 2nd Approval”).

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 and secure handling of health data. - Denial analysis uses health data primarily for:

   • Treatment-related billing and reimbursement.
   • Health system management and quality improvement.
   • Access must be limited to staff who need it for these purposes.

2. UAE PDPL (Federal Decree-Law No. 45/2021) - Health data is sensitive personal data. - Denial processing typically falls under:

   • Legal obligation / contractual necessity (insurance claims, appeals).
   • Healthcare exemption for system management and quality.
   • RBAC and context-based access are key technical and organizational measures to comply with PDPL.
   • Data subject rights (access, correction) are primarily handled via patient portal and EHR; denial data must be included in exports where relevant.

3. DOH (Abu Dhabi) – ADHICS & Malaffi - ADHICS requires:

   • Role-based access control.
   • Least-privilege principle.
   • Comprehensive audit logging.
   • Denial module must ensure:
   • No unnecessary clinical data is exposed to denial staff.
   • Any data shared with Malaffi (if applicable) follows DOH policies (usually clinical, not financial).

4. DHA (Dubai) – NABIDH & eClaimLink - eClaimLink integration (appeals) must:

   • Use secure authentication and authorization.
   • Limit data transmitted to what is required by DHA claim/appeal specifications.
   • NABIDH focuses on clinical HIE; denial module should not push financial-only data to NABIDH unless required by DHA.

5. Insurance Regulations (DOH eClaims / DHA eClaimLink) - Denial and appeal workflows must:

   • Respect payer-specific timelines and formats.
   • Ensure that only authorized staff submit appeals and view payer responses.
   • Role-based permissions for appeal submission and tracking must align with payer portal access policies.

6. Cybersecurity (TDRA/NESA, ADHICS) - Access to denial data must be:

   • Over secure channels (TLS 1.2+).
   • Protected by strong authentication (MFA for remote access).
   • Audit logs for denial module must integrate with central SIEM for anomaly detection (e.g., unusual access patterns by denial staff).

By implementing the roles, permissions, context rules, BTG procedures, and SoD controls described in this document, the Denial Analysis module will support compliant, secure, and auditable handling of denial-related data within UAE healthcare facilities.