How a LIMS works: one sample from request to signed test report
A customer calls: the oil sample from their compressor was tested two weeks ago, the report says the viscosity is out of spec, and they want to know which instrument measured it and whether it was in calibration that day. In a lab that runs on spreadsheets, answering takes an afternoon of digging through folders. In a lab with a LIMS, it takes one click on the sample card. That is, in short, how a LIMS works: every result stays linked to the sample, method, analyst and instrument behind it.
A laboratory information management system (LIMS) is the software that tracks every sample from the moment a customer asks for a test to the signed test report — and keeps a record of who did what, when, and with which equipment. Below is how that works in practice, using the LIMS we build at WAPP as the example.
What a LIMS does in a testing lab
A LIMS replaces the sample log, the instrument calibration spreadsheet, the folder of method documents and the report template in Word with one system where these records are linked. The links are the point: a result is tied to a sample, the sample to a method, the measurement to an instrument, and the instrument to its calibration record.
For a lab working under ISO/IEC 17025, these links are what an assessor checks. They want to see that a result can be traced back to a qualified analyst, a valid method and a calibrated instrument.
A sample's path through the LIMS
A sample goes through seven stages on its way from the customer's request to a signed test report. At each one, the LIMS adds its own record to the sample card.
The customer request opens the job
Work starts with a request from a customer: what needs testing, which parameters, how urgent. The LIMS keeps a customer directory, so the contact person, contract details and history of previous tests are already there. The request becomes the starting point for one or several samples.
Registration gives the sample an ID, a QR code and the data the report needs
The receptionist or analyst registers the sample when it arrives. The LIMS assigns a unique ID and generates a QR code for the label, so the bottle or container can be scanned at any later step instead of reading a handwritten number.
At registration the system records what the report will need later:
- the customer and the request;
- sampling date and sampling report number;
- test type: product quality control, testing under a program, or certification testing;
- sample details — for oil analysis, for example, the lubricant grade, equipment operating hours and top-up volume;
- planned test date and an urgency flag;
- storage conditions such as temperature and humidity.
The sample status becomes "registered". From now on, every change to the card is written to the audit trail.
The method sets which parameters are measured
The method defines how the test is done and which parameters are measured. The LIMS keeps a method catalog with versions, so everyone works from the current revision, and the sample card shows which version was used. Each method lists its parameters (indicators) with units and the equipment it requires.
This removes a common source of errors: an analyst using an outdated method sheet printed months ago.
Instrument calibration is checked before the measurement
When the analyst starts work, the sample moves to "in progress". The analyst selects the instruments used for the measurement, and the LIMS shows each one's calibration status: valid, expiring soon, or expired.
Calibration intervals and due dates live in the equipment register, with a calendar that shows what is due this month. The lab manager sees expiring calibrations before they become a finding, not after.
The equipment register also separates two kinds of records that spreadsheets often mix up:
- measuring instruments — what the lab measured with; these go into the report with their calibration details;
- sampled objects — the engine, gearbox or tank the sample was taken from; these go into the sample description.
The test report is assembled from records the system already holds
Results are entered against the method's parameters, with units already set. The LIMS assembles the test report from the records it already holds: customer, sample description, method, conditions, results, and the measuring instruments with their calibration data. That last block is what ISO/IEC 17025 clause 7.8.2 asks a test report to contain about the equipment used.
Report templates are configured once per report type, so analysts do not reformat a Word file for every sample. How to make sure a report has everything it needs is covered in our article on the contents of a test report.
The analyst and the reviewer sign, each in their role
Before a report goes to the customer, the people responsible sign it: the analyst who performed the test and the person who reviews and approves it. The LIMS records who signed, in which role and when. Roles define who can register samples, enter results, approve reports or change reference data, so each action is done by someone allowed to do it.
After approval the sample is "completed". If a sample cannot be tested — wrong container, insufficient volume, damaged seal — it is marked "rejected", and that decision is recorded in the audit trail too.
The audit trail answers "who changed this?"
Every change in the system — a corrected result, a new calibration date, a reassigned analyst — is written to the audit trail with the user, time and previous value. The traceability view shows the full history of a sample on one screen.
This is what answers the customer call from the beginning of this article: open the sample, see the instrument, open the instrument, see its calibration on the test date.
Spreadsheets vs a LIMS: what changes day to day
| Task | Spreadsheets and paper | LIMS |
|---|---|---|
| Find a sample | Search the log by date or customer | Scan the QR code or search by ID |
| Check an instrument's calibration | Open a separate file, hope it is current | Status shown when the instrument is selected |
| Prepare a test report | Copy data into a Word template | Report assembled from existing records |
| Answer "who changed this result?" | Usually impossible | Audit trail with user, time and old value |
| Prepare for an assessment | Collect records from several folders | Records are already linked to each sample |
What to check when choosing a LIMS
A LIMS only pays off if analysts actually use it. Before choosing a system, check four things:
- Does registering a sample take less time than writing it in the log? If not, staff will keep the log.
- Can it hold the fields your samples actually need — for oil analysis, environmental testing or food testing they differ a lot.
- Does the test report come out in the format your customers and assessors expect, without manual edits?
- Who can change the configuration — methods, templates, roles — without calling the vendor?
Why analysts quietly go back to spreadsheets, and how to avoid it, is covered in Why lab staff bypass LIMS.
How WAPP builds LIMS for testing labs
WAPP builds LIMS around the lab's real workflow: the sample card holds the fields your samples need, report templates match your current documents, and the system runs on your own server if data cannot leave the company. For small labs of up to about 10 people there is a free base version — details are on the LIMS page. An example of a larger project is the SPEKTROKHIM case: a platform for interlaboratory proficiency testing.
Frequently asked questions about how a LIMS works
Key takeaways
A LIMS follows each sample from request to signed report and links every result to a method, an analyst and a calibrated instrument. The value is not in replacing paper as such, but in answering "where did this number come from?" in seconds. When choosing a system, start with how long it takes to register a sample and whether the report comes out the way your customers expect.