A faxed requisition and an HL7 order message are the same information in two forms, separated by a step that most laboratories still perform by hand. This article walks through what that step involves when it is automated properly — six stages, each with one job — and is specific about which stages use deterministic methods and which do not.
It is written for laboratory directors and interface staff evaluating whether this class of automation is safe to put in front of their LIS.
Why paper persists
Referring practices in GI, dermatology, urology, and wound care keep faxing because the fax fits their workflow and the portal does not. The laboratory absorbs the cost rather than risk the referral relationship, and that cost lands on accessioning as keying hours that scale linearly with volume. Any solution requiring the ordering practice to change behavior solves a different problem than the one laboratories actually have.
The six steps
1. Screen
Every inbound file is checked before anything reads it: file type, size, and unsafe content, including active content embedded in PDFs. A file that fails screening is quarantined rather than extracted. This step exists because an inbound fax line is an untrusted input channel that happens to point at a system holding protected health information.
2. Align
The page is matched against a registered template and deskewed. Faxed pages arrive rotated, skewed, cropped, and degraded; alignment is what makes everything downstream reproducible, because a field's region on the page is only meaningful once the page is in a known orientation. Each supported form is registered once, with its fingerprint and field regions mapped.
3. Read
This is the step where method matters most, and where the two kinds of field diverge sharply.
Checkboxes are measured, not interpreted. Mark detection is pixel density inside a registered region, compared against a threshold — classical computer vision, no model involved. The stored result carries the measurement and the threshold, so any decision can be rechecked by hand by a reviewer or an auditor. Test selection on a requisition is almost entirely checkboxes, which means the highest-volume, highest-stakes extraction on the page is fully deterministic.
Written fields are recognized and scored. Patient name, date of birth, collection date, and identifiers are handwritten, and optical character recognition returns both a value and a confidence score. The score is the point: it decides where the order goes next, rather than being a footnote on a value the system has already committed to.
4. Validate
Extracted fields are checked against required-element rules — mapped to 42 CFR §493.1241(c) by citation, including the conditional Pap elements under (c)(7) — plus code validity and compatibility checks. The output is an order-level grade: green for high confidence and ready for final identity confirmation, yellow for uncertain fields routed to a reviewer, red for held until corrected.
5. Confirm
A trained reviewer confirms patient identity and machine-read order content before anything is submitted. This is enforced server-side rather than in the interface, so it cannot be bypassed by a client that skips a screen. Handwritten identity fields are the highest-stakes values on the page and the least reliable to read; human confirmation on them is not a tuning parameter.
6. Deliver
The validated order is serialized to HL7 v2.5.1 as an OML^O21 message and sent over the laboratory's existing interface, with acknowledgement tracking. A message that receives no ACK is held for retry rather than lost. Each delivered message keeps a link back to its source image, which is what makes the QA evidence in step 4 auditable later.
One structured record in the middle
Between reading and delivery sits a single structured order record, and this is the design decision that keeps the rest tractable. Extraction produces that record; delivery serializes it. Because the two are decoupled, HL7 v2.5.1 today and FHIR or another target tomorrow are a change to a thin serializer rather than a rewrite of the engine.
Every field in that record carries its own provenance: the method that read it, the region of the page, the confidence, the status, and the value before any edit. That provenance answers an auditor's question about why a particular value was accepted. It also makes human review efficient, because a reviewer sees which fields are uncertain and why, rather than re-reading the whole form.
What this does not do
It does not infer. Diagnosis codes, test selections, and ordering-provider identifiers are copied from the form and never defaulted, completed, or normalized toward a billable code. A blank field stays blank. An illegible field goes to a person who reads the source image.
It does not replace the LIS, and it does not require the referring practice to change anything. Orders arrive over the interface the laboratory already runs, and the portal and billing handoff are untouched.
It also does not skip the interface work. Connecting to a specific LIS requires the message profile, the test compendium mapping form codes to orderables, the submission endpoint and its ACK semantics, and testing against a test endpoint before anything touches production. That work is per-laboratory and we scope it explicitly rather than assuming it away.
Where it stands
The engine reads, validates, reviews, and delivers on a set of degraded synthetic requisitions. Accuracy figures come from that synthetic test set until pilots produce real ones — we say so rather than borrowing numbers. Live work with protected health information happens only inside a covered environment under a Business Associate Agreement.
To see it on your own forms, the platform page covers the mechanics in more depth and the pilot outline describes the five inputs needed to begin.