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.
Load Sequence (narrative):
- Responsible Department / Function Codes (MD-DEN-010) – foundation for assigning accountability.
- Denial Category Taxonomy (MD-DEN-001) – core classification used by all other datasets.
- Root Cause Classification (MD-DEN-002) – references categories and departments.
- Denial Action Types (MD-DEN-009) – used in prevention actions, linked to categories/root causes.
- Denial Status Codes (MD-DEN-007) – used in
denial_records.status. - Appeal Status Codes (MD-DEN-008) – used in
appeals.status. - Payer Denial Severity Levels (MD-DEN-012) – used for prioritisation and dashboards.
- Submission Channels & Methods (MD-DEN-011) – used in
appeals.submission_methodandsubmission_channel. - Appeal Letter Templates (MD-DEN-004) – depend on categories and submission channels.
- Appeal Deadline Rules (MD-DEN-005) – depend on payers and contracts (from
policy-contract-mgmt). - Denial Code Mapping (MD-DEN-003) – depends on payer lists and denial categories.
- 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
codemust be unique, uppercase alphanumeric with_allowed; length 2–20.display_name_enanddisplay_name_armust not be null or empty.category_groupmust 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_recordscannot be hard-deleted; onlyis_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_causestable- 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
codeunique; pattern<CATEGORY>-<SHORT-DESCRIPTOR>recommended.denial_category_idmust reference an active category.process_failure_pointmust be from controlled list.responsible_department_codemust exist and be active.- Root causes referenced in
denial_root_causescannot 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_tomust be null or ≥effective_from.- Only one active mapping per
(payer_id, payer_code)at any given date. standard_category_idmust be active.- If
is_appealable_default = FALSE,requires_clinical_appealmust 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
codeunique.- For each
(payer_id, denial_category_id, appeal_level, language)there must be at most oneis_default_for_payer = TRUE. - If
language = 'bi', bothbody_template_enandbody_template_armust 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_idis 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; ifmax_amountnot null thenmax_amount>min_amount.required_approver_rolemust match a defined role inusers/rolesmodule.- 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_codedenial_root_cause_master.responsible_department_codedenial_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_masterappeal_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 | بوابة إلكترونية |
| بريد إلكتروني | ||
| 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
- 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.
- Root Cause Classification (MD-DEN-002): - Workshop with Denial Analysts, Coding, Patient Access, Billing. - Map existing free-text reasons to standard codes.
- Appeal Deadline Rules (MD-DEN-005): - Contract Manager extracts terms into structured spreadsheet. - Denial Manager validates and imports.
- 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.
- 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-mgmtto 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-claimsandpolicy-contract-mgmtto 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.