Policy & Contract Management User Roles & Permissions
Home / Revenue Cycle Management / Policy & Contract Management / Roles & Permissions

Policy & Contract Management User Roles & Permissions

This document defines roles, permissions, and access-control rules for the Policy & Contract Management (policy-contract-mgmt) module of the Gates Group HIS, aligned with UAE regulatory requirements (DOH, DHA, MOH, UAE PDPL). It is intended for architects, developers, and security teams implementing RBAC and context-based access in this module.

Role Definitions

Note: Authentication, core user identity, and global role assignment are owned by ehr-patient-mgmt (users, roles, permissions). This module defines module-scoped roles and permissions that are attached to those global users.

Contract Manager

  • Description: Owns end-to-end lifecycle of payer contracts, including drafting, versioning, routing for approval, and managing amendments.
  • Typical UAE job titles:
  • Contract Manager
  • Senior Contracts Executive (RCM)
  • Payer Relations Manager
  • Scope of access:
  • All contracts, contract_fee_schedules, contract_amendments, and payer_networks across all facilities in their organization.
  • Read/write access to payers, insurance_plans, coverage_rules, prior_auth_rules where needed to support contracts.
  • No access to patient-level data; only aggregated reimbursement metrics (from reimbursement_rates).
  • Reporting hierarchy:
  • Reports to: RCM Manager or Finance Director.
  • May supervise: Contract Analysts.

Contract Analyst

  • Description: Performs analytical and configuration work related to contracts, coverage rules, and reimbursement performance.
  • Typical UAE job titles:
  • Contract Analyst
  • Health Insurance Analyst
  • RCM Business Analyst
  • Scope of access:
  • Read access to all payers, insurance_plans, contracts, contract_fee_schedules, fee_schedule_items, reimbursement_rates.
  • Configure and test coverage_rules and prior_auth_rules.
  • Cannot activate contracts or fee schedules; cannot perform final approvals.
  • Reporting hierarchy:
  • Reports to: Contract Manager or RCM Manager.
  • No direct reports typically.

Fee Schedule Analyst

  • Description: Manages fee schedules, tariff imports (DHA/DOH), and rate impact analysis.
  • Typical UAE job titles:
  • Fee Schedule Analyst
  • Tariff Specialist
  • Pricing Analyst (RCM)
  • Scope of access:
  • Create/edit contract_fee_schedules and fee_schedule_items for assigned payers/facilities.
  • Import DHA/DOH tariff schedules and map to contracts.
  • Read-only access to contracts and payers.
  • No access to coverage/prior-auth rule activation.
  • Reporting hierarchy:
  • Reports to: RCM Manager or Finance Director.
  • Works closely with Contract Manager and Billing & Claims team.

RCM Manager

  • Description: Senior leader overseeing revenue cycle operations, payer relationships, and contract performance.
  • Typical UAE job titles:
  • Revenue Cycle Manager
  • Head of Revenue Cycle
  • RCM Director
  • Scope of access:
  • Full read access to all entities in this module.
  • Approve contracts and fee schedules; manage payer master data.
  • Override certain rules (e.g., temporary suspension of coverage rules) with audit.
  • Access to payer performance dashboards and reimbursement_rates.
  • Reporting hierarchy:
  • Reports to: Finance Director or Chief Financial Officer.
  • Supervises: Contract Manager, Fee Schedule Analyst, Contract Analysts, Billing Supervisors.

Finance Director

  • Description: Executive responsible for financial strategy, including payer mix, contract strategy, and high-level approvals.
  • Typical UAE job titles:
  • Finance Director
  • Director of Finance
  • Chief Financial Officer (for smaller hospitals)
  • Scope of access:
  • Read access to all contracts, fee schedules, coverage rules, and payer performance dashboards.
  • Final approval of contracts and major fee schedule changes.
  • No low-level configuration rights (cannot edit line items directly).
  • Reporting hierarchy:
  • Reports to: CEO / Hospital Director.
  • Supervises: RCM Manager, broader finance team.

Billing Specialist (read-only in this module)

  • Description: Billing/claims staff who need to reference contracted rates and coverage rules when coding and submitting claims.
  • Typical UAE job titles:
  • Medical Coder
  • Billing Specialist
  • Claims Officer
  • Scope of access:
  • Read-only access to contracts, contract_fee_schedules, fee_schedule_items, coverage_rules, prior_auth_rules, and payer_networks.
  • No ability to modify payer master, contracts, or rules.
  • Access limited to facilities/departments where they process claims.
  • Reporting hierarchy:
  • Reports to: Billing Supervisor / RCM Manager.
  • No direct reports.

System Administrator

  • Description: Technical administrator responsible for system configuration, payer connectivity, and EDI/eClaimLink/eClaims settings.
  • Typical UAE job titles:
  • HIS Administrator
  • Application Support Specialist (RCM)
  • Health Information Systems Engineer
  • Scope of access:
  • Manage payer connectivity configuration (eClaimLink, DOH eClaims/Shafafiya).
  • Configure EDI settings, submission channels, and system-level parameters.
  • No authority to change financial terms (rates, payment terms) but can view them for troubleshooting.
  • Reporting hierarchy:
  • Reports to: IT Manager / CIO.
  • Works in matrix with RCM Manager for payer connectivity.

Permission Matrix

Legend:

  • ✅ = Allowed
  • ❌ = Not allowed
  • 🔒 = Conditional (context-based, requires additional conditions such as facility assignment, approval, or BTG)

Granular Permissions by Role

Permission Contract Manager Contract Analyst Fee Schedule Analyst RCM Manager Finance Director Billing Specialist System Administrator
Payer Master & Plans
view_payer_master ✅ ✅ ✅ ✅ ✅ ✅ ✅
create_payer 🔒¹ ❌ ❌ ✅ ❌ ❌ 🔒²
edit_payer_demographics 🔒¹ ❌ ❌ ✅ ❌ ❌ 🔒²
manage_payer_contacts ✅ 🔒³ ❌ ✅ ❌ ❌ 🔒²
configure_payer_classification (gov/private/self-pay) ✅ 🔒³ ❌ ✅ ✅ ❌ ❌
manage_insurance_plans (create/edit) ✅ 🔒³ ❌ ✅ ❌ ❌ ❌
activate_deactivate_plan ✅ ❌ ❌ ✅ ✅ ❌ ❌
Contracts & Amendments
create_contract_shell ✅ 🔒³ ❌ ✅ ❌ ❌ ❌
edit_contract_terms (non-financial) ✅ ✅ ❌ ✅ ❌ ❌ ❌
edit_contract_financial_terms (rates, discounts, payment_terms_days) ✅ 🔒⁴ ❌ ✅ 🔒⁵ ❌ ❌
manage_amendments ✅ 🔒³ ❌ ✅ 🔒⁵ ❌ ❌
route_contract_for_approval ✅ ✅ ❌ ✅ ❌ ❌ ❌
approve_contracts (operational approval) ❌ ❌ ❌ ✅ ❌ ❌ ❌
final_approve_contracts (executive sign-off) ❌ ❌ ❌ 🔒⁶ ✅ ❌ ❌
upload_contract_documents (PDF, annexes) ✅ ✅ ❌ ✅ ✅ ❌ ❌
archive_contract_version ✅ 🔒³ ❌ ✅ ✅ ❌ ❌
Fee Schedules
view_fee_schedules ✅ ✅ ✅ ✅ ✅ ✅ ✅
create_fee_schedule 🔒⁷ ❌ ✅ ✅ ❌ ❌ ❌
edit_fee_schedule_header (name, dates, status) 🔒⁷ ❌ ✅ ✅ ❌ ❌ ❌
edit_fee_schedule_items (CPT rates) 🔒⁷ ❌ ✅ ✅ ❌ ❌ ❌
import_tariffs (DHA/DOH) ❌ ❌ ✅ ✅ ❌ ❌ 🔒²
run_fee_schedule_impact_analysis 🔒⁸ ✅ ✅ ✅ ✅ ❌ ❌
publish_fee_schedule (set status=active) ❌ ❌ 🔒⁹ ✅ 🔒¹⁰ ❌ ❌
Coverage & Prior Auth Rules
view_coverage_rules ✅ ✅ ✅ ✅ ✅ ✅ ✅
configure_coverage_rules 🔒¹¹ ✅ ❌ ✅ ❌ ❌ ❌
activate_deactivate_coverage_rule 🔒¹¹ ❌ ❌ ✅ ✅ ❌ ❌
configure_prior_auth_rules 🔒¹¹ ✅ ❌ ✅ ❌ ❌ ❌
activate_deactivate_prior_auth_rule 🔒¹¹ ❌ ❌ ✅ ✅ ❌ ❌
override_rules (temporary suspension for specific payer/service) ❌ ❌ ❌ 🔒¹² 🔒¹² ❌ ❌
Payer Networks & Connectivity
manage_payer_networks (in/out-of-network, tier) ✅ 🔒³ ❌ ✅ ✅ ❌ ❌
manage_payer_connectivity (eClaimLink/eClaims endpoints) ❌ ❌ ❌ 🔒¹³ ❌ ❌ ✅
configure_edi_settings (formats, segments) ❌ ❌ ❌ 🔒¹³ ❌ ❌ ✅
manage_submission_channels (portal vs gateway) ❌ ❌ ❌ 🔒¹³ ❌ ❌ ✅
Analytics & Dashboards
view_payer_performance_dashboard 🔒¹⁴ ✅ 🔒¹⁴ ✅ ✅ 🔒¹⁴ ❌
export_payer_performance_data (CSV/Excel) 🔒¹⁵ 🔒¹⁵ 🔒¹⁵ ✅ ✅ ❌ ❌
view_reimbursement_variance_details (aggregated) ✅ ✅ ✅ ✅ ✅ 🔒¹⁶ ❌
Audit & Security
view_contract_audit_log ✅ ✅ ✅ ✅ ✅ ❌ ✅
view_configuration_audit_log (rules, connectivity) ❌ ❌ ❌ ✅ ✅ ❌ ✅
break_glass_access_policy_contract_module 🔒¹⁷ 🔒¹⁷ 🔒¹⁷ 🔒¹⁷ 🔒¹⁷ ❌ 🔒¹⁷
manage_module_system_config (non-EDI) ❌ ❌ ❌ 🔒¹³ ❌ ❌ ✅ 

**Footnotes / Conditions**

1. 🔒¹ `create_payer` / `edit_payer_demographics` by Contract Manager allowed only for **non-regulated attributes** (contacts, internal classification). Regulatory identifiers (DHA/DOH license, payer codes) require RCM Manager approval.
2. 🔒² System Administrator may create/edit payer connectivity and technical identifiers but **not** financial or contractual attributes.
3. 🔒³ Contract Analyst can propose changes (draft state) but cannot activate; requires Contract Manager or RCM Manager approval.
4. 🔒⁴ Contract Analyst may edit financial terms only in **simulation/draft** contracts; activation requires Contract Manager + RCM Manager approval.
5. 🔒⁵ Finance Director can request/approve financial term changes but typically does not perform data entry; system should allow approval without edit rights.
6. 🔒⁶ In some organizations, RCM Manager may have final approval for low-value or short-term contracts; configurable threshold (e.g., annual value < AED 1M).
7. 🔒⁷ Contract Manager can create/edit fee schedules only **within contracts they own** and only for non-tariff-based components; tariff imports remain with Fee Schedule Analyst.
8. 🔒⁸ Contract Manager can run impact analysis on contracts they own; RCM Manager and Finance Director can run across all payers/facilities.
9. 🔒⁹ Fee Schedule Analyst can publish fee schedules only after RCM Manager approval recorded in workflow.
10. 🔒¹⁰ Finance Director’s approval required for fee schedules exceeding configured variance thresholds vs previous period (e.g., >10% increase).
11. 🔒¹¹ Contract Manager can configure rules only for payers/contracts they manage; activation requires RCM Manager or Finance Director sign-off depending on risk level.
12. 🔒¹² Rule overrides must be time-bound and documented; dual sign-off by RCM Manager + Finance Director for high-impact overrides (e.g., disabling prior auth for entire payer).
13. 🔒¹³ RCM Manager can request and approve connectivity/EDI changes; System Administrator executes technical configuration.
14. 🔒¹⁴ Access to payer performance dashboards may be limited by facility; Billing Specialists see only payers they bill for.
15. 🔒¹⁵ Export of performance data restricted to de-identified/aggregated datasets unless explicit authorization from Data Protection Officer (PDPL requirement).
16. 🔒¹⁶ Billing Specialists see only **aggregated variance**; no payer-level negotiation notes or internal comments.
17. 🔒¹⁷ Break-the-glass access is **rare** in this module (see BTG section); when invoked, grants temporary read-only access across facilities, never write access.

---

## Role Hierarchy

```mermaid
graph TD
    FD[Finance Director] --> RCM[RCM Manager]
    RCM --> CM[Contract Manager]
    RCM --> FSA[Fee Schedule Analyst]
    RCM --> CA[Contract Analyst]
    RCM --> BS[Billing Specialist (RO)]
    ITM[IT Manager / CIO] --> SA[System Administrator]

    %% Inheritance notes (conceptual)
    classDef mgmt fill:#f9f,stroke:#333,stroke-width:1px;
    classDef ops fill:#bbf,stroke:#333,stroke-width:1px;
    classDef tech fill:#bfb,stroke:#333,stroke-width:1px;

    class FD,RCM mgmt;
    class CM,FSA,CA,BS ops;
    class SA,ITM tech;

Inheritance principles (for implementation):

  • RCM Manager inherits all permissions of Contract Manager, Contract Analyst, and Fee Schedule Analyst, plus managerial approvals and overrides.
  • Finance Director inherits all read permissions of RCM Manager plus final approval rights; does not inherit low-level edit/configuration rights.
  • Billing Specialist is strictly read-only in this module; no inheritance of write permissions.
  • System Administrator has technical configuration rights but no financial/contractual edit rights, even if they sit higher in IT hierarchy.

Context-Based Access Rules

1. Facility-Based Restrictions (Multi-Facility)

  • Each user is associated with one or more facilities via users_facilities mapping (owned by ehr-patient-mgmt).
  • For contracts, fee schedules, coverage rules, and payer networks:
  • Contract Manager, Contract Analyst, Fee Schedule Analyst, and Billing Specialist see only records where contracts.facility_id is in their assigned facility list.
  • RCM Manager and Finance Director may be granted multi-facility or enterprise-wide access depending on organization configuration.
  • System Administrator:
  • Can configure connectivity for all facilities but cannot view or edit financial terms beyond what is necessary for routing (e.g., payer IDs, channel types).

2. Department-Based Restrictions

  • Where contracts are department-specific (e.g., radiology-only contracts):
  • Access to detailed terms may be limited to users assigned to those departments (e.g., Radiology Billing Specialist).
  • Implementation: optional department_id on contracts and contract_fee_schedules; access filtered by users_departments mapping.
  • Coverage and prior auth rules that are clinical-pathway-specific (e.g., oncology) may be visible only to:
  • Contract Analysts and RCM staff.
  • Clinical leaders via other modules (e.g., CPOE) through read-only APIs.

3. Patient Relationship Requirements

This module generally works with payer-level and contract-level data, not patient-level records. However:

  • When integrated views show claim examples or denial samples from Billing & Claims:
  • Only aggregated or de-identified data should be shown by default.
  • If patient-level drill-down is enabled (e.g., for denial root cause analysis), access must be restricted to:
    • Users with a legitimate role in billing/RCM.
    • Facilities where the encounter occurred.
  • Patient identifiers (Emirates ID, name) should be masked unless the user also has appropriate permissions in Billing & Claims and EHR modules.

4. Time-Based Access (Shift-Based)

  • For operational staff (Contract Analyst, Fee Schedule Analyst, Billing Specialist):
  • Write operations (e.g., editing contracts, fee schedules, rules) may be restricted to business hours (e.g., 08:00–20:00 local time) to reduce risk of unsupervised changes.
  • After-hours changes require RCM Manager approval or BTG justification.
  • System Administrators may perform connectivity changes during maintenance windows; system should:
  • Log maintenance window start/end.
  • Enforce dual sign-off for high-risk changes (e.g., switching submission channels).

5. Emergency / On-Call Overrides

Although less common than in clinical modules, emergency access scenarios include:

  • Imminent contract expiry that threatens claim submission continuity (e.g., payer portal access changes at midnight).
  • Regulatory tariff changes (DHA/DOH) with hard deadlines requiring urgent fee schedule updates.

Rules:

  1. On-call RCM Manager or Finance Director may invoke BTG to: - Access contracts and fee schedules outside normal facility/department/time constraints. - Approve urgent changes initiated by analysts.
  2. BTG in this module never grants: - Direct access to patient clinical data. - Unrestricted ability for System Administrator to edit financial terms.

All such overrides must follow BTG procedures below.

Break-the-Glass (BTG) Procedures

When BTG is Required

BTG is required when a user needs temporary elevated access beyond their normal scope, such as:

  • RCM Manager needing to view or approve a contract for a facility they are not normally assigned to (e.g., cross-emirate group hospital).
  • Finance Director needing immediate access to all payer performance dashboards during an urgent board meeting, beyond pre-configured filters.
  • System Administrator needing to view limited contract metadata to troubleshoot a critical connectivity failure impacting claims submission.

BTG is not a substitute for poor role design; it is for exceptional, time-limited situations.

BTG Workflow

  1. Initiation - User clicks “Emergency Access (Break-the-Glass)” in the Policy & Contract Management module. - System displays a modal with:
    • Description of BTG scope (read-only vs read/write).
    • Warning referencing UAE PDPL and internal policy.
  2. Justification - User must enter:
    • Free-text reason (min 30 characters).
    • Business impact (dropdown: “Claims at risk”, “Regulatory deadline”, “Executive request”, etc.).
    • Expected duration (15, 30, 60 minutes).
  3. Approval - Default model:
    • For read-only BTG (e.g., viewing cross-facility contracts): auto-approved but flagged for post-review.
    • For write BTG (e.g., emergency fee schedule activation): requires second-level approval:
    • RCM Manager + Finance Director, or
    • RCM Manager + IT Manager (for connectivity-related BTG).
    • Approver receives in-app notification and/or SMS/email.
  4. Access Grant - System grants temporary elevated permissions:
    • Scope-limited (e.g., specific payer or contract).
    • Time-limited (max 60 minutes; configurable).
    • Visual indicator (e.g., red banner) shows BTG mode is active.
  5. Audit Trail - Log entries must include:
    • user_id, role_id, facility_id(s)
    • Start/end timestamps
    • Justification text
    • Approver(s) and timestamps
    • Objects accessed/modified (contract IDs, fee_schedule_ids, rule_ids)
    • IP address / device ID
  6. Post-Access Review - Compliance / Data Protection Officer (DPO) or Internal Audit:
    • Receives daily BTG report.
    • Reviews each BTG event within 24–72 hours.
    • Classifies as justified, questionable, or misuse.
    • Misuse triggers:
    • Temporary suspension of elevated privileges.
    • Possible disciplinary action per HR policy.

UAE PDPL Implications

  • BTG events involve processing of personal data (e.g., payer contacts, potentially patient identifiers in performance views).
  • Under PDPL:
  • BTG must be necessary and proportionate to the legitimate purpose (e.g., ensuring continuity of care via uninterrupted claims).
  • Audit logs for BTG are themselves personal data and must be:
    • Stored securely (encrypted, access-controlled).
    • Retained per internal retention schedule (e.g., 5–10 years).
  • Data subjects (patients) generally do not need to be notified for BTG in this module, as processing is for billing/contractual necessity (legal basis: contract performance and legal obligation).
  • BTG design must align with Federal Law No. 2 of 2019 (ICT in health fields) and emirate-level security standards (ADHICS/NABIDH), which require:
  • Strong authentication.
  • Detailed access logging.
  • Regular audit of exceptional access.

Segregation of Duties

To reduce fraud and error risk, the system must enforce Segregation of Duties (SoD) constraints at the RBAC layer.

1. Conflicting Role Combinations

The following combinations must not be assigned to the same user account:

Role A Role B Risk Enforcement
Contract Manager System Administrator Ability to both define financial terms and alter connectivity/EDI routing, enabling undetected manipulation of claims System-level rule: prevent assignment of both roles to same user_id
Fee Schedule Analyst System Administrator Ability to change rates and technical submission paths Same as above
Billing Specialist System Administrator Ability to alter both claim content and submission channels Same as above
Contract Manager Billing Specialist (with write access in Billing & Claims) Ability to negotiate terms and directly manipulate claim amounts Recommended to separate; if combined, require enhanced audit and approval
RCM Manager DPO (if defined as a role) Conflict between operational responsibility and oversight of data protection Organizational policy; system should support but cannot fully enforce

Implementation:

  • Maintain a role_conflicts table in ehr-patient-mgmt listing incompatible role pairs.
  • On role assignment or update:
  • Validate against role_conflicts.
  • Block assignment and show explanatory message.

2. Dual Sign-Off Requirements

Certain high-risk actions require two distinct users with appropriate roles:

Action Required Approvers System Rules
Final approval of high-value contract (above configured AED threshold) RCM Manager + Finance Director Workflow engine must enforce two approvals; same user cannot fulfill both roles
Activation of new fee schedule with >10% average rate increase Fee Schedule Analyst (preparation) + RCM Manager (approval) + Finance Director (if threshold exceeded) System checks variance vs previous schedule; triggers extra approval step
Temporary override of prior auth rules for entire payer or service category RCM Manager + Finance Director Both must provide justification; override must be time-bound
Change of primary submission channel (e.g., from eClaimLink to direct portal) RCM Manager + System Administrator RCM Manager approves business rationale; System Administrator executes technical change
BTG write-access session in this module Requestor + Approver (RCM Manager or Finance Director) System ensures requestor_user_id != approver_user_id

All dual sign-off events must be:

  • Logged with both approvers’ IDs and timestamps.
  • Included in periodic SoD audit reports.

UAE Regulatory Compliance

This module primarily supports insurance and financial processes but still handles personal data (payer contacts, potentially patient identifiers in performance views). Key UAE regulatory considerations:

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

  • Legal basis:
  • Processing payer and contract data: contractual necessity and legitimate interest of the healthcare facility.
  • Processing patient-level data for reimbursement analysis: legal obligation and healthcare exemption (billing/claims as part of treatment and health system management).
  • Data minimization:
  • Default to aggregated, de-identified data in dashboards.
  • Patient-level drill-down only when necessary and only for users with appropriate roles in Billing & Claims.
  • Access control:
  • Role-based + context-based rules as defined above.
  • BTG used only for exceptional cases, with full audit.
  • Audit & retention:
  • All changes to contracts, fee schedules, coverage rules, and prior auth rules must be logged (who, what, when, before/after values).
  • Audit logs retained per internal policy (typically 7–10 years) and must be exportable for regulatory inspection.

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

  • Requires:
  • Secure handling of health-related financial data (claims, reimbursement).
  • Data residency in UAE for health data; this includes contract and reimbursement data tied to patient encounters.
  • System implications:
  • Databases storing contracts, contract_fee_schedules, coverage_rules, reimbursement_rates must be hosted on UAE-based infrastructure.
  • Any analytics or BI tools accessing this module’s data must also comply with UAE residency and security requirements.

DOH / DHA Insurance & Claims Regulations

  • DHA eClaimLink and DOH eClaims (Shafafiya):
  • Payer connectivity and EDI settings must align with their technical standards.
  • Only System Administrators and RCM Manager can configure these settings.
  • Tariff updates (DHA/DOH):
  • Fee Schedule Analyst must import and apply official tariffs without unauthorized modification.
  • System should maintain a clear distinction between regulatory tariffs and negotiated rates (e.g., percentage of tariff).
  • Auditability:
  • Contract terms and fee schedules must be traceable to specific tariff releases and contract versions for payer disputes and regulatory audits.

Cybersecurity (TDRA / NESA, ADHICS)

  • Access to this module must:
  • Use strong authentication (MFA for remote access).
  • Be logged and monitored for anomalous behavior (e.g., mass export of contract data).
  • System Administrator actions (EDI configuration, connectivity changes) are high-risk and must be:
  • Logged with elevated detail.
  • Included in periodic security reviews.

This specification should be used by development teams to implement RBAC, context-based access, BTG workflows, and SoD controls for the Policy & Contract Management module, ensuring alignment with UAE regulatory requirements and organizational governance.

← Previous Policy & Contract Management Workflows Next → Policy & Contract Management Data Specifications
content/rcm/policy-contract-mgmt/02-roles-permissions.md Generated 2026-02-20 22:54