Bidirectional Analyzer Interfaces: What “Integrated” Should Mean in Your LIS/LIMS Contract
Understand how bidirectional analyzer interfaces connect laboratory instruments with LIS/LIMS, compare interface types, and identify the essential contract clauses, validation requirements, costs, and responsibilities before choosing a vendor.
Table of Contents
TL;DR
A modern Laboratory Information Management System replaces the spreadsheets, paper logs, and disconnected instrument software that quietly drain accuracy and throughput from today’s diagnostic labs. By unifying sample tracking, instrument integration, quality control, and regulatory reporting on a single compliant platform, a well-implemented LIMS routinely cuts result turnaround time by around 40%, reduces transcription errors by nearly 80%, and lets lean teams scale throughput several times over without proportional headcount growth. In the rest of this article we cover the operational jsdkf forcing the shift, the four non-negotiable capabilities of an enterprise-grade system, a side-by-side comparison of manual versus LIMS-driven workflows, and a practical 90-day implementation checklist used by labs that go live successfully on the first attempt.
A bidirectional analyzer interface lets your LIS/LIMS send test orders to an analyzer and receive the results back, usually as ASTM or HL7 messages. In an LIS/LIMS contract, “integrated” should name the analyzer models, the message direction, the builder, the timeline, and the validation steps. The word alone promises none of them.
Somewhere in your lab, a technician can key a sample ID into an analyzer faster than most people can unlock a phone. It is a real skill. It was also supposed to retire the day the system was declared “integrated”, and in many labs it never quite did.
That is the awkward part of any LIS instrument interface: it is easy to demonstrate and hard to verify. A vendor can show a result landing on screen within seconds. Nobody in the room can tell whether it arrived through a validated two-way link, a one-way feed, or that same technician, typing quickly in the next room.
Typing is not a harmless fallback. Researchers at UW Medicine compared 6,930 manually entered point-of-care glucose results with the interfaced results for the same tests, and 260 of the manual entries (3.7%) did not match. About 5 in every 1,000 were clinically significant discrepancies (Mays and Mathias, JAMIA, 2019). The study is older than ideal and covers point-of-care glucose in outpatient clinics, but paired datasets like it are rare.
This guide takes the contract view. You will see what each interface type does, which one suits which analyzer, which ten clauses to write down, and how to validate the interface before it touches a patient result.
Already have your analyzer list to hand? Check whether your analyzers are supported against CrelioHealth’s published device list, then come back for the clauses.
What a bidirectional analyzer interface actually does
A unidirectional interface only sends results from the analyzer to the LIS/LIMS. A bidirectional interface also sends the test orders to the analyzer, so nobody types them in twice. That is the whole difference between the two kinds of LIS instrument interface, and it decides how much manual work survives at the bench. A LIMS instrument interface follows the same pattern, so this guide says LIS/LIMS throughout.
Unidirectional: results only
With a results-only link, the analyzer sends finished results up to the LIS. Staff still create the order on the analyzer by hand: scan or type the sample ID, pick the tests, press start. It works, and for analyzers that cannot accept orders, it is the only option. It does mean the order lives in two places, and the two copies can drift apart.
Bidirectional: orders down, results up
A bidirectional interface moves data both ways, in one of two patterns. In order download, the LIS pushes the order to the analyzer before the sample arrives. In host query, the analyzer reads the sample barcode and asks the LIS what to run.
A host query happens when an analyzer reads a sample barcode and asks the LIS, the host system, which tests to run on that sample. The LIS replies with the order, so staff never select tests at the analyzer. The analyzer then runs those tests and sends the results back.
Results travel back along the same link, with flags, comments, and rerun requests. This is the full path of one sample:
- Order entered in the LIS
- Order download or host query sends the order to the analyzer
- Analyzer runs the tests
- Result upload returns values and flags to the LIS
- Verification in the LIS
- Report released
Buyers write it as bidirectional or bi-directional, and search for phrases like “bi-directional interface with lab equipment”. The spelling varies. So does what vendors mean by it, which is why the next section exists.
| Aspect | Unidirectional | Bidirectional |
|---|---|---|
| Order entry | Entered by hand at the analyzer | Sent from the LIS by order download or host query |
| Result transfer | Analyzer sends results to the LIS | Analyzer sends results, flags and rerun requests to the LIS |
| Typical error risk | Order mismatch between LIS and analyzer; wrong tests selected at the bench | Test code and unit mapping errors, which validation should catch |
| When it is used | The analyzer cannot accept orders | The analyzer supports host query or order download and the lab wants no manual order entry |
For the basics and benefits, CrelioHealth’s earlier post on the basics and benefits of interfacing covers the ground. This guide starts where that one stops.
Why "integrated" is not a contract term
Vendors use “integrated” for anything from a one-way result feed to a fully validated two-way interface, so the word alone commits them to nothing.
Read it the way a contract lawyer would. “Integrated” can describe a results-only link. It can mean orders and results both ways. It can mean a connection through middleware that someone else licenses. It can even mean “supported on some analyzer models, just not yours.” Every one of those fits the word.
Picture a lab (an illustrative composite, not a real customer) that signs for “integration with all major analyzers.” At go-live, two of its six analyzers work both ways, one sends results only, and three are “on the roadmap.” The vendor has broken nothing, because the contract promised nothing specific.
The cost of that gap lands on your bench. Staff go back to retyping orders and results, and delays follow. When the analyzer vendor and the LIS vendor each say the fault sits with the other, you are the only party with a stake in settling it.
To be fair, manual entry is not always sloppy. A 2025 Hong Kong study of paper-to-LIS entry in semen analysis measured transcription error rates of 0.05% to 0.07% for paper forms, against video recordings of the counter readings. The authors also note that catching such errors usually means a second technician checking entries, which adds cost and slows reporting (Lam et al., Basic and Clinical Andrology, 2025). Low error rates are possible by hand. They are expensive to keep.
A demo is a performance. The contract is the record. If an interface detail is not written into the schedule, assume you have not bought it. Swap each vague phrase for a specific ask:
- “Integrates with most instruments” becomes a named list of your analyzer models, with software versions.
- “Bidirectional” becomes a table of tests and message direction for each analyzer.
- “Supported” becomes live in production at another lab on the same model, or a dated build commitment.
- “Quick turnaround on new interfaces” becomes a milestone date for each analyzer in the schedule.
- “Standard support” becomes a named owner and a response time for interface downtime.
ASTM, HL7 and middleware: the messaging behind the interface
An interface is a set of agreed messages. Most analyzers speak ASTM or HL7, and the LIS either connects to the analyzer directly or goes through middleware.
ASTM and HL7 in plain words
What is ASTM in a lab? In analyzer interfacing, ASTM usually refers to the E1394 specification, published by CLSI as LIS02, which covers two-way transmission of test requests and results between instruments and information systems. Its companion, LIS01, covers the low-level protocol that carries the messages.
What is HL7? Health Level Seven (HL7) is a family of healthcare messaging standards. In lab interfaces, HL7 version 2 messages carry orders (ORM, the general order message) and results (ORU, the unsolicited observation result). Some interfaces use an OML message for lab orders instead.
Both formats carry orders, results, and flags. Which one you get depends on the analyzer, the version its maker has implemented, and whether the vendor has switched it on. CLSI also publishes AUTO16, a next-generation instrument interface standard built on HL7, so it is fair to ask whether your analyzers offer it.
Direct interface vs middleware
What is lab middleware? Lab middleware is software that sits between the analyzers and the LIS. It speaks each analyzer’s protocol, applies rules such as autoverification, reruns and routing, and passes clean messages to the LIS in a single format
| Path | Who connects to the analyzer | Best fit | Trade-off | Contract point |
|---|---|---|---|---|
| Direct | The LIS connects to each analyzer | Few analyzers, one or two brands | Each new analyzer needs its own build | Name the builder per analyzer |
| Middleware | The middleware connects; the LIS connects to the middleware | Mixed brands, older units, rule-heavy workflows | One more system to license, run and support | Name who licenses, runs and supports it |
What the analyzer vendor controls
Whichever path you choose, the analyzer’s maker holds three levers: the protocol documentation, firmware updates, and sometimes a license or fee to switch on the interface port. Your LIS vendor cannot waive any of them. The contract should say who deals with the analyzer maker, and who pays if there is a charge.
Which interface type fits your analyzers?
The right type depends on whether each analyzer supports host query, how many brands you run, and how much automation sits around them.
| Your situation | Interface type | Why | Contract point to add |
|---|---|---|---|
| Analyzer supports host query, and you want no manual order entry | Bidirectional, direct | Orders and results move automatically | Named model, direction and test menu |
| Analyzer can only send results | Unidirectional | The analyzer cannot accept orders | State that orders are entered on the analyzer |
| Many analyzers across brands, or older units | Middleware | One connection point for a mixed fleet | Who licenses, runs and supports the middleware |
| Automation line or very high volume | Bidirectional plus middleware rules | Reruns, reflex tests and routing are handled in rules | Rule changes and who owns them |
| You plan to add or replace analyzers | Any, plus a new-interface commitment | The fleet will change | A build timeline for each new analyzer |
A mixed fleet is common: a chemistry analyzer on host query, a hematology unit that only sends results, and an older unit behind middleware. That is normal. The contract just needs to say which analyzer is which.
Whichever LIS interface software you evaluate, the same table applies. For a concrete example of what a vendor’s options look like, CrelioHealth’s lab interface system page describes unidirectional and bidirectional interfaces, HL7 and ASTM support, and middleware connections for older analyzers. Keep it open beside this table when you compare vendors.
The contract clauses that define "integrated"
An LIS contract should define each analyzer interface through ten clauses: named analyzers, direction and test menu, acceptance criteria, builder, timeline, firmware responsibility, new analyzers, cost per interface, support and monitoring, and remedy. Together they turn “integrated” into something you can enforce.
This is buyer guidance in plain English, not legal advice. Ask your counsel to review the final terms.
Scope and acceptance
| Clause | What to specify | Good wording direction | Red flag |
|---|---|---|---|
| 1. Named analyzers | Each analyzer by make, model, and software version | A schedule listing every analyzer to be connected | "All major instruments" |
| 2. Direction and test menu | Order download, result upload, flags and reruns, per test | A table of tests and message direction for each analyzer | "Bidirectional" with no test list |
| 3. Acceptance criteria | How the lab accepts the interface as working | Written test cases and a sign-off step (see the validation section) | Acceptance equals "go-live happened" |
Responsibility and change
| Clause | What to specify | Good wording direction | Red flag |
|---|---|---|---|
| 4. Who builds | LIS vendor, analyzer vendor, or the lab's own IT | A named party per analyzer, including any analyzer-vendor fee | Responsibility left open between vendors |
| 5. Timeline | Build, test and go-live dates per analyzer | Milestone dates in the schedule | "As soon as possible" |
| 6. Firmware and software updates | Who revalidates the interface after an update | Notice before updates and a named party for retesting | The interface breaks after an update and nobody owns the fix |
| 7. New or replaced analyzers | Time and process to add an interface later | A stated process and target timeline for new interfaces | No commitment beyond the current list |
Cost and support
| Clause | What to specify | Good wording direction | Red flag |
|---|---|---|---|
| 8. Cost per interface | One-time build, recurring fee and analyzer-vendor charges | Every fee itemized per interface | Fees quoted only after signature |
| 9. Support and monitoring | Who watches the interface, and the response time when it fails | A support level that covers interface downtime | Interface issues treated as general tickets |
| 10. Remedy | What happens if the interface fails acceptance | A right to delay payment, extend time or exit that item | No consequence for missing the schedule |
Print the three tables, attach them to the contract as a schedule, and fill in every cell for every analyzer. A blank cell is a negotiation you have not had yet. Clauses 6 and 8 deserve extra time, because they cover obligations and costs that appear after signature.
CrelioHealth’s vendor selection checklist adds a useful habit here: ask every shortlisted vendor for a price breakdown that includes per-interface charges, so the comparison covers more than the license fee.
How interface validation should work before go-live
An interface is validated when written test cases show that orders arrive at the analyzer correctly, results return to the right patient and test, and failures are caught, with a record kept for audit. Validation happens before go-live, and the relevant tests repeat after any analyzer firmware or LIS update.
- Agree the test plan and test cases in the contract schedule before the build starts.
- Run order download or host query tests across the full test menu, not a handful of favorite tests.
- Verify results: units, reference flags, comments, reruns, and dilutions.
- Break it on purpose with failure tests: wrong patient ID, duplicate order, analyzer offline, message rejected.
- Sign off in writing, then repeat the relevant tests after any analyzer firmware or LIS update.
The lab has to take part. The vendor can run the scripts, but the person who signs the acceptance should have watched results arrive against the lab’s own test codes.
Keep the records. Test cases, results, deviations, and the sign-off are the evidence you will want if an assessor asks how you verified the interface. ISO 15189:2022, the current edition of the international standard for medical laboratories, includes requirements on control of data and information management (ISO). The standard applies to laboratories, not to software, so the evidence belongs to you. Your accreditation body decides what it expects, so check its rules rather than relying on a general reference.
Retesting after updates connects back to clause 6. If nobody owns revalidation after a firmware change, validation stays a one-time event instead of a practice.
What does a validated, rule-backed interface buy you? A 2022 study from the University of Iowa compared manual entry with an interface through middleware for nearly 100,000 point-of-care chemistry and hematology values over 38 months at two clinics. Serious or obvious errors fell to none after the interface with autoverification, apart from three tied to manual edits of results that had failed autoverification. The authors estimated 21.6 employee hours saved per month by removing manual entry (Fleishhacker et al., Journal of Pathology Informatics, 2022). It is one academic system and point-of-care devices, so read it as a direction, not a guarantee.
A shorter, practical example sits in CrelioHealth’s Arpan Diagnostic Centre case story, which describes interfacing a Sysmex XN-series analyzer so that analyzer flags and QC alerts appear on the LIMS reporting screen.
Questions to ask vendors about analyzer interfaces, with red flags
Eight questions, asked before signing, show whether a vendor can actually deliver the interfaces it names. Ask for the answers in writing. A vendor that answers every question fluently in a meeting and hesitates on paper has told you something.
| Question | Red flag |
|---|---|
| 1. Which of our analyzer models are already live in production, and can we talk to a lab that runs the same model? | Only "supported" models, and no live reference |
| 2. Is the interface bidirectional for our test menu, and can you show an order arriving at the analyzer? | A demo on an emulator, or results appearing with no order sent |
| 3. Who builds, tests, and supports each interface, and who talks to the analyzer vendor? | "We will coordinate" with no named party |
| 4. What is the build timeline for a net-new analyzer, and where is it written? | A verbal estimate that is not in the contract |
| 5. Who pays any analyzer-vendor interface fee? | A fee that appears after signature |
| 6. What happens to the interface when the analyzer firmware changes? | No notice period and no retest commitment |
| 7. How do you monitor interfaces, and how fast do you respond when one fails? | Interface faults handled as general support tickets |
| 8. What does acceptance testing look like, and who signs it off? | Acceptance means the vendor says it is done |
For the high-level version of the interface question, see question 2 in CrelioHealth’s 10 critical questions for LIS vendor evaluation. It focuses on interface counts and service levels for new builds. The eight above go one level deeper, into who does what on your analyzers.
How can you check that your analyzers are supported?
To check supported analyzers, list your own models, compare them with the vendor’s device list, and ask for a reference lab running the same model.
- List each analyzer by make, model, and software version.
- Check the list against the vendor’s published device list. For CrelioHealth, that is the device list.
- Ask what is supported today, what is planned, and what needs a new build.
- Ask for the written schedule from the clause tables, and for a reference lab on the same model.
A device list tells you a model has been connected before. It does not tell you your firmware version, your test menu, or the direction of the messages. That is the job of the schedule in your contract.
If your analyzer is not on the list, say so early. CrelioHealth’s device list page includes a form for requesting an instrument that is not listed, and its integrations hub covers the wider set of software connections.
Check whether your analyzers are supported, or talk to an integration engineer about an analyzer that is not on the list.
Frequently asked questions
What is a host query in a laboratory information system?
A host query is a request from an analyzer to the LIS, the host system, asking which tests to run on a sample. The analyzer reads the sample barcode, the LIS replies with the order, and the analyzer runs those tests. It removes manual order entry at the analyzer and keeps one source of truth for orders.
What is the difference between ASTM and HL7 for analyzer interfaces?
ASTM and HL7 are two message formats that carry orders, results, and flags between analyzers and an LIS. ASTM messages follow the E1394 specification, published by CLSI as LIS02, and HL7 messages follow the HL7 version 2 family. Which one applies depends on the analyzer’s implementation and on whether middleware sits in between.
Do I need middleware between my analyzers and my LIS?
Middleware is worth considering when you run analyzers from several brands, keep older units, or need rules for reruns, reflex tests, and routing. A direct interface can be enough for a few analyzers from one or two brands. Either way, the contract should name who licenses, runs, and supports whatever sits in the middle.
Who is responsible when an analyzer firmware update breaks an interface?
Whoever the contract names. A firmware update can change how an analyzer formats its messages, so someone has to retest the interface afterwards. If clause 6 is blank, the LIS vendor and the analyzer vendor can each point at the other. Write down who gets notice, who retests, and who pays.
How long does it take to build a new analyzer interface?
The answer depends on the analyzer. Build time is shaped by the quality of the protocol documentation, how much the analyzer vendor cooperates, the size of the test menu, and how thorough validation is. Ask the vendor for a written timeline per analyzer, not a general range, and put it in the contract schedule.
Recent Posts
Related Posts
Most labs can show an inspector their critical values list. Far fewer can show who was called at 2 am...
Understand how bidirectional analyzer interfaces connect laboratory instruments with LIS/LIMS, compare...
Mobile phlebotomy is a lab-run service that sends a trained phlebotomist to collect specimens at the...