At the Clinisys Customer Summit last month, Sue Gascoigne-Barnett, Senior Assessment Manager for Healthcare at UKAS, shared a number that every lab implementing or upgrading a LIMS should sit with for a minute.

In 2025, 17 significant non-conformances related to LIMS were reported to UKAS. 14 had the same root cause: a new LIMS set up incorrectly. The other three were cyber attacks.

So what does “set up incorrectly” look like? UKAS shared real examples from its assessments. Without the system names, they read like this:

• After an upgrade, lab results stopped appearing in the order comms system clinicians use.
• After a new LIMS went live, GPs struggled to see results, and results moved inconsistently from the LIMS to order comms and on to the patient record.
• Results weren't reaching GPs, and the referral module didn't tell users when results were ready to review.
• After an upgrade, some results were held in the system and never sent to GPs.
• Results weren't transmitted correctly into end-user IT systems, and some went out uncoded.
• Legacy data migrated from the previous system was merged incorrectly, following instructions from the PAS. A blood group mismatch was escalated to the MHRA.
• Changes to how GP practices received reports weren't communicated before go-live. Rejected samples, missed tests and delayed results followed, along with negative press coverage and a formal query from the CQC.

A few of these sit inside the lab system. Most don't. They happen at the joins: where the LIMS hands results to order comms, GP systems and the patient record, where it takes patient details from the PAS, and where people at the other end rely on results arriving the way they always have. (In US terms: the LIS, CPOE, hospital and primary care EHRs, and ADT.)

That's what makes them so hard to catch. Every institution's pathway is its own mix of systems, suppliers, interfaces, local codes and working practices. No supplier or vendor can test that mix for you, and testing the lab system on its own won't find it. These problems only show up when the whole workflow is tested end to end, with your own systems and your own people.

This isn't only a UK problem. We just don't study it nearly enough here in the US. The best look I can find is a CAP Q-Probes study, reported in CAP TODAY in 2015, in which 45 institutions reviewed 1,064 lab results as they appeared in the EHR.

Ninety-nine percent had been transmitted accurately. But only 70 percent arrived complete, and only 91 percent were formatted appropriately. Nearly a third were missing one or more items, most often the name and address of the performing laboratory and the date and time of the result.

That study is more than a decade old, and it's still the best US data I can find. What arrived wasn't wrong. What was missing left the picture incomplete.

Sue's slides drew the line clearly. Supplier validation is the vendor's evidence that the software was developed, tested and released to its own quality processes. Laboratory verification is evidence that your configured system works with your workflows, instruments, interfaces, users and reports. Both matter, and they are not the same thing. In UKAS's words: “The Laboratory retains responsibility for confirming that the LIMS is fit for its intended use.”

US labs carry the same responsibility in federal law. Under CLIA, “the laboratory must have an adequate manual or electronic system(s) in place to ensure test results and other patient-specific data are accurately and reliably sent from the point of data entry (whether interfaced or entered manually) to final report destination, in a timely manner” (42 CFR 493.1291(a)). That explicitly includes results sent to network or interfaced systems.

Not to the edge of the LIS. To the final report destination.

A line with an end

UKAS set out a risk-based verification lifecycle in eight steps:

1. Define the intended use: scope, disciplines, workflows, interfaces, report types, users
2. Map the requirements: quality management, user needs, clinical oversight
3. Assess risk: errors that could affect patient safety, result validity and confidentiality
4. Design test scripts: normal workflow, boundary conditions, error handling
5. Execute testing: outcome, date, evidence, expected and unexpected results, pass or fail
6. Resolve issues: classify defects, apply corrective actions, retest and approve closure
7. Approve go-live: authorisation from the appropriate people in the department
8. Monitor after go-live: incidents, user feedback, turnaround times, audit

The FDA's Computer Software Assurance guidance follows much the same shape for manufacturers.

It's a sound process. Most labs would recognise it, and plenty follow it.

But look at the shape. It's a line, and it stops at step 8.

So what happens to everything you learn in step 8? The interface that dropped amended reports. The rejection reason nobody tested. The GP practice that stopped receiving results. Where does that knowledge go when the next upgrade arrives?

Most of the evidence is the issue trail

The next slide listed what UKAS expects to see at assessment:

• An approved implementation and verification plan
• A user requirement specification, with traceability
• Risk assessments covering patient safety, result integrity, confidentiality and continuity of service
• Completed test scripts with objective evidence, such as screenshots or extracted records
• Evidence of failed testing, with impact assessment, corrective action and re-testing
• Training and authorisation records for staff using the system
• Supplier documentation and agreements for support, hosting, maintenance and updates
• Formal go-live approval and a post-implementation review

Much of that list is really one thing, the issue trail: what failed, what it could have affected, what was done about it, how it was retested, who approved it and what happened afterwards.

That's also where UKAS sees labs fall short. Among the common non-conformances on her list: testing ideal workflows but not exceptions, rejections, amendments, downtime or interface failures. Weak traceability between requirements, risks, tests, defects and approvals. And poor evidence capture, “making it difficult to demonstrate what was tested and why it was accepted.”

None of that is a competence problem. It's what happens when the trail lives in spreadsheets, inboxes and Word documents with pasted screenshots. The work gets done. The proof gets scattered.

Closing the loop

UKAS's conclusion was one line: “LIMS verification is not a one-off exercise.” The system has to stay fit for purpose “throughout its lifecycle,” and every upgrade, interface change and new analyser restarts the clock.

The same CAP study found that only 79.5 percent of laboratory directors reviewed results in the EHR when it was implemented. Only 61.4 percent reviewed them at least every two years, and 6.8 percent never did.

No test plan catches everything. Some errors will get through. What we can do is make sure the same one never gets through twice.

So the answer isn't more process. It's making step 8 feed step 4.

An issue might turn up in testing, at go-live or six months later. Wherever it appears, it should be logged against the step that found it, or against the gap where no step did. It's tracked through the supplier's fix, retested and approved. Then it goes back into the test library as a scenario, so the next upgrade tests for it as a matter of course.

Do that consistently and the library becomes the lab's memory. It holds the lessons from every go-live, and it doesn't leave when the person who remembers the last interface problem moves on.

That's the reason to manage verification in a system of record rather than a spreadsheet. In Cymetryc, issues are raised from the failed step with the evidence attached, tracked through correction and re-testing, approved, and then incorporated back into the library, so the same error doesn't slip through on the next upgrade. The trail UKAS asks for builds up as the work is done, not the week before an assessment.

Meet Ellen

I'm delighted to introduce Ellen Whiteside, who joined us as UK Delivery & Implementation Lead.

Ellen is an HCPC-registered biomedical scientist. She started in pathology at Blackpool Teaching Hospitals, where she led molecular pathology and the validation and implementation of new diagnostic technologies. She went on to run transformation programmes across the Lancashire & South Cumbria Pathology Collaboration, including digital pathology and LIMS planning. Most recently she was an Assessment Manager at UKAS, assessing medical laboratories against ISO 15189.

She knows what it takes to bring a new system into a lab, and what that lab then needs to show when it's assessed. That's rare, and it's exactly the experience UK labs need beside them on an implementation or upgrade.

Bring your next change and talk it through with her. Reach her any time at ellen@cymetryc.com.