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

# Redraws

> Handle redraw scenarios where patients return for a new blood draw due to missing results.

<Card horizontal icon="person-digging" color="#57164A">
  This feature is in **closed beta**.

  Interested in this feature? Get in touch with your Customer Success Manager.
</Card>

<Warning>
  Please note that this feature is only available for walk-in tests with Labcorp, Quest, and BioReference.
</Warning>

A patient may be eligible for a redraw if their order has missing results due to a lab error.
To get a redraw, the patient will need to go back to the PSC with a new requisition form, listing only the missing biomarkers that need to be retested.

To facilitate this flow, Junction uses the concept of [order transactions](/lab/workflow/order-transactions), which in the case of a redraw flow, will include one initial order and at most, one redraw order.

## Order Transactions and Redraw Orders

If an `initial` order is eligible for a redraw, rather than transitioning the [low-level status](/lab/workflow/lab-test-lifecycle) of the order to `completed`, the order status is set to `redraw_available`.

* At this point, a new order is created, with `origin` set to `redraw`, and it is linked to the same order transaction as the `initial` order
* The order transaction's `status` field will be as follows:
  * `active` - one or more orders belonging to the order transaction are in progress
  * `completed` - all expected lab work for this transaction is completed and no further updates are expected
  * `cancelled` - the initial order has been cancelled (and there's no redraw order), or both the initial and redraw orders have been cancelled

### Webhooks

* A `labtest.order.updated` [webhook](/lab/walk-in/webhooks) will be sent for the `initial` order when it transitions to the `redraw_available` status
* Additionally, `labtest.order.created` and `labtest.order.updated` [webhooks](/lab/walk-in/webhooks) will be sent for the `redraw` order, when it is created and transitions to the `requisition_created` status upon the requisition being processed
* The `labtest.order.created` and `labtest.order.updated` webhook payloads will include origin and order transaction details (including a list of orders that belong to the transaction, ordered by ascending date of order creation) - see the example payload on the [webhooks](/lab/walk-in/webhooks) page for more details
* Ordering of webhook delivery is not guaranteed and should not be relied upon

### Monitoring updates and completion

* The results for the `initial` order will be available via the [results API](/lab/results/result-formats) when the `redraw_available` event is received. **No further updates for this order should be expected.**
* The `redraw` order will move through the usual [order lifecycle](/lab/walk-in/order-lifecycle) and will emit its own webhooks so that updates can be tracked.
* A patient can only go through one redraw per order transaction. This means that a `redraw` order will never transition to a `redraw_available` state.
* When results for the `redraw` order have been received and processed, the `redraw` order status will transition to `completed`, regardless of whether there are still missing results. The order transaction status will also be marked as `completed`.

## Key things to note

* The order transaction should be used as the primary way to reason about all related orders. A workflow for monitoring redraws could be as follows:
  * Save the order transaction ID associated with an order at the point of its creation
  * When processing order webhooks, if an initial order is in a `redraw_available` state, check the order transaction details in the payload to retrieve the order ID for the new redraw order
  * Monitor webhooks for the redraw order to get the latest updates
  * Once the redraw order is completed, use the order transaction endpoint to retrieve combined results

## Integrating with Order Transactions

We recommend that you store both the `order_id` and `order_transaction_id` when placing an order in Junction. This way, if you receive a webhook for an order that you have not seen in your system, you will be able to link it to the initial order via the `order_transaction_id`.
From there, you can always use the `order_transaction_id` directly to obtain results, ensuring you always get the complete set of results for a particular order transaction.