---
title: Medical condition retrieval
summary: Retrieves medical-condition detail for a claim, either a single condition by inline SQL or the full condition list via the claim conditions API.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.View.Claim
reference_type: package
operation_id: OP-VC-07
trigger: Caller reads `clsClaimData.MedicalConditions` (list, API-backed), or calls `clsMedicalConditionData.GetMedicalCondition` directly (single condition, SQL-backed)
---

# 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.
   - On a non-200 status: an error message is added (`"An Error occurred when CCClaimDataApi was called"`) and no conditions are added.
4. **Single-condition path — provide claim and condition identifiers.** The caller provides a claim ID and medical condition ID to `GetMedicalCondition`.
5. **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](../sql/SQL-022.md), [cl_medical_condition](../database-tables.md#cl-medical-condition), [condition_type_code](../database-tables.md#condition-type-code), [claim_decision_code](../database-tables.md#claim-decision-code), [claim_denial_final_reas_cd](../database-tables.md#claim-denial-final-reas-cd), [claim_denial_reason_code](../database-tables.md#claim-denial-reason-code), [claim_denial_status_code](../database-tables.md#claim-denial-status-code)).
6. **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](../business-rules.md#br-004-medical-condition-detail-uses-the-latest-compensability-decision), [cl_cond_compensability_decisn](../database-tables.md#cl-cond-compensability-decisn)).
7. **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.

```mermaid
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.**

## 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. 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`