> ## Documentation Index
> Fetch the complete documentation index at: https://docs.medlistiq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Status values

> The 5 possible statuses and the rules that trigger each.

<Note>
  Status fields are surfaced today on responses from
  **`/v1/medications/infer`** (the FHIR endpoint). The PDF endpoint
  (**`/v1/med-lists/from-documents`**) doesn't expose `status` yet —
  status inference for document-derived medications is in progress.
</Note>

Inferred `status` follows FHIR's `MedicationRequest.status` vocabulary. Five
possible values, each with deterministic triggers.

## The table

| Status      | Triggered by                                                                                                                              |
| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| `active`    | `recent_dispense`, `active_order`, or `self_reported_active`                                                                              |
| `completed` | `course_completed` (explicit completed status or end date in the past) or `prescription_expired` (old order with no recent fill activity) |
| `stopped`   | `order_stopped` (`MedicationRequest.status = stopped`)                                                                                    |
| `cancelled` | `order_cancelled` (`MedicationRequest.status = cancelled`)                                                                                |
| `unknown`   | `insufficient_signal` (no rule fired) or `stale_data` (all data too old to use)                                                           |

## Precedence (when multiple rules fire)

```
active > completed > prescription_expired > stopped > cancelled > unknown
```

If both `active_order` and `order_stopped` fire on resources that resolve to
the same medication, `active` wins — the current state trumps historical
state.

## What raises and lowers confidence

* **Corroboration** — multiple active-leaning signals firing for the same
  medication raise confidence; corroborating evidence is the strongest
  indicator of a confident classification.
* **Missing date** — lowers confidence (the engine can't reason about recency)
* **Missing RxNorm code** — lowers confidence (less certainty that we
  deduplicated correctly)
* **Staleness** — older signals carry less weight than recent ones

## Filtering by status

Pass `statuses` in the request body to filter the response post-inference:

```json theme={null}
{
  "resources": [ ... ],
  "statuses": ["active"]
}
```

The engine still runs on all resources; the filter only trims the output
list. Good for "show me just active meds" without re-invoking.

## Special cases

<AccordionGroup>
  <Accordion title="Medications with only self-reported data">
    If a `MedicationStatement` has `reported=true` (patient-reported, not
    clinician-recorded), the `self_reported_active` rule fires with a lower
    base confidence. Clinician-recorded statements carry more weight.
  </Accordion>

  <Accordion title="Medications with no RxNorm code">
    Grouping still works on normalized display names, but `confidence` is
    lower since we can't confirm we're looking at the right drug across
    sources.
  </Accordion>

  <Accordion title="Prescriptions that expired without a dispense">
    If a `MedicationRequest` is `status=active` but the order is old and no
    `MedicationDispense` is on file, `prescription_expired` fires and
    status becomes `completed`. The order was never actually used.
  </Accordion>
</AccordionGroup>