How laboratories can automate requisition processing

Stage one: intake and classification

Before anything is extracted, the document has to be identified. An inbound queue does not contain only requisitions — it contains insurance cards, medical records, prior results, correspondence and the occasional cover sheet sent on its own.

Classification first is what prevents the most annoying failure mode in this whole pipeline: a results report from another laboratory being processed as if it were an order, creating a phantom order that somebody has to find and delete later. Classification is cheap. Cleaning up phantom orders is not.

Stage two: splitting

A single faxed packet frequently contains several patients. If the pipeline treats the packet as one unit, everything downstream inherits the error — one patient record with mixed demographics, or several patients collapsed into one order.

Splitting means producing one record per patient, each with its own pages, its own extraction and its own review state, while the original document stays linked to all of them. That last part matters: reviewers need to see the source page, and auditors need the original.

Stage three: extraction

This is the part people think of as 'the AI', and it is the part that matters least on its own. Extraction reads the fields: patient demographics, ordering provider and NPI, payer and member details, requested tests, diagnosis codes, collection date and time.

The important design decision is not which model does the reading. It is that extraction produces a confidence per field rather than a single confidence for the document. A requisition where the name is crisp and the member ID is smudged is a normal case, and the pipeline should be able to accept one and question the other.

Stage four: validation

Extraction proposes; validation checks. NPIs have a checksum. Dates have to be plausible and in the right order. ZIP codes and phone numbers have formats. Required fields are required. Requested tests either map to the catalog or they do not.

Validation is where most of the practical accuracy comes from, and it is unglamorous, deterministic code rather than machine learning. A record that fails a validator should be held with the specific failure attached, not pushed through with a warning nobody reads.

Stage five: matching

The extracted patient is either someone the laboratory already knows or someone new. Getting this wrong in the confident direction — merging two different people — is far worse than getting it wrong in the cautious direction.

The right behaviour is to flag close matches as potential duplicates and require a person to confirm or reject the match, rather than merging automatically above some threshold. Duplicate resolution is a two-minute job for a human and an unbounded cleanup if a system gets it wrong at volume.

Stage six: human review, and why it is permanent

Every stage above produces either a clean record or an exception. The exceptions go to a review queue where a person sees the extracted values next to the source page, corrects what is wrong and approves.

This is not a temporary scaffold to be removed once the models improve. Illegible faxes, ambiguous handwriting, tests that are not in the catalog and genuinely novel documents will keep occurring. The goal of automation here is not zero human involvement; it is that human attention goes only to the records that need judgement.

A useful measure for this kind of pipeline is not accuracy in isolation. It is what share of documents reach a person already correct, and how long the exceptions take to work.

What to measure

• Share of documents auto-classified correctly
• Share of records that pass validation without human correction
• Median time from document arrival to order created
• Exception volume grouped by reason — this tells you what to fix next
• Correction rate per field, which shows where extraction is genuinely weak