A liquid handler is very good at moving liquid and completely indifferent to what the liquid is. It will aspirate from A1 and dispense to B2 whether that is a patient sample or a blank. The knowledge of what each well contains, which sample, which patient, which study, lives somewhere else, usually a LIMS or an electronic lab notebook. Connecting the two is what turns a deck of anonymous wells into a run you can trace, and it is a recurring source of integration headaches, judging by how often it comes up on automation forums.
Two systems that were not built to talk
The instrument speaks in deck coordinates and worklists: pick up here, dispense there, this volume, this class. The LIMS speaks in samples and results: this specimen, this test, this outcome. Neither natively knows about the other. The integration job is to translate between them, so the LIMS can tell the instrument what to do with which sample and the instrument can tell the LIMS what it did. Done well, a technician scans a rack and the right method runs against the right samples with no manual transcription, which is where transcription errors used to live.
How the connection is usually made
There are a few common shapes, in rough order of robustness.
- File exchange: the LIMS writes a worklist file the instrument software reads, and the instrument writes results back to a file the LIMS ingests. Simple, common, and brittle if a format drifts.
- Middleware or a scheduler: a layer that sits between many instruments and the LIMS, translating formats and managing state, which scales better than point-to-point files.
- Direct API or driver integration: the instrument software exposes an interface the LIMS calls, or the reverse, through a documented protocol. More work to set up, more reliable once it runs.
- Scripted protocols that query directly: a protocol written in code can read a worklist or call an endpoint at run time, which is powerful but ties the integration into the method itself.
What flows each way
Downstream, the LIMS sends identity and instructions: sample barcodes and their positions, the method to run, volumes, and often the target layout. Upstream, the instrument returns what happened: which sample went where, the volumes actually transferred, any errors or flagged transfers, and the method and version used. The upstream direction is the one people skimp on and regret, because a result with no record of how it was produced is hard to defend later.
Where the liquid class fits
In all of this the liquid class is a referenced input, the same way it is in any protocol. The worklist says use this class for this transfer, and the class carries the parameters. What integration adds is that the class becomes part of the run record: to reproduce or audit a result you need not only which samples and which method, but which version of which class actually moved the liquid. A LIMS that logs the sample and the steps but not the class it ran has recorded half the method.
A liquid handler knows where; a LIMS knows what. Connect them and a run stops being a plate of anonymous wells, as long as the class that moved each sample is in the record too.