---
title: SAIF.Business.View.Claim business rules
summary: Enumerated business rules with per-rule trigger, enforcement, and outcomes.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.View.Claim
reference_type: package
---

# SAIF.Business.View.Claim business rules

This page captures business rules enforced by this library.

## BR-001: Financial transaction retrieval mode selection

| Field | Value |
| --- | --- |
| **Statement** | 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. |
| **Confidence** | Verified |
| **Tables** | N/A |
| **SQL** | [SQL-007](sql/SQL-007.md), [SQL-008](sql/SQL-008.md), [SQL-009](sql/SQL-009.md) |
| **Source** | `Business\SAIF.Business.View.Claim\clsFinancialTransactionCollection.vb` |

---

## BR-002: Active support orders exclude terminated rows

| Field | Value |
| --- | --- |
| **Statement** | Support-order counts only include `cl_claim_support_order` rows whose `term_date` is null. |
| **Trigger** | Claim data requests active support-order counts for a worker. |
| **Enforcement** | `clsClaimData` queries `cl_claim_support_order` with `where term_date is null and worker_id = :WorkerID`. |
| **Outcome** | Only active, non-terminated support orders contribute to the returned count. |
| **Confidence** | Verified |
| **Tables** | [cl_claim_support_order](database-tables.md#cl-claim-support-order) |
| **SQL** | [SQL-001](sql/SQL-001.md), [SQL-030](sql/SQL-030.md) |
| **Source** | `Business\SAIF.Business.View.Claim\clsClaimData.vb` |

---

## BR-003: Prison lookup prepends a synthetic blank choice

| Field | Value |
| --- | --- |
| **Statement** | The prison-code collection prepends a synthetic blank option with code `00` and display name `<blank>` ahead of persisted prison rows. |
| **Trigger** | A caller retrieves the prison-code collection for selection-list use. |
| **Enforcement** | `clsPrisonCodeCollection.Criteria.RetrieveSQL` performs a `UNION` between a hard-coded blank row and `CL_PRISON_CODE` rows. |
| **Outcome** | Consumers receive a selectable blank option even when the table contains only persisted prison codes. |
| **Confidence** | Verified |
| **Tables** | [CL_PRISON_CODE](database-tables.md#cl-prison-code) |
| **SQL** | [SQL-010](sql/SQL-010.md) |
| **Source** | `Business\SAIF.Business.View.Claim\clsPrisonCodeCollection.vb` |

---

## 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. |
| **Confidence** | Verified |
| **Tables** | [cl_medical_condition](database-tables.md#cl-medical-condition), [cl_cond_compensability_decisn](database-tables.md#cl-cond-compensability-decisn) |
| **SQL** | [SQL-022](sql/SQL-022.md) |
| **Source** | `Business\SAIF.Business.View.Claim\clsMedicalConditionData.vb` |

---

## BR-005: Claim reserve totals exclude non-chargeable expense categories

| Field | Value |
| --- | --- |
| **Statement** | 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. |
| **Confidence** | Verified |
| **Tables** | N/A |
| **SQL** | N/A |
| **Source** | `Business\SAIF.Business.View.Claim\clsClaimReservesCollection.vb` |

---

## 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. |
| **Confidence** | Verified |
| **Tables** | N/A |
| **SQL** | N/A |
| **Source** | `Business\SAIF.Business.View.Claim\clsClaimReservesCollection.vb` |

---

## 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. |
| **Confidence** | Verified |
| **Tables** | N/A |
| **SQL** | N/A |
| **Source** | `Business\SAIF.Business.View.Claim\clsClaimPersonView.vb` |

---

## 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. |
| **Confidence** | Verified |
| **Tables** | N/A |
| **SQL** | N/A |
| **Source** | `Business\SAIF.Business.View.Claim\clsInvestigationInfo.vb` |

---

## 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. |
| **Confidence** | Verified |
| **Tables** | N/A |
| **SQL** | N/A |
| **Source** | `Business\SAIF.Business.View.Claim\clsAwardInfo.vb` |

---

## Inherited business rules

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.

### From `clsBusinessBase` (`saif-framework-core`)

#### INH-001: Framework validation lifecycle

| Field | Value |
| --- | --- |
| **Statement** | BOF business objects expose framework-managed validation through `Rules`, `IsValid`, and related messaging surfaces† |
| **Trigger** | Consumers inspect or persist BOF-derived claim view objects† |
| **Enforcement** | Validation behavior is inherited from `clsBusinessBase` rather than declared in this repository† |
| **Outcome** | Derived objects can surface rule, warning, and informational messages through the BOF framework† |
| **Confidence** | Inherited |
| **Origin** | `saif-framework-core` — `clsBusinessBase` |
| **Source** | Framework dependency documentation cached for the run† |

---

### From `clsBusinessApiCriteriaBase` (`saif-framework-core`)

#### INH-002: API criteria route delegation

| Field | Value |
| --- | --- |
| **Statement** | API-backed criteria objects preserve the BOF criteria contract while delegating data retrieval to framework route and API-client resolution services† |
| **Trigger** | API-oriented claim view classes execute retrieval through API criteria objects† |
| **Enforcement** | `clsBusinessApiCriteriaBase` supplies the inherited route-delegation behavior† |
| **Outcome** | API-backed claim view types can participate in BOF retrieval without embedding inline SQL in the derived criteria type† |
| **Confidence** | Inherited |
| **Origin** | `saif-framework-core` — `clsBusinessApiCriteriaBase` |
| **Source** | Framework dependency documentation cached for the run† |

## Notes
- 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.

## Related documentation
- [Index](index.md)
- [Overview](overview.md)
- [Architecture](architecture.md)
- [Dependencies](dependencies.md)
- [Operations and processes](operations-processes.md)
- [Database tables](database-tables.md)
- [SQL catalog](sql/index.md)
- [Procedures](procedures/index.md)
- [API reference](api/index.md)

> **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.

## Sources
- `Business\SAIF.Business.View.Claim\clsFinancialTransactionCollection.vb`
- `Business\SAIF.Business.View.Claim\clsClaimData.vb`
- `Business\SAIF.Business.View.Claim\clsPrisonCodeCollection.vb`
- `Business\SAIF.Business.View.Claim\clsMedicalConditionData.vb`
- `Business\SAIF.Business.View.Claim\clsClaimReservesCollection.vb`
- `Business\SAIF.Business.View.Claim\clsClaimPersonView.vb`
- `Business\SAIF.Business.View.Claim\clsEAIPData.vb`
- `Business\SAIF.Business.View.Claim\clsInvestigationInfo.vb`
- `Business\SAIF.Business.View.Claim\clsAwardInfo.vb`