Instrument middleware as a correctness boundary

Plug-and-play has been an explicit goal of laboratory connectivity standards since the early 2000s, from POCT1-A2 to IHE LAW. Yet CLSI itself acknowledges that analyzer interfaces are still largely built instrument by instrument. And even a well-built interface can deliver a message correctly while carrying the wrong result. That gap is the focus of this article.

Three eras of standards share the same lab

The oldest layer comes from ASTM. E1381 and E1394 were transferred to CLSI in the early 2000s and became LIS01 and LIS02. According to CLSI, they were designed around RS-232 serial links and later extended to TCP/IP, with the protocols themselves essentially unchanged.

CLSI has archived both documents, but still considers them technically valid and keeps them in its library because of their value to laboratories.

Point-of-care devices follow a separate track. CLSI POCT1-A2, published in 2006, has the same status: no longer under active review, still technically valid.

The newest layer is the IHE Laboratory Analytical Workflow (LAW) profile, consolidated by CLSI as AUTO16 in 2019. It moves analyzer communication to HL7 v2.5.1 and adds support for LOINC, UCUM and SNOMED CT. In Europe, LAW is one of the 27 IHE profiles that Commission Decision (EU) 2015/1302 made eligible for referencing in public procurement.

According to the AUTO16 chairholder, all major IVD companies are implementing it, although at IHE the profile is still at Trial Implementation status.

Part of this coexistence is deliberate. AUTO16 explicitly excludes point-of-care exchange, which POCT01 already covers. A laboratory with both core analyzers and POC devices is therefore likely to deal with more than one standard, alongside whatever its older instruments use.

FHIR plays a different role here. HL7's LIVD guide uses it to publish how vendor test codes map to LOINC: configuration and terminology, not result transport. The layer between LIS and hospital systems is the one we looked at in our article on FHIR as an architectural problem.

Each vendor implements its own dialect

CLSI itself names the problem. In announcing AUTO16, it noted that the variability LIS02 leaves to implementers has produced unique vendor implementations, requiring LIS and middleware vendors to build interfaces tailored to each instrument.

Clinisys, writing about POCT1-A2, uses a useful metaphor: the standard is a language an instrument either speaks or does not, while each vendor's implementation is a dialect. In its view, one POC device cannot be swapped for another just because both follow the same standard.

The dialects show up in the details. Clinisys reports that different vendors use the POCT1-A2 device, vendor and serial ID fields for different things, from MAC addresses to model numbers. In a peer-reviewed case report on a POC data management system, Park, Heo and Choi note the same at message level: standard-based messages can be inconsistent when field meanings are ambiguous.

Transport can succeed while content fails

At the frame level, LIS01 defines error detection, error recovery, timeouts and retransmission limits. These mechanisms check that a message arrives intact. They do not check what it means.

An older but instructive case, reported in ADLM's Clinical Laboratory News in 2012, shows the difference. Therapeutic drug monitoring results were sent by an instrument with a "greater than" symbol and read by the LIS as "less than". The error went undetected for seven weeks and affected 187 results. The cause was an instrument default not reset after a software upgrade.

The value was sent correctly and misread on arrival, an instrument-level version of the mapping errors we described for LIS-to-hospital integration. The same article notes that QC, proficiency testing and calibration verification are usually ineffective at catching software errors of this kind.

Peer-reviewed work points in a similar direction. Arifin and Yusof list inconsistent software design in system integration and errors in inter-system data transmission among the causes of LIS-related errors.

A mis-mapped value, a retransmitted result stored twice, an ordered test whose result never comes back. In our experience, these are among the hardest errors to catch, because the transport layer sees a clean exchange while the laboratory workflow remains wrong or incomplete.

Build correctness into the integration layer

We think the integration layer, typically the instrument middleware, is the natural place to build the properties that protocols do not guarantee on their own:

• A canonical internal model. Every dialect is translated into one representation, with qualifiers such as "<" and ">" and result flags treated as first-class fields, not string fragments.
• Idempotent ingestion. A retransmitted result is recognized as such, not stored twice. LAW helps here, since every work order step carries a unique ID assigned by the Analyzer Manager. With legacy protocols, the middleware usually has to build that key itself.
• Explicit reconciliation. Orders sent and results received are tracked against each other, so missing data becomes detectable instead of going unnoticed.
• Interface regression testing. Every instrument firmware or driver update reruns the interface tests, since upgrades and configuration changes recur among the error cases ADLM describes.

One pattern that holds this together is an instrument interface library treated as a product component. Each analyzer gets a driver that isolates its dialect behind a stable internal contract. Adding an instrument then mostly means writing a driver, and a move from LIS02 to LAW can stay largely confined to it.

Engineer correctness instead of assuming it

With archived standards still valid and the newest still at trial implementation, coexistence is likely to continue. For IVD software teams, that moves the design decision from which standard to adopt to where correctness is enforced.

Aimasoft builds that layer for instrument manufacturers and distributors: interfaces where data correctness is engineered across heterogeneous protocols, rather than inferred from a conformance statement.