---
title: Update claim
summary: Persists changes to an existing claim header under optimistic concurrency, re-running the same New-status cascade as insert when applicable.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.Claim.Entry
reference_type: package
operation_id: OP-CE-03
trigger: Caller calls Save() on an existing claim object whose IsDirty flag is true and IsNew is false
---

# Update claim

Once a claim exists, subsequent edits are persisted through the update lifecycle. This operation binds every mutable claim-header field, enforces optimistic concurrency against the row's `UpdateNum`, and — because a claim can transition into New status after its first save — re-runs the same auxiliary-row cascade used by [Insert claim](insert-claim.md) whenever the current status is New.

| Field | Value |
| --- | --- |
| **Operation ID** | OP-CE-03 |
| **Trigger** | `Save()` invoked on a claim object where `IsNew = False` and `IsDirty = True` |
| **Inputs** | Modified claim header fields, `ClaimID`, current `UpdateNum` |
| **Outputs** | Updated `CL_INJURY_CLAIM` row with `UpdateNum` incremented; conditional auxiliary rows for New-status claims; `UpdateError` broken rule on concurrency conflict |
| **Primary components** | `clsClaimEntry.BeforeUpdate`, `clsClaimEntry.AfterUpdate`, `clsClaimEntry.AddNewStatusData` |
| **Entry point** | `Business\SAIF.Business.Claim.Entry\clsClaimEntry.vb` |

## Steps

1. **Apply New-status defaulting.** If `ClaimStatusCode = "N"` (New) at the time of save, `AddNewStatusData` re-applies the same New-status defaults used during insert, including the active-claim flag ([BR-CE-004](../business-rules.md#br-ce-004-active-claim-flag-is-y-only-when-status-is-new)).
2. **Bind and execute the update statement.** `BeforeUpdate` builds parameter bindings for every mutable claim-header field plus the `ClaimID`/`UpdateNum` predicate, and issues the update against `CL_INJURY_CLAIM` ([SQL-022](../sql/SQL-022.md), [CL_INJURY_CLAIM](../database-tables.md#cl_injury_claim)).
3. **Enforce optimistic concurrency.** The update's `WHERE` clause matches on both `ClaimID` and the caller-supplied `UpdateNum`; `AfterUpdate` inspects the rows-affected return value ([BR-CE-011](../business-rules.md#br-ce-011-optimistic-concurrency-update-fails-if-rowsaffected-1)).
   - If `RowsAffected <> 1`: add an `UpdateError` broken rule indicating the row was changed or deleted by another user since it was last retrieved, and do not increment `UpdateNum` in memory.
   - If `RowsAffected = 1`: increment `UpdateNum` on the in-memory object to match the newly persisted value.
4. **Re-run the New-status auxiliary cascade.** When `ClaimStatusCode = "N"`, the same save cycle persists request-decision, status-activity, type-activity, MCO-eligibility, and policy-history rows exactly as in the insert path ([BR-CE-013](../business-rules.md#br-ce-013-saving-a-new-status-claim-cascades-auxiliary-status-rows), [SQL-005](../sql/SQL-005.md), [SQL-006](../sql/SQL-006.md), [SQL-007](../sql/SQL-007.md), [SQL-008](../sql/SQL-008.md), [SQL-009](../sql/SQL-009.md)).
5. **Return the saved object** with the updated `UpdateNum`, or the broken-rule collection populated with the concurrency-conflict error.

## Process flow

```mermaid
flowchart TD
	Start([Save called on existing claim]) --> StatusCheck{ClaimStatusCode = New?}
	StatusCheck -->|Yes| NewData[Apply New-status<br>defaults]
	StatusCheck -->|No| Update[Update CL_INJURY_CLAIM<br>WHERE ClaimID and UpdateNum]
	NewData --> Update
	Update --> Rows{RowsAffected = 1?}
	Rows -->|No| Conflict([Raise UpdateError<br>broken rule])
	Rows -->|Yes| Increment[Increment UpdateNum<br>in memory]
	Increment --> HistoryCheck{ClaimStatusCode = New?}
	HistoryCheck -->|Yes| History[Persist auxiliary<br>status rows]
	HistoryCheck -->|No| Return([Return saved claim])
	History --> Return
```

## Failure and edge-case behavior

- A concurrent update by another session between retrieval and save produces a rows-affected value of `0`, which surfaces as an `UpdateError` broken rule rather than a silent no-op or exception ([BR-CE-011](../business-rules.md#br-ce-011-optimistic-concurrency-update-fails-if-rowsaffected-1)).
- Because business-rule bodies are commented out in `clsClaimEntryBusinessRules.vb`, field-level validation before the update executes relies entirely on database constraints and the optimistic-concurrency check.*
- If a claim's status is changed to New after its initial insert, the same auxiliary-row cascade runs again on every subsequent save while the status remains New, which could produce duplicate auxiliary rows if the underlying SQL does not guard against re-insertion; no such guard was found 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\clsClaimEntry.vb`