> ## 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 Phlebotomy lab tests.

The **Walk-In Test** orders are composed of two different lifecycles, the **Order** lifecycle and
the **Appointment** lifecycle, detailed in the following sections.

## Order Lifecycle

As discussed in [`Lab Test Lifecycle - Statuses`](/lab/workflow/lab-test-lifecycle#statuses), each lab testing modality has the following format

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

For each modality, there can be multiple **low-level statuses**, for **Walk-In Phlebotomy** the possible low-level statuses are:

* `ordered`: Vital received the order, stored it into our system, 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 Vital's system for the order, but doesn't have a scheduled date.
* `appointment_scheduled`: An appointment was scheduled or rescheduled for the order.
* `appointment_cancelled`: The appointment was cancelled, by either the patient, Vital or you.
* `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. (Currently in beta testing.)
* `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 either the patient, Vital or you.

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 the Walk-In Phlebotomy 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

The appointment lifecycle is separate from the order lifecycle, and it corresponds to a single appointment. The possible statuses are defined as follows:

* `pending`: An appointment was placed in the system, and is pending updates from the phlebotomy service.
* `scheduled`: An appointment was scheduled or rescheduled.

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

<Frame caption="Possible state transitions for the Walk-In Phlebotomy Appointment statuses.">
  <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>

The events are related to a single appointment. An order can have multiple existing appointments in Vital system, although only one appointment will be considered active and returned when using the [GET Appointment endpoint](/api-reference/lab-testing/psc-scheduling/get-psc-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.

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

### Appointment Booking Failure

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

* The Appointment will move to the `cancelled` status; and
* 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.