Walk into any modern testing laboratory and count the systems. There's a LIMS at the center, in theory. Around it, each analytical instrument ships with its own vendor software, each with its own export format and its own idea of what a result looks like. Then a scheduling tool, a reporting layer, a client portal, and, holding it all together, more spreadsheets than anyone wants to admit.
The lab's scientific work is usually excellent. The software between the instruments and the certificate is where the time goes.
The expensive problems in lab software are rarely inside any single system. They live in the gaps between systems.
A technician reads a value from an instrument screen and types it into the LIMS. That's transcription: slow, and the single most common source of data errors in a lab.
A sample gets logged in two systems under two identifiers, and three weeks later someone spends an afternoon reconciling which result belongs to which client.
A result sits finished in the instrument software for two days because the batch upload runs when someone remembers to run it. The client is waiting; the science was done on Tuesday.
And when the auditor asks who changed this value and when, the answer involves opening four systems and one binder.
1. The LIMS is the system of record, and everything else knows it. One sample identifier travels from receipt to certificate. If a piece of data matters, it lives in the LIMS or is traceable from it; the instrument software is a source, never an archive.
2. Instruments talk to the LIMS without a human retyping. Every instrument export, whether it's a clean API, a CSV drop folder, or a twenty-year-old serial protocol, gets a parser and an interface that validates the data and posts it automatically. Bidirectional where it pays: worklists go down to the instrument, results come back up.
3. The workflows between systems are software, not habit. QC checks, review-and-approval chains, out-of-spec flags, certificate generation, client notifications. Each of these is a place where an integration either enforces the lab's method or quietly lets it drift.
4. The audit trail is a by-product, not a project. When data moves through interfaces instead of keyboards, who-did-what-when comes free. For laboratories operating under accreditation frameworks like ISO/IEC 17025, that's the difference between preparing for an audit and just opening the system.
Lab software is domain software. An engineer who doesn't know why a chromatography run produces the file it produces, or what an out-of-spec result triggers in an environmental method, will build interfaces that are technically correct and operationally wrong.
That knowledge isn't learned in a six-week project. It's learned by dedicated teams that stay: engineers who sit with the lab, absorb the vocabulary of practices like environmental, chromatography and foods testing, and are still there when the next instrument arrives. That's how we structure this work at Aztia, with multidisciplinary teams that grow with the practice instead of rotating through it.
Laboratories are document-heavy: SOPs, methods, regulations, historical results. That's fertile ground for retrieval-based assistants that answer from the lab's own documentation with citations, and for workflow automation on the repetitive middle of the process. It is not fertile ground for letting a model touch results. The same rule we apply everywhere applies doubly here: AI drafts and retrieves; accountable humans approve.
If your lab's throughput problem lives between systems, the fix is unglamorous and very effective: make the LIMS the single system of record, interface every instrument so nobody retypes a number, turn the human workflows between systems into software, and let the audit trail fall out of the architecture. Then staff it with a team that learns your science, because in laboratory software, the domain is half the code.
About Aztia. We're a software development firm. We build Hura, our technical assessment platform (huraapp.com), holding ourselves to the same process we describe in this series. More at aztia.co.
Thirty minutes, no pitch. Tell us what your systems need to say to each other.
Talk to us →