---
title: Work status and work release tracking
summary: Records and maintains the worker's return-to-work status and the physician's work release status for a claim, always operating on the most recent sequence.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.Claim
reference_type: package
operation_id: OP-BC-11
trigger: A claim-maintenance caller creates or retrieves the current work status or work release status for a claim and saves it
---

# Work status and work release tracking

Two closely related histories are kept for every claim: the work status, which records when the worker actually returned to work, and the work release status, which records when a physician released the worker to work and under what restriction. Both are sequence-numbered histories, both always expose the latest entry, and both are implemented as the same shape of business object, so they are documented together.

| Field | Value |
| --- | --- |
| **Operation ID** | OP-BC-11 |
| **Trigger** | `clsClaimWorkStatus.NewClaimWorkStatus` / `GetClaimWorkStatus`; `clsClaimWorkReleaseStatus.NewClaimWorkReleaseStatus` / `GetClaimWorkReleaseStatus`; followed by `save()` |
| **Inputs** | `ClaimID`; the return-to-work date or the work release date; the work status code or work release code; `UpdateNum`; the acting portal user |
| **Outputs** | A sequence-numbered `CL_CLAIM_WORK_STATUS` or `CL_CLAIM_WORK_RELEASE_STATUS` row; the `HasData` indicator on the release object; error messages `InsertError`, `UpdateError`, `DeleteError`, and rule failures |
| **Primary components** | `clsClaimWorkStatus` (`BeforeCreate`, `AfterCreate`, `ValidWorkStatusDate`), `clsClaimWorkReleaseStatus` (`BeforeCreate`, `AfterCreate`, `Fill`, `ValidWorkReleaseDate`, `HasData`) |
| **Entry point** | `Business\SAIF.Business.Claim\clsClaimWorkStatus.vb` |

## Steps

1. **Reserve a sequence number.** `BeforeCreate` issues a scalar request against the appropriate Oracle sequence — the work status sequence for work status rows ([SQL-003](../sql/SQL-003-saif-business-claim.md), [CLAIM_WORK_STATUS_SEQ](../database-tables.md#claim_work_status_seq)) or the work release status sequence for release rows ([SQL-002](../sql/SQL-002-saif-business-claim.md), [CLAIM_WORK_REL_STATUS_SEQ_NUM](../database-tables.md#claim_work_rel_status_seq_num)).
2. **Seed the new row.** `AfterCreate` assigns the returned sequence number, stores the claim identifier and the acting portal user, sets the update number to zero, and defaults the status code to the numeric-zero character. The release object additionally raises its `HasData` indicator.
3. **Validate the dates before saving.** Each object registers a date rule that runs before persistence:
   - The work status object rejects a return-to-work date that is populated and later than the current moment ([BR-005](../business-rules.md#br-005-date-the-worker-returned-to-work-must-be-valid)).
   - The work release object rejects an invalid work release date at the framework's second rule-check level ([BR-003](../business-rules.md#br-003-work-release-date-must-be-valid)), and separately refuses to save when no work release status data is present at all ([BR-004](../business-rules.md#br-004-work-release-status-data-must-be-present)).
4. **Insert the row.** `save()` applies the pending edit level and delegates to the framework save, which inserts the sequence number, claim identifier, date, `SYSDATE`, update number, and update user.
   - The work status insert hard-codes a work status code of `1`, so a new work status row always starts in that state regardless of what the caller set ([SQL-007](../sql/SQL-007-saif-business-claim.md), [CL_CLAIM_WORK_STATUS](../database-tables.md#cl_claim_work_status)).
   - The work release insert binds the work release code supplied by the caller ([SQL-006](../sql/SQL-006-saif-business-claim.md), [CL_CLAIM_WORK_RELEASE_STATUS](../database-tables.md#cl_claim_work_release_status)).
   - If exactly one row is not affected: add `InsertError` carrying the framework database contention message; otherwise the previous insert error is cleared ([BR-008](../business-rules.md#br-008-updatedelete-row-count-must-equal-1)).
5. **Retrieve the current entry.** `GetClaimWorkStatus` and `GetClaimWorkReleaseStatus` select the row for the claim whose sequence number is the maximum for that claim, so callers always see the latest history entry and never an earlier one ([BR-019](../business-rules.md#br-019-work-status-and-work-release-retrieval-returns-only-the-most-recent-sequence), [SQL-020](../sql/SQL-020-saif-business-claim.md), [SQL-019](../sql/SQL-019-saif-business-claim.md), [CL_CLAIM_WORK_STATUS](../database-tables.md#cl_claim_work_status), [CL_CLAIM_WORK_RELEASE_STATUS](../database-tables.md#cl_claim_work_release_status)).
   - The release object raises its `HasData` indicator as part of filling, so the presence rule in step 3 passes only for a row that actually came back.
6. **Update the row.** Saving an existing row writes the date, `SYSDATE`, an incremented update number, and the update user, keyed on the claim identifier, sequence number, and prior update number ([SQL-034](../sql/SQL-034-saif-business-claim.md), [SQL-033](../sql/SQL-033-saif-business-claim.md)).
   - The work status update never writes the work status code column, so the code assigned at insert can never be changed through this object.
   - If exactly one row is not affected: add `UpdateError` carrying the framework database contention message ([BR-008](../business-rules.md#br-008-updatedelete-row-count-must-equal-1)).
7. **Delete the row.** Deleting removes the row by claim identifier, sequence number, and prior update number ([SQL-045](../sql/SQL-045-saif-business-claim.md), [SQL-044](../sql/SQL-044-saif-business-claim.md)).
   - If exactly one row is not affected: add `DeleteError` carrying the framework database contention message ([BR-008](../business-rules.md#br-008-updatedelete-row-count-must-equal-1)).

## Process flow

The following diagram visualizes this operation's control flow.

```mermaid
flowchart TD
	Start([Caller opens a work status or<br>work release status for a claim]) --> Mode{New or existing?}
	Mode -->|New| Seq[Read the next value from<br>the matching Oracle sequence]
	Seq --> Seed[Seed claim, user, update number<br>and default status code]
	Mode -->|Existing| Get[Select the row with the highest<br>sequence number for the claim]
	Get --> Fill[Fill the object and raise<br>the has-data indicator]
	Seed --> Edit[Caller sets the date<br>and status code]
	Fill --> Edit
	Edit --> Rules{Date valid and<br>data present?}
	Rules -->|No| RuleErr([Rule messages surface;<br>save is refused])
	Rules -->|Yes| Write{New row?}
	Write -->|Yes| Ins[Insert the sequenced row]
	Write -->|No| Upd[Update keyed on claim, sequence<br>and prior update number]
	Ins --> IRows{Rows affected = 1?}
	Upd --> URows{Rows affected = 1?}
	IRows -->|No| IErr([Add InsertError])
	URows -->|No| UErr([Add UpdateError])
	IRows -->|Yes| Done([Row persisted])
	URows -->|Yes| Done
```

## Failure and edge-case behavior

- Because retrieval always returns the highest sequence number, earlier history entries are unreachable through these objects; reading the full history requires a different query.
- The work status code column is written only at insert and never at update, so correcting a mis-set work status requires deleting and re-inserting the row.
- A new work status row is always inserted with the hard-coded status code, so the value the caller placed on the object before saving is silently discarded.
- The two objects express their concurrency check differently — one increments the update number from the bound parameter and the other increments the column value — so a caller reasoning about concurrency must read each statement rather than assume symmetry.*
- The work status object registers only the date rule, so nothing prevents saving a row that carries no meaningful status data, unlike the release object which enforces a presence rule.
- The sequence number is consumed at create time, so an abandoned edit permanently burns a sequence value.
- A return-to-work date exactly equal to the current moment passes the rule; only strictly later dates are rejected.*

## 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\clsClaimWorkStatus.vb`
- `Business\SAIF.Business.Claim\clsClaimWorkReleaseStatus.vb`