BR-008: Third-party recovery persistence follows the package contract¶
Field
Value
Statement
Third-party recovery create, update, delete, and list workflows depend on the PK82033_THIRDPARTY procedure contract instead of inline SQL in the BOF classes.
Trigger
When recovery collections and criteria objects execute package-backed read or write operations.
Enforcement
Collection criteria and lifecycle methods call named PK82033_THIRDPARTY entry points such as THRDPARTY_INSERT, THRDPARTY_UPDATE, NEW_CLAIM_LIST, OPEN_CASE_LIST, and THRDPARTY_CASE_SEARCH_SELECT.
Outcome
Oracle package logic remains the authoritative source for third-party recovery persistence and list-generation behavior.
BR-011: Subsequent intervening cause and suit-filed dates must fall between DOI and today¶
Field
Value
Statement
The subsequent intervening cause date and the suit-filed date, when entered, must each fall on or after the date of injury and on or before the current date.
Trigger
When clsThirdPartyCase validates a case save with either date populated.
Enforcement
Case validation rules clsThirdPartyCase03 and clsThirdPartyCase06 check each date against the DOI-to-today window.
BR-016: Companion claim number must resolve to a valid claim; conflict claims warn of restricted access¶
Field
Value
Statement
A companion claim number entered against a third-party person must resolve to an existing claim; if that claim is flagged as a conflict/restricted-access claim, a warning is raised.
Trigger
When clsThrdpartyCompanionClaim validates a companion claim entry.
Enforcement
Companion claim validation rules clsThrdpartyCompanionClaim01 and clsThrdpartyCompanionClaim02 check claim resolution and conflict status.
Outcome
Unresolvable companion claim numbers fail validation; conflict claims proceed with a warning shown to the user.
BR-018: Expense type, amount, and expense date are required and must fall within the claim's injury-to-today window¶
Field
Value
Statement
A third-party expense requires an expense type and a non-zero amount, and its expense date must fall between the claim's date of injury and the current date.
Trigger
When clsThrdpartyExpense validates an expense save.
Enforcement
Expense validation rules clsThrdpartyExpense02, clsThrdpartyExpense03, clsThrdpartyExpense03a, and clsThrdpartyExpense06 check type, amount, and date range.
Outcome
Expenses missing a type or amount, or with an out-of-range date, fail validation.
BR-020: Expense totals of $5,000 or more require supervisor approval; $25,000 or more require director approval¶
Field
Value
Statement
A recovery case's total expense amount of $5,000 or more requires supervisor-level approval; a total of $25,000 or more requires director-level approval.
Trigger
When clsThrdpartyExpenseApproval.SetExpenseApproval evaluates the case's cumulative expense total.
Enforcement
Expense approval rules clsThrdpartyExpenseApproval02 and clsThrdpartyExpenseApproval03 compare the total against the $5,000 and $25,000 thresholds.
Outcome
Expense totals crossing either threshold raise an approval-required warning and set the corresponding approval status.
BR-022: Settlement total must equal the sum of settlement detail amounts and be greater than zero¶
Field
Value
Statement
A third-party settlement's total amount must equal the sum of its settlement detail category amounts, and the total must be greater than zero.
Trigger
When clsThrdpartySettlement validates a settlement save.
Enforcement
Settlement validation rule clsThrdpartySettlement01 reconciles the total against detail amounts, and a related check under clsThrdpartySettlement02 confirms the total is positive.
Outcome
Settlements whose total does not match the detail sum, or that total zero or less, fail validation.
BR-023: Settlement type and settlement date are required; date cannot be in the future or otherwise unreasonable¶
Field
Value
Statement
A third-party settlement requires a settlement type and a settlement date, and the settlement date cannot be in the future or otherwise implausible.
Trigger
When clsThrdpartySettlement validates a settlement save.
Enforcement
Settlement validation rule clsThrdpartySettlement02 checks for settlement type presence, and rule clsThrdpartySettlement03 (together with shared date-plausibility checks) validates the settlement date.
Outcome
Settlements missing a type or date, or with an invalid date, fail validation.
BR-025: Distribution requires payee name, check number, and a valid check date¶
Field
Value
Statement
A third-party distribution requires a payee name, a check number, and a valid (non-future, plausible) check date.
Trigger
When clsThirdpartyDistribution validates a distribution save.
Enforcement
Distribution validation rule cluster clsThirdpartyDistribution01 (reused across payee-name, check-number, and check-date checks) and rule clsThirdpartyDistribution011 enforce these requirements.
Outcome
Distributions missing a payee name, check number, or valid check date fail validation.
BR-026: Distribution check amount is required and must equal the sum of refund, claim-cost, and other amounts, including excess-cash refund total¶
Field
Value
Statement
A third-party distribution requires a check amount, and that amount must equal the sum of the refund amount, claim-cost amount, other amount, and any excess-cash refund total.
Trigger
When clsThirdpartyDistribution validates a distribution save.
Enforcement
Distribution validation rules clsThirdpartyDistribution02, clsThirdpartyDistribution03, and clsThirdpartyDistribution08 reconcile the check amount against its components.
Outcome
Distributions whose check amount does not reconcile to the sum of its components fail validation.
BR-031: Recovery predictions require a valid lien and percent factor, and cannot exceed projected plus lienable-paid amounts or be negative¶
Field
Value
Statement
A third-party recovery prediction requires a valid lien sequence number and a percent factor between 0 and 100; when expressed as a flat amount, the prediction cannot exceed the sum of the projected and lienable-paid category totals, and cannot be negative.
Trigger
When clsThrdpartyPrediction validates a prediction save.
Enforcement
Prediction validation rules clsThrdpartyPrediction01, clsThrdpartyPrediction02, clsThrdpartyPrediction04, and clsThrdpartyPrediction05 check lien linkage, percent-factor range, the projected/lienable-paid ceiling, and the non-negative constraint.
Outcome
Predictions failing any of these checks fail validation.
BR-032: Predictions pending supervisor approval are flagged with a warning, and prediction detail totals must match the prediction amount¶
Field
Value
Statement
A final prediction with total incurred greater than zero and a calculated incurred percent below 50% is flagged as pending supervisor approval with a warning; separately, a prediction's detail-category totals must reconcile to the overall prediction amount.
Trigger
When clsThrdpartyPrediction validates a final, dirty prediction save.
Enforcement
Prediction validation rule clsThrdpartyPrediction03 evaluates the incurred-percent threshold and updates the prediction status code; rule clsThrdpartyPrediction06 (ValidDispersement) reconciles detail totals against the prediction amount.
Outcome
Low-incurred-percent final predictions are routed to pending-approval status; predictions whose detail totals do not reconcile fail validation.
BR-033: Bill-audit service and claim payment transaction detail lien and non-lien amounts must reconcile to the allowed or paid amount¶
Field
Value
Statement
A bill-audit service line's lien amount plus non-lien amount must equal its allowed amount; a claim payment transaction detail's lien amount plus non-lien amount plus unknown amount must equal its transaction amount.
Trigger
When clsBillAuditService or clsClaimPaymentTransDetail validates a save.
Enforcement
clsBillAuditService's ValidTotal rule and clsClaimPaymentTransDetail's ValidTotal rule each reconcile their respective component amounts against the target total.
Outcome
Bill-audit service lines or claim payment transaction details whose components do not sum to the target amount fail validation.
BR-034: New claim adjuster assignment follows a policy match, then claim number range, then conflict override precedence¶
Field
Value
Statement
New-claim adjuster assignment first honors a conflict/exposure override (assigning a designated conflict adjuster), then attempts a policy-number match against an assignment list, then falls back to matching the claim number's last two digits against a range list; if no match is found, the last-iterated range entry is used as a default.
Trigger
When clsAdjusterAssignment.AssignAdjuster is called during new-claim batch intake.
Enforcement
AssignAdjuster evaluates the confidentiality flag, then the policy-assignment list, then the claim-number-range list, in that order, with an unconditional fallback to the last range entry.
Outcome
Every processed new claim receives an assigned adjuster and user name, following a deterministic precedence order.