Why We Built Order Transactions

Kiana Nicio
June 1st, 2026

Lab testing doesn’t always follow a straight line.

A patient places an order. They go to the wrong lab. A sample is lost. A redraw is required. Results arrive from an unexpected source. A collection fails and needs to be repeated.

These situations aren’t edge cases – they’re a normal part of running a diagnostic program at scale.

Yet most lab integrations still treat testing as a simple relationship between a single order and a single result.

In reality, diagnostic testing is a journey.

The Problem with Orders

Traditionally, every event in the testing process creates another order.

• An original order.
• A replacement order.
• A redraw order.
• An order created to match unsolicited results.
• An order created because the patient went to the wrong collection site.

Soon, what began as a single patient testing experience becomes a collection of disconnected records.

The burden of reconnecting those records falls on engineering teams, operations teams, and support staff.

Customers end up building their own systems to answer questions like:

• Which order represents the original patient intent?
• Which order produced the final result?
• Was this redraw related to the original test?
• Why are there three requisitions for the same patient?
• What actually happened here?

The complexity grows with every exception.

Introducing Order Transactions

Order Transactions give customers a way to track the entire diagnostic journey—not just individual orders.

A transaction represents the patient testing experience from start to finish.

Multiple orders can belong to the same transaction:

• Original orders
• Redraw orders
• Replacement orders
• Wrong-lab corrections
• Future exception workflows

Instead of forcing customers to reconstruct the story themselves, Junction maintains the relationship between these events.

Customers can retrieve results, statuses, and lifecycle information at the transaction level while still maintaining visibility into individual orders.

Learn more in the Order Transactions documentation.

The First Workflow: Redraws

The first major workflow powered by Order Transactions is redraw support.

Historically, redraw workflows often required:

• manual patient outreach
• requisition reuse
• operational coordination
• complex result reconciliation

With Order Transactions, redraws become first-class workflows.

A redraw can generate:

• a new linked order
• a new requisition
• automated patient communications
• independent order tracking

while remaining connected to the original testing journey.

Read more about the redraw workflow and implementation.

Building for the Real World

Order Transactions are not a redraw feature.

Redraws are simply the first problem they solve.

This model creates a foundation for future workflows including:

• unsolicited results
• wrong-lab collections
• replacement orders
• complex diagnostic journeys
• future exception handling and automation

Instead of building a new solution for every exception, Junction now has a unified way to represent them.

Looking Ahead

Our goal is simple:

Lab testing should feel like a single patient journey – not a collection of disconnected orders.

Order Transactions are a major step toward that vision.

And this is only the beginning.

Ready to get started?

Whether you’re implementing redraw workflows today or preparing for future exception handling, Order Transactions provide the foundation for managing complex diagnostic journeys in Junction.

Contact: sales@junction.com or your Junction CSM.