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

# Patient engagement

> Reach patients through voice and digital outreach to gather missing information and move cases forward — delivered as Tasks, using the same API you already integrate.

Intake and coverage tell you what a case needs. **Patient engagement** is how that
need gets closed: reaching the patient — by voice or digital outreach — to gather a
missing detail, confirm information, or move the case to its next step. Synthpop
delivers engagement through the same resource as everything else, the **Task**, so
you orchestrate outreach with the API you have already integrated. Voice
outreach alone already runs at **3,000+ patient calls a day and growing** —
the first healthcare AI agent in Google's Gemini Enterprise Agent Gallery,
running on Vertex AI — and it's built to be trustworthy by construction; see
[Trust & safety](/guides/engagement/trust) for how.

<Info>
  **Availability — engagement runs through Tasks, for enabled organizations.**
  Patient engagement is delivered by creating a Task with an engagement `task_type`
  and is available to organizations that have it **provisioned during onboarding**.
  There are **no engagement-specific endpoints** — no separate outreach or
  messaging API. If engagement is not enabled for your organization, ask your
  Synthpop contact. The [voice agent](/guides/engagement/voice-agent) is one
  engagement channel and has its own page.
</Info>

## What it does

Healthcare cases stall on small, human gaps: a form the patient never returned, a
number that needs confirming, a question only the patient can answer. Engagement
closes those gaps programmatically:

* **Voice outreach.** The [voice agent](/guides/engagement/voice-agent) places and
  handles patient phone calls on your behalf, has the conversation, and returns a
  structured outcome you can act on.
* **Digital outreach.** Reach patients through digital channels to collect or
  confirm information without a manual call.
* **Closed loop.** Whatever the channel, the outcome comes back on the Task — the
  same `TaskDetails` shape you already read — so a completed engagement flows
  straight back into your workflow.

Engagement is the third stage of the [patient journey](/concepts/patient-journey):
intake structures the documents, coverage checks the request, and engagement
reaches the patient to finish what those steps surfaced.

## How it fits the Task model

Engagement introduces no new resource and no new endpoints. It is the ordinary
create → process → read loop with an engagement `task_type`:

<Steps>
  <Step title="Create an engagement Task">
    `POST /task/create` with an engagement `task_type` and whatever context the
    outreach needs (for example, a `request_spec` describing what to collect, or an
    `external_id` correlating the Task to a case in your system).

    ```bash theme={null}
    curl -X POST "https://app.synthpop.ai/public/v1/task/create" \
      -H "Authorization: Bearer $SYNTHPOP_JWT_TOKEN" \
      -F "task_type=patient_outreach" \
      -F "external_id=case-4821"
    ```

    <Note>
      `patient_outreach` here is an **illustrative** placeholder, not a real value.
      Engagement `task_type`s are provisioned per organization during onboarding;
      your Synthpop contact tells you the concrete value to use. Passing an
      unprovisioned type returns `400 "Task type 'X' not in list of tasks for your organization: [...]."`
    </Note>
  </Step>

  <Step title="Synthpop runs the outreach">
    The Task moves through `processing` while Synthpop carries out the outreach.
    Engagement can take time — a patient may not answer immediately — so, as with
    every Task, you observe progress asynchronously rather than blocking on the
    create call. (See [voice agent capabilities](/guides/engagement/capabilities)
    for what a call can do, and [Trust & safety](/guides/engagement/trust) for
    why you can rely on the outcome.)
  </Step>

  <Step title="Read the outcome">
    Poll `GET /task/get` (or receive an opt-in callback) until the Task reaches a
    terminal status. The result — what was collected or confirmed — comes back as
    [Data Items](/concepts/data-items) and, where applicable,
    [Results](/concepts/results) on the same `TaskDetails`. If the Task needs more
    from you first, it pauses at `waiting`; see
    [Responding to waiting tasks](/guides/responding-to-waiting-tasks).
  </Step>
</Steps>

<Note>
  Engagement Tasks are **asynchronous**, like the rest of the API. `POST
      /task/create` returns immediately with `status: "pending"`; the outcome exists
  only after the Task reaches a terminal status. See
  [Working with async results](/guides/async-results). Statuses are exactly
  `pending`, `processing`, `waiting`, `completed`, `failed`, `invalid`.
</Note>

## Channels

<CardGroup cols={2}>
  <Card title="Voice agent" icon="phone" href="/guides/engagement/voice-agent">
    Place and handle patient phone calls, and read back a structured outcome.
  </Card>

  <Card title="Digital outreach" icon="messages">
    Reach patients through digital channels to collect or confirm information —
    created and read exactly like any other Task.
  </Card>

  <Card title="Voice agent capabilities" icon="list-check" href="/guides/engagement/capabilities">
    What the voice agent can do on a call, and the guardrail behind each
    capability.
  </Card>

  <Card title="Trust & safety" icon="shield-check" href="/guides/engagement/trust">
    Why you can rely on what a call says and does.
  </Card>
</CardGroup>

## Good to know

<AccordionGroup>
  <Accordion title="No engagement-specific endpoints">
    Everything runs through the same handful of Task endpoints in the
    [API reference](/api-reference/introduction). The `task_type` you pass on
    create is the only lever that turns a Task into an engagement Task — there is no
    separate outreach, messaging, or telephony API.
  </Accordion>

  <Accordion title="Correlate engagement to the case that triggered it">
    Set `external_id` on create to tie an engagement Task back to the intake or
    coverage case it follows up on, then find related Tasks with
    [`GET /task/list`](/guides/listing-tasks). There is no parent/child field on the
    Task — you correlate with your own identifiers.
  </Accordion>

  <Accordion title="Engagement is provisioned, not self-serve">
    Engagement `task_type`s are enabled per organization. If you don't see the
    behavior described here, engagement likely isn't provisioned for your org yet —
    your Synthpop contact can confirm what's enabled.
  </Accordion>
</AccordionGroup>

## Where to go next

<CardGroup cols={2}>
  <Card title="Voice agent" icon="phone" href="/guides/engagement/voice-agent">
    The voice channel in detail.
  </Card>

  <Card title="Voice agent capabilities" icon="list-check" href="/guides/engagement/capabilities">
    What voice can do on a call, and the guardrail behind each capability.
  </Card>

  <Card title="Trust & safety" icon="shield-check" href="/guides/engagement/trust">
    Why you can rely on what a call says and does.
  </Card>

  <Card title="The patient journey" icon="route" href="/concepts/patient-journey">
    How intake, coverage, and engagement read as one flow.
  </Card>

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

  <Card title="Validate an order" icon="file-import" href="/guides/intake/validate-an-order">
    The concrete end-to-end Task pattern engagement reuses.
  </Card>
</CardGroup>