---
title: EAIP claim and employer search
summary: Validates a set of EAIP search criteria, posts them to the EAIP integration API, and returns masked search results resolved against the EAIP status code table.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.Claim.EAIP
reference_type: package
operation_id: OP-EAIP-10
trigger: User populates clsSearchCriteria and calls clsSearchResult.GetSearchResults
---

# EAIP claim and employer search

The EAIP search screen lets a user find service periods by worker name, policy, return-to-work load, specialist, receipt date range, or EAIP status — in any combination, as long as there is at least one. This operation validates that the combination is coherent before spending a service call on it, posts the criteria to the EAIP integration API, and returns flat result rows with conflicted workers' names replaced by a literal placeholder. It performs no database access of its own.

| Field | Value |
| --- | --- |
| **Operation ID** | OP-EAIP-10 |
| **Trigger** | User populates a `clsSearchCriteria` and calls `clsSearchResult.GetSearchResults(dpi, criteria, showWorkerConflictName)` |
| **Inputs** | Worker first and last name; policy number with rate-account and parent-account indicators; policy name; return-to-work load code and mail identifier; EAIP specialist; initial receipt from/thru dates; a set of EAIP status code selections; a show-conflict-name flag |
| **Outputs** | A list of `EaipSearchResult` rows carrying claim, worker, policy, specialist, status, and date fields, with conflicted worker names replaced by "Confidential" and status codes resolved to descriptions; rule violations when the criteria are incoherent or empty |
| **Primary components** | `clsSearchCriteria` (property normalization, `Rule_ValidPolicyNumber`, `Rule_ValidParentNumber`, `Rule_ValidParentRate`, `Rule_ValidRtwLoadCode`, `Rule_ValidEaipStatusCode`, `Rule_ValidDateRange`, `Rule_HasAtLeastOneCriteria`), `clsEaipStatusCodeSelection`, `clsSearchResult` (`GetSearchResults`, `SearchQuery`), `EaipSearchResult` |
| **Entry point** | `Business\SAIF.Business.Claim.EAIP\Search\clsSearchResult.vb` |

## Steps

1. **Populate the criteria.** The user sets any combination of worker first and last name, policy number, policy name, rate-account and parent-account indicators, return-to-work load code, return-to-work mail identifier, EAIP specialist, and initial receipt date range.
2. **Normalize empty input.** Every string setter converts a blank or whitespace-only value to nothing rather than storing an empty string. This is what makes the "at least one criterion" check and the downstream payload treat an untouched field as absent instead of as a search for the empty string.
3. **Select statuses through the selection wrapper.** EAIP status filtering is expressed as a set of `clsEaipStatusCodeSelection` objects, each exposing active, inactive, and new booleans; setting one adds its status code to the selection set and clearing it removes the code. The criteria therefore always holds a normalized set of codes rather than a set of screen checkbox states.
4. **Validate the policy criteria.** `Rule_ValidPolicyNumber` and `Rule_ValidParentNumber` check the policy and parent-policy values individually, and `Rule_ValidParentRate` rejects selecting both the rate-account and parent-account indicators with the message "Select either rate or parent, not both." — the two are alternative ways of expanding a policy search and cannot be combined.
5. **Validate the remaining criteria.** `Rule_ValidRtwLoadCode` checks the return-to-work load code against its code table, `Rule_ValidEaipStatusCode` checks the selected statuses against the EAIP status code table, and `Rule_ValidDateRange` rejects an initial receipt range whose from-date falls after its thru-date.
6. **Require at least one criterion.** `Rule_HasAtLeastOneCriteria` rejects a wholly empty search, preventing an unfiltered scan of every EAIP claim. A worker-name-specific rule (`Rule_ValidNameSearch`) exists in the source but its registration is commented out, so partial-name searches are not currently constrained.
7. **Build the request.** `GetSearchResults` constructs the API criteria, resolving the configured `EaipApi` client and registering a single route, `V1/Integration/Search/`, as a retrieve-single-with-body call — the criteria set is too large for a query string, so it travels as a posted body.
8. **Post the criteria.** The criteria object is projected into an `EAIPSearchCriteria` payload and posted through the data portal's API access layer. The remote service performs the actual query; this library holds no SQL for it.
9. **Deserialize the results.** Each JSON element in the response is deserialized into an `EaipSearchResult`, a plain projection carrying the claim, worker, policy, specialist, status, and date fields the result grid displays.
10. **Mask conflicted workers.** `WorkerName` returns the constant "Confidential" whenever the row's conflict indicator is set. Note that the show-conflict-name flag captured when the search was constructed is not consulted by that property, so a caller authorized to see conflicted names still receives the masked value.*
11. **Resolve the status for display.** `EaipStatus` maps the row's raw status code through the EAIP status code table so the grid shows the description rather than the code.
12. **Return.** The populated result list is returned to the caller. The rows carry identifiers that the caller uses to open the underlying service period through [Service period management](service-period-management.md); the search rows themselves have no behavior and no save path.

## Process flow

The following diagram visualizes this operation's control flow.

```mermaid
flowchart TD
	Start([User fills in the EAIP search screen]) --> Norm[Setters normalize blanks to nothing;<br>status selections build a code set]
	Norm --> Val{Criteria valid?}
	Val -->|Rate and parent both selected| Rej([Rule violation reported])
	Val -->|Invalid load code or status| Rej
	Val -->|From date after thru date| Rej
	Val -->|No criteria at all| Rej
	Val -->|Yes| Route[Resolve EaipApi client;<br>register V1/Integration/Search/]
	Route --> Post[Post EAIPSearchCriteria payload<br>as retrieve-single-with-body]
	Post --> Des[Deserialize each JSON element<br>into EaipSearchResult]
	Des --> Mask[Conflicted rows return Confidential;<br>status code resolved to description]
	Mask --> Done([Result list returned])
```

## Failure and edge-case behavior

- The worker-name validation rule is present but not registered, so a single-character or wildcard-heavy name search is accepted and left for the remote service to constrain.
- The show-conflict-name flag is captured but never consulted by the masking property, so conflicted worker names appear as "Confidential" even to callers who were granted access — a likely latent defect.*
- All searching happens remotely. A service outage produces whatever the API access layer raises; this code adds no retry, no timeout handling, and no database fallback.*
- Result rows are a point-in-time snapshot with no change tracking and no update path; acting on a row requires loading the real service period.
- Statuses are filtered by an explicit code set, so a status added to the code table but not surfaced by the selection wrapper is unreachable from this screen.*
- Blank-to-nothing normalization means clearing a field is indistinguishable from never setting it; there is no way to search for records whose value is explicitly empty.

## Related documentation

- [Operations and processes](../operations-processes.md)
- [Business rules](../business-rules.md)
- [SQL catalog](../sql/index.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.EAIP\Search\clsSearchCriteria.vb`
- `Business\SAIF.Business.Claim.EAIP\Search\clsSearchResult.vb`
- `Business\SAIF.Business.Claim.EAIP\Search\EaipSearchResult.vb`
- `Business\SAIF.Business.Claim.EAIP\mdlCodeTables.vb`