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

# The patient journey

> How Synthpop models the patient journey — intake, coverage, and engagement — through one uniform Task API.

Synthpop is organized around a single idea: the work you do for a patient is not
three disconnected systems, it is one journey. A referral arrives, coverage has to
be confirmed, and the patient has to be moved forward. You reach every stage of
that arc through **one uniform interface — the Task** — so you learn the model
once and use it for whatever your organization has enabled.

## One resource, three stages

There are no capability-specific endpoints. Everything you build starts with the
same call, `POST /task/create`, and the only lever that changes what Synthpop does
is the **`task_type`** you pass. Intake, coverage, and engagement are not separate
products with separate APIs; they are different `task_type` values flowing through
the same create → process → read loop.

<Note>
  Task types are **provisioned for your organization** during onboarding. There is
  no discovery endpoint — the concrete values available to you come from your
  Synthpop contact. Passing an unprovisioned type returns
  `400 "Task type 'X' not in list of tasks for your organization: [...]."`
</Note>

```mermaid theme={null}
flowchart LR
    P((Patient / case<br/>external_id)) --> A[Intake + coverage<br/>validation Task]
    P --> B[Engagement<br/>voice Task · inbound & outbound]
    A --> RA[TaskDetails]
    B --> RB[TaskDetails]
```

## Following one patient through

<Steps>
  <Step title="Intake — turn documents into structured data">
    A packet lands: a multi-page fax, a scanned order, an insurance card, a
    clinical note. You upload it as-is. Synthpop classifies each document, extracts
    the clinical and demographic detail, and returns it as structured
    [medical records](/concepts/data-items#medical-records) on the Task — no
    templates, no manual keying.

    This is the mainline capability. See
    [Referral & order intake](/guides/intake/overview).
  </Step>

  <Step title="Coverage — decide whether the documentation holds up">
    With the records in hand, Synthpop evaluates the submission against the
    clinical criteria and the patient's payer policy. The outcome is expressed as
    [Results](/concepts/results): a per-code verdict (approved or not), the
    specific issues that stand in the way, and a plain-English conclusion you can
    show a human.

    Coverage is evaluated **within a validation Task** — its results appear in the
    same response, not behind a separate call. See
    [Coverage & authorization](/guides/coverage/overview).
  </Step>

  <Step title="Engagement — move the patient forward">
    When something is missing or a patient needs to be reached, engagement runs as
    its **own Task** (a voice `task_type`, for enabled organizations). The voice
    agent places **outbound** calls and handles **inbound** ones, working the
    follow-up end to end. Same Task model, same `TaskDetails` shape as every other
    capability — a separate Task, tied to the patient's other work by your
    `external_id`.

    See [Patient engagement](/guides/engagement/overview).
  </Step>
</Steps>

## Why it reads as one flow

Because every capability speaks the same Task model, what you learn once applies
everywhere — and you tie a patient's Tasks together with `external_id`:

* **One response shape.** Every Task returns a
  [`TaskDetails`](/concepts/tasks) object. Learn its
  [Data Items](/concepts/data-items) and [Results](/concepts/results) once and you
  can read intake, coverage, and engagement the same way.
* **One asynchronous model.** Every Task is created immediately with
  `status: "pending"` and processed in the background. You observe progress the
  same way everywhere — polling `GET /task/get` or receiving a callback. See
  [Async results](/guides/async-results).
* **One correlation key.** Attach your own `external_id` on create and thread it
  through every Task for a patient to tie Synthpop's work back to the case in your
  system.

<Note>
  **A journey is one or more Tasks — you stitch them together, not Synthpop.**
  Intake and coverage share a validation Task; engagement is a separate voice
  Task; a superseding submission is another Task again. There is no parent/child
  field on a Task — correlate a patient's Tasks yourself with `external_id` and
  [`GET /task/list`](/guides/listing-tasks).
</Note>

## Where to go next

<CardGroup cols={2}>
  <Card title="Tasks" icon="cube" href="/concepts/tasks">
    The core resource and its status lifecycle.
  </Card>

  <Card title="Data Items" icon="layer-group" href="/concepts/data-items">
    Inputs, outputs, and extracted medical records.
  </Card>

  <Card title="Results" icon="clipboard-check" href="/concepts/results">
    Verdicts, issues, and conclusions.
  </Card>

  <Card title="Quickstart" icon="rocket" href="/quickstart">
    From an API key to a validated Task.
  </Card>
</CardGroup>