---
title: Worker lookup via API
summary: Resolves a worker — and, when applicable, an in-progress claim for the same injury — from CCClaimDataApi before an Online 801 submission proceeds.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.Claim.Entry
reference_type: package
operation_id: OP-CE-14
trigger: cls801Submission.FindWorker, delegating to clsFindWorkerAPI
---

# 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.**
   - Sub-step: `clsFindWorkerAPI.FindWorker` issues the REST call and deserializes the response into one or more `cls801FindWorkerDTO` records.
3. **Require a unique `PersonID` consensus** ([BR-CE-022](../business-rules.md#br-ce-022-worker-lookup-requires-unique-personid-consensus-and-uses-a-14-day-injury-date-window-for-same-claim-detection)). 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.*
4. **Check for an existing claim within the injury-date window** ([BR-CE-022](../business-rules.md#br-ce-022-worker-lookup-requires-unique-personid-consensus-and-uses-a-14-day-injury-date-window-for-same-claim-detection)). 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.
   - 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.
   - If no same-claim match is found: the resolved worker is used to prefill submission-data contacts (see [801 submission data CRUD](801-submission-data-crud.md), `LoadClaimWorker`), but no existing `ClaimID` is adopted.
5. **Return the resolved worker (and adopted `ClaimID`, if any)** to the caller for use in completing the submission.

## Process flow

```mermaid
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](check-multiple-claims.md), 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.*

## Related documentation

- [Operations and processes](../operations-processes.md)
- [Business rules](../business-rules.md)
- [SQL catalog](../sql/index.md)
- [Database tables](../database-tables.md)

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