LabLynx, Inc.

10/21/2026

Under the TNI standard, a legal chain of custody procedure is conditional. It is required if your customer requires one and you accepted the samples on that basis. It is an obligation attached to a category of work, not a rule attached to every bottle.

That surprises people, because the signed form is what most environmental analysts were trained on. And the training is not foolish. One form, one signature per transfer, no gaps is a clean rule that audits quickly and survives staff turnover. For work that may end up in front of a judge it is also exactly correct, and nothing here changes that.

But it describes a client requirement and a litigation practice, and a lot of writing about environmental labs presents it as the accreditation standard. Those are different obligations with different triggers, and a lab that has satisfied the first can still fail the second.

What applies to every sample sits in the receipt clauses: acceptance criteria for the condition it arrived in, indelible identification, a preservation check, a holding time check against collection time, a quantity check, and one unambiguous lab identifier linking collection and receipt times, client and project, field identifier, analyses requested, and the person who received it.

Read those two side by side and the emphasis moves. The standard is not asking who signed. It is asking whether the record can be rebuilt.

New article covers what the form is actually for, what the standard requires of every sample, why assessors test reconstruction rather than signatures, and what software can honestly claim to do about any of it.

https://www.lablynx.com/resources/articles/environmental-lab-chain-of-custody-management/



https://www.lablynx.com/resources/articles/environmental-lab-chain-of-custody-management/

10/20/2026

Here is a finding pattern that says something uncomfortable about how labs get assessed.

In a review by The NELAC Institute, assessors from three state programs put control of records among the most common on-site findings. Then they made a point that is easy to skip past: most of those findings did not affect the data that was generated. The results were fine. The lab simply could not produce objective evidence that the activity had occurred.

The examples are ordinary bench work rather than paperwork theater. The original incubator temperature and the corrected value after thermometer correction both have to be recorded, because a derived number without its source cannot be checked. Standard and reagent origin, receipt and preparation have to sit with the run that used them. The equipment used has to be identified against the analysis, or the run can only be believed rather than rebuilt.

The same pattern shows up on the custody record. The fields that fail assessment are rarely the signatures. They are collection time, because everything downstream is measured from it, and receipt condition, because it is the acceptance decision the standard requires and the one most often recorded as a tick rather than a temperature.

Our new article works through what the TNI standard actually asks for on a routine environmental sample, which turns out to be narrower and harder than the form on your bench.

The signed custody form on your bench is probably not what your assessor will write you up for. The requirement underneath it is narrower and harder: rebuild one named sample, on demand.

10/15/2026

Here is the reason labs stay on their current system that nobody says out loud in the meeting, because it sounds like inertia:

Switching feels risky and the system we have still works.

That is a legitimate reason. A working system that nobody is fighting has real value, and a migration spends that value up front before it returns any. The problem is not that people think it. The problem is that it goes unsaid, so it gets smuggled into the conversation dressed up as a security concern, and then everyone spends an hour arguing about data centers instead of the thing actually being weighed.

Say it out loud and the decision gets easier, because it can be set against the three things that genuinely differ between hosted and on-premises. Who administers the system, meaning who patches it and who is awake at two in the morning. What your lab does on the days the system is unavailable. And whether anyone has approved any money yet.

On-premises stays the right answer in real cases, by the way. A sovereignty rule or written policy prohibiting external hosting settles it outright. Instrument connections that depend on legacy serial interfaces assuming a local network can cost more to move than hosting ever saves. An organization already running comparable systems with staffed IT and an out-of-hours rota pays very little for one more. And a validated system mid-cycle, where revalidation would exceed the saving, should probably stay put.

New article works through all of it, including what the deployment decision does not decide.

The security conversation is usually standing in for a question about who administers the system. Name the three constraints that genuinely differ and the choice gets simpler.

10/13/2026

The four ways lab automation projects go wrong, and none of them are technology problems.

Scope that grows quietly. Phase one starts as four instruments and is eleven by month three, because each addition was individually reasonable and nobody ever decided to double the project. The defense is a written phase-one scope with a named owner who has to approve every addition, and a schedule that gets revised when they do.

Automating a process nobody has described. If the current process cannot be written on one page that two people agree with, automation encodes the disagreement and then hides it. The two departments that disagreed now each believe the system is wrong.

Assuming headcount falls. What usually changes is what people do, moving effort from handling samples to reviewing results and troubleshooting exceptions. A business case built on redeploying skilled people survives contact with reality. One built on removing them invites a reckoning.

Buying the hardware first. The handler arrives, the workflow it was meant to serve was never written down, and the integration to the system that should receive its output was never scoped. The most expensive object in the project spends its first six months as furniture.

Our new article covers the three conditions that make a process worth automating in the first place, and why counting your exceptions before counting your volume is the order that saves money.

Three conditions decide whether a laboratory process is worth automating. Most fail at least one, which is why choosing the candidate matters more than choosing the technology.

10/13/2026

If a software vendor tells you their LIMS is validated, they are describing their own development testing. That is useful information. It is not your validation, and the difference matters more than it sounds.

Validation is documented evidence that a system does what your lab needs it to do, in the configuration you are actually running. Not the vendor's source code. Your deployment. Your specifications, your test methods, your workflows, your user roles. None of that existed until you built it, which is precisely why nobody outside your lab can validate it.

The obligation does not change if the system is hosted. What changes is the split of the work. A vendor can qualify the infrastructure and the base platform once and share that evidence with every customer. What it cannot do is confirm that your stability study workflow behaves correctly, because that configuration is yours alone. Ask a prospective vendor what it hands over, in writing, before the contract rather than after.

And validation is not a milestone you pass at go-live. It is a state you maintain. Adding a new test method does not mean revalidating everything, but it does mean assessing what the change could affect and testing that. Without change control, every change becomes a small undocumented revalidation, and the package slowly stops describing the system you are running.

New article covers what each regulator asks for, and the three places these projects reliably go wrong.

Four frameworks ask for the same thing in different vocabularies. None of them wants volume, and none of them lets a software vendor sign for you.

10/01/2026

Got the end-of-life notice for your Element, HORIZON or Apollo LIMS? 📬

Staying with Clinisys still means a new system, which means migrating your data, rebuilding your reports and validating all over again. If you're rebuilding either way, you might as well do it on your own timeline.

Our new article walks through what the move actually looks like, from counting what your lab really has to running old and new side by side until the results match. Most mid-size labs are live in 7 to 9 months.

👉 https://www.lablynx.com/resources/articles/replacing-element-horizon-lims/

09/29/2026

Cloud is not a type of LIMS.

Cloud, hosted and on-premises describe who runs the servers and who administers the system. They say nothing about what your lab tracks, what it calls its work, or what it reports. Which means they cannot make a system built for testing labs fit a manufacturing QC lab. A cloud LIMS built for testing labs is a testing LIMS that happens to be in the cloud.

Deployment is a real decision and it deserves real thought. Who patches the system, who holds the backups, whether a validated tenancy is available, whether policy requires an air-gapped installation. But it is an administration decision, and it comes after the fit question is settled. Treating it as a type puts the least important question first, which is convenient for whoever wins on that question.

The same goes for industry as a type. A food LIMS and an environmental LIMS are both sample-centred testing systems with different method libraries, limit tables and report templates. The industry is a configuration, not a type. A vendor who cannot show you a food lab and a water lab running on the same product, with different words and different reports, is selling two products under one name.

What actually predicts fit is what your lab tracks. A sample, a patient, an experiment, a batch, or a machine. Most labs can place themselves in under a minute, and once placed, they know which demo questions matter and which to skip.

New article covers all five, plus how a mixed lab should choose when it sits in two rows at once.

Every vendor list of LIMS types is a list of the vendor's own products. The useful cut is by what the lab does with a sample, and it changes which questions matter in a demo.

09/24/2026

Every regulated lab has a shelf of signed SOPs and a drawer of completed worksheets, and every one of those worksheets makes the same claim: this procedure was followed.

The trouble is that the claim gets made once, at the end, in a single signature. It cannot tell you when the third step happened. It cannot tell you whether the fourth was done at all. And it definitely cannot tell you whether somebody went back and re-did step two after step five.

That is what a laboratory ex*****on system is for, and it is probably the least glamorous category in lab software. It walks an analyst through a method one step at a time and records each step as it is completed: who did it, when, in what order, with what values entered along the way. Not a description of the procedure. A log of one particular run of it.

The idea is not new. Manufacturing has had ex*****on systems for decades, because a batch record that says what actually happened is the difference between a release decision and a guess. Labs took longer to adopt it because a bench method feels more like craft than production. Regulators have not shared that view for some time. Where a result depends on a procedure being followed, they want evidence that it was, and a signature at the bottom of a page is an assertion rather than evidence.

Our new article covers what ex*****on records, why the method has to be locked while it runs, and the simple test for whether a given method in your lab still fits in a notebook.

A signed SOP says a procedure was followed. It cannot say when the third step happened or whether the fourth was skipped. That difference is the case for a laboratory ex*****on system.

09/17/2026

The holding time clock starts at collection. Not at receipt, not at the vehicle, not when somebody gets back to the bench.

Which means the most consequential number on an environmental sample gets written down by one person, standing in a field or beside an outfall, often in weather, before anyone from the lab has touched the bottle. Every holding time check downstream is measured from it.

Write that time later from memory and it looks like a small administrative gap. It isn't. Every downstream check is now unverifiable, and an assessor asking how you know the sample was in hold has nothing to read.

Two other things have to be right at that same moment, and neither can be repaired afterward. The container and preservative have to match the analysis, because if they don't, the loss has already happened and the analysis is not recoverable. And the field document has to be finished before the sample leaves the site: site, matrix, analyses requested, preservative used, collector. That's the record connecting a bottle to a place.

By the time the sample reaches an instrument, the result is largely already decided. Analytical precision on a sample that was preserved wrong is precision about the wrong thing.

New article follows one sample through the whole sequence, collection to state deliverable, with the point at which each stage fails:

By the time a sample reaches an instrument its result is largely decided. Here is the work in order, with the point at which each stage fails an assessor.

09/15/2026

There's a reason the paper notebook is still on the bench, and it isn't stubbornness.

Researchers who studied this in 2017 put it plainly: a screen still cannot be written on as accurately or as cheaply as paper in a wet lab. The reasons are physical rather than philosophical. You take gloves off to type. A laptop at the bench is a spill target. There is nowhere safe to put a tablet.

That study also found something that undercuts the usual sales pitch. Awareness of electronic lab notebooks was near universal, around 98 percent, while actual group-level use sat at 11 percent. The barriers people named were ongoing system cost (93 percent) and future development cost (90 percent), well ahead of the upfront license. Nobody needed convincing that notebooks exist. They were doing the math on what year three looks like.

The thing that actually moves adoption turns out to be compliance rather than productivity. One institutional program saw demand spike in 2018, right after the national research funder made data management plans mandatory for grant applications.

Worth knowing if you're weighing a notebook against a sample system, because they are not interchangeable and buying on the feature list is how labs end up with the wrong one. A LIMS is built around the sample. An ELN is built around the experiment. Plenty of labs need both, and that's normal. The expensive mistake is buying one and expecting it to do the other's job.

Feature grids for the two categories look nearly identical. The data model underneath has not converged, and a decade of adoption evidence shows exactly where it still bites.