14 days free, no card, and we move your data across for youStart a lab trial
Recognised by
Trusted & regulated
HL7 or ASTM, serial or network, one-way or two-way. And the detail most vendors skip: a cloud service cannot listen to your analyser at all. What a lab should understand before buying an interface.
Written by the PingMeDoc™ team, last checked 22 August 2026, 10 min read
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.
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.
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.
What that local component must do
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.
Per instrument
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.
Send us your instrument list (make, model and how they are connected) and we will tell you plainly which ones we can interface today and which are still pilot.
Read next