The short answer
Analyzer interfacing connects a lab machine to the LIS so test orders go out and results come back without retyping. ASTM-style messages over serial or network links and HL7 messages are the two protocols most commonly used. Whether a given machine works depends on its output interface, so each device must be assessed, mapped and tested before go-live.
Key takeaways
- Interfacing removes manual transcription, but only after careful test-code mapping, sample ID discipline and staged testing.
- ASTM and HL7 are message formats. The physical link (serial RS-232 or TCP/IP) and the analyzer's own settings are separate decisions.
- One-way interfaces send results to the LIS. Bidirectional interfaces also send worklists from the LIS to the analyzer.
- Assess device by device. No honest vendor can promise a specific model works without checking its interface documentation.
- Keep a manual fallback. Labs must be able to run tests and report if an interface fails.
How does LIS analyzer interfacing work?
Analyzer interfacing is the automated exchange of data between a laboratory analyzer and the laboratory information system. In a bidirectional setup, the LIS sends the analyzer the sample ID and the tests ordered for it. The analyzer runs those tests and sends the results back to the LIS, where a technician reviews and validates them. In a one-way setup, the analyzer only sends results.
The benefit is simple: nobody types the numbers. Fewer manual keystrokes means fewer transcription errors and faster reports. The effort is less simple. It involves choosing a protocol, deciding on the link, mapping test codes, controlling sample IDs and testing on real samples.
This post explains those pieces in plain English. It sits within our wider laboratory information system guide, and it describes what is commonly done rather than promising any specific machine will work.
What are ASTM and HL7?
ASTM
ASTM-style protocols are among the most widely used for connecting analyzers to a LIS. The original specifications from ASTM International (E1381 for the transmission layer and E1394 for the record format) were later adopted by CLSI as LIS01 and LIS02. Messages are made of records, such as patient, order and result records, with fields separated by delimiters.
ASTM links are very commonly carried over a serial connection, and many analyzers also support the same messages over TCP/IP.
HL7
HL7 Version 2 is a messaging standard that is widely used in healthcare to move data between systems. Messages are text lines made of segments and fields, separated by pipe characters. For lab work, you typically meet:
- Order messages (often ORM or OML types) that carry the request.
- Result messages (often ORU) that carry the result.
- Acknowledgements (ACK) confirming receipt.
HL7 messages are commonly sent over TCP/IP using a simple framing method called MLLP. Some analyzers speak HL7 natively, while others speak ASTM or a proprietary format and need a translator in between.
FHIR
You may also hear about FHIR, a newer standard that uses web APIs. It is increasingly used for health-record exchange, including in India's digital health programme, but most analyzer connections today still use ASTM or HL7 v2. See the glossary for a short definition.
How is the analyzer physically connected?
The protocol is the language. The link is the road.
| Link | How it works | Typical notes |
|---|---|---|
| Serial (RS-232) | A cable between the analyzer port and a computer or serial-to-network converter | Common on older analyzers, short distances, needs matching baud rate and settings |
| TCP/IP (Ethernet) | The analyzer connects over the network to the LIS server or a middleware | Needs IP planning, ports and firewall rules, more flexible |
| USB or file export | Some devices export result files that are picked up by software | Less real-time, may require file-watching logic |
| Middleware | A layer between analyzer and LIS handles translation and rules | Useful with many device types or complex rules |
The device's manual or interface specification tells you what it supports. The exact settings, such as baud rate, parity, host IP and port, must match on both sides.
What actually travels between the LIS and the analyzer?
Order download (LIS to analyzer)
When a sample is received in the lab and its barcode is scanned, the LIS knows which tests are required. In a host query setup, the analyzer reads the sample barcode, asks the LIS "what tests are ordered for this ID?" and receives the answer. In a worklist download setup, the LIS pushes the list to the analyzer ahead of time.
Result upload (analyzer to LIS)
After running, the analyzer sends a message with the sample ID, the test code, the value, units, flags and a timestamp. The LIS matches the sample ID to the patient and order, applies reference ranges and flags, and places the result in a pending-validation state.
Quality control and calibration data
Some labs also interface QC results, though this is a separate design decision. Many labs prefer to keep QC in a dedicated process and review.
How does test-code mapping work?
Every analyzer uses its own test codes or channel numbers. The LIS uses its own test master. Mapping tells the system that analyzer code "GLU" corresponds to the LIS test "Glucose (Fasting)", and that units and decimals should be treated in a certain way.
This is the most time-consuming and error-prone part of interfacing. Do it as a table, check it with the lab in-charge, and keep it under change control.
Typical mapping decisions:
- Which analyzer code maps to which LIS test, and in which sample type.
- Unit conversion, where analyzer and LIS units differ.
- Rounding and decimal places.
- How to handle dilution or repeat results.
- How to treat flags such as "high", "low" or "instrument error".
- How multi-parameter tests (such as a full blood count) are split.
Why do sample IDs matter so much?
Interfacing works on sample IDs. If the barcode on the tube is not the barcode the LIS expects, the analyzer's results cannot be matched, or worse, may be matched to the wrong patient. Controlled labelling is therefore a precondition, not an extra. Read our article on barcode sample tracking in labs for the labelling and scanning practices that make interfaces reliable.
Check these:
- One unique ID per sample, generated by the LIS.
- Labels that print legibly and stay on the tube.
- Barcode symbology that the analyzer's reader can read.
- A rule for add-on tests and repeat runs.
What does an interfacing project look like?
Treat it as a small project with stages, not an installation visit.
- Device discovery. List analyzers, models, current connection ports and whether interface documentation exists. This is where an honest vendor will say what is and is not possible.
- Interface specification. Obtain the analyzer's host interface document and agree protocol, link and data fields.
- Mapping. Build the test-code, unit and flag table with the lab.
- Configuration. Set communication parameters on both sides. Configure host query or worklist as applicable.
- Staging test. Run test and known samples in a non-live environment. Compare automated values against manual or printed values.
- Go-live. Switch on for a limited set of tests or shifts. Keep manual entry as a fallback.
- Monitor. Review unmatched results, error messages and technician feedback in the first weeks.
- Support. Define who handles an analyzer service visit, firmware change or LIS update.
Our lab analyzers integration page describes how DevOrbital HMS scopes and enables each device on its own.
What can go wrong?
| Problem | Typical cause | What to check |
|---|---|---|
| No communication | Cable, port, baud rate or IP mismatch | Link settings, converters, firewall |
| Results not appearing | Sample ID mismatch or unmapped test code | Barcode content, mapping table |
| Wrong units or decimals | Mapping or unit conversion error | Mapping table, test master |
| Duplicate results | Repeat runs or reconnection resends | Rules for repeats, message IDs |
| Missed orders | Host query not answered or timing issue | Query settings, response time |
| Garbled data | Serial settings or character encoding | Parity, stop bits, encoding |
| Silent failure | No monitoring | Queue alerts, daily reconciliation |
Reconcile daily in the first weeks: tests run on the analyzer against results received by the LIS.
Do you need an interface engine?
For one or two analyzers, a direct connection between the device and the LIS is often enough. For many devices from different manufacturers, a middleware or interface engine can normalise protocols, route messages, apply auto-validation rules and give one place to monitor traffic. The trade-off is another component to maintain. Choose based on device count and volume, not on trend.
Should you auto-validate results?
Once interfaces are stable, some labs apply auto-validation rules, where results inside defined limits and with no flags are released without manual review. This can speed up turnaround, but it is a clinical governance decision for the lab's medical head, with rules documented and reviewed. An LIS should log which results were auto-validated and by which rule. See reduce lab turnaround time for where this fits among other levers.
What should you ask a vendor before you start?
- Which of our analyzers have you assessed, and what interface did they expose?
- Who obtains the device interface documentation, and from whom?
- Is the interface one-way or bidirectional for each device?
- How is each device scoped, tested and enabled? Is there a staging step?
- What happens if an analyzer is replaced or upgraded?
- How are failed or unmatched messages shown to the technician?
- Can the lab keep running on manual entry if the interface fails?
- Is there an audit trail of automatically received results and edits?
A good answer will often start with "it depends on the device". That is the correct answer.
Next steps
For the hospital side of the flow, explore the laboratory information system module, which supports manual entry, typed reports and templates alongside optional device interfacing, and the hospital management system that carries orders and results across departments.