Skip to content

Worker lookup via API

Before an Online 801 submission can be completed, the submitting party must be matched to a known worker record in ClaimCenter's data API, and — if the worker already has a claim open for essentially the same injury — that existing claim should be adopted rather than creating a duplicate. This operation orchestrates the REST call and the consensus/window logic that decides whether a lookup result is usable.

Field Value
Operation ID OP-CE-14
Trigger cls801Submission.FindWorker, called during submission entry before a claim is finalized
Inputs Submission name fields (first/last name), tax ID (SSN), birth date, injury date
Outputs Resolved cls801FindWorkerDTO worker record(s); adopted ClaimID on a same-claim match
Primary components cls801Submission.FindWorker, clsFindWorkerAPI.FindWorker
Entry point Business\SAIF.Business.Claim.Entry\Online801\Submission\cls801Submission.vb

Steps

  1. Build the lookup request. FindWorker on cls801Submission gathers the name, tax ID, and birth date fields from the current submission and passes them to clsFindWorkerAPI.
  2. Call the CCClaimDataApi worker-find endpoint.
  3. Sub-step: clsFindWorkerAPI.FindWorker issues the REST call and deserializes the response into one or more cls801FindWorkerDTO records.
  4. Require a unique PersonID consensus (BR-CE-022). If the API returns multiple candidate records, the lookup only treats the match as usable when all candidates resolve to the same PersonID; a lookup returning records for different people is not treated as a confident match.*
  5. Check for an existing claim within the injury-date window (BR-CE-022). For a confidently matched worker, the lookup inspects whether the worker already has a claim whose injury date falls within a 14-day window of the submission's injury date.
  6. If a same-claim match is found: adopt that claim's ClaimID onto the submission, so the submission is associated with the existing claim instead of creating a new one.
  7. If no same-claim match is found: the resolved worker is used to prefill submission-data contacts (see 801 submission data CRUD, LoadClaimWorker), but no existing ClaimID is adopted.
  8. Return the resolved worker (and adopted ClaimID, if any) to the caller for use in completing the submission.

Process flow

flowchart TD
    Start([FindWorker called<br>during submission entry]) --> Call[Call CCClaimDataApi<br>worker-find endpoint]
    Call --> Consensus{Unique PersonID<br>across results?}
    Consensus -->|No| NoMatch([No confident match;<br>caller proceeds manually])
    Consensus -->|Yes| Window{Existing claim within<br>14-day injury-date window?}
    Window -->|Yes| Adopt[Adopt existing<br>ClaimID onto submission]
    Window -->|No| Prefill[Use resolved worker<br>to prefill submission data]
    Adopt --> Return([Return resolved worker])
    Prefill --> Return

Failure and edge-case behavior

  • The consensus rule means a genuinely ambiguous name/SSN match (multiple different people) is treated as no usable match rather than surfacing the ambiguity to the caller for manual resolution; the API response itself is available to the caller but the automated logic does not pick a candidate.*
  • The 14-day injury-date window mirrors the window used by Check multiple claims for worker, but is evaluated against ClaimCenter API data rather than the local CL_INJURY_CLAIM table, so the two checks can disagree if the two systems are out of sync.*
  • This operation makes an outbound REST call with no local database read or write of its own; failures in the REST call itself (timeouts, non-success status codes) are not shown to have an explicit retry or fallback path in the traced source.*

Note: Statements marked with * were inferred from code structure, naming conventions, or contextual evidence where direct confirmation was not available in source artifacts.

Sources

  • Business\SAIF.Business.Claim.Entry\Online801\Submission\cls801Submission.vb
  • Business\SAIF.Business.Claim.Entry\Online801\Submission\clsFindWorkerAPI.vb