Skip to content

SAIF.Business.Claim architecture

SAIF.Business.Claim is a component-tier business/domain class library built on the SAIF Business Object Framework (BOF), sitting below the application layer (SAIF.Application.Claim*) and the presentation layer (LegalMaintenance WebForms). It provides claim-domain business objects covering benefit schedules and payments, awards (including federal awards), claim work status and work-release status, employee work addresses, injured body parts, DCBS 1502 transfers, PPD degree-award calculations, and reserve-service code tables.

Responsibilities

  • Benefit-schedule and benefit-payment stop processing (clsActiveBenefitSchedule.ProcessBenefitPayment).
  • Award lifecycle management, including setting awards to Pending and cascading benefit-payment updates (clsSetAwardPaymentPending).
  • Claim work status and work-release status persistence (clsClaimWorkStatus, clsClaimWorkReleaseStatus).
  • Employee work address maintenance (clsClaimEmployeeWorkAddress).
  • Injured body-part maintenance with primary-body-part rule enforcement (clsWorkerInjuredBodyPart, clsWorkerInjuredBodyPartCollection).
  • DCBS 1502 transfer record handling (cls1502Transfer, cls1502TransferList).
  • Read-only stored-procedure-backed lookups (aggravation-rights dates, timeliness of first payment, medically-stationary date, statutory weekly wage calculation).
  • Dynamic, caller-supplied claim-list SQL execution (clsClaimListGenerator).
  • PPD degree-award calculation with an auditable calculation trail (clsPPDScheduledDegreeAwards, clsPPDUnscheduledDegreeAwards).
  • Cached code-table access for PPD and reserve-service code tables (mdlPPD, mdlReserveServices).

Component boundaries

  • Business object layer (root namespace): persistent BOF business objects and collections (e.g., cls1502Transfer, clsActiveBenefitSchedule, clsAwardBenefitPayment, clsClaimWorkStatus, clsWorkerInjuredBodyPart), each nesting a Criteria class implementing IBusinessCriteria/iBusinessCriteria that supplies CreateSQL, RetrieveSQL, InsertSQL, UpdateSQL, and DeleteSQL.
  • SAIF.Business.Claim.PPD namespace: PPD body-part and degree-award calculation types (mdlPPD, clsPPDBodyParts, clsPPDScheduledDegreeAwards, clsPPDUnscheduledDegreeAwards).
  • SAIF.Business.Claim.ReserveServices namespace: reserve-service code-table types (mdlReserveServices, clsVocationalServiceTypes, medical/vocational service code-table classes).
  • Database boundary: Oracle only, reached exclusively through the BOF DataPortal (ProcessPortalRequest), SqlHelper.ResultSetQuery, and CommandType.StoredProcedure calls; no direct OracleConnection/connection-string handling appears in this library.
  • Service boundary: a single outbound call into ClaimServices.hasReleasedScheduledPayment(...), which originates from the external SAIF.Business package and is not implemented in this repository**.
  • No UI, no HTTP, no messaging — the library exposes no web/API surface.
  • Excluded/dormant boundary: three source files (clsBenefitSchedule.vb, clsFederalBenefitSchedule.vb, Enums.vb) exist on disk but are excluded from the <Compile> ItemGroup and are therefore not part of the built assembly.

Interaction model

  • The presentation layer (LegalMaintenance) and application-layer projects (SAIF.Application.Claim.Legal) reference this library via <ProjectReference>/root-namespace <Import>, and SAIF.Business.Claim.Legal also references it directly*.
  • Persistence follows the BOF pattern: a business class supplies SQL text and parameter binding through its nested Criteria class, and the framework DataPortal executes the request; BeforeX/AfterX hooks implement post-persistence logic (e.g., cascading updates, optimistic-concurrency checks).
  • Validation is implemented through the BOF Rules engine using RuleData attributes on business-object methods (see Business rules).
  • Headline finding: a repo-wide search of every public type name and module function name across all .vb, .aspx, and .ascx files outside SAIF.Business.Claim/ returned zero usages; the assembly is compiled and linked into LegalMaintenance via project references, but no type in it is invoked anywhere in this repository, suggesting the library is inherited/shared code carried by the solution rather than active LegalMaintenance functionality*.

Architecture diagram

The following diagram shows high-level component interactions for SAIF.Business.Claim.

flowchart TD
    A[LegalMaintenance WebForms] --> B[SAIF.Application.Claim.Legal]
    B --> C[SAIF.Business.Claim.Legal]
    C --> D[SAIF.Business.Claim<br>business objects + Criteria classes]
    A --> D
    D --> E[BOF DataPortal<br>ProcessPortalRequest]
    E --> F[(Oracle database<br>CL_* tables, stored procedures)]
    D --> G[ClaimServices.hasReleasedScheduledPayment<br>SAIF.Business package]

Sequence diagram

The following diagram shows the primary benefit-payment stop processing sequence.

sequenceDiagram
    participant Caller
    participant ActiveBenefitSchedule as clsActiveBenefitSchedule
    participant ClaimServices
    participant DataPortal as BOF DataPortal
    Caller->>ActiveBenefitSchedule: ProcessBenefitPayment(claimId, callingApplication)
    ActiveBenefitSchedule->>DataPortal: RetrieveSchedSQL (active schedules)
    DataPortal-->>ActiveBenefitSchedule: schedule rows
    ActiveBenefitSchedule->>ClaimServices: hasReleasedScheduledPayment(...)
    ClaimServices-->>ActiveBenefitSchedule: released status
    ActiveBenefitSchedule->>DataPortal: UpdateSchedSQL or DeletePaymentSQL
    DataPortal-->>ActiveBenefitSchedule: RowsAffected
    ActiveBenefitSchedule-->>Caller: success/failure + StopStatus

Design constraints

  • Oracle-only persistence; all SQL uses :BindVariable syntax, SYSDATE, and <SEQ>.NEXTVAL FROM DUAL conventions*.
  • Module-level Static code-table caches (mdlPPD, mdlReserveServices) have no expiry and no synchronization, making them process-lifetime and not thread-safe*.
  • clsClaimListGenerator executes caller-supplied dynamic SQL (Criteria.SQLStatement) with only a single :ID bind parameter, a SQL-injection and maintainability risk whose actual exposure depends on callers, none of which exist in this repository*.
  • Optimistic concurrency and audit columns (UPDATE_NUM, UPDATE_DATE, UPDATE_USER) are enforced uniformly across persistent classes via After* hooks checking RowsAffected.
  • No security/authorization enforcement exists anywhere in the library; the only user context consumed is IDataPortalInfo.UserID, used solely to populate audit columns.
  • No connection strings or configuration keys are defined in this library; runtime connection/database selection is delegated to the BOF DataPortal via the caller-supplied PortalID*.

Note: Statements marked with * were inferred from code structure, naming conventions, or contextual evidence where direct confirmation was not available in source artifacts. Statements marked with ** could not be confirmed; treat as unknown until verified.

Sources

  • SAIF.Business.Claim/SAIF.Business.Claim.vbproj
  • SAIF.Business.Claim/app.config
  • SAIF.Business.Claim/Web.config
  • SAIF.Business.Claim/mdlPPD.vb
  • SAIF.Business.Claim/mdlReserveServices.vb
  • SAIF.Business.Claim/SAIF.Business.Claim.Tests/Tester.vb