Wiring Analyzers into the LIS

Walk into any mid-sized diagnostic lab and you will find a technologist retyping results. The haematology analyzer prints a strip, someone reads the strip, and someone keys the numbers into the information system. It works, until it does not: a transposed digit on a potassium result, a sample ID typed one off, a critical value that sat on a printout for twenty minutes because nobody was standing at the machine. Analyzer interfacing exists to close that gap. Done well, the result leaves the instrument and lands in the LIS with no human hand in between. Done badly, it introduces new and stranger failures than the manual process it replaced.

The Two Dialects Every Lab Speaks

Most laboratory instruments talk in one of two dialects, and you will meet both. The older one is ASTM E1381/E1394, a serial protocol that predates the web and still runs the majority of installed analyzers. The newer one is HL7, usually version 2.x, carrying ORU result messages and ORM order messages. Plenty of instruments now speak HL7 over TCP; plenty of older ones only offer a nine-pin serial port and an ASTM frame.

The interface engine's job is translation. It has to:

• Read the instrument's native frames, whether that means listening on a serial line or accepting an HL7 message on a socket.
• Map the instrument's test codes to your LIS test codes, because the analyzer calls it GLU and your LIS calls it Glucose-F.
• Normalise units and reference ranges so a result means the same thing regardless of which of your three chemistry analyzers produced it.

Kōami's LIS sits on an interface layer that speaks both dialects, so a lab can run a decade-old cell counter and a brand-new immunoassay analyzer side by side without maintaining two mental models.

Unidirectional Is Simple, Bidirectional Is Worth It

There are two levels of ambition. A unidirectional interface pushes results from the analyzer to the LIS. It is straightforward, it eliminates transcription, and for a low-volume bench it may be all you need. A bidirectional interface adds the return path: the LIS sends the worklist and the sample identity to the analyzer, so the instrument knows which tests to run on which tube before the technologist touches anything.

Bidirectional is more work to commission, and it is worth it in any lab with real volume:

• It removes the second transcription - the one where a technologist programs the analyzer by hand - which is where sample mix-ups are born.
• It supports host query, where the analyzer scans a barcode, asks the LIS "what do I run on this tube," and gets an answer in real time.
• It lets you add or cancel a test after the tube is loaded without walking back to the machine.

A unidirectional interface saves typing. A bidirectional interface changes who is responsible for getting the right test on the right tube - and hands that responsibility to software that does not get distracted.

Nothing Auto-Verifies Until the Rules Say So

The fear every lab director voices is the same: if results flow straight through, will a wrong number reach a clinician unchecked? The answer is that raw instrument output should never post automatically. Between the analyzer and the verified report sits a layer of rules, and that layer is where a good interface earns its keep.

Auto-verification releases a result without human review only when it passes every gate you set:

• Delta checks, which flag a result that has moved implausibly far from the patient's previous value for the same test.
• Analytical range limits, which hold anything outside the instrument's reportable range for a technologist to look at.
• Critical-value rules, which never auto-release. A potassium of 6.8 or a platelet count of 15 gets escalated to a human and, ideally, triggers a documented call to the ward.

Everything that fails a rule lands in a review queue. Everything that passes flows through. The point is not to remove the technologist; it is to spend their attention on the ten results that need it instead of the four hundred that do not. Kōami lets a lab tune these rules per test and per analyzer, because a delta check that makes sense for creatinine is nonsense for a one-off tumour marker.

Commissioning Is Where Interfaces Live or Die

An interface that passed a vendor demo can still fail in production, and the reasons are mundane. A firmware update changes the frame format. Someone swaps the serial cable for one with a different pinout. The analyzer's clock drifts and results arrive stamped in the wrong order. The unglamorous work of commissioning and monitoring is what separates an interface that runs for years from one that quietly corrupts data.

Treat it as an operational discipline:

• Validate the mapping with real samples across the full analytic range before going live, not just the two control levels that happen to be loaded.
• Reconcile counts daily at first - results produced by the analyzer versus results landed in the LIS - so a silent drop is caught in hours, not weeks.
• Alarm on silence. An interface that stops sending is more dangerous than one that sends errors, because errors get noticed and silence does not.

Kōami surfaces interface health as something a lab supervisor can watch, so a stalled connection raises a flag instead of a mystery.

Analyzer interfacing is one of those investments whose payoff is measured in things that stop happening: the mistyped result, the delayed critical call, the sample run twice because nobody was sure the first run posted. It is not glamorous engineering. It is careful mapping, honest rules, and monitoring that assumes something will eventually break. Get that right and the lab gets faster and safer at the same time, which is a rare combination worth working for.