LIS Order Pull: Fetch Test Orders From Any HIS Automatically

There is a pattern that repeats in lab integration projects, and it has almost nothing to do with protocols. The result side goes live in a week. The order side takes a quarter.

The reason is architectural rather than technical. Sending results out is an outbound operation — the middleware initiates a connection to the LIS or HIS, pushes data, and closes. Receiving orders in the classic way is inbound: the HIS initiates a connection to the middleware, which means the middleware has to be listening on a port, and that port has to be reachable from wherever the HIS lives. In a hospital network, "reachable" is a request that goes to a security team, gets a firewall change ticket, gets a review, and waits.

LIS order pull integration inverts the direction. Instead of waiting for the HIS to deliver orders, the middleware asks for them — on a schedule, over an outbound connection, using the same direction of travel that already works for results. Nothing has to be opened. This post covers how it works, how it is configured, what happens when the endpoint is unreachable, and where it fits alongside conventional order intake.

Why Inbound Integrations Stall

Consider what a traditional HL7 order feed asks of a hospital. The middleware runs an MLLP listener on a port. The HIS integration engine opens a TCP connection to that port and sends ORM^O01 or OML^O21 messages. For that to work end to end, somebody has to:

• Assign the middleware machine a stable address that will not change.
• Open an inbound firewall rule from the HIS segment to that address and port.
• Get that rule through security review, since it is a new ingress path into a clinical network.
• Keep the rule documented so the next network change does not silently remove it.

None of those steps is unreasonable on its own. Together they are why the order half of an integration frequently sits in a queue while the result half has been running for two months. And the delay is not neutral — a lab running results-only is still entering every order by hand at the instrument keypad, which is the exact transcription work the project was meant to remove. The bidirectional order loop stays half-open for as long as the firewall ticket does.

What Order Pull Actually Does

Order pull replaces the listener with a poller. LISBridge is configured with an HIS or HMS endpoint, a credential, and an interval. On each cycle it makes an outbound HTTPS request to that endpoint, asks for pending orders, and receives whatever is waiting.

Three pieces make it work in practice.

1. The pull endpoint

The HIS side exposes a read endpoint that returns pending orders — specimen identifier, patient identity, requested tests, and priority. In LISBridge Lab this is a first-class route with its own authentication path, so a polling device can reach it without going through the interactive session cookie flow that a browser user would use.

2. The global pull token

Polling needs a credential that belongs to the device rather than to a person. LISBridge uses a global pull token issued from the lab's setup panel: you generate it once, paste it into the desktop application's LIS setup, and the device authenticates with it on every cycle. No user account is tied to the integration, so it does not break when staff change.

3. Payload storage and indexing

Pulled orders are not consumed and forgotten. The raw payload is stored and indexed alongside the parsed order, which matters for two reasons. If the parse is wrong — a field in an unexpected position, a test code that does not map — the original is still there to diagnose against. And when someone asks six weeks later why a particular specimen was run with a particular panel, the answer is a record rather than a reconstruction.

Configuring a Pull Endpoint

The setup is deliberately short, because the difficulty in this kind of integration is organisational rather than technical.

1. Generate the pull token in the LIS Desktop setup panel on the lab side.
2. Enter the endpoint and token in the LISBridge desktop application's order pull configuration.
3. Set the interval. Short enough that a technologist is not waiting on the poll, long enough that you are not hammering the HIS. A minute or two suits most workloads.
4. Run a validation cycle. Place a test order in the HIS, confirm it arrives, confirm it routes to the analyzer you expect.
5. Confirm the return path. Result goes back, matched to the right specimen, into the right record.

Step 5 is the one to be strict about. An order interface that delivers orders but does not close the loop cleanly is worse than no order interface, because now two systems believe they know what was run.

When the Endpoint Is Unreachable

A poller that retries blindly against a dead endpoint is a denial-of-service tool aimed at your own hospital. LISBridge applies a per-node endpoint reachability cooldown: when a configured endpoint stops responding, that node backs off rather than continuing to hammer it every cycle, and resumes normally once the endpoint answers again.

The per-node part matters in a multi-endpoint lab. One unreachable HIS should not slow down polling against a second one that is perfectly healthy, and cooldown state is tracked per endpoint rather than globally.

The wider failure story is the same one that applies to every connection in the system — reconnect with backoff, crash-safe local storage, and logging that makes a failure visible rather than silent. That is covered in more depth in what happens when the connection drops.

Closing the Loop

Order pull is one leg of a round trip. The full path looks like this:

1. A clinician orders tests in the HIS.
2. LISBridge polls, fetches the pending order, stores the payload.
3. The routing engine decides which analyzer runs which portion of the order.
4. The order is delivered in the analyzer's own dialect — HL7 OML over MLLP, or an ASTM order record — or held until the analyzer asks for its worklist, depending on how that instrument behaves.
5. The analyzer runs the specimen and returns results.
6. Results are parsed, matched to the originating order, and delivered to the LIS.

Step 4 is worth a note. Not every analyzer wants to be told; many prefer to ask. LISBridge answers worklist queries on every transport and replies in the same dialect the analyzer asked in — a query that arrives as ASTM gets an ASTM worklist, a QRY^Q02 gets a DSR^Q03. Orders are held against the specimen rather than pinned to a bench, so an order stays answerable to whichever instrument legitimately asks for it, and an analyzer is never handed work that was routed elsewhere.

For the broader picture of how the pieces fit between instruments and hospital systems, see laboratory integration and how it works.

FAQ

Does order pull replace HL7 order intake?

No — it is an additional path. If your hospital already has an MLLP feed pushing ORM or OML messages and it works, keep it. Pull exists for the very common case where establishing that inbound path is the blocker.

What if our HIS has no pull endpoint?

Most modern systems can expose a read endpoint for pending orders more easily than they can be granted a new inbound path into a clinical network — it is a change on their side rather than on the security perimeter. Where the HIS genuinely cannot, conventional inbound HL7 intake remains supported.

How frequently should it poll?

One to two minutes covers routine workflow without noticeable waiting. Labs with a heavy stat workload sometimes go shorter; the constraint is what your HIS is comfortable serving.

Is the pull token safe to reuse across devices?

It is a global token by design, which makes deployment across several devices straightforward. Treat it as a credential: store it in the application rather than in a shared document, and regenerate it if a device is decommissioned outside your control.

Does this require the internet?

It requires network reachability to your HIS, which for most labs is on the internal network rather than the public internet. LISBridge itself runs locally and its licensing is enforced offline, so a WAN outage does not stop result capture — only the polling cycle pauses, and resumes when the endpoint returns.

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