Skip to content

Medical condition retrieval

This operation retrieves medical-condition detail for a claim, together with the latest compensability decision and denial metadata. There are two retrieval paths that populate the same clsMedicalConditionData shape: the list path used by clsClaimData.MedicalConditions retrieves all conditions for a claim through the claim conditions API and maps each row via Load; the single-condition path (clsMedicalConditionData.GetMedicalCondition) queries Oracle directly for one claim/condition pair and is available for callers that already know the specific medical condition ID.

Field Value
Operation ID OP-VC-07
Trigger Caller reads clsClaimData.MedicalConditions (routes through clsMedicalConditionList), or calls clsMedicalConditionData.GetMedicalCondition(dataPortalInfo, claimID, medicalConditionID) directly
Inputs Claim ID (list path); claim ID and medical condition ID (single-condition path)
Outputs clsMedicalConditionList of clsMedicalConditionData (list path); single clsMedicalConditionData (single-condition path) — medical-condition description, decision, denial, and diagnosis data
Primary components clsMedicalConditionList.BeforeRetrieve/AfterRetrieve, clsMedicalConditionData.Load, clsMedicalConditionData.Criteria.RetrieveSQL, clsMedicalConditionData.GetMedicalCondition
Entry point Business\SAIF.Business.View.Claim\clsMedicalConditionList.vb, Business\SAIF.Business.View.Claim\clsMedicalConditionData.vb

Steps

  1. List path — select the conditions route. clsMedicalConditionList.BeforeRetrieve sets the API route to the claim-conditions endpoint for the given claim ID.
  2. List path — call the conditions API. The framework dispatches the request and returns ResponseData(Of ClaimConditions).
  3. List path — map condition rows. AfterRetrieve checks StatusCode = HTTP 200 and, for each Condition row, constructs a clsMedicalConditionData and calls Load(dataPortalInfo, row) to populate it, adding it to the collection.
  4. On a non-200 status: an error message is added ("An Error occurred when CCClaimDataApi was called") and no conditions are added.
  5. Single-condition path — provide claim and condition identifiers. The caller provides a claim ID and medical condition ID to GetMedicalCondition.
  6. Single-condition path — join to reference and decision data. The query joins the medical-condition row to condition-type and decision reference tables (SQL-022, cl_medical_condition, condition_type_code, claim_decision_code, claim_denial_final_reas_cd, claim_denial_reason_code, claim_denial_status_code).
  7. Single-condition path — select the latest compensability decision. A correlated subquery selects the maximum COND_COMP_DECISION_ID for the claim and medical condition, keeping only the most recent decision row (BR-004, cl_cond_compensability_decisn).
  8. Return the object. Either path returns a flattened medical-condition view to the caller.

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([Caller requests medical condition data]) --> Which{List for claim,<br>or single condition by ID?}
    Which -->|List| Route[Set claim-conditions API route]
    Route --> Call[Call conditions API]
    Call --> Status{API status 200?}
    Status -->|No| Err([Error message added; no conditions returned])
    Status -->|Yes| MapEach[Load each Condition row into clsMedicalConditionData]
    MapEach --> DoneList([Return clsMedicalConditionList])
    Which -->|Single condition| Join[Join condition to type,<br>decision, and denial reference tables]
    Join --> Latest[Select latest compensability decision]
    Latest --> DoneSingle([Return single clsMedicalConditionData])

Failure and edge-case behavior

  • A non-200 status from the conditions API yields an empty condition list plus an error message rather than a thrown exception.
  • The single-condition SQL path and the API-backed list path can, in principle, return conditions with different underlying data if the API and Oracle sources fall out of sync; no reconciliation logic was found between the two paths.*
  • Table names in the single-condition query are unqualified, so schema ownership could not be confirmed from source alone.**

Note: Statements marked with * were inferred from code structure, naming conventions, or contextual evidence where direct confirmation was not available in source artifacts. Statements marked with ** could not be confirmed; treat as unknown until verified.

Sources

  • Business\SAIF.Business.View.Claim\clsMedicalConditionList.vb
  • Business\SAIF.Business.View.Claim\clsMedicalConditionData.vb