How to Connect a New Analyzer to Your LIS: A Step-by-Step Guide

A new analyzer arrives, the field engineer installs it, and the instrument runs samples perfectly. Then someone asks the obvious question: how do the results get into the LIS? If the answer is "a technologist will type them in", you have just created a permanent manual process on day one.

This guide walks through how to connect a new analyzer to your LIS in the order the work actually happens: what to collect from the vendor, which physical connection to use, how to identify the protocol dialect, how to map fields, how to validate, and what to check before go-live. It is written for hospital IT administrators and lab managers who own the project but do not want it to turn into a six-month custom integration.

Before You Start: What to Collect From the Vendor

Most interface delays are not technical. They are waiting for a document or a setting that nobody asked for early enough. Before anyone touches a cable, collect the following.

• The interface or host communication manual. This is separate from the user manual. It describes the message formats the analyzer sends and receives. Ask for the version that matches the installed firmware.
• Supported connection types. RS-232 serial, TCP/IP, or file transport. Some analyzers offer more than one, and the choice matters later.
• The protocol family. HL7 v2.x, ASTM E1394, or a vendor-specific format. If the manual says "proprietary", you still need the record layout.
• Whether the analyzer supports host query. Bidirectional analyzers can ask the LIS what tests to run for a barcode. Result-only analyzers cannot.
• The parameter list. Every test code, unit and flag the analyzer can report, including calibration and QC identifiers.
• Sample messages. A captured example of a real result transmission is worth more than ten pages of specification.
• Analyzer-side settings. Transmission mode, baud rate, parity, port numbers, and any option that must be switched on before the instrument will talk at all.

If you can only get one thing quickly, get the sample messages. They answer the dialect question faster than any document.

Step 1: Choose the Physical Layer

The physical layer is how bytes travel between the analyzer and the machine running your interface software. In practice there are three options.

RS-232 serial

Common on older analyzers and still present on current ones. It is a point-to-point link: one analyzer, one serial port, one cable. The settings (baud rate, data bits, parity, stop bits) must match on both ends exactly, and the cable pin-out must be right, which is where many first attempts fail. A null-modem cable where a straight-through is needed, or the reverse, produces silence rather than an error. USB-to-serial adapters add another variable, so test them before you rely on them.

TCP/IP

Preferred where available. You assign the analyzer an IP address, decide which side listens and which side connects, and agree on a port. Network connections are easier to extend across a building and easier to monitor. Decide early whether the analyzer acts as client or server, because the firewall and addressing plan depends on it.

File transport

Some analyzers exchange messages as files on an FTP, FTPS or SFTP server rather than over a live socket. The workflow is different: results appear as files to be picked up, and orders are dropped as files for the analyzer to read. It works well, but it needs a file server and credentials in the plan.

For a deeper comparison of the first two, see RS-232 vs TCP/IP for lab instruments, and for the connection side of the product see RS-232 and TCP/IP connectivity.

Step 2: Identify the Protocol Dialect

"It uses HL7" or "it uses ASTM" is only the beginning. Both are families of conventions, and analyzers implement them with local variations: different field positions, different handshake behaviour, different ways to flag a rerun or a QC result.

Look at a captured transmission and answer these questions:

1. Is the message framed with control characters (for example start and end of text markers, or an enquiry and acknowledge handshake), and does the receiver have to acknowledge each frame?
2. Are records pipe-delimited (HL7 or ASTM style), fixed-width, or XML?
3. Where does the sample identifier sit, and is it the barcode or an internal sequence number?
4. How are units, abnormal flags and result status represented?
5. How does the instrument mark calibration, QC and patient samples?

Real lab floors are not standards-compliant. A fixed-width record with no delimiters, vendor framing around it, or XML dropped on a file server are all ordinary. If your interface engine only understands textbook HL7, those analyzers become custom projects. For background on the two main families, read HL7 vs ASTM E1394 and how LISBridge handles HL7 and ASTM.

Step 3: Connect and Capture Raw Traffic First

Before mapping anything, prove that data arrives. Connect the analyzer, run a single known sample, and capture the raw transmission. Do not try to interpret it yet. You are answering one question: does the link work end to end?

If nothing arrives, work through the layers in order. For serial: cable type, port selection, then communication settings. For TCP/IP: can you reach the address, is the port open, who is listening and who is connecting. Then check the analyzer's own transmission setting, because many instruments have a mode where they simply do not send automatically.

Keeping the raw data matters beyond troubleshooting. Storing the raw instrument message next to every parsed result gives you traceability: if a value is ever questioned, you can show exactly what the analyzer sent. LISBridge stores the raw protocol data alongside each parsed result for this reason.

Step 4: Map Fields

Field mapping translates what the analyzer calls a parameter into what your LIS expects. Typical mapping tasks include:

• Test codes. The analyzer's code for haemoglobin versus your LIS's test code.
• Units. Make sure g/dL and g/L are not confused, and that the LIS expects the unit the analyzer sends or converts consistently.
• Sample identifiers. Barcode, accession number and any analyzer-side sequence number.
• Flags and comments. Abnormal flags, instrument alarms and rerun markers.
• Result types. Numeric, text, and histogram or graph data if you want it.

The traditional approach is to ask a vendor or programmer to hard-code this. The better approach is to configure it yourself. In LISBridge you map any analyzer parameter to any LIS field without custom programming and without raising a vendor ticket, which changes mapping from a project into an afternoon task.

Step 5: Handle Orders if the Analyzer Is Bidirectional

If the analyzer supports host query, the instrument scans a barcode and asks the LIS which tests to run. The interface has to answer that query, usually within a short window. A good implementation also answers cleanly when no order is found, so the analyzer does not hang waiting. Seventeen of the 37 instruments LISBridge supports are bidirectional. You can read more in bidirectional lab orders explained and analyzer host query and worklists.

If your HIS or LIS sits behind a firewall, check how orders will be fetched. LISBridge pulls test orders from any HIS or HMS by outbound polling, so you do not need to open inbound firewall ports.

Step 6: Run Validation Samples

Do not go live on the first successful message. Build a short validation plan.

1. Normal and abnormal patient samples. Confirm values, units and flags match the analyzer display.
2. Edge values. Very high, very low, and results the analyzer flags as invalid.
3. Calibration and QC runs. They must not land in a patient record. Confirm they are separated from the patient pipeline.
4. Reruns and repeats. Check how a repeated result is represented and which one the LIS keeps.
5. Multiple samples in quick succession. Check ordering and duplicates.
6. A deliberate fault. Unplug the cable or stop the interface and confirm the system recovers and nothing is lost.

That last test is more valuable than it sounds. Links drop. LISBridge reconnects automatically with exponential backoff and jitter, and stores results in crash-safe local storage so a power cut or restart does not lose them. Whatever tool you use, prove that behaviour before you depend on it.

Step 7: Go-Live Checklist

• Interface host is on a UPS or otherwise protected from power loss.
• Analyzer IP address, or serial port assignment, is documented and will not change on reboot.
• Field mapping is saved and backed up.
• Technologists know what changed: results now arrive automatically, and manual entry stops.
• A named person knows where to look when results do not appear.
• Monitoring shows connection state for the analyzer.
• A rollback plan exists: how to revert to manual entry for a shift if needed.

Common Failure Modes

• Analyzer is set not to transmit. The link is fine; the instrument's output option is off.
• Wrong cable or port settings. Silence, not an error message.
• Sample ID mismatch. Results arrive but cannot be matched because the analyzer sends a sequence number instead of the barcode.
• Units differ between analyzer and LIS. Values look plausible but are wrong by a factor.
• QC treated as patient data. Calibration results appear against patients.
• Handshake timeouts. The interface acknowledges too slowly, so the analyzer retransmits and duplicates appear.
• Firmware updated. A software update on the analyzer changes message layout and breaks a working interface.

That last one is why parser updates matter. LISBridge's parsers are delivered as a WASM module that updates silently in the background with no restart and no downtime. See WASM parsers in lab middleware for how it works. For the practical setup walkthrough in the product, see getting started and device connectivity.

Frequently Asked Questions

How long does it take to connect a new analyzer to a LIS?

The physical connection takes minutes to hours. The elapsed time is dominated by waiting for vendor documentation, analyzer-side settings and validation samples. With a supported instrument and a configurable mapping, a lab can move from connection to validated results quickly; a custom interface written from scratch typically takes far longer.

Do I need the analyzer vendor involved?

Usually for documentation and for enabling the host communication option. You should not need them for the integration itself if your middleware already supports the instrument.

Should I use RS-232 or TCP/IP?

Use TCP/IP when the analyzer offers it. Use RS-232 when it is the only option or the existing infrastructure demands it. Both work reliably when configured correctly.

What if my analyzer does not use HL7 or ASTM?

Many do not. Fixed-width records, vendor framing and XML over a file server are all in use. Check that your middleware lists the specific instrument, not just the standards.

How do I stop QC results reaching patient records?

Choose an interface that recognises calibration and QC identifiers and routes them away from the patient pipeline, then test it with a QC run during validation.

Connect the Next Analyzer Without a Custom Project

LISBridge supports 37 lab instruments out of the box across RS-232, TCP/IP and file transport, with configurable field mapping and automatic reconnection. A hospital with five analyzers eliminated around two hours a day of transcription.

Start your free trial — no credit card required. lisbridge.com/pricing