LabLynx, Inc.

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.

09/10/2026

Turning on audit trails is not a configuration step you finish. It is a permanent review obligation you take on.

FDA's data integrity guidance expects audit trails to be reviewed at the same frequency as the data they protect, and where no frequency is specified, the lab sets one by risk assessment. So somebody has to actually read them, week after week. And it is the missed review that gets cited, not the trail itself. Budgeting for the license and not for the reviewing is how a system that passed its validation still produces findings two years later.

The same pattern shows up in accreditation. Ask an ISO/IEC 17025 assessor what they cite most often and it is rarely a missing electronic audit trail. It is incomplete management-review inputs, particularly risk identification under clause 8.9.2. No system generates that for you either.

That is the part usually left out of a lab software business case: not what the system does, but what it costs to keep running properly.

Our new article covers the five kinds of data the phrase "laboratory informatics" actually names, which system owns each, what the whole thing returns, and what it will not fix no matter what you spend.

The term feels vague because it names five different kinds of laboratory data at once. Separate them, decide who owns each, and the shortlist writes itself. Then cost it from your own records.

09/08/2026

Buy the wrong lab system and you find out on the first morning, not during the demo.

The clearest example is history. After a conversion, no patient has any history in the new system, so automated delta checks have nothing to compare against. A delta check is the flag that fires when a result has moved implausibly since the last one. Nothing looks broken. The system simply has no past, and every check that depends on a past has quietly stopped existing. Transfusion services are separately exposed where historical blood type was not migrated, which can mean a second draw before products are issued.

None of that appears in a feature comparison. And the feature lists really have converged: plenty of products serve both markets, and a vendor using both terms on a page is doing search coverage rather than misleading you.

What has not converged is the regulation and the data model. An LIS is built around a patient, a requisition and an accession number, under CLIA, with an EHR on one side and billing on the other. A LIMS is built around a sample, a client, a project and a holding-time clock, under ISO/IEC 17025 or 21 CFR Part 11.

Our new article covers both, plus why a clinical lab says accessioning and an environmental lab says sample login for the same moment, and the one question worth asking a vendor that the acronym cannot answer.

The two acronyms describe systems built around different objects, a patient and a sample. The feature lists have converged. The regulation and the data model have not, and that surfaces at go-live.