Billing & Claims Management Workflows

This document defines seven core workflows for the Billing & Claims Management (billing-claims) module. Each workflow includes process steps, actors, decision points, integration hooks, exception handling, and the paperless transformation achieved by the HIS.

Regulatory context: All workflows must comply with UAE Federal Decree-Law No. 45/2021 on Personal Data Protection (UAE PDPL), MOH/DOH/DHA revenue cycle regulations, and emirate-level health information exchange policies (NABIDH in Dubai, Malaffi in Abu Dhabi). Claims workflows must follow DHA eClaimLink and DOH eClaims/Shafafiya technical and business rules, including coding standards (ICD-10-AM, CPT, SNOMED CT, LOINC, RxNorm) and payer-specific contract terms.

WF-BILLINGCLAIMS-001: Automated Charge Capture

(Reference to brief: WF-BIL-001)

Process Flow

Actor: System (automated), Charge Entry Clerk
Trigger: Clinical service performed (order completed, procedure done, medication dispensed, bed charge accrued)

Pre-conditions:

• Patient and encounter exist in shared entities (patients, encounters)
• Provider, facility, and department are valid and active
• Relevant clinical order/result exists in source module (CPOE, LIS, RIS, PIS, scheduling)
• Contract and fee schedule available for patient’s active insurance (via policy-contract-mgmt)
• Charge description master and charge_capture_rules configured and active

1. Receive service event - System receives real-time event from:

   • CPOE / LIS / RIS / PIS (order completed/resulted) or
   • Scheduling (bed day, OR time, visit completion).
   • Event includes patient, encounter, provider, service date/time, and clinical code (e.g., SNOMED CT, LOINC, internal procedure code).

2. Validate encounter and coverage - System verifies:

   • Encounter is open or within allowable post-discharge window.
   • Patient has active insurance coverage for service date (via policy-contract-mgmt).
   • If missing/invalid, flag event for manual review (no charge created yet).

3. Map service to chargeable item - System uses Charge Description Master and charge_capture_rules to map:

   • Clinical code → CPT/HCPCS, revenue code, internal service code.
   • If no mapping found, create exception for Charge Entry Clerk.

4. Determine payer and contract - System identifies primary payer, plan, and contract from policy-contract-mgmt (e.g., Daman, THIQA, Oman Insurance). - For self-pay, assign facility self-pay fee schedule.

5. Apply charge capture rules - System evaluates charge_capture_rules:

   • Modifier logic (e.g., bilateral procedures, multiple procedures).
   • Bundling/unbundling (e.g., inclusive services).
   • Facility vs professional component (TC/26 modifiers).
   • Rules may suppress duplicate charges or split charges into multiple lines.

6. Calculate charge amount - System queries fee_schedule_items (via policy-contract-mgmt) for:

   • Contracted rate for CPT/HCPCS + modifier(s).
   • Calculates:
   • charge_amount (gross charge).
   • contracted_rate (expected allowed amount).

7. Attach diagnosis and medical necessity - System pulls ICD-10-AM diagnoses from encounter (via EHR) and:

   • Associates them with the charge.
   • Validates medical necessity against payer rules (e.g., DHA/DOH policies).

8. Create charge record - System INSERTs into charges:

   • Patient, encounter, provider, facility, department, service date, CPT/HCPCS, ICD-10 codes, modifiers, quantity, charge_amount, contracted_rate, source_module, source_order_id, charge_status = PENDING_EDIT.
   • System INSERTs into charge_details for revenue code, cost center, DRG (if applicable).

9. Run pre-claim edit checks - System evaluates claim_edits relevant to charge-level (e.g., age/gender appropriateness, mutually exclusive procedures, frequency limits). - If errors/warnings:

   • Store edit results and set charge_status = ERROR or WARNING.
   • If clean:
   • Set charge_status = READY.

10. Flag exceptions for manual review

    • Charges with ERROR status appear in Charge Review Worklist (SCR-BIL-001) for Charge Entry Clerk to correct (e.g., missing modifier, invalid diagnosis).

11. Accumulate charges on encounter

    • Charges remain linked to encounter until:
    • Encounter is discharged/closed, or
    • Periodic claim generation job runs (see WF-BILLINGCLAIMS-002).

Data Modified:

• charges — INSERT, UPDATE (charge_status, contracted_rate, error flags)
• charge_details — INSERT
• charge_capture_rules — READ
• claim_edits — READ
• Shared references (READ only): patients, encounters, providers, facilities, departments, fee_schedule_items, contracts, insurance_plans, payers

Mermaid Flowchart

Decision Points

1. Encounter & coverage valid? - If no active encounter or coverage on service date → no charge created; event queued for manual review.
2. Service mapping found? - If no CDM mapping → exception; Charge Entry Clerk must configure mapping or manually enter charge.
3. Edit errors/warnings present? - If errors → charge blocked from claim generation until corrected. - If warnings → may proceed but highlighted in worklist for review.

Integration Points

• CPOE / LIS / RIS / PIS / Scheduling
• Direction: Inbound
• Data: Completed orders, procedures, bed days, OR time
• Protocol: Internal API / HL7 DFT^P03, ADT (INT-BIL-001, INT-BIL-002)
• Policy & Contract Management (policy-contract-mgmt)
• Direction: Inbound
• Data: Fee schedules, contracts, payer rules
• Protocol: Internal API / shared DB (INT-BIL-003)
• EHR & Patient Management (ehr-patient-mgmt)
• Direction: Inbound
• Data: Patient demographics, diagnoses, provider/facility references
• Protocol: Internal API / HL7 ADT (INT-BIL-009)

Exception Handling

• Missing encounter or coverage:
• Event logged; Charge status not created.
• Worklist entry for Charge Entry Clerk to correct registration/coverage.
• No CDM mapping:
• System raises configuration alert to Revenue Cycle Manager.
• Temporary manual charge entry allowed with audit trail.
• Rule engine failure (technical):
• System creates basic charge with minimal fields and flags charge_status = SYSTEM_ERROR.
• Technical alert to IT; charges excluded from claim generation until reprocessed.
• High-risk PDPL data access:
• Access to financial data logged with user ID and timestamp; only authorized roles can view/edit.

Paperless Transformation

Remaining Paper Touchpoints: None — fully digital (subject to rare use of paper notes in downtime procedures, which are later back-entered).

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Charge record exists with charge_status = READY, WARNING, or ERROR
• Contracted rate populated from fee schedule
• ICD-10-AM diagnoses linked to charge for medical necessity
• Pre-claim edit results stored; errors routed to worklist

SLA and Timing

State Transition Diagram

WF-BILLINGCLAIMS-002: Claim Generation & Scrubbing

(Reference to brief: WF-BIL-002)

Process Flow

Actor: Billing Specialist, System (automated)
Trigger: Encounter closed/discharged, or scheduled batch claim generation job

Pre-conditions:

• Encounter status = discharged/closed in encounters
• All relevant charges for encounter have been captured (charges with charge_status ≠ DRAFT)
• Patient insurance coverage and payer contract are valid for service dates
• Claim edit rules (claim_edits) and payer rules are configured and active

1. Identify encounters ready for billing - System scans encounters for:

   • Discharged/closed status.
   • No existing active claim for primary payer.
   • Excludes encounters with unresolved charge errors.

2. Aggregate charges into claim - For each encounter and payer:

   • Group all eligible charges with charge_status = READY.
   • System creates claim header candidate (one per encounter per payer).

3. Create claim header - INSERT into claims:

   • Patient, encounter, payer, plan, contract, claim_type (inpatient/outpatient), total_charge_amount (sum of charges), claim_status = DRAFT, created_at.

4. Create claim lines - For each charge:

   • INSERT into claim_lines with:
   • CPT, modifiers, ICD-10 pointer, quantity, charge_amount.
   • Link to charges.charge_id.

5. Apply standard claim edits - System evaluates claim_edits:

   • CCI bundling/unbundling.
   • Modifier validation.
   • Diagnosis–procedure matching (ICD-10-AM vs CPT).
   • Age/gender appropriateness.
   • Updates claim/line statuses and logs edit results.

6. Validate completeness - System checks:

   • Attending provider present and valid.
   • Facility and department codes valid per DHA/DOH requirements.
   • Patient identifiers (MRN, Emirates ID 784-YYYY-NNNNNNN-C) and demographics complete.
   • If missing, mark claim claim_status = ERROR.

7. Run payer-specific validations - For DHA (Dubai) payers:

   • Validate eClaimLink XML requirements (e.g., provider DHA license, NABIDH facility ID).
   • For DOH (Abu Dhabi) payers:
   • Validate Shafafiya/DOH eClaims rules (e.g., DOH provider ID, Malaffi facility ID).
   • Apply payer-specific rules from policy-contract-mgmt (e.g., THIQA, Daman).

8. Calculate expected reimbursement - For each claim line:

   • Retrieve contracted allowed amount from fee_schedule_items / contract.
   • Update claim_lines.allowed_amount and claims.total_expected_amount (if stored).

9. Route errors to worklist - Claims with any hard errors:

   • Set claim_status = EDIT_ERROR.
   • Add to Claim Generation & Scrubbing screen (SCR-BIL-002) for Billing Specialist.

10. Mark clean claims as ready

    • Claims with no hard errors:
    • Set claim_status = READY_FOR_SUBMISSION.
    • Generate internal claim batch ID if part of batch run.

11. Generate claim payloads

    • For each ready claim:
    • Build DHA eClaimLink XML or DOH eClaims payload as per payer.
    • Store reference in claim_submissions (pre-submission record with status PENDING).

Data Modified:

• claims — INSERT, UPDATE (claim_status, totals, expected amounts)
• claim_lines — INSERT, UPDATE (allowed_amount, line_status)
• charges — UPDATE (link to claim_id if modeled, status to BILLED when submitted)
• claim_edits — READ
• claim_submissions — INSERT (pre-populated for submission)
• Shared references (READ): patients, encounters, providers, facilities, departments, payers, insurance_plans, contracts, fee_schedule_items

Mermaid Flowchart

Decision Points

1. Encounter ready for billing? - If charges missing or unresolved errors → encounter excluded from claim generation.
2. Hard edit errors present? - If yes → claim blocked from submission; Billing Specialist must correct data.
3. Payer-specific rule failures? - If DHA/DOH format or business rule fails → claim flagged with specific error codes for correction.

Integration Points

• Policy & Contract Management
• Direction: Inbound
• Data: Contracted rates, payer-specific rules, financial class
• Protocol: Internal API / shared DB (INT-BIL-003)
• EHR & Patient Management
• Direction: Inbound
• Data: Patient demographics, Emirates ID, diagnoses, provider credentials
• Protocol: Internal API / HL7 ADT (INT-BIL-009)
• DHA eClaimLink / DOH eClaims
• Direction: Outbound (payload preparation)
• Data: Claim XML/structured payload (not yet transmitted; actual send in WF-003)
• Protocol: DHA eClaimLink REST, DOH eClaims/Shafafiya API (INT-BIL-004, INT-BIL-005)

Exception Handling

• Missing mandatory data (e.g., Emirates ID, provider license):
• Claim set to EDIT_ERROR; error details shown on SCR-BIL-002.
• Invalid coding (ICD-10-AM/CPT mismatch):
• Claim line flagged; Billing Specialist can correct diagnosis or procedure codes.
• System failure during batch generation:
• Partial progress logged; successfully created claims remain; failed encounters re-queued for next run.
• PDPL compliance:
• Only authorized Billing Specialist/Revenue Cycle Manager roles can view full financial details; access logged.

Paperless Transformation

Remaining Paper Touchpoints: None — fully digital, except rare payer requests for supporting documents that may still be scanned and attached.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Claim exists with claim_status = READY_FOR_SUBMISSION or EDIT_ERROR
• All claim lines linked to source charges
• Expected reimbursement calculated from contracted rates
• Payer-specific payload generated and stored for submission

SLA and Timing

State Transition Diagram

WF-BILLINGCLAIMS-003: Electronic Claim Submission

(Reference to brief: WF-BIL-003)

Process Flow

Actor: Billing Specialist, System (automated batch)
Trigger: Claims marked as READY_FOR_SUBMISSION (from WF-BILLINGCLAIMS-002)

Pre-conditions:

• Claims exist in claims with claim_status = READY_FOR_SUBMISSION
• Corresponding claim_submissions pre-records exist or will be created
• DHA eClaimLink and DOH eClaims connectivity configured and active
• Submission channels defined in master data (Claim Submission Channels)

1. Select claims for submission - System or Billing Specialist filters claims by:

   • Payer, submission channel, date range, facility.
   • Selects all with claim_status = READY_FOR_SUBMISSION.

2. Batch claims by payer and channel - System groups claims into batches:

   • DHA eClaimLink (Dubai payers).
   • DOH eClaims/Shafafiya (Abu Dhabi payers).
   • Other private payer APIs or manual channels.

3. Create submission batch records - For each batch:

   • Generate batch_id.
   • INSERT multiple rows into claim_submissions with:
   • submission_channel, submission_datetime (planned), batch_id, gateway_status = PENDING.

4. Transmit to DHA eClaimLink - For DHA batch:

   • System builds XML payload per eClaimLink schema.
   • Sends via REST API (INT-BIL-004).
   • Receives immediate acknowledgement (ACK/NACK).

5. Transmit to DOH eClaims/Shafafiya - For DOH batch:

   • System builds DOH eClaims payload.
   • Sends via Shafafiya API (INT-BIL-005).
   • Receives initial response.

6. Transmit to private payer portals (if integrated) - For payers with direct API:

   • Send claims via agreed protocol.
   • For non-integrated payers:
   • Mark claims as MANUAL_SUBMISSION_REQUIRED and provide export (e.g., PDF/CSV) for portal upload.

7. Record gateway responses - For each claim in batch:

   • Update claim_submissions.gateway_status (e.g., ACCEPTED, REJECTED).
   • Store gateway_response, response_datetime.
   • Update claims.claim_status:
   • SUBMITTED if accepted.
   • GATEWAY_REJECTED if rejected.

8. Handle gateway rejections - Claims with GATEWAY_REJECTED:

   • Appear in Claim Submission Tracker (SCR-BIL-003).
   • Billing Specialist reviews rejection reasons and corrects underlying claim.
   • On correction, new submission record created for resubmission.

9. Track claim lifecycle - System periodically polls DHA/DOH/payer APIs for status updates:

   • In review, adjudicated, paid, denied.
   • Updates claim_submissions and claims.claim_status accordingly.

10. Support manual submission

    • For payers requiring paper or portal-only:
    • System generates claim print/export.
    • Billing Specialist records manual submission date and reference in claim_submissions.

Data Modified:

• claim_submissions — INSERT, UPDATE (gateway_status, gateway_response, response_datetime, rejection_reason)
• claims — UPDATE (claim_status)
• Shared references (READ): payers, contracts, facilities

Mermaid Flowchart

Decision Points

1. Submission channel available? - If no electronic channel configured → mark as manual submission; still tracked in system.
2. Gateway ACK/NACK result? - If NACK (rejected) → claim not considered submitted; must be corrected and resubmitted.
3. Status updates from payer? - If adjudicated → triggers WF-BILLINGCLAIMS-004 (Payment Posting). - If denied → flows into WF-BILLINGCLAIMS-006 (Denial Management).

Integration Points

• DHA eClaimLink
• Direction: Outbound/Inbound
• Data: Claim XML submissions, ACK/NACK, status updates
• Protocol: REST API (INT-BIL-004)
• DOH eClaims / Shafafiya
• Direction: Outbound/Inbound
• Data: Claim submissions, responses
• Protocol: DOH eClaims API (INT-BIL-005)
• Private payer portals
• Direction: Outbound/Inbound (where integrated)
• Data: Claim submissions, status
• Protocol: Payer-specific APIs or manual export

Exception Handling

• API connectivity failure (DHA/DOH):
• Batch marked as FAILED_TRANSMISSION.
• Automatic retries with backoff; if repeated failure, alert Billing Specialist.
• Schema validation error:
• If local XML generation fails → claim remains READY_FOR_SUBMISSION with error log; requires technical correction.
• Duplicate submission detection:
• System checks payer reference IDs to avoid re-submitting already accepted claims.
• PDPL considerations:
• Only minimum necessary patient data sent; logs maintained for all external transmissions.

Paperless Transformation

Remaining Paper Touchpoints: Some payers may still require paper attachments; these are scanned and linked to the claim record.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• All accepted claims have claim_status = SUBMITTED with gateway reference
• Rejected claims routed to Submission Tracker with rejection reasons
• Periodic status polling initiated for submitted claims
• Submission audit trail recorded with timestamps and batch IDs

SLA and Timing

WF-BILLINGCLAIMS-004: Payment Posting & Reconciliation

(Reference to brief: WF-BIL-004)

Process Flow

Actor: Payment Poster, AR Specialist
Trigger: Remittance advice / Explanation of Benefits (EOB) received from payer (ERA file or paper EOB)

Pre-conditions:

• Claims previously submitted and present in claims
• ERA import interfaces configured for DHA/DOH and major payers
• Bank deposit accounts configured in finance system

1. Receive remittance advice - System imports ERA files from:

   • DHA eClaimLink, DOH eClaims, or payer-specific channels.
   • For paper EOBs, Payment Poster manually enters remittance header.

2. Create remittance record - INSERT into remittance_advice:

   • Payer, remittance_date, total_paid, total_claims, file_reference, import_datetime, status = IMPORTED.

3. Parse ERA and match claims - System parses remittance details:

   • For each remitted claim, match by payer claim reference, internal claim ID, or patient/encounter.
   • If no match found, mark as UNMATCHED for manual review.

4. Create payment batch - INSERT into payments:

   • Payer, payment_date, payment_amount (sum of remitted payments), payment_method (EFT, cheque), check_number/EFT reference, batch_id, reconciled = false.

5. Allocate payments to claims - For each matched claim:

   • Determine allowed_amount, paid_amount, adjustment_amount, patient_responsibility.
   • INSERT into payment_allocations:
   • payment_id, claim_id, claim_line_id, allocated_amount, adjustment_amount, adjustment_code, patient_responsibility_amount.

6. Update claim and claim lines - UPDATE claim_lines:

   • Set paid_amount, adjustment_amount, denial_code (if any), line_status (e.g., PAID, PARTIAL, DENIED).
   • UPDATE claims:
   • total_paid_amount, total_adjusted_amount, patient_responsibility, claim_status (e.g., PAID, PARTIALLY_PAID, DENIED).

7. Calculate patient responsibility and transfer to patient billing - For each claim:

   • Compute patient responsibility (co-pay, co-insurance, deductible).
   • Create or update patient_invoices and patient_payments linkage as needed (or flag for WF-BILLINGCLAIMS-005).

8. Identify underpayments and denials - System compares paid_amount vs allowed_amount (from contracts). - If underpayment beyond tolerance or denial codes present:

   • Flag for Denial Specialist/AR Specialist.
   • Send summary to Denial Analysis module (INT-BIL-006).

9. Reconcile bank deposits - Payment Poster verifies:

   • payments.payment_amount vs bank statement deposits.
   • Once reconciled, set payments.reconciled = true and record bank_deposit_date.

10. Generate posting reports

    • System generates daily payment posting report for finance and Revenue Cycle Manager.

Data Modified:

• remittance_advice — INSERT, UPDATE (status)
• payments — INSERT, UPDATE (reconciled, bank_deposit_date)
• payment_allocations — INSERT
• claim_responses — INSERT (for detailed adjudication, if modeled here)
• claims — UPDATE (total_paid_amount, total_adjusted_amount, patient_responsibility, claim_status)
• claim_lines — UPDATE (paid_amount, adjustment_amount, denial_code, line_status)
• ar_aging — UPDATE/REGENERATE (via scheduled job)
• Shared references (READ): payers, contracts, patients, encounters

Mermaid Flowchart

Decision Points

1. Claim match found? - If no match → line flagged as UNMATCHED; Payment Poster must manually link or create appropriate record.
2. Underpayment or denial present? - If yes → claim flagged for Denial Management workflow.
3. Bank reconciliation successful? - If discrepancy between ERA total and bank deposit → Payment Poster investigates and may hold reconciliation.

Integration Points

• DHA eClaimLink / DOH eClaims / Payer ERA feeds
• Direction: Inbound
• Data: ERA files, remittance details
• Protocol: As per payer (often via secure SFTP/API)
• Policy & Contract Management
• Direction: Inbound
• Data: Contracted allowed amounts for variance checks
• Protocol: Internal API / shared DB (INT-BIL-003)
• Denial Analysis module
• Direction: Outbound
• Data: Denied claims, denial codes, underpayment details
• Protocol: Internal API / shared DB (INT-BIL-006)

Exception Handling

• ERA file format errors:
• File rejected; status set to IMPORT_ERROR in remittance_advice; IT notified.
• Partial posting:
• If posting interrupted, system ensures idempotency; already posted lines not duplicated.
• Unmatched payments:
• Remittance lines without matching claims held in suspense; AR Specialist resolves.
• PDPL compliance:
• Financial data access restricted; audit logs maintained for all posting and adjustment actions.

Paperless Transformation

Remaining Paper Touchpoints: Some payers may still send paper EOBs; these are manually keyed and scanned, then attached to remittance records.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• All matched ERA lines allocated to claims with correct paid/adjusted amounts
• Unmatched remittance lines flagged for manual resolution
• Underpayments and denials identified and routed to Denial Analysis
• Patient responsibility calculated and queued for patient billing
• Bank reconciliation status recorded

SLA and Timing

State Transition Diagram

WF-BILLINGCLAIMS-005: Patient Billing & Statement Generation

(Reference to brief: WF-BIL-005)

Process Flow

Actor: Patient Billing Specialist, System (automated)
Trigger: Patient balance established after insurance adjudication, or self-pay encounter completion

Pre-conditions:

• Claims adjudicated and patient responsibility calculated (from WF-BILLINGCLAIMS-004), or self-pay charges finalized
• Patient contact details and communication preferences available (from ehr-patient-mgmt)
• Financial policies (discounts, charity, payment plans) configured

1. Identify accounts with patient balance - System scans claims and patient_invoices:

   • Where patient_responsibility > 0 and not fully paid.
   • For self-pay encounters, uses total charges as patient responsibility.

2. Calculate consolidated patient balance - For each patient:

   • Aggregate outstanding balances across encounters.
   • Consider prior credits or overpayments.

3. Apply financial policies - System checks:

   • Eligibility for charity care or discounts (e.g., UAE nationals, government programs).
   • Existing payment plans.
   • Patient Billing Specialist can adjust or approve discounts per policy.

4. Generate patient invoice - INSERT into patient_invoices:

   • Patient, invoice_date, total_amount, paid_amount (initially 0), balance, due_date, statement_number, delivery_method (portal/email/SMS/print), status = PENDING_SEND.

5. Create itemized statement - System compiles:

   • Encounter charges, insurance payments, adjustments, patient responsibility.
   • Generates bilingual (EN/AR) statement PDF/HTML for portal.

6. Deliver statement - Based on patient preference:

   • Publish to Patient Portal (via FHIR API INT-BIL-007).
   • Send email/SMS with secure link.
   • Queue for print/mail if required.
   • UPDATE patient_invoices.sent_datetime and status = SENT.

7. Accept patient payment - When patient pays (online via portal, POS, bank transfer):

   • INSERT into patient_payments:
   • Patient, invoice_id, encounter_id (if applicable), payment_amount, payment_method, payment_datetime, receipt_number, collected_by, payment_location.

8. Update invoice and account - UPDATE patient_invoices.paid_amount and balance. - If balance = 0 → set status = PAID. - If partial payment → status = PARTIALLY_PAID.

9. Issue receipt - System generates digital receipt (EN/AR) and:

   • Displays in portal.
   • Optionally emails/SMS or prints at POS.

10. Monitor aging and escalate

    • System tracks overdue invoices by aging buckets.
    • Overdue accounts appear on Patient Billing worklist for follow-up, reminders, or external collections per policy.

Data Modified:

• patient_invoices — INSERT, UPDATE (paid_amount, balance, status, sent_datetime)
• patient_payments — INSERT
• ar_aging — UPDATE/REGENERATE
• Shared references (READ): patients, encounters, claims, patient portal integration

Mermaid Flowchart

Decision Points

1. Eligible for discounts/charity? - If yes → apply policy-based adjustments before invoicing.
2. Delivery method available? - If patient has portal access and consent → prefer digital delivery; otherwise print/mail.
3. Invoice fully paid? - If yes → close invoice; if no → continue aging and follow-up.

Integration Points

• Patient Portal
• Direction: Bidirectional
• Data: Outbound statements and balances; inbound online payments
• Protocol: FHIR R4 REST API (INT-BIL-007)
• Patient Access
• Direction: Bidirectional
• Data: Co-pay amounts at check-in, payment status
• Protocol: Internal API (INT-BIL-008)
• EHR & Patient Management
• Direction: Inbound
• Data: Patient demographics, contact details, consent preferences
• Protocol: Internal API / HL7 ADT (INT-BIL-009)

Exception Handling

• Invalid contact details (email/phone):
• Delivery fails; system flags invoice for manual contact update.
• Payment reversal/chargeback:
• Negative patient_payments entry or refunds record created; invoice balance recalculated.
• PDPL consent:
• If patient has not consented to electronic communication, restrict to portal or print; log consent status.

Paperless Transformation

Remaining Paper Touchpoints: Some patients may still request printed statements or receipts; these are generated from the system.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Patient invoice exists with correct balance and delivery method
• Statement delivered via patient's preferred channel (portal, email, SMS, print)
• Any collected payments recorded and allocated to invoice
• AR aging updated to reflect current patient balances

SLA and Timing

WF-BILLINGCLAIMS-006: Claim Denial Management

(Reference to brief: WF-BIL-006)

Process Flow

Actor: Denial Specialist, AR Specialist
Trigger: Claim denied or partially denied by payer (identified during payment posting)

Pre-conditions:

• Denial codes and adjustment reason codes configured in master data
• Claims and payment allocations updated from WF-BILLINGCLAIMS-004
• Access to clinical documentation (via EHR) for appeal preparation

1. Identify denied/underpaid claims - System scans claims, claim_lines, and payment_allocations:

   • Where denial codes present or paid_amount < allowed_amount beyond tolerance.
   • Adds items to Denial Worklist (SCR-BIL-007).

2. Categorize denial - System categorizes by denial reason:

   • Eligibility, authorization, coding, medical necessity, timely filing, benefit limits.
   • Uses Denial Reason Codes master and payer-specific mappings.

3. Route to appropriate specialist - Based on category:

   • Eligibility/authorization → AR Specialist.
   • Coding/medical necessity → Denial Specialist (with Coding team input).
   • Assigns owner and due date (based on payer days-to-file).

4. Review and root cause analysis - Specialist reviews:

   • Claim details, remittance advice, payer notes.
   • Clinical documentation from EHR (NABIDH/Malaffi-compliant access).
   • Determines root cause (internal error vs payer issue).

5. Decide on appeal - If low financial impact or low success probability:

   • May accept denial and write off per policy (with approval).
   • If appeal warranted:
   • Proceed to prepare appeal.

6. Prepare appeal package - Compile:

   • Corrected claim information (if coding error).
   • Supporting clinical notes, lab/imaging reports.
   • Appeal letter template (EN/AR) referencing payer rules and UAE regulations where relevant.
   • Ensure no unnecessary PHI beyond minimum required (PDPL).

7. Submit appeal - Via:

   • eClaimLink (DHA) or DOH eClaims, where supported.
   • Payer portal upload.
   • Email/fax (if required) with tracking logged.
   • Record appeal submission in claim notes or dedicated appeal tracking (within claim_responses or related table).

8. Track appeal status - System tracks:

   • Appeal submitted, in review, overturned, upheld, partial recovery.
   • Updates relevant fields and worklist status.

9. Record final outcome - If overturned/partial:

   • Additional payment posted via WF-BILLINGCLAIMS-004.
   • If upheld:
   • Denial finalized; write-off processed per policy.
   • Denial data sent to Denial Analysis module for trending.

Data Modified:

• claims — UPDATE (claim_status, denial-related flags)
• claim_lines — UPDATE (denial_code, line_status)
• claim_responses — INSERT (appeal records, outcomes)
• payments / payment_allocations — INSERT/UPDATE (for recovered amounts)
• ar_aging — UPDATE/REGENERATE
• Shared references (READ): payers, contracts, patients, encounters

Mermaid Flowchart

Decision Points

1. Appeal warranted? - Based on financial threshold, days-to-file, and likelihood of success.
2. Appeal outcome? - Overturned, partially overturned, or upheld; each path has different financial impact.
3. Root cause internal vs payer? - Internal errors may trigger process improvements and staff training.

Integration Points

• Denial Analysis module
• Direction: Outbound
• Data: Denial reasons, amounts, appeal outcomes
• Protocol: Internal API / shared DB (INT-BIL-006)
• Policy & Contract Management
• Direction: Inbound
• Data: Contract terms, timely filing limits, authorization requirements
• Protocol: Internal API (INT-BIL-003)
• DHA eClaimLink / DOH eClaims / Payer Portals
• Direction: Bidirectional
• Data: Appeal submissions and responses
• Protocol: As per payer (often via same channels as claims)

Exception Handling

• Missed appeal deadlines (days-to-file exceeded):
• System warns before deadline; if missed, claim marked as non-appealable.
• Incomplete documentation:
• Appeal cannot be submitted; worklist item remains open until documentation attached.
• PDPL compliance:
• Only minimum necessary clinical data attached to appeals; access logged.

Paperless Transformation

Remaining Paper Touchpoints: Some payers may still require faxed appeals; these are scanned and linked to the claim.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Denial categorized and root cause identified
• Appeal submitted within payer days-to-file limit (if warranted)
• Appeal outcome recorded; additional payment posted or write-off processed
• Denial data fed to Denial Analysis module for trending

SLA and Timing

State Transition Diagram

WF-BILLINGCLAIMS-007: Co-Payment / Point-of-Service Collection

(Reference to brief: WF-BIL-007)

Process Flow

Actor: Registration Clerk, Cashier
Trigger: Patient check-in for outpatient visit or at discharge (inpatient/ED)

Pre-conditions:

• Appointment or encounter exists in scheduling / encounters
• Insurance eligibility and benefits verified via Patient Access (INT-BIL-008)
• Co-pay rules configured in policy-contract-mgmt

1. Retrieve encounter and coverage - At check-in/checkout, system retrieves:

   • Encounter details (service type, department).
   • Patient insurance plan and eligibility result.

2. Calculate expected co-payment - System queries policy-contract-mgmt:

   • Co-pay/co-insurance rules based on plan, service type (consultation, procedure, imaging).
   • Calculates expected patient responsibility at point-of-service.

3. Display co-payment amount - On Cashier / POS Collection screen (SCR-BIL-009):

   • Show amount due, prior balances, and explanation (e.g., “20% co-insurance for MRI”).

4. Confirm with patient - Registration Clerk/Cashier informs patient of amount and payment options. - If patient disputes, staff can view benefit details (if available).

5. Collect payment - If patient agrees:

   • Accept payment via cash, credit/debit card, Apple Pay, online link, etc.
   • INSERT into patient_payments:
   • Patient, encounter_id, payment_amount, payment_method, payment_datetime, receipt_number, collected_by, payment_location = POS.

6. Issue receipt - System generates receipt (EN/AR) and:

   • Prints or sends via email/SMS.

7. Update encounter financials - System links payment to encounter and future invoice:

   • Reduces outstanding patient responsibility for that encounter.

8. If patient declines payment - Staff records reason (e.g., financial hardship, will pay later). - Encounter flagged for follow-up billing:

   • Note added to patient_invoices pipeline.

9. End-of-day reconciliation - Cashier runs end-of-day report:

   • Compares patient_payments collected at POS vs physical cash/card terminal totals.
   • Discrepancies investigated and resolved.

Data Modified:

• patient_payments — INSERT
• patient_invoices — UPDATE/INSERT (future billing adjustments)
• ar_aging — UPDATE/REGENERATE (reflecting early collections)
• Shared references (READ): patients, encounters, insurance_plans, contracts

Mermaid Flowchart

Decision Points

1. Patient willing to pay at POS? - If yes → immediate collection improves POS collection rate KPI. - If no → account moves to standard billing workflow.
2. Coverage and co-pay rules available? - If not available → estimate or mark as “to be determined”; avoid over-collection.
3. Reconciliation discrepancies? - If mismatch between system and physical totals → investigation required before closing day.

Integration Points

• Patient Access
• Direction: Bidirectional
• Data: Eligibility verification, co-pay rules, estimated patient responsibility
• Protocol: Internal API (INT-BIL-008)
• Policy & Contract Management
• Direction: Inbound
• Data: Co-pay/co-insurance rules per plan and service
• Protocol: Internal API / shared DB (INT-BIL-003)
• Patient Portal
• Direction: Outbound
• Data: Updated balance and payment receipts
• Protocol: FHIR R4 REST API (INT-BIL-007)

Exception Handling

• Eligibility not available or system down:
• Staff may collect standard visit fee or defer collection; note reason.
• Payment terminal failure:
• Accept cash or bank transfer; record manually and later reconcile.
• PDPL compliance:
• Payment card data handled by PCI-compliant external gateway; HIS stores only tokens/limited metadata.

Paperless Transformation

Remaining Paper Touchpoints: Some patients may request printed receipts; these are generated from the system.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Patient payment recorded with receipt number and collection details
• Encounter financial balance reduced by collected amount
• Receipt issued in patient's preferred format
• End-of-day reconciliation data available for cashier review

SLA and Timing