Billing & Claims Management User Roles & Permissions

This document defines the role-based access control (RBAC) model for the Billing & Claims Management (billing-claims) module. It is designed for UAE multi-facility providers and aligns with Federal Law No. 2 of 2019 (ICT in Health Fields), UAE PDPL, DOH ADHICS, and DHA/NABIDH/eClaimLink requirements.

Role Definitions

For all roles below, user identity, authentication, and base role assignment are owned by ehr-patient-mgmt. This module adds billing-specific permissions and context rules.

Charge Entry Clerk

Description: Staff responsible for reviewing and entering charges generated from clinical modules and correcting charge-related errors.
Typical UAE titles: Charge Entry Clerk, Billing Data Entry Officer, Revenue Integrity Clerk.
Scope of access:
Patients: All patients for encounters in assigned facilities/departments; no access to clinical notes.
Data:
- Full create/update access to charges, charge_details for in-scope encounters.
- Read-only access to encounter metadata (dates, visit type), basic demographics (name, MRN, age, gender), and insurance plan (for rate selection).
- Read-only access to fee schedule items and charge capture rules.
Cannot view detailed clinical documentation beyond coded diagnoses/procedures needed for billing.
Reporting hierarchy: Reports to Billing Supervisor or Revenue Cycle Manager.

Billing Specialist

Description: Staff responsible for claim assembly, scrubbing, and submission preparation.
Typical UAE titles: Medical Biller, Claims Executive, Insurance Billing Officer.
Scope of access:
Patients: All insured and self-pay patients whose encounters are in billing status for assigned facilities.
Data:
- Full access (create/update) to claims, claim_lines, claim_submissions for assigned payers/facilities.
- Run and manage claim edit worklists; view claim_edits outcomes.
- Read-only access to charges, charge_details, ar_aging, remittance_advice.
- Read-only access to limited clinical codes (ICD-10-AM, CPT, DRG) but not narrative clinical notes.
Reporting hierarchy: Reports to Billing Supervisor or Revenue Cycle Manager.

Payment Poster

Description: Staff responsible for posting payer remittances and reconciling payments.
Typical UAE titles: Payment Poster, Insurance Cash Application Officer, Finance Officer – Medical Claims.
Scope of access:
Patients: Patients with open claims or outstanding balances for assigned payers/facilities.
Data:
- Create/update payments, payment_allocations, and link to claims, claim_lines.
- Read-only access to claims, claim_lines, claim_responses, remittance_advice.
- Update reconciliation flags and batch status; no ability to change original charges.
Reporting hierarchy: Reports to Finance Manager or Revenue Cycle Manager.

AR Specialist

Description: Staff responsible for managing accounts receivable, follow-up, and collections from payers.
Typical UAE titles: AR Specialist, Insurance Follow-up Officer, Collections Executive – Medical.
Scope of access:
Patients: Patients with outstanding balances in assigned aging buckets, payers, or facilities.
Data:
- Read/write access to follow-up notes (AR worklist), claim status fields, and appeal tracking fields.
- Read-only access to payments, payment_allocations, remittance_advice.
- Read-only access to ar_aging dashboards with drill-down to claim level.
- Cannot modify charge amounts or fee schedules.
Reporting hierarchy: Reports to AR Supervisor or Revenue Cycle Manager.

Denial Specialist

Description: Staff focused on denial analysis, categorisation, and appeal preparation.
Typical UAE titles: Denial Management Specialist, Claims Reconciliation Officer, Insurance Auditor.
Scope of access:
Patients: Patients with denied or underpaid claims for assigned payers/facilities.
Data:
- Read/write access to denial categorisation fields, appeal records, and appeal status.
- Read-only access to claims, claim_lines, claim_responses, remittance_advice, and denial-related payment_allocations.
- Access to denial reason master data and claim edit rules (read-only).
Reporting hierarchy: Reports to AR Manager or Revenue Cycle Manager; may have dotted line to Denial Analysis team.

Patient Billing Specialist

Description: Staff responsible for patient-facing billing, statements, and patient payment plans.
Typical UAE titles: Patient Accounts Officer, Self-Pay Billing Specialist, Patient Financial Services Executive.
Scope of access:
Patients: Patients with patient-responsibility balances (self-pay, co-pay, deductibles) in assigned facilities.
Data:
- Create/update patient_invoices, patient_payments, payment plans, and refund requests (draft).
- Read-only access to claims, claim_lines, payments (payer portions) to explain balances.
- View demographics, contact details, and insurance coverage (administrative data only).
Reporting hierarchy: Reports to Patient Accounts Supervisor or Revenue Cycle Manager.

Cashier

Description: Front-desk or cashier staff collecting point-of-service payments and issuing receipts.
Typical UAE titles: Cashier, Front Office Cashier, POS Collection Officer.
Scope of access:
Patients: Patients presenting at registration, discharge, or outpatient clinics in assigned locations.
Data:
- Create patient_payments records and issue receipts.
- Read-only view of patient balance summary and amount due; no access to detailed claim lines or denial details.
- Access to end-of-day reconciliation reports for their own drawer only.
Reporting hierarchy: Reports to Finance/Cash Office Supervisor or Patient Access Manager.

Revenue Cycle Manager

Description: Senior role overseeing the entire revenue cycle, including configuration and staff management.
Typical UAE titles: Revenue Cycle Manager, Head of Billing & Claims, Finance Manager – Revenue Cycle.
Scope of access:
Patients: All patients across facilities, for billing/financial data only.
Data:
- Full read access to all billing entities (charges, claims, payments, patient_invoices, ar_aging, etc.).
- Configuration rights for charge_capture_rules, claim_edits, financial classes, and master data used by this module.
- Approve write-offs, refunds, and adjustments above defined thresholds.
- Access to revenue dashboards and KPI reports across facilities and departments.
Reporting hierarchy: Reports to Chief Financial Officer (CFO) or Hospital Director; supervises Billing, AR, Denial, and Patient Accounts teams.

Permission Matrix

Legend:

✅ = Allowed
❌ = Not allowed
🔒 = Conditional (depends on context: facility/department assignment, amount thresholds, or workflow state)

Key module permissions (non-exhaustive but granular for build):

Permission / Function	Charge Entry Clerk	Billing Specialist	Payment Poster	AR Specialist	Denial Specialist	Patient Billing Specialist	Cashier	Revenue Cycle Manager
Patient & Encounter Access
View basic patient demographics (name, MRN, age, gender)	✅	✅	✅	✅	✅	✅	✅	✅
View full contact details (phone, email, address)	🔒	🔒	🔒	🔒	🔒	✅	✅	✅
View insurance coverage & plan details	✅	✅	✅	✅	✅	✅	🔒	✅
View encounter list for assigned facility/department	✅	✅	✅	✅	✅	✅	🔒	✅
Charges & Coding
Create new charge record (`charges`)	✅	🔒	❌	❌	❌	❌	❌	✅
Edit existing charge record before claim generation	✅	🔒	❌	❌	❌	❌	❌	✅
Edit existing charge record after claim submission	🔒 (with reason + approval)	🔒 (limited fields)	❌	❌	❌	❌	❌	✅
View charge details (`charge_details`)	✅	✅	✅	✅	✅	🔒	❌	✅
Override automated charge capture rules	❌	❌	❌	❌	❌	❌	❌	🔒
Claim Generation & Scrubbing
Create claim header (`claims`) from eligible encounter	❌	✅	❌	❌	❌	❌	❌	✅
Edit claim header (payer, type, bill type, claim notes)	❌	✅	❌	🔒 (status only)	🔒 (appeal notes only)	❌	❌	✅
Create and edit claim lines (`claim_lines`)	❌	✅	❌	❌	🔒 (denial-related fields)	❌	❌	✅
Run claim edit engine (`claim_edits`)	❌	✅	❌	❌	❌	❌	❌	✅
Manage claim edit worklist (assign, requeue)	❌	✅	❌	❌	❌	❌	❌	✅
Override non-critical claim edit warnings	❌	🔒	❌	❌	❌	❌	❌	✅
Claim Submission & Tracking
Generate DHA eClaimLink XML batch	❌	✅	❌	❌	❌	❌	❌	✅
Generate DOH eClaims / Shafafiya batch	❌	✅	❌	❌	❌	❌	❌	✅
Submit claims electronically via configured channels	❌	✅	❌	❌	❌	❌	❌	✅
View claim submission status (`claim_submissions`)	🔒	✅	✅	✅	✅	🔒	❌	✅
Resubmit rejected claims (gateway rejection)	❌	✅	❌	❌	❌	❌	❌	✅
Mark claim as “manual submission” and record reference	❌	✅	❌	❌	❌	❌	❌	✅
Remittance & Payment Posting
Import ERA / remittance file (`remittance_advice`)	❌	❌	✅	❌	❌	❌	❌	✅
View remittance advice details	❌	🔒	✅	✅	✅	🔒	❌	✅
Create payer payment batch (`payments`)	❌	❌	✅	❌	❌	❌	❌	✅
Edit payer payment batch header (date, method, reference)	❌	❌	✅	❌	❌	❌	❌	✅
Allocate payment to claim header (`payment_allocations`)	❌	❌	✅	❌	❌	❌	❌	✅
Allocate payment to claim line	❌	❌	✅	❌	❌	❌	❌	✅
Record contractual adjustment codes	❌	❌	✅	❌	🔒	❌	❌	✅
Mark payment batch as reconciled	❌	❌	✅	❌	❌	❌	❌	✅
Denials & Appeals
View denial codes on claim lines	❌	✅	✅	✅	✅	🔒	❌	✅
Categorise denial (eligibility, coding, auth, etc.)	❌	❌	❌	✅	✅	❌	❌	✅
Create and update appeal record	❌	❌	❌	✅	✅	❌	❌	✅
Upload appeal documentation references (IDs, not documents)	❌	❌	❌	✅	✅	❌	❌	✅
Submit appeal via integrated eClaimLink/DOH APIs	❌	❌	❌	🔒	✅	❌	❌	✅
Update appeal status and outcome	❌	❌	❌	✅	✅	❌	❌	✅
Patient Billing & POS
Generate patient invoice (`patient_invoices`)	❌	❌	❌	❌	❌	✅	❌	✅
Edit patient invoice (before sending)	❌	❌	❌	❌	❌	✅	❌	✅
Send statement (portal/email/SMS/print)	❌	❌	❌	❌	❌	✅	❌	✅
Record patient payment (`patient_payments`)	❌	❌	❌	❌	❌	✅	✅	✅
View detailed patient financial account summary	❌	🔒	🔒	✅	✅	✅	🔒	✅
Create and manage patient payment plans	❌	❌	❌	❌	❌	✅	❌	✅
Initiate refund request (`refunds` – draft)	❌	❌	❌	❌	❌	✅	❌	✅
Approve and finalise refunds	❌	❌	❌	❌	❌	❌	❌	🔒
View and perform end-of-day cash reconciliation	❌	❌	❌	❌	❌	🔒	✅	✅
AR & Reporting
View AR aging dashboard (`ar_aging`)	❌	🔒	🔒	✅	✅	🔒	❌	✅
Manage AR follow-up worklist	❌	❌	❌	✅	🔒	❌	❌	✅
Update claim follow-up status and notes	❌	❌	❌	✅	✅	❌	❌	✅
Generate AR and collection reports	❌	🔒	🔒	✅	🔒	🔒	❌	✅
View revenue dashboard (facility-wide)	❌	❌	❌	🔒	🔒	🔒	❌	✅
Configuration & Administration
Manage charge capture rules (`charge_capture_rules`)	❌	❌	❌	❌	❌	❌	❌	✅
Manage claim edit rules (`claim_edits`)	❌	❌	❌	❌	🔒 (propose only)	❌	❌	✅
Manage financial class codes and payment methods	❌	❌	❌	❌	❌	❌	❌	✅
Approve high-value write-offs / adjustments	❌	❌	🔒	🔒	❌	❌	❌	✅
View billing audit logs (who changed what)	🔒	🔒	🔒	🔒	🔒	🔒	❌	✅
Perform break-the-glass access to restricted financial records	❌	❌	❌	❌	❌	🔒	❌	🔒

Notes on 🔒 (conditional) permissions:

Facility/department scoping: Many view permissions are limited to the user’s assigned facilities/departments.
Threshold-based approvals: Write-offs, adjustments, and refunds may require dual sign-off above configured amounts (see Segregation of Duties).
Appeal submission: AR Specialists may submit appeals only for specific payers or under delegation from Denial Specialist/Revenue Cycle Manager.
Break-the-glass: Only for specific scenarios (e.g., legal/complaint investigations) with strict justification and post-review.

Role Hierarchy

Role hierarchy defines permission inheritance and reporting lines for the billing-claims domain.

flowchart TD A["Chief Financial Officer / Hospital Finance Director"] --> B["Revenue Cycle Manager"] B --> C1["Billing Supervisor"] B --> C2["AR & Denial Supervisor"] B --> C3["Patient Accounts Supervisor"] B --> C4["Cash Office Supervisor"] C1 --> R1["Charge Entry Clerk"] C1 --> R2["Billing Specialist"] C2 --> R3["Payment Poster"] C2 --> R4["AR Specialist"] C2 --> R5["Denial Specialist"] C3 --> R6["Patient Billing Specialist"] C4 --> R7["Cashier"] %% Permission inheritance (conceptual) B -.inherits.-> C1 B -.inherits.-> C2 B -.inherits.-> C3 B -.inherits.-> C4

Inheritance rules:

Supervisors (Billing, AR & Denial, Patient Accounts, Cash Office) inherit all permissions of their subordinate roles for view-only purposes, plus limited override/approval permissions. These supervisor roles are configured in the global RBAC but follow the same pattern.
Revenue Cycle Manager inherits all subordinate functional permissions but is additionally granted configuration and approval rights.
CFO/Finance Director has read-only access to all billing data and dashboards; configuration remains with Revenue Cycle Manager and IT.

Context-Based Access Rules

Context-based rules ensure that even with role permissions, access is constrained by facility, department, relationship, time, and emergency status, in line with Federal Law No. 2/2019, UAE PDPL, DOH ADHICS, and DHA/NABIDH principles.

1. Facility-Based Restrictions (Multi-Facility)

Each user is assigned one or more facilities and optionally business units (e.g., hospital vs. polyclinic).
All queries in billing-claims must enforce facility_id filtering based on:
Encounter facility (encounters.facility_id)
Claim facility (claims.facility_id)
Payment facility (payments.facility_id)
Examples:
A Billing Specialist at “Dubai Creek Hospital” cannot view claims for “Abu Dhabi Corniche Medical Center” unless explicitly assigned to both.
Revenue Cycle Manager can be configured as multi-facility and see cross-facility dashboards.

2. Department-Based Restrictions

For large hospitals, access can be restricted by service department (e.g., Radiology, Surgery, Outpatient Clinics).
Charge Entry Clerks may be limited to specific department_id values in charges and encounters.
AR and Denial Specialists may be assigned by payer group rather than department; in such cases, department restriction is relaxed but facility restriction remains.

3. Patient Relationship Requirements

Billing staff do not have a clinical “treating relationship” but must still follow minimum necessary principles:
Access is limited to administrative and financial data required for billing, not full clinical records.
When integrated screens show clinical context (e.g., diagnosis descriptions), they must be limited to coded data (ICD-10-AM, CPT) without full narrative notes.
For VIP or restricted patients (e.g., high-profile individuals):
Additional flag on patient record triggers extra access checks; only designated billing staff (whitelisted) may access their financial records.
All access to VIP accounts is highlighted in audit logs for compliance review.

4. Time-Based Access (Shift-Based)

Users have configured working hours and shift patterns (from HR or scheduling).
Optional policy (configurable per facility):
Non-managerial billing users (Charge Entry, Billing Specialist, Cashier, etc.) can only access the module during their active shift plus a configurable grace period (e.g., 30 minutes).
Access outside shift requires:
- Supervisor approval (pre-approved overtime) or
- Break-the-glass justification (for urgent financial corrections tied to patient safety, e.g., preventing discharge delay).
System logs all access with timestamps to support ADHICS and NESA audit requirements.

5. Emergency / On-Call Overrides

Emergency overrides in billing are rare but may be needed for:
Immediate billing updates required for emergency transfers or life-saving procedures where payer pre-approval is critical.
Urgent correction of claim data to avoid interruption of ongoing treatment (e.g., dialysis schedule blocked due to insurance issue).
Rules:
Only Revenue Cycle Manager and designated on-call supervisors can invoke emergency override for:
- Temporarily expanding facility scope.
- Temporarily allowing modification of locked claims (pre-submission) or charges.
Every override requires:
- Explicit reason.
- Time-limited elevation (e.g., 60 minutes).
- Automatic notification to compliance/finance.

Break-the-Glass (BTG) Procedures

BTG in billing-claims is primarily for accessing restricted financial records (e.g., VIP patients, legally sealed accounts) or performing actions outside normal scope in urgent situations. It must comply with UAE PDPL and Federal Law No. 2/2019 confidentiality requirements.

1. When BTG is Required

Accessing financial records of:
VIP patients flagged as restricted.
Staff members or relatives of staff (to prevent misuse).
Patients involved in legal cases or complaints where records are sealed.
Overriding:
Facility/department restrictions in urgent operational scenarios.
Lock on claims/charges after a defined cut-off (e.g., after submission) when correction is necessary to prevent harm (e.g., payer rejecting life-sustaining treatment).
Viewing historical audit logs for a specific patient account when the user normally has only aggregated reporting access.

2. BTG Workflow

Initiation - User clicks “Break-the-Glass” on a restricted screen (e.g., patient account, claim detail). - System displays a warning banner:
“You are requesting emergency access to restricted financial information. This action is fully audited and subject to post-event review under UAE PDPL and Federal Law No. 2/2019. Proceed only if strictly necessary.”
Justification - User must enter:
- Free-text reason (minimum length).
- Category (e.g., “VIP billing issue”, “Legal complaint investigation”, “Urgent treatment funding”).
- For some categories (e.g., legal investigation), user must select authorising authority (e.g., Legal Department, Compliance).
Approval (if required) - Configurable:
- For Revenue Cycle Manager: BTG may be auto-approved but still audited.
- For other roles (e.g., Patient Billing Specialist), BTG request may require supervisor approval before access is granted, unless flagged as “time-critical”.
Access Grant - System grants:
- Time-limited access (e.g., 30–60 minutes).
- Scope-limited to the specific patient or claim.
- BTG banner remains visible on all accessed screens.
Logging - For each BTG session, log:
- User ID, role, facility.
- Patient ID / claim ID.
- Timestamp (start/end).
- Reason and category.
- Actions performed (view, edit, export).
- Source IP/device.
Notification - Automatic notification to:
- Compliance/Data Protection Officer (DPO) or equivalent.
- Revenue Cycle Manager.
- For repeated BTG by same user, escalate to higher management.

3. Post-Access Review

Daily or weekly review by Compliance/Revenue Cycle Manager:
Validate that BTG usage was legitimate and proportionate.
Check for patterns of misuse (e.g., frequent access to staff accounts).
Actions:
If misuse suspected:
- Temporarily suspend access.
- Initiate internal investigation per facility policy.
If legitimate:
- Document justification and close review.
Retention:
BTG logs are part of the audit trail and must be retained at least as long as financial records, and in line with PDPL and Federal Law No. 2/2019 requirements.

4. UAE PDPL Implications

BTG processing is justified under:
Legal obligation (handling complaints, legal requests).
Vital interests (ensuring continuity of care via urgent billing corrections).
Health system management (per Federal Law No. 2/2019).
Even when consent is not required, PDPL requires:
Transparency: Facilities should include BTG practices in privacy notices.
Accountability: Detailed records of BTG events and DPIA (Data Protection Impact Assessment) for BTG design.
Data minimisation: BTG grants only the minimum additional access necessary.

Segregation of Duties

To reduce fraud and error risk, the system must enforce segregation of duties (SoD) and dual sign-off for sensitive operations.

1. Conflicting Role Combinations

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

Conflict Pair	Risk	System Control
Cashier + Payment Poster	Same person collecting and posting payer/patient payments → risk of misappropriation	RBAC engine must prevent assignment of both roles to one user; admin UI should show SoD violation warning
Cashier + Patient Billing Specialist	Same person negotiating payment plans and handling cash → risk of unauthorised discounts and diversion	Block combined assignment or require CFO approval with enhanced monitoring
Payment Poster + AR Specialist	Same person posting payments and managing follow-up → risk of hiding non-posted payments or manipulating AR	Allowed only in small facilities with explicit SoD override flag and enhanced audit
Payment Poster + Revenue Cycle Manager	Excessive power over payments and approvals → risk of large-scale fraud	Strongly discouraged; if unavoidable, require CFO-level approval and quarterly audit
Charge Entry Clerk + Billing Specialist (full)	Same person creating charges and generating claims → risk of upcoding/unjustified charges	May be allowed in small clinics but flagged; claim edits and random audits required
Patient Billing Specialist + Revenue Cycle Manager	Same person negotiating patient settlements and approving write-offs → risk of unauthorised waivers	If combined, enforce dual sign-off for write-offs/refunds above low threshold

The RBAC configuration UI must:

Validate role assignments against a SoD rule set.
Display blocking errors or warnings when conflicting roles are selected.
Allow explicit override only for designated administrators with justification and audit.

2. Dual Sign-Off Requirements

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

Action	Primary Role	Secondary Approver	Threshold / Condition
High-value contractual write-off on payer claim	Payment Poster or AR Specialist	Revenue Cycle Manager or Finance Manager	Above configurable amount (e.g., AED 5,000 per claim)
Patient refund issuance	Patient Billing Specialist	Revenue Cycle Manager or Finance Manager	All refunds, or above AED 1,000 (configurable)
Manual adjustment reducing patient balance to zero	Patient Billing Specialist	Revenue Cycle Manager	All manual zeroing adjustments
Retroactive charge deletion after claim submission	Charge Entry Clerk or Billing Specialist	Revenue Cycle Manager	Any deletion after claim submission date
Change to claim edit rules (`claim_edits`)	Revenue Cycle Manager	CIO/IT Admin or Compliance	All changes; require change-control ticket ID
Change to charge capture rules (`charge_capture_rules`)	Revenue Cycle Manager	Clinical Coding Lead or Medical Director (for clinical impact)	All changes affecting clinical code mapping

Implementation details:

System must enforce that approver ≠ initiator.
Approval workflow must capture:
Initiator, approver, timestamps.
Reason and supporting references (e.g., payer letter, internal memo).
Actions remain in pending state until approved; no financial impact is applied before approval.

UAE Regulatory Compliance

This RBAC design supports compliance with UAE healthcare and data protection regulations as follows:

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

Confidentiality of health data:
Billing users see only administrative and coded clinical data necessary for claims and billing.
Access to narrative clinical notes is excluded from this module.
Access control:
Role-based and context-based restrictions (facility, department, VIP flags) ensure only authorised staff access health-related financial data.
Auditability:
All create/update/delete operations on financial records, and all BTG events, are logged with user, timestamp, and context.

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

Lawful basis:
Insurance claims and billing are processed under legal obligation and health system management; explicit consent is not required for core billing flows.
Portal-based patient payments and communications may require consent; this is handled in the Patient Portal module but respected here.
Data minimisation & purpose limitation:
Billing roles are restricted from accessing unnecessary clinical data.
Use of billing data for secondary purposes (e.g., marketing) is not permitted without additional consent and is outside this module’s scope.
Data subject rights:
Audit logs and structured data allow facilities to respond to access, correction, and portability requests.
Any export of billing data must respect PDPL cross-border transfer rules (e.g., when sending to external auditors outside UAE).

DOH / DHA / Insurance Regulations

DOH ADHICS & DHA security standards:
RBAC, SoD, and BTG align with ADHICS requirements for access control, logging, and monitoring.
DHA eClaimLink & DOH eClaims:
Only authorised Billing Specialists and Revenue Cycle Manager can submit claims and appeals via these channels.
Denial and appeal tracking supports payer audit requirements.
Insurance contract compliance:
Segregation of duties and audit trails support payer audits and reduce risk of fraudulent claims.

This specification should be used by the development team to implement the billing-claims RBAC model, including database-level permissions, service-layer checks, UI visibility rules, and audit logging.