How does medical laboratory analyzer work regarding protocols and communication?

Question

I have been studying about Abbott analyzers and came through ASTM protocol. I do not understand thought the exact process: 1)Is the "middleware/host" sending orders to the analyzer when a person visits the laboratory and requests to do some tests and prints a barcode which is being sticked to the speciment container so when the analyzer scans the barcode it knows already what orders to execute or 2)The laboratory software only creates a barcode and saves in a database the required tests and then the analyzer sends queries to the middleware/host to ask for this specific barcode what orders to execute?

When the analyzer scans the barcode, will it already have the orders in the memory or it will send queries to the middleware/host to ask for orders?

Answer 1

In general, there are 2 main types of LIS interfaces:

1. Bi-directional - communication both ways. LIS can push the orders to the instrument or drop them on a 3rd party communication card (Data Innovations). Instruments can then compare a scanned barcode within its memory or query the card/LIS. Instruments can push the test results to the card/LIS when completed.

2. Uni-directional - communication 1 way.

   a - Instrument only receives orders from LIS. User required to type results into LIS.

   b - Instrument only sends results to LIS. User required to put specimen in a tray position dictated by the LIS or barcode the sample.

For Abbott instruments you would need to provide a model # to know what interface options are available.

Answer 2

To expand on Bart's answer a little...

For a Bi-directional there are two main ways of operating:

Pushed order. Much as Bart described, once a order is booked into the LIS for tests that are set up on a particular analyser the LIS sends a message to the analyser with the order details. For example (in ASTM):

H|\^&|||TPS|||||AIA-21||P|1|20230110164703
P|1|2602158|2602158||EDITESTPATIENT^Nine||19600902|M
O|1|2602158||^^^sIgG_m3^8|||||||||||Sp.1 L|1|N

Here the LIS has sent this order message unsolicited to the analyser. It's for specimen number 2602158 on EDITESPATIENT Nine. The test required is sIgG_m3 using test method 8. The analyser must store this order until it sees specimen 2602158.

Host query. When a specimen is loaded on to the analyser it send a query to the LIS asking what tests it requires. If the specimen order has been booked in to the LIS then the LIS responds with the specimen details of any tests it requires for that analyser (bearing in mind that a specimen may require many different tests done on many different analysers, the LIS will be set up to send the right test codes to the right analysers). For Example:

H|\^&|||Panther|||||Host||P|1|
Q|1|^9536958||ALL||||||||O
L|1|N

This is a query message from a Panther analyser to the LIS. A single specimen was been loaded the a barcoded ID number 9536958. The LIS responds with the following message:

H|\^&|||Host|||||Panther||P|1
P|1|12345678|||EDITESTPATIENT^TWENTYONE||19650715|F|||||CMIC
O|1|9536958||^^^SARSCoV2^|R|20221230090400|||||N||||Swab||||||||||O
L|1|N

The response tells the analyser that specimen 9536958 is for patient number 12345678 (EDITESTPATIENT, TWENTYONE) is it needs a SARSCoV2 test (COVID-19).

There are advantages and disadvantages of each method. Pushed orders means the analyser already has the order ready and waiting in its database and it can get on with it as soon as it sees the specimen. This is potentially important in high throughput situations (such as tracked fully automated laboratories) where delays in doing host queries and waiting for responses from the LIS can easily cause a tailback in your laboratory I/O module. But the interface for both your LIS/Middleware and the analysers needs to be able to effectively handle order changes, additions an cancellations too, which adds some complexity. And your analyser will be handling a database of orders, some of which they'll potentially never see. That needs to managed, which is straight forward enough (an automatic expiry after a given time period is generally the way forward), you just need to have done it (surprising how often I've seen it forgotten).

Host query dispenses with the need to handle order additions, cancellations and changes, and the analyser doesn't need to maintain a database of orders. But it does need to communicate with the LIS and await a response for each order, which can be a problem in high throughput labs. The ASTM protocol was originally defined with RS232 (serial) comms in mind with a default 9600 baud rate. Many analysers still use serial comms (although can generally go faster than 9600 baud these days). For these systems we use a Terminal Server device (see Lantronix UDS 1100) to convert serial comms to TCP/IP for sending messages on to the LIMS. Although most analysers can instead used a direct TCP/IP connection these days, but not all.

As ASTM was designed with serial in mind it's usually a single channel comms protocol with defined cooperation between the LIS and analyser as to which has priority over message sending and receiving. If one side wants to send a message it starts by sending an ENQ control code. If the other side is ready to receive it replies with a ACK, or if it isn't, it replies with a NAK. If the first side received a NAK reply it must wait 5 seconds before trying again. If it gets an ACK it can get on with sending its message. If one side is sending a message the other must wait until it has finished (signified by an EOT) before it can start sending a message. Clearly this can create delays with message flow if theres lot happening (think host queries for hundreds of specimens and the responses along with hundreds of results messages), especially if you happen to be limited to 9600 baud.

Some analysers have extended ASTM to use separate incoming and outgoing comms channels, just like HL7, directly over TCP/IP which solves some of these issues. But if that's what you're going to do, why not just use an HL7 interface instead of ASTM? HL7 is a more tightly defined protocol, more suited to high data throughput. I guess, the answer is because the analyser vendor already has a defined ASTM interface written, with LIS drivers widely available so its cheaper to keep that rather than reimplementing it using HL7. Fortunately, there are some analysers that do give you the option.