Denial Analysis Master Data & Configuration

Denial Analysis Master Data & Configuration

Master Data Inventory

ID Data Set Source Approx. Records Owner Update Frequency Approver
MD-DEN-001 Denial Category Taxonomy Industry best practice + facility-defined ~30 Denial Manager Annual formal review; ad‑hoc as needed Revenue Cycle Manager
MD-DEN-002 Root Cause Classification Facility-defined (mapped to process failure points) ~50 Denial Manager Quarterly review; as patterns emerge Revenue Cycle Manager
MD-DEN-003 Denial Code Mapping (Payer → Standard Category/Reason) Payer denial code lists (DHA eClaimLink, DOH eClaims, payer portals) ~500 Denial Analyst Team Lead Monthly; on payer circulars Denial Manager
MD-DEN-004 Appeal Letter Templates Facility-developed (payer- and category-specific) ~30 Denial Manager Quarterly; on payer requirement change Revenue Cycle Manager
MD-DEN-005 Appeal Deadline Rules Payer contracts (policy-contract-mgmt) ~50 Denial Manager On contract change; at least annually Revenue Cycle Manager + Contract Manager
MD-DEN-006 Write-Off Approval Thresholds Facility finance policy ~5 Finance Director Annual; on policy change CFO / Finance Committee
MD-DEN-007 Denial Status Codes Internal standard 10–20 Denial Manager Rare; annual review Revenue Cycle Manager
MD-DEN-008 Appeal Status Codes Internal standard 10–20 Denial Manager Rare; annual review Revenue Cycle Manager
MD-DEN-009 Denial Action Types (Prevention Actions) Internal standard 10–20 Denial Manager Annual; as new initiatives arise Revenue Cycle Manager
MD-DEN-010 Responsible Department / Function Codes (for Denials) Facility org structure 20–50 HR / Operations On org change COO
MD-DEN-011 Submission Channels & Methods (Appeals) Internal standard + payer requirements 10–15 Denial Manager Annual; on payer change Revenue Cycle Manager
MD-DEN-012 Payer Denial Severity Levels Internal standard 5–10 Denial Manager Annual Revenue Cycle Manager

Note: Patients, providers, encounters, facilities, users, payers, claims, and claim lines are shared entities and are not redefined here. They are referenced via foreign keys as per module brief.


Setup Sequence

Denial analysis relies heavily on payer mappings and internal taxonomies. Load master data in the following dependency order.

flowchart TD A["Step 1: MD-DEN-010 Responsible Department Codes"] --> B["Step 2: MD-DEN-001 Denial Category Taxonomy"] B --> C["Step 3: MD-DEN-002 Root Cause Classification"] C --> D["Step 4: MD-DEN-009 Denial Action Types"] B --> E["Step 5: MD-DEN-007 Denial Status Codes"] E --> F["Step 6: MD-DEN-008 Appeal Status Codes"] B --> G["Step 7: MD-DEN-012 Payer Denial Severity Levels"] H["Step 8: MD-DEN-011 Submission Channels & Methods"] --> I["Step 9: MD-DEN-004 Appeal Letter Templates"] J["Step 10: MD-DEN-005 Appeal Deadline Rules"] --> K["Step 11: MD-DEN-003 Denial Code Mapping"] B --> K L["Shared: Payers, Contracts, Claims"] --> J K --> M["System Go-Live for Denial Analysis"] D --> M F --> M G --> M I --> M

Load Sequence (narrative):

  1. Responsible Department / Function Codes (MD-DEN-010) – foundation for assigning accountability.
  2. Denial Category Taxonomy (MD-DEN-001) – core classification used by all other datasets.
  3. Root Cause Classification (MD-DEN-002) – references categories and departments.
  4. Denial Action Types (MD-DEN-009) – used in prevention actions, linked to categories/root causes.
  5. Denial Status Codes (MD-DEN-007) – used in denial_records.status.
  6. Appeal Status Codes (MD-DEN-008) – used in appeals.status.
  7. Payer Denial Severity Levels (MD-DEN-012) – used for prioritisation and dashboards.
  8. Submission Channels & Methods (MD-DEN-011) – used in appeals.submission_method and submission_channel.
  9. Appeal Letter Templates (MD-DEN-004) – depend on categories and submission channels.
  10. Appeal Deadline Rules (MD-DEN-005) – depend on payers and contracts (from policy-contract-mgmt).
  11. Denial Code Mapping (MD-DEN-003) – depends on payer lists and denial categories.
  12. Go-live once all above are loaded and validated.

Master Data Specifications

MD-DEN-001: Denial Category Taxonomy

Purpose

Standard, bilingual taxonomy grouping denials into high-level categories (e.g., eligibility, authorization, coding). Used in:

  • denial_categories (owned table)
  • denial_records.denial_category_id
  • Trend analysis, dashboards, payer scorecards
  • Appeal template selection and prevention planning

Logical Table: denial_categories (master rows)

Schema

Field Type Required Description
category_id INT YES (PK) Surrogate key
code VARCHAR(20) YES Unique category code (e.g., ELIG, AUTH)
display_name_en VARCHAR(200) YES English name
display_name_ar VARCHAR(200) YES Arabic name
category_group VARCHAR(100) NO Higher-level grouping (e.g., Front-End, Mid-Cycle, Back-End)
description_en VARCHAR(500) NO Detailed English description
description_ar VARCHAR(500) NO Detailed Arabic description
responsible_department_code VARCHAR(50) NO (FK) Default responsible department (FK → MD-DEN-010)
is_preventable_default BOOLEAN YES Default assumption if denials in this category are usually preventable
is_active BOOLEAN YES Active flag
sort_order INT NO For UI ordering
created_at DATETIME YES Audit
created_by INT YES FK → users.user_id
updated_at DATETIME YES Audit
updated_by INT YES FK → users.user_id

Sample Data

category_id code display_name_en display_name_ar category_group description_en responsible_department_code is_preventable_default is_active sort_order
1 ELIG Eligibility الأهلية Front-End Denials due to patient not eligible or coverage not active at time of service. PATIENT_ACCESS TRUE TRUE 10
2 AUTH Authorization / Pre-cert الموافقات المسبقة Front-End Missing, invalid, or insufficient prior authorization. PATIENT_ACCESS TRUE TRUE 20
3 CODING Coding / Billing الترميز والفوترة Mid-Cycle Incorrect or incomplete diagnosis/procedure coding or billing rules. CODING TRUE TRUE 30
4 MEDNEC Medical Necessity الضرورة الطبية Mid-Cycle Services deemed not medically necessary by payer criteria. CLINICAL PARTIAL TRUE 40
5 TIMELY Timely Filing تقديم متأخر للمطالبة Back-End Claims submitted after payer filing deadline. BILLING TRUE TRUE 50
6 DUP Duplicate مكرر Back-End Duplicate claim or service already billed/paid. BILLING TRUE TRUE 60
7 BUNDLE Bundling / Inclusive تجميع الخدمات Mid-Cycle Service considered part of another billed service. CODING PARTIAL TRUE 70
8 ADMIN Administrative / Other إداري / أخرى Back-End Other administrative reasons not covered above. RCM_ADMIN PARTIAL TRUE 80

Data Governance

  • Owner: Denial Manager
  • Approval process: 1. Change request raised by Denial Analyst or Revenue Cycle Manager. 2. Impact assessment on reporting and mappings. 3. Review in monthly denial governance meeting. 4. Approved changes implemented by HIS configuration team in test, then production.
  • Update frequency: Formal annual review; ad‑hoc when new categories are needed.
  • Change notification:
  • Email to denial team, coding, billing, and patient access.
  • Update to training materials and SOPs.
  • Versioned change log in RCM configuration repository.

Validation Rules

  • code must be unique, uppercase alphanumeric with _ allowed; length 2–20.
  • display_name_en and display_name_ar must not be null or empty.
  • category_group must be one of: Front-End, Mid-Cycle, Back-End, Other.
  • responsible_department_code, if populated, must exist in MD-DEN-010.
  • At least one active category must exist for each category_group.
  • Categories referenced by denial_records cannot be hard-deleted; only is_active = FALSE.

MD-DEN-002: Root Cause Classification

Purpose

Detailed classification of underlying process failures leading to denials, mapped to denial categories and process points (front-end, mid-cycle, back-end). Used in:

  • denial_root_causes table
  • Prevention action planning and KPI “Preventable Denial Rate”

Logical Table: denial_root_cause_master

Schema

Field Type Required Description
root_cause_id INT YES (PK) Surrogate key
code VARCHAR(30) YES Unique root cause code (e.g., ELIG-INS-EXPIRED)
display_name_en VARCHAR(200) YES English name
display_name_ar VARCHAR(200) YES Arabic name
denial_category_id INT YES (FK) FK → denial_categories.category_id
process_failure_point VARCHAR(50) YES Registration, Eligibility, Authorization, Coding, Clinical Documentation, Billing, Payer
description_en VARCHAR(500) NO Detailed English description
description_ar VARCHAR(500) NO Detailed Arabic description
responsible_department_code VARCHAR(50) YES (FK) FK → MD-DEN-010
is_systemic_flag BOOLEAN YES Indicates if typically systemic (vs one-off)
is_active BOOLEAN YES Active flag
created_at DATETIME YES Audit
created_by INT YES FK → users.user_id
updated_at DATETIME YES Audit
updated_by INT YES FK → users.user_id

Sample Data

root_cause_id code display_name_en display_name_ar denial_category_id process_failure_point responsible_department_code is_systemic_flag
1 ELIG-INS-EXPIRED Insurance expired at DOS انتهاء التأمين في تاريخ الخدمة 1 Eligibility PATIENT_ACCESS TRUE
2 ELIG-ID-MISMATCH Emirates ID / member ID mismatch عدم تطابق رقم الهوية / رقم العضوية 1 Registration PATIENT_ACCESS TRUE
3 AUTH-NOT-OBTAINED Authorization not obtained عدم الحصول على الموافقة 2 Authorization PATIENT_ACCESS TRUE
4 COD-DX-NOT-SPEC Diagnosis not specific enough تشخيص غير محدد بشكل كافٍ 3 Coding CODING TRUE
5 COD-PROC-NOT-COV Procedure not covered per policy إجراء غير مشمول حسب الوثيقة 3 Coding CODING PARTIAL
6 MEDNEC-GUIDELINE Does not meet payer clinical guideline لا يطابق إرشادات شركة التأمين الطبية 4 Clinical Documentation CLINICAL TRUE
7 TIMELY-LATE-SUB Claim submitted after filing limit إرسال المطالبة بعد المهلة المحددة 5 Billing BILLING TRUE
8 BILL-DUP-SUB Duplicate claim submission إرسال مطالبة مكررة 6 Billing BILLING TRUE

Data Governance

  • Owner: Denial Manager
  • Approval process:
  • New root cause proposed by Denial Analyst with example denials.
  • Reviewed in denial governance meeting; mapped to category and department.
  • Approved codes added by HIS configuration team.
  • Update frequency: Quarterly review; ad‑hoc for emerging patterns (e.g., new payer edits).
  • Change notification:
  • Updated root cause list circulated to denial team and department heads.
  • Training sessions for analysts on new codes.

Validation Rules

  • code unique; pattern <CATEGORY>-<SHORT-DESCRIPTOR> recommended.
  • denial_category_id must reference an active category.
  • process_failure_point must be from controlled list.
  • responsible_department_code must exist and be active.
  • Root causes referenced in denial_root_causes cannot be deleted; only inactivated.

MD-DEN-003: Denial Code Mapping (Payer → Standard Category/Reason)

Purpose

Maps payer-specific denial codes (e.g., DHA eClaimLink rejection codes, DOH eClaims codes, private payer codes) to internal denial categories and root causes. Enables:

  • Automated categorisation in WF-DEN-001
  • Consistent analytics across payers
  • Identification of preventable denials

Logical Table: denial_code_mapping

Schema

Field Type Required Description
mapping_id INT YES (PK) Surrogate key
payer_id INT YES (FK) FK → payers.payer_id
payer_code VARCHAR(50) YES Payer denial/rejection code (e.g., R3, DHA-ELIG-001)
payer_code_description VARCHAR(500) NO Description from payer documentation
standard_category_id INT YES (FK) FK → denial_categories.category_id
default_root_cause_id INT NO (FK) FK → denial_root_cause_master.root_cause_id
severity_level_code VARCHAR(20) NO (FK) FK → MD-DEN-012
is_appealable_default BOOLEAN YES Default assumption if denial is appealable
requires_clinical_appeal BOOLEAN YES If physician/clinical input usually required
effective_from DATE YES Start date of mapping validity
effective_to DATE NO End date (null = current)
is_active BOOLEAN YES Active flag
created_at DATETIME YES Audit
created_by INT YES FK → users.user_id
updated_at DATETIME YES Audit
updated_by INT YES FK → users.user_id

Sample Data (UAE-focused)

mapping_id payer_id payer_code payer_code_description standard_category_id default_root_cause_id severity_level_code is_appealable_default requires_clinical_appeal
1 101 (DHA-eClaimLink) R3 Member not eligible on date of service 1 (ELIG) 1 (ELIG-INS-EXPIRED) HIGH TRUE FALSE
2 101 R5 Prior approval required but not obtained 2 (AUTH) 3 (AUTH-NOT-OBTAINED) HIGH TRUE FALSE
3 102 (DOH-Shafafiya) DEN-045 Diagnosis code not specific 3 (CODING) 4 (COD-DX-NOT-SPEC) MEDIUM TRUE FALSE
4 201 (Daman) DNMN Service not medically necessary per policy 4 (MEDNEC) 6 (MEDNEC-GUIDELINE) HIGH TRUE TRUE
5 202 (Oman Insurance) TF01 Claim submitted after time limit 5 (TIMELY) 7 (TIMELY-LATE-SUB) HIGH FALSE FALSE
6 101 R12 Duplicate claim 6 (DUP) 8 (BILL-DUP-SUB) MEDIUM FALSE FALSE

Data Governance

  • Owner: Denial Analyst Team Lead
  • Approval process:
  • New or changed payer codes identified from remittance files or payer circulars.
  • Analyst proposes mapping (category, root cause, severity).
  • Denial Manager reviews and approves.
  • HIS configuration team updates mapping table.
  • Update frequency: Monthly; plus within 5 working days of any payer circular from DHA, DOH, MOH, or private payers.
  • Change notification:
  • Email to denial team and billing.
  • Release notes in RCM change log.
  • For major changes, short training session.

Validation Rules

  • (payer_id, payer_code, effective_from) must be unique.
  • effective_to must be null or ≥ effective_from.
  • Only one active mapping per (payer_id, payer_code) at any given date.
  • standard_category_id must be active.
  • If is_appealable_default = FALSE, requires_clinical_appeal must be FALSE.
  • Severity must exist in MD-DEN-012.

MD-DEN-004: Appeal Letter Templates

Purpose

Standardised, bilingual templates for appeal letters, parameterised by payer, denial category, and appeal level. Used in WF-DEN-003 for automated letter generation and to ensure compliance with payer-specific formats (including DHA eClaimLink and DOH eClaims requirements).

Logical Table: appeal_letter_templates

Schema

Field Type Required Description
template_id INT YES (PK) Surrogate key
code VARCHAR(50) YES Template code (e.g., DAMAN-MEDNEC-L1)
payer_id INT YES (FK) FK → payers.payer_id (null for generic templates)
denial_category_id INT NO (FK) FK → denial_categories.category_id (null = generic)
appeal_level VARCHAR(20) YES Level1, Level2, External
language VARCHAR(5) YES en, ar, bi (bilingual)
subject_en VARCHAR(200) NO Email/letter subject (EN)
subject_ar VARCHAR(200) NO Subject (AR)
body_template_en TEXT NO English body with placeholders (e.g., {{patient_name}})
body_template_ar TEXT NO Arabic body with placeholders
is_default_for_payer BOOLEAN YES If this is default for payer/category/level
is_active BOOLEAN YES Active flag
created_at DATETIME YES Audit
created_by INT YES FK → users.user_id
updated_at DATETIME YES Audit
updated_by INT YES FK → users.user_id

Sample Data (abbreviated bodies)

template_id code payer_id denial_category_id appeal_level language subject_en is_default_for_payer
1 DHA-MEDNEC-L1-BI 101 (DHA) 4 (MEDNEC) Level1 bi First Level Appeal – Medical Necessity TRUE
2 DOH-CODING-L1-EN 102 (DOH) 3 (CODING) Level1 en Coding Denial Appeal TRUE
3 DAMAN-ELIG-L1-BI 201 (Daman) 1 (ELIG) Level1 bi Eligibility Denial Appeal TRUE
4 GENERIC-TIMELY-L1-EN NULL 5 (TIMELY) Level1 en Timely Filing Appeal TRUE
5 GENERIC-ADMIN-L1-EN NULL 8 (ADMIN) Level1 en Administrative Denial Appeal TRUE

Example body_template_en (for DHA-MEDNEC-L1-BI):

Dear Sir/Madam,
We are submitting an appeal for claim {{claim_number}} for patient {{patient_name}} (Emirates ID {{emirates_id}}) treated at {{facility_name}} on {{service_date}}. The service {{service_description}} was denied for medical necessity. Based on DHA guidelines and attached clinical documentation, we request reconsideration…

Data Governance

  • Owner: Denial Manager
  • Approval process:
  • Draft prepared by Denial Analyst with input from Coding Specialist and Physician Advisor (for clinical appeals).
  • Legal/compliance review for UAE PDPL and payer-specific wording.
  • Final approval by Revenue Cycle Manager.
  • Update frequency: Quarterly review; immediate update when payer format requirements change.
  • Change notification:
  • Updated templates communicated to denial team.
  • Old templates retired (set is_active = FALSE).

Validation Rules

  • code unique.
  • For each (payer_id, denial_category_id, appeal_level, language) there must be at most one is_default_for_payer = TRUE.
  • If language = 'bi', both body_template_en and body_template_ar must be populated.
  • Template bodies must not contain hard-coded PHI; only placeholders.
  • Placeholders must be from approved list (e.g., {{patient_name}}, {{emirates_id}}, {{claim_number}}, {{denied_amount}}).

MD-DEN-005: Appeal Deadline Rules

Purpose

Defines payer-specific deadlines for filing appeals, by claim type and denial type, based on contract terms. Used to:

  • Start and track appeal clock in WF-DEN-001
  • Calculate “Days remaining to appeal” on worklists
  • Identify expired appeal opportunities

Logical Table: appeal_deadline_rules

Schema

Field Type Required Description
rule_id INT YES (PK) Surrogate key
payer_id INT YES (FK) FK → payers.payer_id
claim_type VARCHAR(20) YES IP, OP, ER, PHARMACY, etc.
denial_category_id INT NO (FK) FK → denial_categories.category_id (null = all)
appeal_level VARCHAR(20) YES Level1, Level2, External
days_to_file INT YES Number of calendar days from denial date
source_reference VARCHAR(200) NO Contract clause or payer policy reference
effective_from DATE YES Start date
effective_to DATE NO End date (null = current)
is_active BOOLEAN YES Active flag
created_at DATETIME YES Audit
created_by INT YES FK → users.user_id
updated_at DATETIME YES Audit
updated_by INT YES FK → users.user_id

Sample Data

rule_id payer_id claim_type denial_category_id appeal_level days_to_file source_reference
1 101 (DHA) IP NULL Level1 30 DHA eClaimLink Policy v4.0 – Section 6
2 101 OP NULL Level1 15 DHA eClaimLink Policy v4.0 – Section 6
3 102 (DOH) IP NULL Level1 30 DOH Shafafiya Manual – Appeals
4 201 (Daman) IP 4 (MEDNEC) Level1 60 Daman Contract 2025 – Clause 8.2
5 201 IP 4 (MEDNEC) Level2 90 Daman Contract 2025 – Clause 8.3

Data Governance

  • Owner: Denial Manager
  • Approval process:
  • Contract Manager provides updated contract terms from policy-contract-mgmt.
  • Denial Manager translates into rules (per claim type/category).
  • Revenue Cycle Manager approves.
  • Update frequency: On contract renewal or amendment; at least annual review.
  • Change notification:
  • Updated rules communicated to denial team.
  • System recalculates appeal deadlines for new denials only (historic denials unaffected unless explicitly reprocessed).

Validation Rules

  • (payer_id, claim_type, denial_category_id, appeal_level, effective_from) must be unique.
  • days_to_file > 0.
  • Only one active rule per (payer_id, claim_type, denial_category_id, appeal_level) at a given date.
  • If denial_category_id is null, rule applies as default; category-specific rules override default.

MD-DEN-006: Write-Off Approval Thresholds

Purpose

Defines financial thresholds and required approval levels for writing off denied amounts. Used in:

  • denial_records.resolution_type = 'write_off'
  • Workflow routing for approvals (Denial Manager, Finance Director, CFO).

Logical Table: writeoff_approval_thresholds

Schema

Field Type Required Description
threshold_id INT YES (PK) Surrogate key
code VARCHAR(30) YES Threshold code (e.g., WO-LOW, WO-HIGH)
min_amount DECIMAL(18,2) YES Inclusive lower bound (AED)
max_amount DECIMAL(18,2) NO Inclusive upper bound (AED), null = no upper limit
required_approver_role VARCHAR(100) YES Role name (e.g., Denial Manager, Finance Director, CFO)
description_en VARCHAR(300) NO English description
description_ar VARCHAR(300) NO Arabic description
is_active BOOLEAN YES Active flag
created_at DATETIME YES Audit
created_by INT YES FK → users.user_id
updated_at DATETIME YES Audit
updated_by INT YES FK → users.user_id

Sample Data

threshold_id code min_amount max_amount required_approver_role description_en
1 WO-LOW 0.00 999.99 Denial Manager Denials up to AED 1,000 can be approved by Denial Manager.
2 WO-MED 1000.00 9999.99 Finance Director Denials between AED 1,000 and AED 10,000 require Finance Director approval.
3 WO-HIGH 10000.00 NULL CFO Denials above AED 10,000 require CFO approval.

Data Governance

  • Owner: Finance Director
  • Approval process:
  • Proposed by Finance team based on risk appetite and audit requirements.
  • Approved by CFO / Finance Committee.
  • Update frequency: Annual or on policy change.
  • Change notification:
  • Communicated to Denial Manager and Revenue Cycle Manager.
  • Internal finance policy documents updated.

Validation Rules

  • Threshold ranges must be continuous and non-overlapping.
  • min_amount ≥ 0; if max_amount not null then max_amount > min_amount.
  • required_approver_role must match a defined role in users/roles module.
  • At least one active threshold must exist.

MD-DEN-007: Denial Status Codes

Purpose

Standard set of statuses for denial lifecycle, used in denial_records.status and worklists.

Logical Table: denial_status_master

Schema

Field Type Required Description
status_code VARCHAR(30) YES (PK) Unique status code (e.g., NEW, IN_REVIEW)
display_name_en VARCHAR(100) YES English label
display_name_ar VARCHAR(100) YES Arabic label
is_terminal BOOLEAN YES Indicates final state (e.g., CLOSED, WRITTEN_OFF)
description_en VARCHAR(300) NO Description
description_ar VARCHAR(300) NO Description
sort_order INT NO UI ordering
is_active BOOLEAN YES Active flag

Sample Data

status_code display_name_en display_name_ar is_terminal sort_order
NEW New جديد FALSE 10
ASSIGNED Assigned مُسند FALSE 20
IN_REVIEW Under Review قيد المراجعة FALSE 30
PENDING_INFO Pending Info بانتظار المعلومات FALSE 40
APPEAL_IN_PROGRESS Appeal in Progress استئناف قيد الإجراء FALSE 50
RESOLVED_RECOVERED Resolved – Recovered تم الحل – تم التحصيل TRUE 60
RESOLVED_WRITE_OFF Resolved – Written Off تم الحل – شطب TRUE 70
RESOLVED_NO_ACTION Resolved – No Further Action تم الحل – لا إجراء إضافي TRUE 80

Governance & Validation

  • Owner: Denial Manager; annual review.
  • Status codes are controlled; no free-text.
  • At least one non-terminal and one terminal status must be active.
  • Denials in terminal status cannot revert to non-terminal without supervisor override.

MD-DEN-008: Appeal Status Codes

Purpose

Standard statuses for appeal lifecycle, used in appeals.status.

Logical Table: appeal_status_master

Schema

Field Type Required Description
status_code VARCHAR(30) YES (PK) e.g., DRAFT, SUBMITTED, UNDER_REVIEW, OVER_TURNED
display_name_en VARCHAR(100) YES English label
display_name_ar VARCHAR(100) YES Arabic label
is_terminal BOOLEAN YES Final state flag
description_en VARCHAR(300) NO Description
description_ar VARCHAR(300) NO Description
sort_order INT NO UI ordering
is_active BOOLEAN YES Active flag

Sample Data

status_code display_name_en display_name_ar is_terminal sort_order
DRAFT Draft مسودة FALSE 10
SUBMITTED Submitted تم الإرسال FALSE 20
ACKNOWLEDGED Acknowledged by Payer تم الاستلام من شركة التأمين FALSE 30
UNDER_REVIEW Under Review قيد الدراسة FALSE 40
ADDITIONAL_INFO Additional Info Requested معلومات إضافية مطلوبة FALSE 50
OVER_TURNED Overturned تم قبول الاستئناف TRUE 60
UPHELD Upheld تم رفض الاستئناف TRUE 70
PARTIAL Partially Overturned قبول جزئي للاستئناف TRUE 80
WITHDRAWN Withdrawn تم سحب الاستئناف TRUE 90

Governance & Validation

  • Owner: Denial Manager.
  • Only terminal statuses allowed when linking to appeal_outcomes.
  • Appeals in terminal status cannot be edited except by Senior Denial Analyst.

MD-DEN-009: Denial Action Types (Prevention Actions)

Purpose

Standardises types of prevention actions used in denial_prevention_actions.action_type (WF-DEN-005).

Logical Table: denial_action_type_master

Schema

Field Type Required Description
action_type_code VARCHAR(30) YES (PK) e.g., TRAINING, SYSTEM_RULE, PROCESS_CHANGE
display_name_en VARCHAR(100) YES English label
display_name_ar VARCHAR(100) YES Arabic label
description_en VARCHAR(300) NO Description
description_ar VARCHAR(300) NO Description
is_active BOOLEAN YES Active flag
sort_order INT NO UI ordering

Sample Data

action_type_code display_name_en display_name_ar
TRAINING Staff Training تدريب الموظفين
SYSTEM_RULE System Rule / Edit قاعدة / تنبيه في النظام
PROCESS_CHANGE Process Change تغيير في الإجراءات
CHECKLIST Checklist / Form Update تحديث النماذج / قوائم التحقق
PAYER_DISCUSSION Payer Discussion / Escalation مناقشة / تصعيد مع شركة التأمين

MD-DEN-010: Responsible Department / Function Codes

Purpose

Standard codes for departments/functions accountable for denials and prevention actions. Used in:

  • denial_categories.responsible_department_code
  • denial_root_cause_master.responsible_department_code
  • denial_prevention_actions.responsible_party

Logical Table: denial_responsible_department_master

Schema

Field Type Required Description
department_code VARCHAR(50) YES (PK) e.g., PATIENT_ACCESS, CODING
display_name_en VARCHAR(100) YES English name
display_name_ar VARCHAR(100) YES Arabic name
description_en VARCHAR(300) NO Description
description_ar VARCHAR(300) NO Description
is_active BOOLEAN YES Active flag
sort_order INT NO UI ordering

Sample Data

department_code display_name_en display_name_ar
PATIENT_ACCESS Patient Access / Registration قسم التسجيل واستقبال المرضى
CODING Coding Department قسم الترميز الطبي
BILLING Billing قسم الفوترة
CLINICAL Clinical Services الخدمات السريرية
RCM_ADMIN Revenue Cycle Administration إدارة دورة الإيرادات

MD-DEN-011: Submission Channels & Methods (Appeals)

Purpose

Defines allowed submission methods and channels for appeals, used in appeals.submission_method and appeals.submission_channel (WF-DEN-003).

Logical Tables:

  • appeal_submission_method_master
  • appeal_submission_channel_master

Schema – Methods

Field Type Required Description
method_code VARCHAR(30) YES (PK) e.g., PORTAL, EMAIL, API
display_name_en VARCHAR(100) YES English label
display_name_ar VARCHAR(100) YES Arabic label
is_active BOOLEAN YES Active flag

Sample Data – Methods

method_code display_name_en display_name_ar
PORTAL Web Portal بوابة إلكترونية
EMAIL Email بريد إلكتروني
FAX Fax فاكس
API API Integration تكامل عبر واجهة برمجة التطبيقات

Schema – Channels

Field Type Required Description
channel_code VARCHAR(30) YES (PK) e.g., DHA_ECLAIM, DOH_ECLAIM, PAYER_PORTAL
display_name_en VARCHAR(100) YES English label
display_name_ar VARCHAR(100) YES Arabic label
payer_id INT NO (FK) FK → payers.payer_id (null = generic)
api_endpoint VARCHAR(255) NO For API-based channels
is_active BOOLEAN YES Active flag

Sample Data – Channels

channel_code display_name_en display_name_ar payer_id
DHA_ECLAIM DHA eClaimLink منصة مطالبات هيئة الصحة بدبي 101
DOH_ECLAIM DOH eClaims / Shafafiya منصة مطالبات دائرة الصحة أبوظبي 102
PAYER_PORTAL Payer Web Portal بوابة شركة التأمين NULL
EMAIL_SUBMIT Email Submission إرسال عبر البريد الإلكتروني NULL

MD-DEN-012: Payer Denial Severity Levels

Purpose

Standard severity levels used to prioritise denials and for scorecards. Used in:

  • denial_code_mapping.severity_level_code
  • Dashboards and worklist sorting.

Logical Table: denial_severity_level_master

Schema

Field Type Required Description
severity_level_code VARCHAR(20) YES (PK) e.g., HIGH, MEDIUM, LOW
display_name_en VARCHAR(50) YES English label
display_name_ar VARCHAR(50) YES Arabic label
priority_weight INT YES Numeric weight (higher = more urgent)
description_en VARCHAR(200) NO Description
description_ar VARCHAR(200) NO Description
is_active BOOLEAN YES Active flag

Sample Data

severity_level_code display_name_en display_name_ar priority_weight
HIGH High عالي 100
MEDIUM Medium متوسط 50
LOW Low منخفض 10

Configuration Parameters

Parameter Type Default Description Governance
max_denial_results_per_search Integer 100 Maximum denials returned in a single worklist search to protect performance. System Admin (with Denial Manager input)
default_denial_sort_order String severity, appeal_deadline, denied_amount DESC Default sort order for Denial Worklist (SCR-DEN-001). Denial Manager
auto_assign_by_payer Boolean true If true, new denials are auto-assigned based on payer/category routing rules. Denial Manager
auto_categorize_from_mapping Boolean true If true, system uses MD-DEN-003 to auto-assign category/root cause. Denial Manager
appeal_deadline_warning_days Integer 5 Number of days before deadline when denials are flagged as “At Risk”. Denial Manager
max_appeals_per_denial Integer 3 Maximum number of appeal records allowed per denial. Denial Manager
default_appeal_followup_days Integer 15 Default days after submission to set follow-up date if payer-specific SLA not configured. Denial Manager
enable_payer_severity_weighting Boolean true If true, severity weights (MD-DEN-012) affect worklist priority. Denial Manager
writeoff_requires_reason_comment Boolean true If true, user must enter comment when resolution_type = write_off. Finance Director
export_default_format String CSV Default export format for denial analytics (CSV/Excel/JSON). System Admin
pdpl_data_retention_years Integer 7 Retention period for denial and appeal records, aligned with UAE PDPL and facility policy. Data Protection Officer / Compliance

Data Load Procedures

1. Initial Load

Sources

  • Payer denial code lists from:
  • DHA eClaimLink documentation (Dubai)
  • DOH eClaims / Shafafiya documentation (Abu Dhabi)
  • Private payers (Daman, Oman Insurance, etc.)
  • Existing spreadsheets/logs used by denial team.
  • Facility finance and RCM policies (write-off thresholds).
  • Contracts from policy-contract-mgmt (for appeal deadlines).

Process

  1. Foundation sets (MD-DEN-010, MD-DEN-001, MD-DEN-007, MD-DEN-008, MD-DEN-009, MD-DEN-012, MD-DEN-011): - Prepared in CSV templates. - Reviewed by Denial Manager and uploaded via admin UI or ETL.
  2. Root Cause Classification (MD-DEN-002): - Workshop with Denial Analysts, Coding, Patient Access, Billing. - Map existing free-text reasons to standard codes.
  3. Appeal Deadline Rules (MD-DEN-005): - Contract Manager extracts terms into structured spreadsheet. - Denial Manager validates and imports.
  4. Denial Code Mapping (MD-DEN-003): - Import payer code lists (CSV/Excel). - Map each code to category and root cause; unresolved codes flagged for manual mapping.
  5. Appeal Letter Templates (MD-DEN-004): - Draft templates in HTML/Markdown with placeholders. - Load via admin UI or JSON import.

Formats

  • CSV for bulk master data:
  • UTF-8, comma-separated, header row.
  • Bilingual fields as separate columns (display_name_en, display_name_ar).
  • JSON for complex fields (e.g., template bodies) when using API-based import.

2. Ongoing Synchronisation

  • Payer code updates:
  • Monthly job to ingest new denial codes from eClaimLink / Shafafiya APIs or uploaded files.
  • Unmapped codes placed in “staging” table for analyst review.
  • Contract changes:
  • Integration with policy-contract-mgmt to notify when contracts updated.
  • Denial Manager reviews and updates MD-DEN-005.
  • Template updates:
  • Managed manually via admin UI with versioning.

3. Validation on Import

For each dataset:

  • Structural validation:
  • Required columns present.
  • Data types correct (e.g., integers for days_to_file, decimals for amounts).
  • Referential validation:
  • FKs (payer_id, denial_category_id, root_cause_id, department_code) must exist and be active.
  • Business rules:
  • No overlapping date ranges for rules/mappings.
  • Unique constraints (e.g., codes, composite keys) enforced.
  • PDPL considerations:
  • Master data sets do not contain direct patient identifiers.
  • Import logs must not include PHI; only configuration values.

4. Import/Export Interfaces

  • Admin UI:
  • For Denial Manager and System Admin to upload CSV files and manage templates.
  • Internal API (JSON):
  • For integration with billing-claims and policy-contract-mgmt to fetch mappings and deadlines.
  • Export:
  • CSV/Excel exports of master data for audit and governance reviews.
  • Access controlled via roles; exports logged for PDPL compliance.

This specification provides the master data and configuration foundation required for the Denial Analysis module to support automated categorisation, appeal management, prevention planning, and UAE-specific payer integrations.

content/rcm/denial-analysis/06-master-data.md Generated 2026-02-20 22:54