> For the complete documentation index, see [llms.txt](https://docs.mdintegrations.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mdintegrations.com/partner/key-concepts/patient-journey.md).

# Patient Journey

This page follows a patient interaction from checkout through fulfillment, showing how intake, clinical review, and pharmacy fulfillment connect into a single continuous flow.

{% stepper %}
{% step %}

#### Checkout

The patient selects an [Offerings](/partner/key-concepts/offerings.md) and completes a purchase on your storefront.
{% endstep %}

{% step %}

#### Intake

The patient completes an intake Questionnaire through a Voucher-driven [White-Label Apps](/partner/integration-paths/white-label-apps.md) or a [API](/partner/integration-paths/api.md).
{% endstep %}

{% step %}

#### Create the records

In the *white-label flow*, MDI creates or matches the [Patients & Encounters](/partner/key-concepts/patients-and-encounters.md) on your behalf.

In a *custom integration*, your application creates these same records through the API instead.
{% endstep %}

{% step %}

#### Queued

The Encounter enters `Created`. This status usually lasts seconds, not minutes, as the Encounter waits to be picked up.
{% endstep %}

{% step %}

#### Assignment

MDI assigns a physician, and the Encounter moves to `Assigned`, where clinical review normally takes place. If a physician goes several hours without acting on it, MDI's smart assignment algorithm reassigns the Encounter to another available doctor, so that every Encounter is reviewed within 24 hours.
{% endstep %}

{% step %}

#### Clinical review

The physician reviews the intake, history, and requested Offering. From here, depending on what the physician needs, the Encounter may move to:

* `Support` for operational help.
* `Waiting` while the physician awaits the patient's reply.
  {% endstep %}

{% step %}

#### Decision

The physician approves or rejects the treatment plan.
{% endstep %}

{% step %}

#### Prescription processing

Once approved, the Encounter moves to `Processing` while MDI submits the prescription to the pharmacy.
{% endstep %}

{% step %}

#### Resolution

The Encounter moves to `Completed` once the pharmacy confirms the order. Rejected or invalid Encounters move to `Cancelled` instead — and note that Cancelled Encounters are usually still billed, since clinical review has already taken place by that point.
{% endstep %}

{% step %}

#### Fulfillment

The pharmacy fulfills the order using your configured [Pharmacy Fulfillment](/partner/key-concepts/pharmacy-fulfillment.md).
{% endstep %}

{% step %}

#### Refill or follow-up

When the patient needs more medication, the next step depends on whether refills remain. See [Refills & Follow-Up](/partner/key-concepts/refills-and-follow-up.md) for both paths.
{% endstep %}
{% endstepper %}

### Journey step vs. Encounter status

The stepper above walks through the journey conceptually, but each step also maps to a concrete Encounter status your integration can check against:

| Stage                  | Encounter status                   | Primary actor                     |
| ---------------------- | ---------------------------------- | --------------------------------- |
| Checkout               | —                                  | Patient, storefront               |
| Intake submitted       | `Created`                          | Patient, MDI, or your application |
| Physician assigned     | `Assigned`                         | MDI                               |
| Clinical review        | `Assigned` / `Support` / `Waiting` | Physician, support staff, patient |
| Prescription submitted | `Processing`                       | MDI, pharmacy                     |
| Resolved               | `Completed` / `Cancelled`          | Pharmacy, physician               |

{% hint style="info" %}
A checkout does not always map to one Encounter. Your [Offerings](/partner/key-concepts/offerings.md) configuration determines whether multiple Offerings share an intake or require separate Encounters.
{% endhint %}

### Checkout timing

Storefront integrations can run checkout either before or after the white-label intake flow, and which pattern you choose determines when an Encounter enters clinical review.

#### Checkout before intake

This is the simpler, more common pattern: the patient pays first, then completes intake.

1. Patient selects a product and adds it to their cart.
2. Patient completes checkout (payment + shipping) on your storefront.
3. Patient is prompted to complete the Medical Intake Form.
4. Patient completes intake. MDI creates the Patient and Encounter, and the Encounter immediately enters the review queue.

{% hint style="success" %}
Best for: Simple flows where every checkout should proceed straight to review
{% endhint %}

#### Checkout after intake

Here the order is reversed — the patient completes intake first, then pays. Use this pattern when you want clinical intake finished before the patient is sent into checkout:

1. Based on a Voucher generated via `POST /v1/partner/vouchers`, the patient is redirected to the white-labeled MDI intake form *before* checkout.
2. Patient completes the intake form.
3. MDI creates the Patient and Encounter — but the Encounter is created with `hold_status: true`, which prevents it from being picked up by a physician for assignment.
4. Patient is redirected back to your storefront to complete checkout (payment + shipping).
5. Once checkout is confirmed, call the API to set `hold_status: false`. A Support user can also move the case to `Assigned` directly in the Clinicians App. Either way, the Encounter then enters the review queue.

If the patient never completes checkout, the Encounter simply stays on hold — it is never billed or reviewed.

{% hint style="success" %}
Best for: Flows where you don't want to bill or queue an Encounter until payment is confirmed
{% endhint %}

{% hint style="info" %}
`hold_status` controls whether a physician can be assigned to an Encounter.

Release the hold only after checkout succeeds.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.mdintegrations.com/partner/key-concepts/patient-journey.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.