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

# Order and Appointment Lifecycle

> Learn the order and appointment statuses, state transitions, and scheduling flows for walk-in lab tests.

Walk-in orders have separate order and appointment lifecycles. The order lifecycle represents the overall lab order, while the appointment lifecycle represents an optional visit scheduled through Junction.

## Order lifecycle

As described in [Order Status and Lifecycle](/lab/workflow/lab-test-lifecycle#statuses), each lab testing modality has the following format:

`[HIGH-LEVEL STATUS].[TEST MODALITY].[LOW-LEVEL STATUS]`

For walk-in orders, the possible low-level statuses are:

* `ordered`: Junction received the order and started processing it asynchronously.
* `requisition_created`: An order requisition form was validated and created with the partner laboratory, making the order available to be carried out.
* `requisition_bypassed`: An order requisition form wasn't created when the order was placed with us because it already existed.
* `appointment_pending`: An appointment was placed in Junction's system for the order but does not have a scheduled date.
* `appointment_scheduled`: An appointment was scheduled or rescheduled for the order.
* `appointment_cancelled`: The appointment was cancelled by the patient, Junction, or your Team.
* `partial_results`: The laboratory has started making partial results available.
* `redraw_available`: The result has been marked as final but is missing biomarker results due to lab error.
* `completed`: The laboratory processed the blood sample and final results are available.
* `sample_error`: The collected sample was unprocessable by the lab.
* `cancelled`: The order was cancelled by the patient, Junction, or your Team.

The Finite State Machine that defines the possible transitions for the low-level statuses described above is illustrated in the following diagram.

<Frame caption="Possible state transitions for walk-in order low-level statuses.">
  <img src="https://mintcdn.com/vital/deJB3IUUpJEYmyW_/img/walkin-statuses.png?fit=max&auto=format&n=deJB3IUUpJEYmyW_&q=85&s=445ad3691cc5e3966288b7f599946d41" alt="" width="796" height="996" data-path="img/walkin-statuses.png" />
</Frame>

<br />

<Info>
  In **sandbox**, there is no async transition from the `ordered` state to the `requisition_created` state. This must be **manually triggered** via the **Junction Dashboard**.
</Info>

## Appointment lifecycle

Each appointment has both a current `status` and a normalized `event_status`. The `events` array contains the history of normalized appointment events.

### Appointment status

The appointment object's `status` describes its current scheduling or provider state:

| Status | Meaning |
| - | - |
| `pending` | Junction is waiting for the appointment provider to acknowledge the request. |
| `reserved` | The time slot is held while the order requisition is being created. |
| `confirmed` | The appointment is confirmed. |
| `in_progress` | The appointment is in progress. |
| `completed` | The appointment was completed. |
| `cancelled` | The appointment was cancelled. |

### Appointment event status

The appointment object's `event_status` and each `events[].status` use normalized lifecycle values:

| Event status | Meaning |
| - | - |
| `pending` | The appointment request is awaiting provider acknowledgment. |
| `reserved` | The appointment is held until its requisition is created. |
| `scheduled` | The appointment was scheduled or rescheduled. A `confirmed` appointment uses the `scheduled` event status. |
| `in_progress` | The appointment is in progress. |
| `completed` | The appointment was completed. |
| `cancelled` | The appointment was cancelled. |

Not every provider produces every status. Treat both enums as non-exhaustive and handle unknown values gracefully.

The Finite State Machine that defines the possible transitions for the appointment statuses described above is illustrated in the following diagram.

<Frame caption="Common walk-in appointment event-status transitions.">
  <img src="https://mintcdn.com/vital/deJB3IUUpJEYmyW_/img/walkin_appt_statuses.png?fit=max&auto=format&n=deJB3IUUpJEYmyW_&q=85&s=c1f5499175f945ba8a3284fc25f60c48" alt="" width="1454" height="854" data-path="img/walkin_appt_statuses.png" />
</Frame>

An order can have multiple appointment records over time, but the [Get PSC Appointment endpoint](/api-reference/lab-testing/psc-scheduling/get-psc-appointment) returns the active appointment.

## Scheduling appointments before a requisition has been created

<Note>
  This feature is available upon request. To enable, please get in touch with your Customer Success Manager.
</Note>

When this feature is enabled on your Team, you can create a Patient Service Center (PSC) appointment even before the requisition has been created for the corresponding Order (i.e., reaching the `requisition_created` status).

This allows you to build an experience that can order the lab test *and* book an appointment consecutively, without having to wait on the asynchronous requisition creation process that may take an indeterminate amount of time.

### API Journey

<Steps>
  <Step title="Creating an appointment">
    You create an Appointment for an Order which does not yet have a requisition.

    The Appointment starts with the `reserved` status.

    <Note>
      If the order requisition has been created on or before the time slot confirmation, the Appointment moves directly to the `confirmed` status. The `reserved` status will be skipped.
    </Note>
  </Step>

  <Step title="Waiting for Requisition Creation">
    The requisition is being created asynchronously.
  </Step>

  <Step title="Requisition has been created">
    The requisition has now been created.

    1. The Order will move through the `requisition_created`, `appointment_pending` and `appointment_scheduled` Order statuses in quick succession.
    2. The Appointment will move to the `confirmed` status automatically, which corresponds to the `scheduled` appointment event.

    You will receive three `labtest.order.updated` events, one each for the three Order status transitions. You will also receive a `labtest.appointment.updated` event for the Appointment status transition.
  </Step>
</Steps>

## Cancelling an appointment

If an Appointment is cancelled **before** a requisition has been created:

* The Appointment will move to the `cancelled` status; and
* There is no change to the Order, which will remain in the `ordered` status.

If an Appointment is cancelled **after** a requisition has been created:

1. The Appointment will move to the `cancelled` status; and
2. The Order will move from the `appointment_pending` or `appointment_scheduled` status to the `appointment_cancelled` status.

### Auto-cancellation of appointments without requisition

In cases where appointments can be scheduled before a requisition has been created, the appointment will be automatically cancelled by Junction if the following happens:

1. More than 8 hours have passed since the order was created, and no requisition has been received.
2. There are fewer than 2 hours until the appointment start time, and no requisition has been received.

<Note>
  The 8-hour auto-cancellation rule does not apply to [scheduled orders](/lab/workflow/scheduled-orders#scheduled-orders). Scheduled orders are fulfilled on their `activate_by` date, so Junction does not cancel their appointments based solely on the fact that more than 8 hours have passed since order creation without a requisition.
</Note>

## Arizona scheduling

<Note>
  This feature is available upon request. To enable, please get in touch with your Customer Success Manager.
</Note>

When this feature is enabled on your Team, you can book appointments with Quest in Arizona (Sonora Quest).

### API Journey

<Steps>
  <Step title="Creating an appointment">
    You create an Appointment for an Order to an Arizona PSC.

    The Appointment starts with the `reserved` status.
  </Step>

  <Step title="Waiting for Appointment Confirmation">
    The appointment is being created asynchronously.
  </Step>

  <Step title="Appointment has been created">
    The appointment has now been created.

    1. The Order will move through the `appointment_pending` and `appointment_scheduled` Order statuses in quick succession.
    2. The Appointment will move to the `confirmed` status automatically, which corresponds to the `scheduled` appointment event.

    You will receive a `labtest.appointment.updated` event for the Appointment status transition. You will also receive two `labtest.order.updated` events, one each for the two Order status transitions.
  </Step>
</Steps>

<Info>
  Arizona Scheduling uses separate Order and Appointment lifecycles. Appointment status changes are delivered through [`labtest.appointment.updated`](/event-catalog/labtest.appointment.updated). The Order status updates for `appointment_pending` and `appointment_scheduled` are emitted only after Sonora Quest confirms the appointment. If you use this feature, make sure your webhook endpoint is subscribed to appointment-level events.
</Info>

### Appointment Booking Failure

If we are unable to book the Appointment asynchronously, then:

* The Appointment will move to the `cancelled` status.
* Junction will send a `labtest.appointment.updated` event for the cancelled Appointment.
* There is no change to the Order, which will remain in its last status.

### Cancellation and Rescheduling

Cancellation and rescheduling for Arizona should be done directly by the patient, via the email they receive from Sonora Quest. It is not possible to cancel/reschedule via Junction.


## Related topics

- [Order and Appointment Lifecycle](/lab/at-home-phlebotomy/order-appointment-lifecycle.md)
- [Schedule PSC Appointments](/lab/walk-in/psc-appointment-scheduling.md)
- [Webhooks](/lab/walk-in/webhooks.md)
- [Patient Communications](/lab/workflow/communications.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.