Analyser interfacing: what actually connects, and how

Without an interface, someone reads a number off an instrument display and types it into a screen. On a busy day that is several hundred transcriptions, done by a person who is also doing four other things.

The time saving is real but secondary. The reason interfacing matters is that manual transcription is the largest single source of error on the bench, and its failure mode is silent. A mistyped haemoglobin looks like a haemoglobin. A decimal place in the wrong position on a potassium result is a clinical event that no validation rule will necessarily catch, because the value is still a number in a plausible range.

Nearly every analyser in an Indian lab speaks one of two protocol families. Which one is usually a setting on the machine rather than a fixed property of it, and plenty of instruments support both.

ASTM E1381 / E1394

The older pair, and still common on serial-connected instruments. E1381 is the low-level conversation — ENQ to ask permission, ACK to grant it, frames wrapped in STX and ETX with a checksum, and a retry if the checksum fails. E1394 is what is inside those frames: a header record, then patient, order, result and comment records, then a terminator.

HL7 v2

The newer and more common choice on networked instruments, typically v2.3.1 or v2.5.1. Results arrive as an ORU^R01 message — an observation result. Framing is usually MLLP, a thin wrapper that marks where each message starts and ends on the socket.

Vendor variants

Both standards leave room, and manufacturers use it. Two instruments can both claim HL7 v2.3.1 and disagree about which segment carries the sample identifier. Expect to read one real message from your actual machine before anything is certain.

The practical consequence: the protocol name in a brochure tells you which stack is needed, not whether the interface will work. That is settled by capturing a real transmission from the specific instrument, in the mode your lab will actually run it in.

Beneath the protocol is the physical question of how the two machines are joined, and this is where most interfacing projects stall.

• Serial (RS-232). A cable, often through a USB converter on the LIS side. Simple, reliable, and limits you to one instrument per port at whatever distance a cable reaches.
• Network (TCP/IP). Ethernet. More flexible, and introduces the direction question below.

On a network connection, one side listens and the other dials. It is easy to assume the LIS is the server and the analyser reports in to it — and on many instruments it is the other way round. The analyser listens on a port and expects the LIS to connect to it. Others can be configured either way, with the setting buried in a communications menu.

There is a related trap worth naming, because it has cost real projects days. Analysers are sometimes configured on an isolated subnet with no gateway — a machine on 10.0.0.2 with a blank gateway cannot be reached from a lab LAN on 192.168.x, no matter how correct the software is. The receiving computer has to sit on the same subnet, or the network has to be changed.

This is the single most useful thing on this page when you are evaluating a cloud LIMS that advertises analyser interfacing.

Your analyser talks over your lab’s own network, behind your router. A cloud application cannot hold a listening socket on that network, and cannot dial into a machine behind your NAT. There is no API endpoint anywhere on the internet that an analyser can be pointed at. This is not a limitation of any particular product — it is how networks work.

So every genuine cloud interface has a second component: a small always-on program running on a PC inside the lab, which speaks the protocol locally and forwards results up to the cloud. Whether a vendor mentions this unprompted is a reasonable proxy for whether they have actually done it.

Most analysers can be run in two modes, and the default is frequently the dangerous one.

With synchronous acknowledgement off, the instrument transmits and moves on. It never learns whether anything received the message. Auto-retransmit typically cannot be enabled without acknowledgement, so there is no recovery either. A result lost in transit is lost silently — on a sample that has already been consumed and cannot be re-run without calling the patient back.

With acknowledgement on, the receiver must answer within the instrument’s timeout — commonly around ten seconds — and the instrument can retry if it hears nothing. This is the mode you want, and switching it on is usually a checkbox.

Once messages arrive, the remaining work is translation, and it is where the lasting value and the lasting risk both live.

An analyser emits its own parameter codes. Your LIMS has its own test master. Something has to state that this instrument’s code for haemoglobin is your test master’s haemoglobin, in the same units, with your reference ranges applied. Multiply that by every parameter on every instrument.

Two rules are worth insisting on. First, units must be checked rather than assumed — an instrument reporting in one unit against a test master expecting another produces a plausible wrong number, which is the worst kind. Second, a mapping must never be written from memory or guessed from a similar name: a wrong mapping silently routes one analyte’s value into another analyte’s row, and the resulting report looks completely normal.

If you are mapping to LOINC codes as well — worth doing, because it makes results portable and comparable outside your own system — the same caution applies with more force. A LOINC code that is nearly right is wrong.

Answer these for each instrument, from the machine’s own settings screens rather than from a brochure. Most take a minute to check, and each one is a project delay if it is discovered late.

Everything above comes from our own interfacing work, including a capture taken off a real haematology analyser rather than from documentation — which is why this page is specific about acknowledgement modes and isolated subnets, and where the isolated-subnet example came from.

The status: analyser interfacing over HL7 on PingMeDoc™ is in pilot, not general availability. The ingest, mapping and instrument registry are built and proven against a real capture; the on-premise agent is the piece being hardened. We list it as a pilot on our own pricing page for the same reason it is stated plainly here — a plan inclusion is a commitment, and we would rather you knew now than during implementation.

If interfacing is the deciding factor for your lab, tell us which instruments you run and we will tell you honestly whether we can connect them today.