Host Query Explained: When the Analyzer Asks for the Worklist

Vendors sell "bidirectional" as a checkbox. Every LIS comparison table in 2026 has a column for it, and every entry in that column says yes. What none of them show is the behaviour behind the word — and the behaviour is where integrations actually succeed or quietly fail.

Here is the thing that comparison table will not tell you: a large share of analyzers will not accept an order you push at them. They will not listen for one. They wait until a specimen is physically loaded, then they ask the host a question — what am I supposed to run on this? — and they wait a few seconds for an answer.

That exchange is called host query. If your middleware does not implement it properly, the analyzer asks, nothing useful comes back, and the specimen sits there waiting for someone to key the order in by hand. The link looks connected. Results still flow. Ordering just never works, and nobody can say exactly why.

Push vs. Host Query: Two Ways an Order Reaches an Analyzer

There are two models, and analyzers pick one.

Push (unsolicited download). The host decides an order exists and sends it to the analyzer without being asked. The analyzer holds it in a pending worklist until the matching specimen appears. This is intuitive, it maps well to how people imagine ordering, and it is how most integration diagrams are drawn.

Host query. The analyzer takes the lead. It reads the specimen — usually from a barcode — and sends a query to the host containing the sample identifier. The host looks up what tests are ordered for that sample and replies. The analyzer runs what came back.

Host query is the better model for a busy bench, for a reason that is obvious once stated: the analyzer only asks about specimens it is actually holding. There is no pending worklist to go stale, no orders queued for samples that were never delivered, no reconciliation between what the host thinks is on the instrument and what is physically there. The specimen's presence is what triggers the conversation.

It is also why "we support bidirectional ordering" is an incomplete statement. Supporting push and supporting host query are different pieces of work, and an analyzer that only does host query gets nothing at all from a push-only implementation.

The ASTM Q-Record Exchange

In ASTM E1394, the query is a Q record.

The analyzer opens a session and sends a message containing a Header record, then a Q record carrying the sample identifier it wants information about, then a Terminator. In plain terms: here is a sample ID, tell me what to do with it.

The host answers with an ordinary ASTM message built the normal way — Header, Patient, Order, Terminator (H / P / O / L). The Order records carry the test codes to run. From the analyzer's point of view this is just a worklist download; the only thing that makes it a query response rather than an unsolicited push is that it arrived because the analyzer asked.

Two details matter and are frequently missed. First, the sample identifier in the Q record has to be matched against your order store exactly as the analyzer sent it — including any padding or field-width behaviour that particular instrument applies. Second, the response has to arrive inside the analyzer's query window, which is often short.

The HL7 QRY^Q02 → DSR^Q03 Exchange

In HL7 v2, the same conversation uses a different message pair.

The analyzer sends a QRY^Q02 — a query message whose QRD and QRF segments carry the sample identifier and the scope of the request. The host replies with a DSR^Q03, a display-oriented response containing an MSH header, an MSA acknowledgement segment, and the order content in DSP segments. The analyzer then closes the exchange with an ACK^Q03.

The HTSH-2000 biochemistry analyzer is a clean example of this pattern in production. It queries with QRY^Q02, expects a DSR^Q03 containing MSH plus MSA plus up to three DSP segments, and acknowledges with ACK^Q03. Its query window is six seconds. It accepts no unsolicited orders at all — host query is the only ordering path it has. If you push at it, nothing happens, and nothing tells you nothing happened.

Why Answering in the Wrong Dialect Fails Silently

Some analyzers speak more than one protocol. The CXL PRO, for instance, is dual-dialect: it will talk HL7 v2.3.1 over MLLP, and it will talk classic ASTM, and it does host query in both.

That creates a specific and nasty failure mode. If the analyzer queries in ASTM and the host replies in HL7 — or the reverse — the analyzer does not raise an error. It receives bytes it cannot interpret as an answer to its question, treats the query as unanswered, and moves on. No alarm on either side. The technologist sees a specimen the analyzer declined to run and assumes there was no order.

The rule LISBridge enforces is simple and absolute: reply in the dialect the analyzer asked in. Asked in ASTM, answered in ASTM. Asked in HL7, answered in HL7. The host's configured preference does not override the question that was actually asked. It sounds obvious written down; it is a common source of dead bidirectional links in the field.

Why an Explicit "No Orders" Reply Beats Silence

Here is the case most implementations get wrong.

The analyzer queries a sample ID. The host looks it up and finds nothing — the order was never placed, or it was placed against a different identifier, or it was already completed. What should the host do?

The intuitive answer is: nothing. There are no orders, so there is nothing to send.

The intuitive answer is wrong. Silence forces the analyzer to sit through its full query timeout before concluding it has no answer. On an instrument with a six-second window, that is six seconds of a stalled position, repeated for every unmatched specimen. On a busy run that becomes real throughput loss, and — worse — a timeout is indistinguishable at the analyzer from a broken link. The instrument cannot tell "the host has no orders for this sample" from "the host is not there."

The correct behaviour is an explicit, well-formed negative. In HL7, that is an MSA|NF — a "no data found" acknowledgement with no DSP segments — which closes the analyzer's query window cleanly and immediately. The analyzer knows the host is alive, knows there are no orders, and moves to the next position without waiting. In ASTM, the equivalent is a properly framed response with no Order records.

LISBridge sends a real answer to every query, including the negative ones, on every transport. A question always gets a reply.

Holding the Order Against the Specimen, Not a Bench Position

There is a design decision underneath host query that affects reliability more than the message formats do: what is an order attached to?

Systems that attach a pending order to an analyzer — "these tests are for machine 3" — break as soon as the physical world diverges from the plan. The specimen is run on machine 4 because machine 3 is in maintenance. The rack is moved. The sample is repeated on a second instrument. In each case the order is in the wrong place, and someone has to intervene.

LISBridge holds query-driven orders against the specimen. The order belongs to the sample identifier, not to a bench position. Whichever analyzer asks about that specimen gets the order, and the answer is correct regardless of where the tube physically ended up. An order can also be cancelled while it is still answerable, which matters when a test is withdrawn between placement and the analyzer getting to the sample.

This also means host-query ordering works the same way across a multi-analyzer floor without per-instrument order routing configuration. The specimen carries the association; the analyzers just ask.

Host Query Over Serial, TCP, and File Transport

A query is a conversation, and conversations are usually assumed to need a live socket. That assumption excludes a lot of real lab equipment.

LISBridge answers worklist queries across all three of its connection tiers:

• RS-232 serial — the older bench analyzers that still run perfectly well and are not going anywhere.
• TCP/IP — the common case for networked instruments, including MLLP-framed HL7.
• FTP / FTPS / SFTP file transport — analyzers like the bioMérieux VIDAS KUBE that exchange orders and results as files on a server rather than over a socket.

Host query over file transport is the one most middleware skips, because it does not look like a conversation. It is one: the analyzer deposits a request, the host deposits an answer, and the same rules apply — answer in the right format, answer promptly, and answer even when the answer is "nothing." More on the transport layer in device connectivity, and on the protocol layer in HL7 and ASTM support.

Which LISBridge Instruments Support Host Query

Seventeen of the 37 instruments LISBridge supports out of the box are order-capable, including:

• Mindray BS-430 — chemistry, host query with standards-compliant ACK trigger echo (instrument page)
• HTSH-2000 — biochemistry, HL7 QRY^Q02 host query only, six-second window, MSA|NF on no match
• CXL PRO — auto-chemistry, dual-dialect host query in both HL7 and ASTM
• VIDAS KUBE — bioMérieux immunoassay, order exchange as XML over the BCI Connect file server
• Horiba Yumizen, Horiba Pentra XLR, Maglumi, YHLO iFlash, Abbott i800, Maccura i1000, Diatron Pictus 700, Dymind DH-76, ADVIA Centaur CP and others

Host query is the default posture rather than an option you switch on. Analyzers that expect to be asked are treated as the normal case, because on most lab floors they are.

FAQ

How do I know whether my analyzer uses push or host query?

The instrument's host connection specification will say — look for a query message, a Q record, or a QRY message type in the supported message list. In practice, the faster test is behavioural: if orders you push are ignored but the analyzer runs fine when tests are keyed in at the instrument, it is almost certainly a host-query analyzer. Some instruments support both and are configured for one.

What happens if the host is slow to answer?

The analyzer times out its query window and proceeds as though no orders exist. This is why response latency matters more in host query than in push ordering — and why an immediate negative reply is better than a slow positive one. Running the middleware locally, as a desktop application on the lab network rather than as a remote cloud service, removes a round trip that a short query window cannot absorb.

Can one specimen be queried by two analyzers?

Yes, and it happens routinely — a sample split across chemistry and immunoassay, or a repeat on a second instrument. Because orders are held against the specimen rather than a bench position, each analyzer asking about that sample gets the orders relevant to it.

What if the order is cancelled after the analyzer already asked?

An order can be cancelled while it is still answerable — that is, before the analyzer has been given it. Once the analyzer has the order and has begun the run, cancellation is an instrument-side operation, as it would be with any ordering model.

Does host query work if my LIS is the source of orders?

Yes. LISBridge pulls orders from your HIS or LIS by outbound polling — no inbound firewall ports to open — and holds them against the specimen, ready to answer whichever analyzer asks. The analyzer's query is answered from that store rather than by a live round trip to the LIS, which is what keeps the reply inside the query window.

The Short Version

"Bidirectional" on a comparison table tells you nothing about whether your analyzer will actually get its orders. What matters is whether the middleware answers the question the analyzer asks, in the dialect it asked in, on the transport it uses, inside its timeout, and whether it bothers to say "nothing for this one" instead of going quiet.

Those behaviours are not a feature list. They are the difference between a bidirectional link that works and one that is configured, connected, and doing nothing.

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