Medical condition management

Medical condition management maintains three related record families for a claim: medical conditions, their compensability decision history, and the separate list of omitted or denied conditions. Conditions edit their current decision through a working copy so that history rows are never mutated by accident, diagnosis codes are validated live against the diagnosis catalog under date-gated ICD-9 and ICD-10 rules, and a successful save queues follow-up claim tasks for denial reviews, appeal-stay interest, and deferred decisions.

Field	Value
Operation ID	OP-CM-09
Trigger	Caller invokes clsMedicalConditionCollection.GetMedicalConditionCollection(dataPortal, claimData), edits condition, decision, or omitted-condition properties, and calls Save() on the collection
Inputs	ClaimID through the claim data object; per condition MedicalConditionDescr, MedicallyStationaryDate, MajorContributingCauseFLCD, ConditionTypeCode, DiagnosisCode, RequestDate, FormallyRequestedCode; per decision DecisionCode, DecisionDate, DenialStatusCode, DenialStatusEffDate, DenialReasonCode, DenialFinalReasonCode; per omitted condition the equivalent description, type, request, and denial fields
Outputs	Persisted rows in the medical condition, condition compensability decision, and omitted/denied condition tables; generated claim tasks for denial, appeal, and deferred-decision follow-up; broken-rule errors and warnings when validation fails
Primary components	clsMedicalCondition and clsMedicalConditionCollection (Add, Save, DeterimineTasks, WriteTasks), clsConditionDecision and clsConditionDecisionCollection (CurrentDecision, PriorDecisionDate, DecisionHistory, Copy, DiscardCopy, MarkOriginalDirty), clsOmittedCondition and clsOmittedConditionCollection
Entry point	Business\SAIF.Business.Claim.Maintenance\clsMedicalConditionCollection.vb

Steps

1. Retrieve the claim's conditions. GetMedicalConditionCollection calls the portal retrieve with a criteria carrying the claim data; BeforeRetrieve caches the claim data and binds the claim identifier (SQL-069, CL_MEDICAL_CONDITION). Each row is loaded into a condition object, added to the collection, and used to track the running maximum identifier; the collection is then positioned on the first item.
2. Lazily load each condition's decision history. The first access to a condition's decisions retrieves the decision collection for that condition and claim and registers it as a child (SQL-062, CL_COND_COMPENSABILITY_DECISN), ordered by decision identifier descending.
3. If no decision rows exist, a brand-new deferred decision is added.
4. Otherwise the highest-identifier decision is remembered as the original, and a working copy of it — identifier reset to zero, marked as a copy, marked clean — is inserted at the head so consumers edit a scratch copy rather than the persisted history row.
5. Retrieve the omitted and denied conditions. The omitted-condition collection uses its own criteria, binds the claim identifier, and reads its rows ordered by decision date and identifier ascending (SQL-071, CL_OMITTED_COND_DENIED). It is a sibling of the medical-condition collection, not a child of it.
6. Create a new medical condition. Create() sets the acting user, zero update number, current update date, zero identifier, blank description, empty medically-stationary date, blank major-contributing-cause flag, the original condition type, blank formally-requested code, the claim identifier from the criteria, and an empty diagnosis code; it then builds a fresh decision collection containing one new deferred decision.
7. Assign identifiers on add. The collection's add override assigns the next sequential condition identifier from an in-memory counter seeded by the maximum identifier seen at retrieve time, propagates that identifier onto every child decision, and then adds the item. The omitted-condition collection applies the same pattern to its own identifier.
8. Edit fields. Setting any tracked property marks the object dirty; decision and omitted-condition fields additionally record that the object was modified and latch flags recording whether the decision code changed to denied or to deferred, which later drive both validation and task generation.
9. Validate bottom-up. The collection rules require at least one condition once the claim is closed, open, or denied, and warn — without blocking — when a closed claim has an accepted condition with no medically-stationary date. Each condition then runs its own field rules, validates its child decision collection, and each decision runs its own field rules. None of these in-code rule identifiers is catalogued as a numbered business rule for this library.*
10. Validate the diagnosis code against the catalog. The ICD-9 check runs only when the claim's injury date precedes the ICD-10 effective date of 1 October 2015, and the ICD-10 check only on or after that date; each issues a scalar lookup, and only when the diagnosis code value was modified and non-blank (SQL-067, SQL-068, CBP_DIAGNOSIS). The ICD-10 check additionally detects an ICD-9 code entered on an ICD-10 claim and reports a distinct message.
11. Guard the decision-date ordering. A dirty condition is rejected when its current decision date is earlier than the previously persisted decision's date, preventing an out-of-order decision history.*
12. Save the conditions. Save() applies the pending edit and the base save walks the dirty, new, and deleted conditions. For each condition, a deleted item takes the delete path, otherwise the condition's own changed fields are inserted (SQL-014, CL_MEDICAL_CONDITION) or updated (SQL-096, CL_MEDICAL_CONDITION), and the decision collection is then always cascaded.
13. Resolve the working copy on decision save. The decision collection applies its pending edit, then:
    • If the current decision is a copy and qualifies to reuse the original — judged from whether the decision code was originally deferred and has now been modified, and whether the code or date changed — the copy is discarded and marked clean, its values are pushed back onto the original persisted decision, and the original is forced into the save set as an update (SQL-094, CL_COND_COMPENSABILITY_DECISN).
    • Otherwise the copy is retained and saved as a brand-new history row (SQL-011, CL_COND_COMPENSABILITY_DECISN).

14. Generate follow-up tasks after a successful condition save. The task determination walks the dirty conditions and queues tasks:

    • A denied decision that was just changed to denied queues a seventy-day denial review task, using a different task number for injury and aggravation requests.
    • An appeal denial status queues a stayed-compensation-interest task with a ninety-day offset.
    • On a state-jurisdiction claim with a deferred decision, an injury date before 1 January 2002 queues ninety- and forty-five-day decision-due tasks for new conditions and a thirty-day task for omitted conditions, with duplicate suppression; an injury date on or after that date queues a unified sixty-day and thirty-day review pair regardless of condition type.
    • Queued tasks are persisted only when at least one task was produced.
    • Sub-step: the task generator writes the queued claim tasks, applying the duplicate suppression comparison and the prior-work-day date adjustment.

    Origin: clsClaimTaskGenerator is implemented in SAIF.Business.Tasks.Claim and executed on behalf of this operation. That library is documented in the previous format, so no per-operation page exists; see Operations and processes in the SAIF.Business.Tasks.Claim documentation set. 13. Delete a medical condition. The delete hook first clears and cascades a save of the decision collection, removing the persisted history rows, then issues the parent delete keyed by claim identifier, condition identifier, and update number; a rows-affected value other than one raises the DB contention error (SQL-115, CL_MEDICAL_CONDITION) (BR-CM-001). 14. Maintain omitted conditions. The omitted condition is a flatter object with its decision fields on the row itself and no child history: create seeds a deferred decision code directly, and the lifecycle writes an insert (SQL-015, CL_OMITTED_COND_DENIED), an update (SQL-097, CL_OMITTED_COND_DENIED), or a delete keyed by omitted-condition identifier, claim identifier, and update number (SQL-116, CL_OMITTED_COND_DENIED) (BR-CM-001). 15. Generate omitted-condition tasks. The omitted-condition task logic mirrors the medical-condition logic with its own task wording, and splits the deferred pre-2002 state-jurisdiction branch into both a ninety-day and a forty-five-day due-date task, keyed off the condition type enumeration rather than the medical-condition string constants.

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([GetMedicalConditionCollection claim]) --> Read[Select medical conditions<br>for the claim]
    Read --> Lazy[On first access, load each<br>condition's decision history]
    Lazy --> Copy{Decision rows exist?}
    Copy -->|No| Defer[Add a new deferred decision]
    Copy -->|Yes| Work[Remember original;<br>insert working copy at head]
    Defer --> Edit
    Work --> Edit[Caller edits conditions,<br>decisions, omitted conditions]
    Edit --> Valid[Collection rules, condition rules,<br>decision rules]
    Valid --> Diag{Diagnosis code modified?}
    Diag -->|Yes| Lookup[Date-gated ICD-9 or ICD-10<br>lookup against the diagnosis catalog]
    Diag -->|No| Order[Decision date must not precede<br>the prior decision date]
    Lookup --> Order
    Order --> Ok{Any error-severity<br>rule broken?}
    Ok -->|Yes| Invalid([Save blocked;<br>warnings alone do not block])
    Ok -->|No| Save[Save applies edit,<br>walks dirty conditions]
    Save --> State{Condition state}
    State -->|Deleted| DelKids[Clear and save decisions,<br>then delete the condition]
    State -->|New| Ins[Insert condition]
    State -->|Modified| Upd[Update condition]
    Ins --> Cascade[Cascade decision collection save]
    Upd --> Cascade
    DelKids --> Rows
    Cascade --> Reuse{Working copy reuses<br>the original decision?}
    Reuse -->|Yes| UpdD[Discard copy;<br>update the original row]
    Reuse -->|No| InsD[Insert a new history row]
    UpdD --> Rows{Expected rows affected?}
    InsD --> Rows
    Rows -->|No| Err([DB contention or insert error;<br>save reports failure])
    Rows -->|Yes| Tasks[Determine and write<br>follow-up claim tasks]
    Tasks --> Done([Save succeeded])

Failure and edge-case behavior

• Insert, update, and delete failures are detected purely by the affected row count in each after-hook; a mismatch adds the DB contention message, or a literal insert-failure message for inserts, leaving a broken rule so the overall save reports failure (BR-CM-001).
• The "at least one condition" rule blocks saving only once the claim status is closed, open, or denied; new or incomplete claims are exempt.
• The closed-claim medically-stationary check is a warning rather than an error, so a closed claim with an accepted condition and no medically-stationary date can still be saved once the user confirms.
• Diagnosis-code validation is date-gated on the ICD-10 effective date, so exactly one of the two catalog checks applies to a given claim, and the ICD-10 branch additionally reports an ICD-9 code entered by mistake.
• Reverting a decision to deferred is blocked once any decision in the history was accepted or denied, but only when the current decision object itself was modified, so unmodified deferred history rows are not retroactively flagged.
• Because the current decision is a working copy rather than the persisted instance, a misclassification of whether to reuse the original would silently update the original row instead of creating new history, or the reverse.*
• Reverting an omitted condition to deferred is blocked only when the decision was changed to deferred in the current edit session; a companion "changed to denied" check exists in source but is inactive.
• The denial-status, denial-reason, denial-type, and final-reason required-field rules apply only to state-jurisdiction claims; out-of-state and federal claims skip them entirely.
• All future-date tolerances on the medically-stationary, request, decision, denial-effective, and omitted-decision dates use a fixed seven-day allowance regardless of jurisdiction or claim status.
• Duplicate task suppression compares only the trimmed task text plus a computed prior-work-day-adjusted date, so a task with slightly different wording or a different computed date would not be recognized as a duplicate and could be queued twice.

Related documentation

• Operations and processes
• Business rules
• SQL catalog
• Database tables

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.Maintenance\clsMedicalCondition.vb
• Business\SAIF.Business.Claim.Maintenance\clsMedicalConditionCollection.vb
• Business\SAIF.Business.Claim.Maintenance\clsConditionDecision.vb
• Business\SAIF.Business.Claim.Maintenance\clsConditionDecisionCollection.vb
• Business\SAIF.Business.Claim.Maintenance\clsOmittedCondition.vb
• Business\SAIF.Business.Claim.Maintenance\clsOmittedConditionCollection.vb