Skip to content

Claim information and authorization support

This operation groups the claim-facing helpers implemented in ClaimServices and clsClaimSecurity. Together they resolve claimant addresses and contacts, validate claim state, check payment and authorization status, and apply the small update statements that this library owns.

Field Value
Operation ID OP-SB-07
Trigger Caller invokes claim lookup, authorization, or claim-update helpers.
Inputs Claim ID or number, person or beneficiary IDs, responsibility code, benefit/payment context, employee mail ID, amount, dates, update user
Outputs Claim address/contact objects, booleans, counts, dates, adjuster IDs, or update success state
Primary components ClaimServices.getPersonAddress, ClaimServices.GetResponsibleAdjuster, ClaimServices.HasExistingBenefitPayment, ClaimServices.HasReserveAuthorization, ClaimServices.IsClaimAvailableExternalView, clsClaimSecurity.GetClaimSecurityByClaimID
Entry point Business\SAIF.Business\ClaimServices.vb

Steps

  1. Data-API retrieval helpers such as GetBeneficiaryAddresses, GetClaimContacts, GetWorkerAddress, and clsClaimSecurity.GetClaimSecurityByClaimID send CCClaimData API requests keyed by claim or person identifiers and return the typed response objects without issuing local SQL.
  2. Person-address retrieval uses pk82001_claim.getPersonAddress when the caller requests a claim person mailing or payment address, passing the person, claim, address-type, and optional date inputs into the procedure (SQL-005, PROC-RULE-005, PROC-RULE-006, PROC-RULE-007, PROC-RULE-008, PROC-RULE-009, PROC-RULE-010, PROC-RULE-011, PROC-RULE-012, PROC-RULE-013, PROC-RULE-014, PROC-RULE-015).
  3. The procedure either chooses a fallback address type or returns no row when no qualifying address exists.
  4. Responsible-adjuster lookup executes the claim-number or claim-ID variant of the adjuster query and returns the matching employee mail ID from the responsibility tables (SQL-006, SQL-007, CL_INJURY_CLAIM, CL_CLAIM_RESPONSIBILITY).
  5. Claim-validity helpers run point queries to confirm that a claim exists, a responsibility code is known, a legal collection or legal case exists, an investigation request date exists, incurred costs are present, or a support-order connection is present (SQL-008, SQL-009, SQL-010, SQL-011, SQL-015, SQL-016, SQL-017, CL_INJURY_CLAIM, CL_CLAIM_RESPONSIBILITY, LEGAL_COLLECTION, INVESTIGATION, LEGAL_CASE, CL_INCURRED_COST_HISTORY, CL_INCURRED_CATEGORY_COST, CL_CLAIM_SUPPORT_ORDER_CONN).
  6. HasExistingBenefitPayment builds the payment-history query according to benefit type, settlement full/partial code, legal-order status, optional issue date, and optional amount so the search lands on the correct payment-category slice (SQL-012, BR-SB-010, CL_FINANCIAL_TRANS, CL_FINANCIAL_TRANS_DTL).
  7. Released-payment helpers and non-posted-payment checks run the payment-transaction status queries that distinguish released, federal, scheduled, or unposted states (SQL-013, CL_FINANCIAL_TRANS).
  8. Override-access checks query CL_SECURITY_OVERRIDE, join to ADP_VIRTUAL_EMPLOYEE_VIEW, and return whether the requesting mail ID has claim-specific override access (SQL-014, CL_SECURITY_OVERRIDE, ADP_VIRTUAL_EMPLOYEE_VIEW).
  9. Reserve and payment authorization checks call sp82348_claim_authorization, pass the employee, business-process, function, and amount inputs, and succeed only when the procedure finds a row with a sufficient maximum amount (SQL-018, PROC-RULE-033).
  10. IsClaimAvailableExternalView queries the claim row and returns True only when external_view_flag = 'Y' (SQL-021, CL_INJURY_CLAIM, BR-SB-006).
  11. The update helpers owned by this library write directly to claim-side tables: UpdatePharmacyEligibilityToIneligible marks the pharmacy report row ineligible, and UpdateIssueDate advances the next issue date for the selected payment transaction type (SQL-044, SQL-045, CL_PHARMACY_ELIGIBILITY_REPORT, PAYMENT_TRANSACTION_TYPE_CODE).
  12. The getMaxBurialAmt helper delegates to sp82288_CalcMaxBurialAmt and returns the procedure result when callers need the current burial maximum (SQL-004).

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([Claim-service request]) --> Type{Lookup, validation, auth, or update?}
    Type -->|Lookup| Lookup[Resolve Data API call, address procedure, or adjuster query]
    Type -->|Validation| Validate[Run claim, responsibility, legal, or payment checks]
    Type -->|Authorization| Auth[Run override or claim-authorization check]
    Type -->|Update| Update[Apply claim-side update SQL]
    Lookup --> Return1([Return claim data])
    Validate --> Return2([Return boolean or date])
    Auth --> Return3([Return authorization result])
    Update --> Return4([Return update success])

Failure and edge-case behavior

  • Address requests can return no row when the procedure cannot find a qualifying address after applying its fallback rules (PROC-RULE-015).
  • Payment-history checks change behavior based on benefit context, so callers must supply the correct benefit and settlement inputs to reach the intended query branch (BR-SB-010).
  • Claim visibility intentionally returns False unless the claim row is explicitly marked for external view (BR-SB-006).
  • Authorization helpers return False when the stored procedure or override lookup finds no qualifying row.

Sources

  • Business\SAIF.Business\ClaimServices.vb
  • Business\SAIF.Business\clsClaimAddress.vb
  • Business\SAIF.Business\clsClaimSecurity.vb
  • Business\SAIF.Business\CCClaimDataAPI\Address.vb
  • Business\SAIF.Business\CCClaimDataAPI\ClaimContacts.vb
  • Business\SAIF.Business\CCClaimDataAPI\clsClaimSecurityData.vb
  • Business\SAIF.Business\CCClaimDataAPI\ResponseData.vb