Financial transaction collection retrieval chooses a different pk83407_payment_hist_trans stored procedure based on whether the caller searches by claim ID, policy number, or reimbursement issue date.
Trigger
A caller retrieves clsFinancialTransactionCollection using one of the supported search modes.
Enforcement
clsFinancialTransactionCollection.Criteria.RetrieveSQL returns SelectFinTranByClaimId, SelectFinTranByPolicyNum, or SelectReimbFinTranByIssueDate according to the criteria mode.
Outcome
The collection dispatches the mode-specific stored procedure and returns the corresponding financial-transaction result set.
BR-004: Medical condition detail uses the latest compensability decision¶
Field
Value
Statement
Medical-condition detail joins only the latest compensability decision row for the claim and medical condition by selecting the maximum COND_COMP_DECISION_ID.
Trigger
A caller retrieves clsMedicalConditionData for a claim and medical condition.
Enforcement
clsMedicalConditionData.Criteria.RetrieveSQL uses a correlated subquery over cl_cond_compensability_decisn to keep the highest decision ID for the condition.
Outcome
The returned medical-condition view reflects the most recent compensability decision state for the targeted condition.
The reserve collection removes legal non-chargeable expense and other non-chargeable expense reserve rows before exposing category totals to callers.
Trigger
A caller retrieves clsClaimReservesCollection for a claim.
Enforcement
clsClaimReservesCollection filters out reserve rows whose category matches CategoryLegalNonChargeableExpense or CategoryOtherNonChargeableExpense after loading the API-returned reserve set.
Outcome
Category totals such as TotalIncurred, TotalPaid, and TotalReserves never include non-chargeable expense amounts.
BR-006: Death and burial reserves are combined only when the caller opts in¶
Field
Value
Statement
Burial reserve amounts are merged into the death-benefit reserve category only when the caller sets CombineDeathAndBurialReserve on the reserve collection criteria; otherwise the two categories remain separate.
Trigger
A caller retrieves clsClaimReservesCollection with the combine flag set.
Enforcement
clsClaimReservesCollection checks If MyCriteria.CombineDeathAndBurialReserve Then before folding burial amounts into the death-benefit total.
Outcome
Reserve totals reflect either combined or separate death/burial categories depending on caller intent, so downstream displays must match the flag they requested.
BR-007: Claim person identifier resolution requires a provider location number or a numeric public ID¶
Field
Value
Statement
clsClaimPersonView resolves PersonID from the contact's provider location sequence number when it is nonzero; otherwise it requires the API PublicID to be numeric, and raises an error if neither is available.
Trigger
A caller loads a clsClaimPersonView from an API-returned Contact row (e.g. during beneficiary retrieval).
Enforcement
Load sets PersonID from ProviderLocSeqNumber when nonzero, else parses PublicID as numeric, else throws "Unexpected public ID...".
Outcome
Beneficiary and other claim-person rows without a resolvable identifier fail loudly instead of silently producing an unusable person record.
BR-008: EAIP header retrieval accepts either a period sequence number or a claim ID, not both¶
Field
Value
Statement
When retrieving EAIP header data, the criteria clears the claim ID whenever a period sequence number is supplied, and clears the period sequence number otherwise, so exactly one identifier is sent to the EAIP API.
Trigger
A caller constructs clsEAIPData with both a claim ID and a period sequence number available.
Enforcement
BeforeRetrieve executes If MyCriteria.PeriodSeqNum > 0 Then MyCriteria.ClaimID = Nothing Else MyCriteria.PeriodSeqNum = Nothing.
Outcome
The EAIP API route always resolves on a single identifier, avoiding ambiguous or conflicting lookup criteria.
Confidence
Verified
Tables
N/A
SQL
N/A
Source
Business\SAIF.Business.View.Claim\clsEAIPData.vb
BR-009: EAIP specialist resolution falls back when the assigned user is not an active EAIP specialist¶
Field
Value
Statement
The EAIP specialist contact is only returned as the assigned employee when that employee's job title contains "EAIP" and the employee is active; otherwise the policy-level EAIP user or a pseudo-employee placeholder is used instead.
Trigger
A caller reads clsEAIPData.EAIPSpecialist (or the related policy RTW consultant property).
Enforcement
The property checks JobTitle.Contains("EAIP") AndAlso IsActive; when this fails it falls back to the policy EAIP user or calls clsEmployeeData.NewPseudoEmployee(...).
Outcome
Callers always receive a usable employee-shaped object, even when the claim-level EAIP assignment is stale or the assigned user has left the EAIP role.
Confidence
Verified
Tables
N/A
SQL
N/A
Source
Business\SAIF.Business.View.Claim\clsEAIPData.vb
BR-010: Active fraud investigation search excludes closed, cancelled, and unassigned cases¶
Field
Value
Statement
The active-fraud-case query only returns investigations typed as fraud (FRD) whose status is not CLOSE, CAN, or UNASG.
Trigger
A caller retrieves clsInvestigationInfoCollection.GetActiveFraudCases.
Enforcement
The collection's SQL filter is "Where INV.INVESTIGATION_TYPE_CODE = 'FRD' and INV.INVESTIGATION_STATUS_CODE not in ('CLOSE','CAN','UNASG')".
Outcome
Closed, cancelled, and unassigned fraud investigations never appear in the active-case result set.
BR-011: PPD award balances are recalculated from state award payee history rather than reused from the award row¶
Field
Value
Statement
For permanent partial disability (PPD) benefit-type awards, the award balance amount from the primary award query is discarded and replaced with a value computed from cl_state_award_monthly_payee and cl_benefit_payee.
Trigger
A caller retrieves clsAwardInfo details for a claim that has one or more PPD awards.
Enforcement
clsAwardInfo runs a second SQL statement (PPDAwardBalanceSQL) per PPD award row and overwrites the balance from the first (AwardRetrieveSQL) query.
Outcome
PPD award balances reflect payee-level payment history instead of the potentially stale balance stored on the award/benefit-payment tables.
Rules in this section originate from base classes or services provided by dependency framework libraries. They are enforced by inherited behavior, not by code in this library.
Stored-procedure-backed note and financial-transaction paths were referenced from code, but Oracle source was not found during Stage 1b retry; no additional procedure-level business rules were documented from those packages.
Note: Statements marked with † are derived from dependency library documentation via the Legends CLI. They describe inherited behavior from the indicated origin library and should be verified if the dependency version changes.