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

# MedListIQ

> Medication list reconciliation. Send source data, like FHIR resources or clinical PDFs, get a clean deduplicated list.

MedListIQ takes the medication data you already have and returns one
deduplicated list per patient, with inferred status, coded fields, and an
auditable evidence trail.

Two ways in:

* **`POST /v1/medications/infer`** — FHIR resources from any EHR, pharmacy, or
  patient app. Mix `MedicationRequest`, `MedicationDispense`,
  `MedicationStatement`, and `Medication` freely. Status vocabulary mirrors
  FHIR (`active`, `completed`, `stopped`, `cancelled`, `unknown`), with
  per-medication confidence and a rule-trace evidence list.
* **`POST /v1/med-lists/from-documents`** — clinical PDFs (referrals, H\&Ps,
  discharge summaries, progress notes) for a single patient. We pull the
  medication mentions from each document and reconcile across the packet.
  Each medication carries the document / page / text-snippet evidence it
  was inferred from.

<CardGroup cols={2}>
  <Card title="FHIR quickstart" icon="play" href="/quickstart">
    First inference call from FHIR resources in under a minute.
  </Card>

  <Card title="PDFs quickstart" icon="file-pdf" href="/from-documents">
    Submit clinical PDFs and get back a deduplicated med list.
  </Card>

  <Card title="Understanding the output" icon="list" href="/guides/understanding-output">
    How to interpret `status`, `confidence`, and `evidence`.
  </Card>

  <Card title="Playground" icon="flask" href="https://medlistiq.com/dashboard/playground">
    Pre-loaded scenarios for both endpoints — or upload your own PDFs.
  </Card>
</CardGroup>

## How it works

<Steps>
  <Step title="You send the data you have">
    Structured FHIR resources, clinical PDFs, or both — whichever your source
    system produces. A typical referral packet might be 3-12 PDFs (H\&P,
    discharge summary, progress notes, labs); an EHR feed is usually a FHIR
    bundle. Mix and match across requests as needed.
  </Step>

  <Step title="We deduplicate and classify">
    Cross-source matches are reconciled into one entry per medication — the way
    a clinical pharmacist would read a list of orders, dispenses, narrative
    notes, and patient-reported meds and consolidate them. The FHIR pathway
    adds a status, a confidence score, and a rule trace; the PDF pathway
    preserves the document / page / text-snippet evidence behind every
    medication.
  </Step>

  <Step title="You get a clean list">
    One entry per medication with display name, code, status, dosage
    instructions, and the evidence trail. The FHIR endpoint lets you pick the
    response envelope (`inferred_list`, `fhir_bundle`, or `fhir_array` —
    see [Output formats](/guides/output-formats)). The PDF endpoint returns a
    fixed shape with per-mention evidence preserved.
  </Step>
</Steps>

## Key properties

* **Deterministic** — same input produces the same output. Every status change is auditable.
* **Versioned** — every response carries a `ruleset_version` (`YYYY-MM-DD.vN`) — in `meta` for FHIR responses, in the `x-ruleset-version` header for PDF responses. Pin to a version if you need behavior stability.
* **Stateless** — nothing is persisted about the patient. We don't store PHI.
* **RxNorm output** — every medication carries a canonical RxNorm code, consistent across Epic, Cerner, community-pharmacy sources, and document text.
* **FHIR-ready** — FHIR responses available as our ergonomic `inferred_list` or as FHIR R4 (`fhir_bundle` / `fhir_array`) depending on what your system consumes.