Bidirectional Lab Orders: How LISBridge Sends Tests to Analyzers

Most lab middleware is described as an interface. In practice, a large share of it is a receiver. Results come off the analyzer, get parsed, and get delivered to the LIS. That is genuinely useful — it is the half of the workflow that eliminates manual transcription — but it leaves the other half of the loop untouched.

The untouched half is the order. Somebody still has to tell the analyzer which tests to run on which tube. In a results-only setup, that somebody is a technologist standing at the instrument's keypad, selecting a panel, entering a specimen ID, and pressing start. The result comes back automatically. The instruction went in by hand.

A bidirectional lab order interface closes that loop: the order travels from the LIS or HIS out to the analyzer, and the result travels back. This post covers what that actually involves — order intake, routing, protocol dialects, host query, tracking and retry — and which instruments in the LISBridge catalogue support it.

Why Results-Only Is Half the Job

Start with what a technologist does in a unidirectional lab, per specimen:

1. Read the requisition or the LIS screen to see which tests are ordered.
2. Walk to the analyzer.
3. Enter the specimen identifier on the instrument keypad.
4. Select the test panel from the instrument's menu.
5. Load the tube and start the run.

Steps 3 and 4 are transcription — the exact activity that automated result capture was introduced to eliminate, still happening, just in the opposite direction. And it carries the same error profile. A mistyped specimen ID at the keypad produces a result correctly attributed to the wrong specimen. A wrong panel selection produces the right tests on the wrong tube, or the wrong tests on the right one, and neither is caught by anything downstream.

There is a workload argument too. In a lab running a mixed workload across several benches, entering orders at the instrument is a meaningful fraction of a technologist's shift — and it is the part that has to happen while the specimen is in hand, which makes it a bottleneck rather than a background task.

How Order Dispatch Works

Order dispatch has more moving parts than result collection, because it involves initiating a conversation rather than listening to one. Four pieces have to exist.

1. Order intake

Orders have to arrive from somewhere. Two paths cover almost everything:

• The HIS or LIS pushes them. An HL7 ORM^O01 or OML^O21 message arrives over MLLP. This is the classic pattern, and it requires the hospital to open an inbound path to the middleware.
• The middleware pulls them. LISBridge polls a configured HIS or HMS endpoint on an outbound connection and fetches pending orders. This matters more than it sounds: an outbound poll requires no inbound firewall ports, which is frequently the difference between an integration that gets approved by hospital IT and one that stalls in review for a quarter.

Either way, the order lands in LISBridge with the specimen identifier, the patient identity, and the requested tests.

2. Routing

An order for a CBC and a chemistry panel is not one instruction. It is at least two, addressed to two different machines. The routing layer decides which analyzer receives which portion of an order, based on which tests each instrument performs and which instruments are currently connected.

This is also where a lab's own configuration lives. Two labs with identical instruments will route differently depending on their workload split, and the routing rules have to be editable by the lab rather than fixed by a vendor.

3. Protocol translation

Each analyzer expects orders in its own grammar. Broadly there are two families, and the same instrument sometimes supports both:

• HL7 order messages — OML^O21 or the older ORM^O01, transported over MLLP.
• ASTM order records — a worklist expressed as ASTM header, patient, order and terminator records (H / P / O / L), framed per ASTM E1381.

The CXL PRO auto-chemistry analyzer is a useful illustration of why "we support HL7" is an insufficient specification. It speaks HL7 v2.3.1 over MLLP and classic ASTM, and it is bidirectional in both: on the HL7 side a QRY^Q02 query is answered with a DSR^Q03 response; on the ASTM side a Q-record query is answered with an H/P/O/L worklist. One instrument, two complete dialects. An interface supports whichever it has actually implemented.

If the underlying message structures are unfamiliar, HL7 ORU and ORM messages covers them segment by segment.

4. The host query responder

This is the piece that most distinguishes a real bidirectional interface, and it inverts the direction of initiation.

Many analyzers do not want to be pushed a worklist in advance. They want to scan the barcode on the tube in front of them and ask: what am I supposed to run on this specimen? That query arrives at the middleware, which has to look up the specimen, find the pending order, and answer within the instrument's timeout window — typically a matter of seconds.

The workflow this enables is the one labs actually want. A tube arrives, someone loads it, the analyzer reads the barcode, asks, receives its instruction, and runs. Nobody selects anything. The specimen carries its own identity and the order is retrieved against it.

Building this well is a latency problem as much as a protocol problem. The responder has to be listening, the lookup has to be fast, and a slow answer is functionally the same as no answer — the instrument times out and falls back to manual entry.

The 16 Order-Capable Instruments

LISBridge supports 35 named instruments. Sixteen of them are bidirectional — LISBridge sends orders to them as well as receiving results:

Horiba Yumizen · Horiba Yumizen H550 · Horiba Pentra C400 · Horiba Pentra XLR · Maglumi · ADVIA Centaur CP · ADVIA Centaur XPT · Mindray BS-430 · YHLO iFlash · Dymind DH-76 · Orphée Mythic 22 AL · Abbott i800 · Maccura i1000 · Diatron Pictus 700 · CXL PRO · VIDAS KUBE

Two of those deserve a note.

CXL PRO is the dual-dialect case described above — HL7 v2.3.1 over MLLP and classic ASTM, bidirectional in both.

VIDAS KUBE (bioMérieux) is bidirectional over a file transport rather than a socket. Orders and results move as aiMessage and lisMessage XML documents across a BCI Connect file server over FTP, FTPS, or SFTP. This is a third connection tier alongside RS-232 and TCP/IP, and it behaves differently in practice — file-based exchange has different latency and different failure modes than a live socket. Where several physical units of the same model sit behind one shared file server, each registers with its own device serial rather than collapsing into a single host entry, which keeps licensing and deduplication accurate.

The reason to publish this list at model resolution rather than as a count is that counts are not verifiable. Much of this market competes on integration totals — "150+ EMR systems," "700+ supported models" — while the instrument list stays vague. A lab manager evaluating middleware is not searching for a number. They are searching for the machine on their bench.

Order Tracking and Retry

Dispatching an order is not the same as knowing it arrived, and this is where bidirectional interfaces are separated from bidirectional demos.

Every order LISBridge dispatches carries a state: pending, sent, acknowledged, resulted, failed. That state is what allows the obvious questions to be answered — was this order actually sent, did the instrument acknowledge it, has a result come back, and if not, how long has it been waiting.

The failure handling underneath it:

• Automatic reconnect with exponential backoff and jitter. A dropped analyzer link recovers itself rather than waiting for someone to notice. Jitter matters when several instruments lose a shared switch simultaneously — without it they all retry in lockstep.
• Crash-safe local storage. Orders and results are written to SQLite with write-ahead logging. A power cut or an unexpected restart does not take the queue with it.
• Endpoint cooldown on order pull. A HIS endpoint that is unreachable is backed off rather than hammered, and recovery is automatic.
• Raw protocol retention. The exact bytes exchanged with the instrument are stored alongside the parsed record. When an order is disputed, there is evidence rather than an inference.

In LISBridge Lab, order state is visible alongside the specimen through Order Entry and Specimen Accession, so an unresulted order is a visible item on a worklist rather than something discovered when a clinician asks where a result went.

The Configuration Question

There is a step in every bidirectional deployment that vendors tend not to discuss in marketing material: somebody has to map the LIS's test codes to each analyzer's internal codes. The LIS calls a test one thing; the Mindray calls it another; the Horiba calls it a third.

Across most of this market, that mapping is a vendor engagement — a ticket, a professional-services conversation, sometimes a change request with a price attached. The industry has recently started saying so openly. In July 2026 Clinisys, serving 7,000-plus labs across 42 countries, announced a partnership to add a low-code configuration layer to its platform, on the stated basis that traditional LIMS/LIS configuration "relies heavily on development resources, creating bottlenecks that slow change and limit operational agility."

That is a fair description of the problem, and the layer it addresses sits above the one a lab hits when a new analyzer arrives on the bench. LISBridge treats the instrument-level mapping as a product default: map any analyzer parameter to any LIS field yourself, in the application, with no ticket and no second platform licence. It is the difference between waiting on a queue and configuring the interface the afternoon the machine is delivered.

Frequently Asked Questions

What does bidirectional actually mean for a lab interface?

That orders travel from the LIS or HIS to the analyzer, and results travel back. A unidirectional interface only does the second half — results are automated, order entry is still manual at the instrument.

Does bidirectional require barcodes on the tubes?

Not strictly, but the host query workflow depends on the analyzer being able to identify the specimen in front of it, which in practice means a barcode. Without one, orders have to be pushed as a worklist with a defined position or sequence, which is more fragile.

What if my analyzer is not on the order-capable list?

Then it collects results only, and orders are entered at the instrument. That is not a LISBridge limitation so much as an instrument one — many analyzers have no order-receiving capability in their firmware at all. Results capture still eliminates the larger share of the manual work.

Do I need to open firewall ports for the hospital to send us orders?

Not with order pull. LISBridge polls the HIS or HMS endpoint outbound on a schedule, which means no inbound ports and, usually, a much shorter security review.

What happens to an order if the analyzer is offline?

It stays queued in a pending state with its status visible. The connection retries with exponential backoff, and the order dispatches when the link is restored. Nothing is silently dropped, and the queue survives a restart.

The Wider Picture

Bidirectional operation is where middleware stops being a data pipe and starts being part of the workflow. The order originates in the chart, reaches the machine without anyone retyping it, and comes back attached to the same specimen identifier it left with.

LISBridge is a native desktop application built with Rust and Tauri, running locally in the lab, connecting over RS-232 serial, TCP/IP, or FTP/FTPS/SFTP. It parses ASTM E1394, HL7 v2, and vendor dialects; it supports 35 named instruments, 16 of them bidirectionally; and it runs offline, with device-based licensing that does not depend on an internet connection.

For more depth on the protocol layer, see HL7 and ASTM support, or read the earlier overview at bidirectional lab middleware. For the full path from instrument to LIS, see how it works.

Start your free trial — no credit card required. lisbridge.com/pricing