LIMS with process automation for Laboratorios Microal

The client

Laboratorios Microal is an accredited testing laboratory in Seville. Its analysts process food, water and environmental samples against a catalog of 601 analytical methods covering 3,524 parameters, with 1,511 instruments, for 1,134 clients.

The laboratory already had a commercial LIMS. What it did not have was anything that managed the work: which samples were pending, who was doing them, which containers had been prepared, which digester position each sample occupied, which quality controls the method required and whether they had passed. That layer lived on paper worksheets, on spreadsheets and in the memory of the people running each line.

Sistema MICROAL closes that gap. It ingests every sample from the LIMS automatically, turns the pending analyses into assignable work, guides the technician through preparation and reading, enforces the quality-control regime the method requires, applies the calculations and pushes validated results back to the LIMS without anybody re-typing a number.

A synchronization you can trust

Two engineering decisions are the difference between a reliable synchronization and one that is not.

The first: the import never deletes pending work. An earlier approach inferred that "if the sample is not in the LIMS pending list, the LIMS has closed it". The team measured that inference and found it false, because the endpoint returns what was received that day rather than what is pending. Work is now marked as resolved, never removed.

The second: the ingestion is idempotent and runs under a lock, so the nightly job and a manual "synchronize now" cannot collide or double-import.

A single definition of "pending"

What makes the assignment screen correct rather than merely convenient is a single shared definition of what "still to do" means. A reading line is live only when all three of these hold:

1. The LIMS holds no result for it yet (an empty placeholder row is not a result).
2. It has not been internally blocked.
3. The inbound synchronization has not marked it complete.

That definition lives in exactly one place in the code and is shared by the assignment screen, the preparation grid and the "mother method" move. It had previously been written twice and the two copies had drifted — which is how three screens come to disagree about the same sample.

The assignment also refuses to create work that cannot physically be done: the capacity check knows how many positions each digester has and will not let a supervisor build a worksheet that will not fit on the bench.

The primary record, the regulated document

A primary record is the controlled document for one batch of work. Opening one shows how much metrological rigor the system carries: the analyst and the date; the instrument, chosen from the catalog with its serial number and position count; a sample count that explicitly includes the quality controls, because a control occupies a physical position exactly like a sample does; a supervisor observations field whose placeholder says what it is for ("justify in writing, e.g. accepting a record with a missing or failed QC"); and the digestion temperature control.

That last one deserves attention. The conformity limits are not a fixed band: they are computed as 120 °C ± 2 with a +0.1903 correction taken from the calibration certificate of the specific thermometer used on the specific digester, giving 118.1903 – 122.1903 °C. The record cannot be closed without the temperature, and the screen says so.

A record cannot quietly close with bad controls

The primary record's state is driven by an evaluator that reduces its linked controls to one of three signals: all passed, at least one definitively failed, or incomplete. A definitive failure outweighs incomplete siblings — the conservative choice. Records closed automatically with controls that do not meet the ratios the method requires generate a persisted QC alert that surfaces on the validation screen.

And where a supervisor decides to accept a record anyway, the system does not block them: it requires them to write down why, which is precisely what an auditor will ask for.

Traceability as a by-product

Every primary record carries the instruments used by serial number, the position each sample occupied, the weighings, the analyst, the timestamps, and who closed it and when. None of that is an extra form to fill in — it is the record the technician was already working through.

How we work on the code

Three practices are visible throughout the repository:

• The documentation is in the code, and it records why. Modules open with an explanation of the decision they encode and, frequently, of the measurement that settled it — including the cases where an earlier assumption was tested and found false. That is what lets a rule survive the person who wrote it.
• Every API route requires an authenticated session. The routers are mounted behind a single session dependency, with four deliberate public endpoints (login, logout, root and health check). A test walks the live route table and fails if any route is reachable without a session, and a second test asserts the walk itself still sees the four public routes — so the check cannot silently stop checking.
• Changes are reviewed against a running copy of production. Every pull request is mounted together with the others on an integration environment, its migrations are rehearsed against a fresh copy of the production database and verified by value —rows touched, rows left pending, rows outside scope— before anything reaches the laboratory.

Where the project stands

The platform is in production and in daily use for sample ingestion, the method and equipment catalogs, preparation and work assignment. The execution and quality-control modules are deployed and are being adopted line by line as the laboratory takes each one off paper.

Development continues on a weekly cadence, with changes reaching production through a reviewed pull-request pipeline and a rehearsed migration path.