Skip to content

Medical bill and non-recurring payment processing

This operation covers clsMedicalBillPayment and the clsNonRecurringPaymentBase family (clsBurialPayment, clsEaipPayment, clsEmployerRefundPayment, clsPenaltyPayment), which share a common lifecycle: validate type-specific eligibility rules, get approved, and release as a permanent financial transaction rather than a retained benefit-payment record.

Field Value
Operation ID OP-CP-12
Trigger Adjuster creates one of clsMedicalBillPayment, clsBurialPayment, clsEaipPayment, clsEmployerRefundPayment, clsPenaltyPayment and calls Approve()/Save()
Inputs Payee type, service/expense category, payment amount, from/thru dates, worker death date (burial), expense ID (EAIP)
Outputs Released financial transaction (via Payment posting and totals management); the payment's own CL_BENEFIT_PAYMENT row deleted after successful release
Primary components clsMedicalBillPayment, clsNonRecurringPaymentBase, clsBurialPayment, clsEaipPayment, clsEmployerRefundPayment, clsPenaltyPayment
Entry point Business\SAIF.Business.Claim.Payment\Payments\NonRecurringPayments\clsNonRecurringPaymentBase.vb

Steps

  1. Require a responsible adjuster and a non-void claim (BR-CP-057). clsPaymentBase.Rule_CheckAssignedAdjuster/Rule_CheckClaimNotVoidOrInprogress block any payment (including these non-recurring types) when the claim has no active responsible adjuster or is Void.
  2. Validate the issue date (BR-CP-058). Rule_CheckValidIssueDate/Rule_CheckIssueDateIsWorkingDay require a reasonable date no more than 28 days in the future, not earlier than the next scheduled issue date (unless a same-day rush check), and on a working day.
  3. Validate medical bill payee and MCO fee coding (BR-CP-059). clsMedicalBillPayment.Rule_CheckPayeeTypeCode requires the payee to be Worker or Medical Provider; Rule_CheckMCOPayment/Rule_CheckMCOPaymentWithIME block an MCO fee on a non-chargeable bill or one with IME services.
  4. Derive claim cost category and reimbursement program (BR-CP-059). GetClaimCostInfo derives these from the service category and, for own-motion-reimbursable claims, from the injury date relative to a claim-type-specific cutoff.
  5. Cap and restrict a burial payment (BR-CP-060). clsBurialPayment.OnInstantiationComplete/Rule_CheckMaxBurialAmount derive the maximum from the statutory bulletin-year amount as of the worker's fiscal-year death date (or injury date); exceeding it warns rather than blocks. Rule_CheckValidPayeeType requires the payee to be the deceased worker's provider ("Other") or the worker record itself.
  6. Validate EAIP eligibility (BR-CP-061). clsEaipPayment.Rule_CheckExpenseId/Rule_CheckPaymentAmount require a non-zero expense ID and an amount greater than $1.00.
  7. Validate penalty payment eligibility (BR-CP-061). clsPenaltyPayment.Rule_CheckValidPayeeType restricts the payee to Attorney, Worker, or Other; Rule_CheckValidPaymentCategory restricts the category to Medical/TD/PPD/PTD/Fatal; Rule_CheckValidFromDate/Rule_CheckValidThruDate require the from date not to be after the thru date.
  8. Load employer refund cost caps (SQL-053, CLAIM_NON_DISAB_REIMB_MAX) — clsEmployerRefundPayment consults this table for reimbursement-maximum context (see also BR-CP-073 in Refund adjustment processing, which governs the same cumulative-cap concept for refunds).
  9. Approve the payment. Every non-recurring type except EAIP runs the standard awaiting-approval authority checks (self-approval, cash-card, rush-check) inherited from clsPaymentBase/clsNonRecurringPaymentBase.
  10. Bypass the authority gate for EAIP (BR-CP-063). clsEaipPayment.Approve moves directly from initiation to Approved without running the self-approval, cash-card, or rush-check checks applied to every other payment type.
  11. Create financial transactions on release. CreateFinancialTransactions (base, shadowed per type) posts the payment through Financial transaction and remark management and Payment posting and totals management.
  12. Delete the benefit-payment header after successful release (BR-CP-062). Once financial transactions are successfully created, clsNonRecurringPaymentBase.Save/clsMedicalBillPayment.Save delete the payment's own CL_BENEFIT_PAYMENT row — the financial transaction becomes the sole permanent record of the payment.

Process flow

flowchart TD
    Start([Adjuster creates non-recurring payment]) --> AdjusterCheck{Responsible adjuster<br>assigned; claim not Void?}
    AdjusterCheck -->|No| Blocked1([Blocked])
    AdjusterCheck -->|Yes| IssueDate{Issue date valid<br>and working day?}
    IssueDate -->|No| Blocked2([Blocked: invalid issue date])
    IssueDate -->|Yes| TypeRules{Type-specific rules<br>satisfied?}
    TypeRules -->|No| Blocked3([Blocked: type-specific violation])
    TypeRules -->|Yes| PaymentType{Payment type?}
    PaymentType -->|EAIP| BypassGate[Approve directly;<br>bypass authority checks]
    PaymentType -->|Other| StdApproval{Standard awaiting-approval<br>checks pass?}
    StdApproval -->|No| Blocked4([Blocked: approval error])
    StdApproval -->|Yes| CreateTrans
    BypassGate --> CreateTrans[Create financial transactions]
    CreateTrans --> Success{Transactions<br>created successfully?}
    Success -->|No| Blocked5([Save fails; header retained])
    Success -->|Yes| DeleteHeader[Delete CL_BENEFIT_PAYMENT<br>header row]
    DeleteHeader --> Done([Payment released;<br>financial transaction is record])

Failure and edge-case behavior

  • Because EAIP payment approval bypasses the authority gate entirely (BR-CP-063), an EAIP payment's initiator can approve their own payment — a deliberate exception, not an oversight, but one worth flagging to anyone auditing separation-of-duties controls.
  • Since the benefit-payment header row is deleted after release (BR-CP-062), any UI or report that queries CL_BENEFIT_PAYMENT directly for a released non-recurring payment will not find it — only the resulting financial transaction remains.
  • Burial payment amounts above the statutory maximum are permitted with only a warning, not blocked, so this cap is advisory rather than hard-enforced at this layer.
  • MCO fee validation on medical bill payments is a binary allow/block based on chargeability and IME-service flags; there is no partial-fee or prorated-fee handling visible in this layer.

Note: Statements marked with * were inferred from code structure, naming conventions, or contextual evidence where direct confirmation was not available in source artifacts.

Sources

  • Business\SAIF.Business.Claim.Payment\Payments\MedicalBillPayments\clsMedicalBillPayment.vb
  • Business\SAIF.Business.Claim.Payment\Payments\NonRecurringPayments\clsNonRecurringPaymentBase.vb
  • Business\SAIF.Business.Claim.Payment\Payments\NonRecurringPayments\clsBurialPayment.vb
  • Business\SAIF.Business.Claim.Payment\Payments\NonRecurringPayments\clsEaipPayment.vb
  • Business\SAIF.Business.Claim.Payment\Payments\NonRecurringPayments\clsEmployerRefundPayment.vb
  • Business\SAIF.Business.Claim.Payment\Payments\NonRecurringPayments\clsPenaltyPayment.vb
  • Business\SAIF.Business.Claim.Payment\Payments\clsPaymentBase.vb