Denial Analysis Workflows

This document defines six core workflows for the Denial Analysis module of the Gates Group HIS. The module supports UAE revenue cycle operations by digitising denial intake, root cause analysis, appeals, prevention planning, and payer performance monitoring.

Regulatory context (UAE):
- UAE PDPL (Federal Decree-Law No. 45/2021): governs processing of patient and payer-related personal data in denial analytics and reporting.
- DHA eClaimLink / DOH eClaims (Shafafiya): define electronic claim and appeal formats and timelines for Dubai and Abu Dhabi.
- MOH / DOH / DHA: oversight of billing practices, clinical documentation standards, and auditability of write-offs and appeals.
- NABIDH / Malaffi: clinical data sources that may be referenced for medical necessity appeals (via other modules).

All workflows assume strict role-based access control (RBAC) and audit logging in line with UAE PDPL and local health authority policies.

WF-DENIALANALYSIS-001: Denial Receipt & Categorization (WF-DEN-001)

Process Flow

Actor: System (automated), Denial Analyst
Trigger: Claim denied or partially denied during payment posting in billing-claims

Pre-conditions:

• Claim exists in billing-claims.claims and is linked to:
• patients.patient_id (from ehr-patient-mgmt)
• payers.payer_id (from policy-contract-mgmt)
• Payment posting process has received denial information from payer (eClaimLink / DOH eClaims / other).
• Payer-specific denial code mapping is configured in denial_categories / mapping tables.

Steps:

1. System receives denial feed from billing-claims when a claim (e.g., Claim #DXB-2026-000234) is posted with a denial or partial denial status.
2. System validates inbound data: - Confirms claim_id exists. - Confirms patient_id, payer_id, facility_id are present. - Confirms denied amount > 0.
3. System creates a new record in denial_records with: - claim_id, claim_line_id (if line-level denial), - patient_id, payer_id, facility_id, - denial_date (from payer remittance), - denial_code and denial_description, - denied_amount and initial status = 'NEW'.
4. System auto-maps payer denial code to internal denial_category_id using the Denial Code Mapping master data: - Example categories: Eligibility, Authorization, Coding, Medical Necessity, Timely Filing, Duplicate, Bundling.
5. System calculates financial impact: - Stores denied_amount, - Optionally calculates estimated patient_impact_amount (if patient liability increases) and stores in extended fields.
6. System determines whether denial is header-level (entire claim) or line-level and sets appropriate flags in denial_records.
7. System assigns the denial to a Denial Analyst: - Uses routing rules based on denial_category_id, payer_id, facility_id, and workload. - Updates assigned_analyst_id and status = 'ASSIGNED'.
8. System calculates appeal deadline: - Queries Appeal Deadline Rules master data (from contracts via policy-contract-mgmt), - Sets appeal_deadline_date in denial_records, - Starts internal “appeal clock” (days remaining).
9. System queues the denial for root cause analysis: - Adds to the analyst’s worklist (screen SCR-DEN-001), - Flags high-priority items (e.g., denied_amount > configured threshold, or appeal_deadline_date within X days).
10. Denial Analyst reviews the worklist, optionally adjusts priority, and confirms ownership of the denial.
11. System logs all actions in an internal audit log (table in this module or shared) including user, timestamp, and changes for PDPL accountability.
12. System notifies relevant stakeholders (optional configuration):
    • Email/notification to Denial Manager for large denials (e.g., > AED 50,000),
    • Dashboard widgets updated for real-time denial volume.

Data Modified:

• denial_records — INSERT (new denial), UPDATE (assignment, status, appeal_deadline_date, priority)
• denial_trends — UPDATE/INSERT (aggregated counters for period, payer, category)
• payer_denial_scorecards — UPDATE (incremental metrics, if near-real-time)
• Audit log table (module-level, e.g., denial_audit_log) — INSERT

Mermaid Flowchart

Decision Points

1. Validation success
   - If claim/patient/payer references are valid → proceed to create denial_records.
   - If invalid → do not create denial; log error and notify Denial Manager and Billing team for data correction.

2. Denial code mapping
   - If payer denial code is mapped → set denial_category_id and proceed.
   - If not mapped → set category to UNMAPPED, flag for manual categorization, and optionally route to Senior Denial Analyst.

3. Priority determination
   - If denied_amount ≥ configured high-value threshold OR appeal_deadline_date within X days → mark as high priority and notify Denial Manager.
   - Else → standard priority.

Integration Points

• Billing & Claims (billing-claims)
• Direction: Inbound
• Data: Claim denial details (claim status, denial codes, denied amounts, line-level info).
• Mechanism: Internal API / shared database (INT-DEN-001).

• Trigger: Payment posting sets claim to denied/partially denied.

• Policy & Contract Management (policy-contract-mgmt)

• Direction: Read
• Data: Appeal deadline rules per payer/contract.
• Mechanism: Internal API / shared database (INT-DEN-002).
• Trigger: Need to compute appeal_deadline_date.

Exception Handling

• Missing or invalid references (claim, patient, payer, facility):
• System does not create denial_records.
• Error logged with details (e.g., Claim #AUH-2026-001122, Emirates ID 784-1990-1234567-1).
• Notification sent to Billing Supervisor and Denial Manager.

• Once corrected in billing-claims, denial feed is resent or reprocessed.

• Unmapped denial codes:

• Denial created with denial_category_id = NULL and status = 'NEEDS_CATEGORY'.
• Added to a special “Unmapped Denials” queue for Denial Manager.

• Denial Code Mapping master data updated; system can retroactively re-categorise.

• Appeal deadline rule missing:

• System sets appeal_deadline_date to NULL and flags deadline_status = 'UNKNOWN'.
• Alert to Denial Manager and Contract Management team to configure rule.

• Denial remains in worklist but highlighted as “Deadline Unknown”.

• System / database error:

• Transaction rolled back; denial not created.
• Error logged with stack trace; IT support alerted.
• Billing-claims retains denial status and can re-trigger once resolved.

Paperless Transformation

Remaining Paper Touchpoints: None — fully digital for receipt and categorisation.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Denial record exists with status = 'ASSIGNED' and analyst ownership confirmed
• Internal denial category mapped from payer denial code
• Appeal deadline calculated and appeal clock started
• Denial visible on analyst worklist with priority flag
• Denial trends and scorecards updated with new denial data

SLA and Timing

State Transition Diagram

WF-DENIALANALYSIS-002: Root Cause Analysis (WF-DEN-002)

Process Flow

Actor: Denial Analyst, Denial Manager
Trigger: Denial categorized and assigned (status ASSIGNED in denial_records)

Pre-conditions:

• denial_records row exists with valid claim_id, payer_id, denied_amount.
• Denial assigned to an analyst (assigned_analyst_id not NULL).
• Analyst has view_denials and analyze_root_cause permissions.
• Access to claim, encounter, and contract details via:
• billing-claims (claim details),
• ehr-patient-mgmt (clinical context via other modules),
• policy-contract-mgmt (contract terms).

Steps:

1. Denial Analyst opens the Denial Worklist (SCR-DEN-001) and selects a denial with status ASSIGNED.
2. System loads Denial Detail & Root Cause screen (SCR-DEN-002) showing: - Claim header and line details (CPT, ICD-10-AM, charges), - Payer denial codes and narrative, - Patient demographics (e.g., Ahmed Al-Maktoum, Emirates ID 784-1985-1234567-2), - Encounter details (date of service, facility, provider).
3. Analyst reviews payer response and original claim submission, including any prior authorisation numbers and eligibility checks.
4. Analyst investigates process flow: - Front-end: registration, eligibility, authorisation (via patient-access and scheduling). - Mid-cycle: coding, documentation (via coding and clinical documentation modules). - Back-end: billing, claim submission timing and format (via billing-claims).
5. Analyst identifies the primary root cause category (e.g., “Front-end – Eligibility not verified”) and selects from the Root Cause Classification master data.
6. Analyst documents detailed root cause in denial_root_causes: - root_cause_category, root_cause_detail, - process_failure_point (e.g., “Pre-registration – insurance card not scanned”), - responsible_department (e.g., Patient Access, Coding, Billing), - identified_by (analyst user), identified_date.
7. System links denial_root_causes.root_cause_id back to denial_records.root_cause_id and updates is_preventable based on analyst input.
8. Analyst determines whether the denial is preventable: - If preventable → sets is_preventable = TRUE. - If non-preventable (e.g., payer policy change, benefit limit reached) → sets is_preventable = FALSE.
9. Analyst recommends next action: - Appeal (go to WF-DEN-003), - Corrected claim resubmission (via billing-claims), - Write-off (subject to approval thresholds), - No further action (e.g., non-appealable). Recommendation is recorded in denial_records.next_action.
10. System updates denial_records.status to:
    • READY_FOR_APPEAL, READY_FOR_RESUBMISSION, or PENDING_WRITE_OFF_REVIEW.
11. If the analyst identifies a systemic pattern (e.g., repeated eligibility denials for a specific clinic), they flag “Systemic Issue” in the UI.
12. System prompts creation of a denial_prevention_actions record (see WF-DEN-005) and pre-populates category, payer, and description.
13. Denial Manager periodically reviews root cause distributions and systemic flags via dashboards, ensuring alignment with DOH/DHA audit expectations.

Data Modified:

• denial_root_causes — INSERT (new root cause record)
• denial_records — UPDATE (root_cause_id, is_preventable, next_action, status, responsible_department)
• denial_prevention_actions — INSERT (if systemic issue flagged)
• denial_trends — UPDATE (root cause statistics)

Mermaid Flowchart

Decision Points

1. Preventable vs non-preventable
   - If preventable → flagged for prevention metrics and potential action planning.
   - If non-preventable → excluded from preventable denial KPIs.

2. Systemic pattern
   - If analyst flags systemic issue → auto-create denial_prevention_actions draft and notify Denial Manager.
   - If not systemic → no prevention action created.

3. Next action selection
   - If appeal recommended → denial routed to Appeal Management queue (WF-DEN-003).
   - If corrected claim resubmission → task sent to Billing team; status READY_FOR_RESUBMISSION.
   - If write-off → routed to Denial Manager/Finance for approval based on Write-Off Approval Thresholds.

Integration Points

• EHR / Clinical Modules (via ehr-patient-mgmt and others)
• Direction: Read
• Data: Clinical notes, orders, documentation supporting medical necessity.

• Used to determine if documentation gaps caused denial.

• Patient Access

• Direction: Read
• Data: Eligibility checks, authorisation records.

• Used to identify front-end failures.

• Billing & Claims (billing-claims)

• Direction: Read/Notify
• Data: Claim submission history, resubmission options.

• Used when recommending corrected claim resubmission.

• Policy & Contract Management (policy-contract-mgmt)

• Direction: Read
• Data: Contract terms, coverage rules.
• Used to distinguish payer policy denials from internal process failures.

Exception Handling

• Insufficient data to determine root cause:
• Analyst sets root_cause_category = 'UNKNOWN' and records notes.
• Denial flagged for escalation to Senior Denial Analyst.

• System tracks unresolved root causes for management review.

• Conflicting information between systems (e.g., eligibility verified in Patient Access but payer denies for eligibility):

• Analyst records discrepancy in denial_root_causes.
• System can tag denial for payer dispute and contract review.

• Data shared with Policy & Contract Management for future negotiations.

• User session timeout / unsaved changes:

• Auto-save draft root cause notes every X minutes.
• If session expires, user can resume from last draft without data loss.

Paperless Transformation

Remaining Paper Touchpoints: None — analysis and documentation are fully digital.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Root cause identified and documented with classification and detail
• Denial marked as preventable or non-preventable
• Next action determined (appeal, resubmission, write-off, no action)
• Denial status updated to reflect recommended action
• Systemic issues flagged and prevention action drafted if applicable

SLA and Timing

WF-DENIALANALYSIS-003: Appeal Preparation & Submission (WF-DEN-003)

Process Flow

Actor: Denial Analyst, Coding Specialist, Physician Advisor
Trigger: Root cause analysis recommends appeal (denial_records.next_action = 'APPEAL')

Pre-conditions:

• denial_records has:
• status = 'READY_FOR_APPEAL',
• appeal_deadline_date not passed.
• Required roles:
• Denial Analyst with prepare_appeals and submit_appeals,
• Coding Specialist (for coding-related denials),
• Physician Advisor (for medical necessity denials).
• Appeal templates and rules configured in master data:
• Appeal Letter Templates,
• Appeal Deadline Rules.

Steps:

1. Denial Analyst opens the Appeal Management screen (SCR-DEN-003) for a denial marked READY_FOR_APPEAL.
2. System displays: - Denial details and root cause, - Days remaining until appeal_deadline_date, - Suggested appeal level (e.g., first-level reconsideration) based on payer rules.
3. Analyst selects appeal level (first-level, second-level, external review) and confirms that the deadline has not passed.
4. System checks if additional clinical or coding support is required: - If denial category is Coding → prompts involvement of Coding Specialist. - If Medical Necessity → prompts Physician Advisor involvement.
5. Coding Specialist (if involved) reviews claim codes and: - Provides corrected CPT/ICD-10-AM codes and rationale, - Documents changes in the appeal record (not directly altering original claim yet).
6. Physician Advisor (if involved) drafts or uploads a letter of medical necessity, ensuring clinical justification aligns with UAE standards and payer policies.
7. Analyst selects appropriate appeal letter template (payer- and category-specific) from master data and merges: - Patient details (e.g., Fatima Al-Nahyan, Emirates ID 784-1992-7654321-3), - Claim and denial details, - Root cause explanation (if relevant), - Coding rationale and/or medical necessity narrative.
8. System assembles supporting documentation: - Clinical notes, lab results, imaging reports (via other modules), - Authorisation records, eligibility proofs, - Any prior correspondence with payer.
9. Analyst reviews the assembled appeal package and confirms submission method: - DHA eClaimLink (Dubai), - DOH eClaims / Shafafiya (Abu Dhabi), - Other payer portal or email/fax (if allowed).
10. System creates an appeals record with:
    • denial_id, appeal_level, submission_method, submission_channel,
    • supporting_docs references, appeal_letter_path,
    • status = 'DRAFT'.
11. Analyst submits the appeal:
    • For eClaimLink / DOH eClaims → system calls respective APIs (INT-DEN-004, INT-DEN-005) and receives tracking number.
    • For other methods → analyst records reference number manually.
12. System updates appeals:
    • Sets submission_date, status = 'SUBMITTED',
    • Stores tracking_number and submission_channel.
13. System sets follow_up_date based on payer-specific response timelines and adds the appeal to the follow-up queue (WF-DEN-004).
14. System updates denial_records.status = 'UNDER_APPEAL' and logs all actions for PDPL-compliant audit.

Data Modified:

• appeals — INSERT (new appeal), UPDATE (status, submission details, follow_up_date)
• denial_records — UPDATE (status = 'UNDER_APPEAL')
• appeal_outcomes — no change yet (created in WF-DEN-004)
• Audit log — INSERT

Mermaid Flowchart

Decision Points

1. Appeal deadline check
   - If current date > appeal_deadline_date → system prevents electronic appeal submission, flags denial for write-off review, and records reason.
   - If within deadline → proceed.

2. Support required
   - If coding-related → require Coding Specialist review before submission.
   - If medical necessity → require Physician Advisor letter.
   - Else → analyst may proceed alone.

3. Submission success
   - If eClaimLink / DOH eClaims API returns success → store tracking number and mark SUBMITTED.
   - If API fails → log error, allow retry, or switch to alternate submission channel (e.g., manual portal upload) with manual tracking number.

Integration Points

• Billing & Claims (billing-claims)
• Direction: Outbound (later)
• Data: Corrected codes and resubmission instructions when appeal involves corrected claims.

• Trigger: Successful appeal that requires resubmission.

• DHA eClaimLink (INT-DEN-004)

• Direction: Outbound / Inbound
• Data: Appeal submissions and tracking numbers; responses handled in WF-DEN-004.

• Protocol: REST API, eClaimLink appeal endpoints.

• DOH eClaims / Shafafiya (INT-DEN-005)

• Direction: Outbound / Inbound
• Data: Appeal submissions and tracking numbers.

• Protocol: DOH eClaims API.

• Clinical Data Sources (via other modules)

• Direction: Read
• Data: Clinical notes, lab results, imaging, authorisation records used as supporting documentation.

Exception Handling

• Appeal deadline passed:
• System blocks new appeal creation.
• Denial automatically routed to PENDING_WRITE_OFF_REVIEW.

• Denial Manager notified; reason recorded for audit.

• Missing required documentation:

• System validates required attachments based on denial category and payer rules.

• If missing → prevents submission and highlights missing items (e.g., “Medical necessity letter required”).

• API submission failure (eClaimLink / DOH eClaims):

• Error logged with response code.
• Appeal remains in DRAFT or SUBMISSION_FAILED status.

• Analyst can retry or switch to alternate channel (e.g., manual portal upload) and record external reference.

• PDPL considerations:

• Only minimum necessary patient data included in appeal package.
• Access to appeal documents restricted to authorised roles; all downloads logged.

Paperless Transformation

Remaining Paper Touchpoints: Some payers may still require physical documentation or signed letters; system should allow recording of such external submissions but core process is digital.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Appeal record created with tracking number from payer gateway
• Supporting documentation attached (clinical notes, corrected codes, necessity letter)
• Appeal submitted via appropriate channel (eClaimLink, DOH eClaims, or manual)
• Follow-up date set based on payer response timelines
• Denial status updated to UNDER_APPEAL

SLA and Timing

State Transition Diagram

WF-DENIALANALYSIS-004: Appeal Tracking & Resolution (WF-DEN-004)

Process Flow

Actor: Denial Analyst
Trigger: Appeal submitted, follow-up deadline reached, or payer response received

Pre-conditions:

• appeals record exists with status = 'SUBMITTED'.
• denial_records.status = 'UNDER_APPEAL'.
• Integration with eClaimLink / DOH eClaims active for applicable payers.

Steps:

1. System runs scheduled jobs to: - Check for appeals with follow_up_date <= today, - Poll payer APIs (eClaimLink / DOH eClaims) for status updates where supported.
2. System updates appeals.submission_status (e.g., UNDER_REVIEW, ADDITIONAL_INFO_REQUESTED, RESOLVED) based on payer responses.
3. Denial Analyst opens Appeal Management screen (SCR-DEN-003) to review appeals in the follow-up queue.
4. For appeals with ADDITIONAL_INFO_REQUESTED: - Analyst gathers requested documents or clarifications. - System allows uploading additional documents and resubmitting via API or portal. - appeals record updated with new submission date and notes.
5. For appeals with RESOLVED status: - System prompts analyst to record outcome in appeal_outcomes:
   • payer_decision (Overturned, Upheld, Partial),
   • response_date, recovered_amount, adjustment_code, notes.
6. Analyst verifies payment posting in billing-claims for overturned or partial decisions: - Confirms that recovered amount matches payer decision. - If mismatch → flags discrepancy for Billing team.
7. System updates denial_records: - resolution_type (Recovered, Partial Recovery, Write-off, No Action), - resolution_date, - recovered_amount, - status = 'CLOSED' (if no further appeal planned) or status = 'READY_FOR_NEXT_APPEAL_LEVEL'.
8. If payer decision is Upheld and further appeal is warranted: - Analyst updates denial_records.next_action = 'SECOND_LEVEL_APPEAL'. - Denial returns to WF-DEN-003 for higher-level appeal.
9. If payer decision is Upheld and no further appeal: - Denial may be routed to write-off workflow (outside this module) based on finance policy.
10. System updates denial_trends and payer_denial_scorecards:
    • Increments counts for appeals, success rates, average resolution time.
11. System logs all actions and maintains a complete appeal history for each denial.

Data Modified:

• appeals — UPDATE (status, submission_status, notes)
• appeal_outcomes — INSERT (new outcome record)
• denial_records — UPDATE (status, resolution_type, resolution_date, recovered_amount, next_action)
• denial_trends — UPDATE
• payer_denial_scorecards — UPDATE

Mermaid Flowchart

Decision Points

1. Additional information requested
   - If yes → analyst must provide requested documents; appeal remains open.
   - If no → proceed to outcome handling.

2. Payer decision
   - Overturned / Partial → verify payment and record recovery.
   - Upheld → decide on further appeal vs write-off.

3. Further appeal
   - If further appeal justified (based on contract, amount, and internal policy) → route back to WF-DEN-003 at higher level.
   - If not → close denial and route to write-off if applicable.

Integration Points

• DHA eClaimLink / DOH eClaims
• Direction: Bidirectional
• Data: Appeal status updates, final decisions.

• Trigger: Scheduled polling or webhook callbacks.

• Billing & Claims (billing-claims)

• Direction: Read
• Data: Payment postings for recovered amounts.
• Used to validate recovered_amount and update denial resolution.

Exception Handling

• No response from payer within expected timeframe:
• System flags appeal as “Overdue”.
• Analyst prompted to follow up via phone/email and record contact attempts.

• Follow-up notes stored in appeals or related notes table.

• Mismatch between payer decision and payment:

• Analyst records discrepancy in appeal_outcomes.notes.
• Denial flagged for Billing team investigation.

• Status may remain open until resolved.

• API polling failure:

• System logs error and retries with backoff.
• If persistent, alerts IT and Denial Manager; analysts can manually update status from payer portals.

Paperless Transformation

Remaining Paper Touchpoints: Some payers may still send paper decision letters; these can be scanned and attached to the appeal record.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Appeal outcome recorded with payer decision and financial impact
• Denial resolved with final status (RECOVERED, WRITE_OFF_APPROVED, CLOSED)
• Payment recovery verified against billing postings
• Denial trends and payer scorecards updated with outcome data
• If further appeal warranted, denial routed back to WF-003

SLA and Timing

WF-DENIALANALYSIS-005: Denial Prevention Action Planning (WF-DEN-005)

Process Flow

Actor: Denial Manager, Revenue Cycle Manager, Department Heads
Trigger: Trend analysis identifies recurring denial pattern (via dashboards or systemic flags from WF-DEN-002)

Pre-conditions:

• denial_trends populated with historical data by period, payer, category, department.
• Root cause data available in denial_root_causes.
• Denial Manager has configure_rules, create_prevention_plans, and view_analytics permissions.

Steps:

1. Denial Manager opens the Denial Trend Dashboard (SCR-DEN-004) and filters by period (e.g., last quarter), payer, and category.
2. System displays: - Denial rate trends, - Top denial reasons, - Financial impact by category, department, provider.
3. Manager identifies a significant recurring pattern (e.g., high eligibility denials for outpatient radiology in Dubai).
4. System allows drill-down to underlying denials and root causes to confirm pattern and quantify impact (denial count, denied amount, preventable proportion).
5. Manager decides to initiate a prevention action and opens the Prevention Action Tracker (SCR-DEN-006).
6. System pre-populates a new denial_prevention_actions record with: - denial_category_id, payer_id (if payer-specific), - Baseline pre_intervention_rate from denial_trends, - Description template.
7. Manager defines the action: - action_type (e.g., Training, Process Change, System Configuration, Payer Escalation), - Detailed description, - responsible_party (e.g., Patient Access Manager), - target_date.
8. System sets status = 'PLANNED' and notifies the responsible party and relevant Department Head.
9. Responsible party implements the action (outside system, e.g., training sessions, workflow changes, new eligibility checks).
10. Once implemented, responsible party updates the action in the system:
    • Sets completion_date,
    • Changes status = 'COMPLETED',
    • Adds implementation notes.
11. After a defined monitoring period, System recalculates:
    • post_intervention_rate from denial_trends,
    • ROI using KPI formula: (reduction_in_denied_amount - implementation_cost) / implementation_cost * 100.
12. Manager reviews results on the dashboard:
    • If effective → marks action as SUCCESSFUL.
    • If not → marks as INEFFECTIVE and may plan additional actions.
13. System stores all prevention actions and outcomes for continuous improvement and for demonstrating compliance and proactive management to DOH/DHA/MOH auditors.

Data Modified:

• denial_prevention_actions — INSERT (new actions), UPDATE (status, dates, rates, ROI)
• denial_trends — UPDATE (post-intervention metrics)
• Possibly a prevention_action_notes table — INSERT

Mermaid Flowchart

Decision Points

1. Pattern significance and preventability
   - If pattern is minor or non-preventable → no action created; monitored only.
   - If significant and preventable → prevention action initiated.

2. Effectiveness of intervention
   - If post-intervention denial rate and denied amount decrease as targeted → action marked SUCCESSFUL.
   - If not → action marked INEFFECTIVE and may trigger additional interventions.

Integration Points

• All RCM modules
• Direction: Outbound (conceptual)
• Data: Prevention actions may require changes in Patient Access, Coding, Billing, or Contract Management workflows.

• Trigger: Implementation of process changes (e.g., new eligibility checks, coding guidelines).

• Policy & Contract Management

• Direction: Outbound
• Data: Denial patterns and prevention actions may inform contract renegotiations.

Exception Handling

• Insufficient data to measure impact:
• If monitoring period too short or volume too low, system flags “Insufficient data”.

• Manager can extend monitoring period or adjust evaluation criteria.

• Action not implemented by target date:

• System sends reminders to responsible party and escalates to Denial Manager / Revenue Cycle Manager.

• status remains PLANNED with overdue flag.

• Incorrect configuration of action parameters:

• Manager can edit action details; system logs all changes for audit.

Paperless Transformation

Remaining Paper Touchpoints: None — planning and tracking are fully digital; some training materials may still be printed but are outside the HIS scope.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Prevention action created with clear owner, target date, and baseline metrics
• Responsible party notified and action tracked in system
• Post-intervention rates measured after monitoring period
• Action effectiveness assessed (SUCCESSFUL or INEFFECTIVE)

SLA and Timing

WF-DENIALANALYSIS-006: Payer Denial Scorecard Generation (WF-DEN-006)

Process Flow

Actor: Denial Manager, Revenue Cycle Manager
Trigger: Monthly/quarterly reporting cycle or on-demand payer performance review

Pre-conditions:

• denial_records, appeals, appeal_outcomes, and denial_trends populated for the reporting period.
• payer_denial_scorecards table available.
• Access to payer master data from policy-contract-mgmt.

Steps:

1. Denial Manager opens the Payer Scorecard screen (SCR-DEN-005) and selects reporting period (e.g., Q1 2026) and facilities (e.g., Dubai and Abu Dhabi hospitals).
2. System aggregates data by payer: - total_claims (from billing-claims), - total_denials and denial_rate, - total_denied_amount, - total_recovered from appeal_outcomes.
3. System calculates payer-specific metrics: - Denial rate by category (eligibility, coding, etc.), - Appeal rate and appeal success rate, - Average appeal resolution time, - Preventable denial proportion.
4. System writes or updates payer_denial_scorecards rows for each payer: - payer_id, period_start, period_end, - Calculated metrics and rank based on denial impact.
5. Manager reviews payer ranking and can: - Filter by payer type (e.g., THIQA, Daman, Oman Insurance), - Drill down into specific denial categories or departments.
6. System allows exporting scorecards to PDF/Excel for sharing with Contract Management and leadership.
7. Revenue Cycle Manager uses scorecards in strategic meetings: - Identifies payers with high denial rates or low appeal success, - Prepares talking points for contract renegotiations.
8. System can generate summary reports highlighting: - Top 5 payers by denied amount, - Payers with improving or worsening trends, - Recommendations for contract clauses or operational changes.
9. Manager may annotate scorecards with comments (e.g., “Daman – discuss timely filing window extension”) stored in the system.
10. System archives historical scorecards for trend analysis over multiple periods.

Data Modified:

• payer_denial_scorecards — INSERT/UPDATE (per payer per period)
• denial_trends — READ (no change)
• Optional scorecard_notes table — INSERT

Mermaid Flowchart

Decision Points

1. Drill-down requirement
   - If manager needs more detail → drill-down to category/department/provider level.
   - If not → use high-level scorecard.

2. Payer ranking criteria
   - Default ranking by total denied amount; manager can switch to denial rate or preventable denial rate.

Integration Points

• Billing & Claims (billing-claims)
• Direction: Read

• Data: Total claims submitted per payer and period.

• Policy & Contract Management (policy-contract-mgmt)

• Direction: Read / Outbound
• Data: Payer master data and contract details; scorecards shared for renegotiation planning (INT-DEN-002).

Exception Handling

• Incomplete data for period:
• System warns if payment posting or denial data is incomplete (e.g., month still open).

• Manager can proceed with partial data (flagged) or wait until period close.

• Payer master data mismatch:

• If payer_id in denials not found in payer master → flagged as data quality issue.
• Denial Manager and Master Data team notified to correct mapping.

Paperless Transformation

Remaining Paper Touchpoints: Some leadership meetings may still use printed scorecard summaries, but source data and generation are fully digital.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Payer scorecards generated and stored for the reporting period
• Payer ranking calculated based on denial impact
• Scorecards available for drill-down, export, and sharing
• Historical scorecards archived for trend analysis across periods

SLA and Timing