Skip to main content

This feature is in closed beta.Interested in this feature? Get in touch with your Customer Success Manager.
Please note that this feature is only available for walk-in tests with Labcorp, Quest, and BioReference.
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, 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 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 will be sent for the initial order when it transitions to the redraw_available status
  • Additionally, labtest.order.created and labtest.order.updated 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 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 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 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.