Laboratory Analyser Integration: How Results Get From the Instrument to the Report
Retyping analyser printouts is slow and it's where transcription errors creep in. Connecting analysers fixes that, but only if the interface, mapping and validation are done properly. This guide explains how the connection works, what to check, and exactly how eMedHub fits in.
Updated 30 October 2026
The Path From Instrument to Report
Most analyser integrations have the same layers. Knowing which layer does what makes it clear who is responsible when something goes wrong.
- Layer 1
Analyser
Runs the sample, identified by the barcode on the tube, and produces results for each parameter.
- Layer 2
Instrument interface
The analyser outputs results over a serial or network connection, usually in an ASTM- or HL7-style message format.
- Layer 3
Interface middleware
Reads the instrument's messages, extracts sample ID, parameter codes and values, and forwards them.
- Layer 4
eMedHub result API
Receives the sample ID, analyser ID, analyser test code and value, then maps the code to the ordered test.
- Layer 5
Result in the report
The value is saved against the test, flagged as machine-entered, and checked against reference ranges before review and release.
In eMedHub, layers 4 and 5 are part of the product. Layers 2 and 3 are provided by the analyser and the interface middleware.
Unidirectional vs Bidirectional Interfaces
| Aspect | Unidirectional | Bidirectional |
|---|---|---|
| What flows | Results from the analyser to the LIS | Orders from the LIS to the analyser, and results back |
| How the analyser knows what to run | Tests are selected at the analyser by staff | The analyser asks the LIS for the sample's tests (host query) or receives a worklist |
| Main benefit | No retyping of results | No retyping of results or test selection at the instrument |
| Main dependency | Result message format and test-code mapping | Both of those, plus order messages and host-query support on the analyser and middleware |
Where eMedHub fits:eMedHub's result API receives results. It does not send orders to analysers or answer host queries. If an analyser needs order download, the middleware must handle it.
Mapping Codes and Rejecting What Doesn't Fit
Each analyser names its parameters with its own codes. eMedHub keeps a mapping from each analyser test code to your test. When a message doesn't match, eMedHub rejects it instead of guessing:
Unknown facility key
Unmapped analyser code
Test not ordered for the sample
Accepted values are saved against the test and marked as machine-entered. Any later edit appears in the result change log.
Validating an Analyser Connection Before Go-Live
- Step 1
Map every parameter
List each analyser parameter code and the eMedHub test it should fill, including units.
- Step 2
Check barcode compatibility
Confirm the analyser's scanner reads your printed sample ID labels.
- Step 3
Run in parallel
For an agreed period, compare machine-posted values with manual entry for the same samples.
- Step 4
Test the failure paths
Deliberately send an unmapped code and an un-ordered test to confirm they're rejected and logged.
- Step 5
Sign off and monitor
Your pathologist signs off the mapping. After go-live, review the result change log for corrections.
Limitations to Know Up Front
- eMedHub does not drive instruments directly. A middleware layer that understands your analyser's interface is required.
- eMedHub does not push orders to analysers or answer host queries. Where an analyser needs this, it must be handled by the middleware. Ask us about your setup.
- Which analyser models can be connected depends on the middleware, not on eMedHub. We don't publish a model list we can't stand behind; we confirm your instruments during the assessment.
- Analyser test-code mapping is set up by our implementation team, not from a lab-user screen.
Barcodes matter as much as the interface. See how SID barcoding prevents sample mix-ups.
Analyser Integration: Common Questions
What is laboratory analyser integration?
It is the connection that sends results from a lab analyser to the laboratory information system automatically, so staff don't retype values from printouts. It usually involves the analyser's interface, middleware that reads it, and the LIS that stores the results.
What is the difference between unidirectional and bidirectional interfaces?
A unidirectional interface sends results from the analyser to the LIS only. A bidirectional interface also sends orders from the LIS to the analyser, either as a worklist or in reply to the analyser's host query, so staff don't select tests at the instrument.
What are ASTM and HL7 in lab integration?
They are message standards. Many analysers output results in an ASTM-style format (the lab-instrument standards now maintained as CLSI LIS1/LIS2), while HL7 v2 is widely used between hospital systems and some instruments. Middleware translates whichever format the analyser uses.
How does eMedHub receive analyser results?
Through a result API. Interface middleware sends the sample ID, analyser ID, analyser test code and result. eMedHub maps the code to the ordered test, saves the value and marks it as machine-entered. Messages with an unknown facility, an unmapped code or a test not ordered on that sample are rejected.
Does eMedHub support bidirectional analyser integration?
eMedHub's result API receives results; it does not send orders to analysers or answer host queries. If your analysers need order download, the middleware has to handle it. We'll review this for your instruments.
Which analysers can eMedHub connect to?
That depends on the interface middleware used, not on eMedHub alone. We don't publish a list of analyser models; share your instrument list and we'll confirm what's possible.
Do machine results still need review?
Yes. Machine-entered values are checked against reference ranges and flagged like any other result. Where your lab has approval switched on, they still need approval before release.