If you run a diagnostic laboratory, you have probably been told your analyzers are "integrated" with your information system. In most labs we look at, they are not. What has usually been installed is a one way result feed, and the difference between that and a genuine bidirectional interface is roughly the difference between a printer and a conversation.
This article is written for lab owners, pathologists and operations managers who are evaluating whether to build or buy an interface, and who want to understand what they are actually paying for. It assumes no software background, but it does not simplify the parts that matter.
1. The difference between one way and bidirectional
A unidirectional interface means the analyzer sends results out and something on the other end catches them. That is genuinely useful. It stops a technician retyping numbers, which is where most transcription errors come from. But the analyzer is still working blind. It does not know what tests were ordered for the sample sitting in the rack. Somebody has to tell it, usually by keying a worklist into the analyzer keypad or loading samples in a fixed sequence and hoping the order holds.
A bidirectional interface closes that loop. The analyzer reads the barcode on the tube, asks the host system "what do you want me to run on this sample", and the host answers with the exact test panel that was ordered. Results come back tagged to the right patient and the right order automatically.
Ask your current vendor one question: can a technician load a rack of tubes in any order, with no worklist entered on the analyzer, and have every sample run the correct panel? If the answer is no, you have a one way feed, whatever the contract calls it.
The operational difference compounds quickly. Sample sequencing errors disappear. Rerun and reflex logic can be driven centrally instead of configured per instrument. A technician stops being the integration layer between two machines that could talk to each other directly.
2. The protocols your analyzers actually speak
Almost every clinical analyzer in service speaks one of two language families, and knowing which one you have determines most of the work.
ASTM E1381 and E1394, now published as CLSI LIS01-A2 and LIS02-A2
This is the older and still overwhelmingly common family, especially on biochemistry and haematology instruments. It defines a record structure, header, patient, order, result, comment and terminator records, each a delimited line, plus a low level framing and handshake layer. Messages are wrapped in control characters, split into frames if they exceed length limits, and each frame carries a checksum the receiver validates before acknowledging.
The handshake matters more than people expect. The sender raises an enquiry, waits for acknowledgement, transmits framed data, and waits for an acknowledgement or a negative acknowledgement per frame. Get the timing or the retry behaviour wrong and the interface appears to work in testing, then silently drops results under load when two instruments transmit at once.
HL7 version 2.x
Newer instruments and most middleware speak HL7 v2, typically wrapped in MLLP over a TCP socket. Order messages and result messages carry the clinical content in pipe delimited segments. HL7 is better documented and easier to reason about, but it is famously loose. Two vendors can both be "HL7 compliant" and still disagree on which field carries the sample identifier.
The honest summary: neither protocol is difficult in isolation. What makes these projects hard is that every instrument vendor implements the standard slightly differently, and the deviations are usually undocumented. You find them by connecting to the actual instrument and reading what comes down the wire, not by reading the specification.
3. Serial, TCP and the physical layer
A surprising number of analyzers still present an RS-232 serial port as the primary interface, including instruments purchased recently. If the analyzer and the server are not physically adjacent, that becomes a cabling question or a serial to ethernet converter question before it becomes a software question.
Things worth establishing early, because they change the estimate:
- Serial or TCP for each instrument, and if serial, the baud rate, parity and flow control the vendor expects
- Whether the analyzer initiates the connection or expects the host to listen
- Whether the instrument can be configured for host query mode at all, or whether that requires a firmware or software option from the vendor
- What happens to results generated while the host is unreachable, whether the analyzer queues them or discards them
That last point deserves attention. An interface that loses results during a network blip is worse than no interface, because staff stop trusting it and quietly go back to manual entry while still paying for the system.
4. Where these projects break
In our experience the protocol itself is rarely the thing that sinks a laboratory interface project. These are:
Sample identifier mismatch
The barcode on the tube, the accession number in the information system, and the sample identifier the analyzer transmits are three different things in many labs. Reconciling them is often the single largest piece of work, and it is a process design question as much as a technical one.
Quality control results arriving as patient results
Most analyzers transmit QC runs on the same channel as patient samples. If the interface does not recognise and divert them, QC values land in patient records. This needs to be handled explicitly and tested deliberately.
Flags, alarms and non numeric results
Real analyzer output is not a clean number. It carries abnormal flags, instrument alarms, dilution indicators, values reported as greater than or less than a threshold, and error codes. An interface built and tested only against clean numeric output will fail on the first haemolysed sample.
Units and reference ranges
Instruments can be configured in different unit systems and often transmit their own reference ranges, which may or may not match the ones your reports should show. Deciding which system is authoritative is a clinical decision that should be made before code is written, not after.
The second analyzer
Interfaces are almost always scoped for one instrument and then quietly expected to handle four. Multiple concurrent connections, per instrument configuration and independent failure handling are architectural decisions. Retrofitting them into a single instrument design is usually a rewrite.
Not sure which category your current setup falls into?
Send us the make and model of your analyzers and a description of how results reach your system today. We will tell you whether what you have is bidirectional, what it would take to get there, and whether it is worth doing. No charge and no obligation.
Book a Discovery Call5. The interface licence trap
This is the part that catches most laboratories financially, and it has nothing to do with software difficulty.
Many analyzer manufacturers treat the data interface as a chargeable option rather than a standard capability. The instrument is fully capable of host query mode, but the feature is locked until you buy an interface licence, and in some cases the vendor will only enable it for their own information system or an approved partner. The protocol documentation may also be withheld or released only under agreement.
Before commissioning any interface work, get written answers to three questions from each analyzer vendor:
- Is host query, meaning bidirectional, supported on this exact model and firmware version, and is it currently enabled on our unit
- What is the one time and recurring cost to enable it, and does that cost differ depending on which system we connect to
- Will you supply the interface specification document, and under what conditions
If a vendor will not enable bidirectional mode for a third party system, that is a genuine constraint on your options and you should know it before you spend anything on development.
6. Middleware or direct integration
There are two credible architectures and the right answer depends on your instrument count.
| Consideration | Direct integration | Middleware layer |
|---|---|---|
| Best suited to | One to three instruments, stable configuration | Four or more instruments, or mixed vendors |
| Upfront cost | Lower | Higher |
| Cost of adding an instrument | Significant, often near the original build | Incremental, usually configuration only |
| Rules and reflex logic | Handled in the information system | Handled centrally in the middleware |
| Failure isolation | One connection failing can affect the whole path | Per instrument isolation is straightforward |
The mistake we see most often is a lab with six analyzers paying for six point to point integrations built at different times by different people, none of which log consistently, so when a result goes missing nobody can say which link dropped it.
7. How to scope the work before you commit budget
Whether you build this in house, hire us, or hire anyone else, insist on this information being gathered before a fixed price is quoted. Any competent vendor will want it too.
- An inventory of every analyzer: make, model, firmware version, protocol, transport, and current interface licence status
- A captured sample of real traffic from each instrument, meaning an actual log of what the machine transmits, not the specification
- The current sample identifier flow, from requisition to barcode to accession number
- A decision on which system owns units and reference ranges
- An explicit answer on QC handling
- Expected daily sample volume and peak concurrency
- What must happen when the host is unavailable
A single analyzer, one protocol, clean identifiers and no licence obstruction is a matter of weeks, not months. A multi instrument laboratory with mixed vendors, contested identifiers and no captured traffic is a different project entirely. Anyone who quotes you a firm price for the second scenario without seeing your actual instrument output is guessing.
Where we fit
Ponykaams has built laboratory information systems with direct analyzer interfacing, including bidirectional biochemistry and haematology work, alongside diagnostic centre booking platforms and healthcare reporting systems. We are a software consultancy, not an instrument reseller, so we have no incentive to steer you toward a particular analyzer or an unnecessary middleware purchase.
If the honest answer is that your existing setup is adequate and the money is better spent elsewhere, we will say so.
Common questions
