LIMS Software Development Problems: The 7 That Cost Labs Real Money, and How to Avoid Them

Why does the replace everything at once scope fail?

The renewal quote lands, the director decides to build, and the project is scoped to replace the incumbent across every site, every department and every workflow, with all instrument interfaces, electronic health record integration and the client portal in release one. Ten months later chemistry is running in parallel, histology has not started, and the send out spreadsheet is still the operational record because the new system does not model send outs yet.

What makes this specific to laboratories is that cutover risk is clinical rather than commercial. You cannot pause a laboratory. Every department that switches has to run in parallel, be reconciled, and be validated with the instruments it depends on, and validation is calendar time regardless of how fast anyone codes.

Sequence by department, not by feature. Release one is accessioning, barcode specimen tracking with a proper parent and child model, a defined test catalogue, result entry and verification, reporting, and two to four instrument interfaces for one department. Run it in parallel for two to four weeks, reconcile daily, then cut over and take the next department. Multi site routing, autoverification, electronic health record ordering, client portals and billing export follow. The first department is the one that teaches the team your laboratory, and paying for that lesson across six sites at once is how these projects become the story people tell about custom software.

What goes wrong when you migrate from a legacy LIMS and a decade of spreadsheets?

Three problems recur. The first is the patient index. Years of accessioning produce duplicate patients under name variants, transposed dates of birth and different medical record numbers from different ordering clients. Loading it without a deduplication and review pass means the new system's patient history is fragmented, which matters immediately because delta checks in autoverification compare against prior results for the same patient. A fragmented index makes delta checks useless and, worse, silently useless.

The second is the spreadsheets. The send out tracker, the add on log, the freezer map and the redraw list are not supplementary data, they are the parts of the workflow the old system could not hold. They have to be modelled as first class features before they can be migrated, and teams that plan to import them as reference tables end up importing a description of a process rather than the process itself.

The third is validating that anything moved correctly. A load that runs without errors is not a reconciled load.

The fix is staged migration with reconciliation reports that prove counts and values match the source, department by department, plus a parallel run before each cutover. Plan for migration to consume roughly a fifth of the project, and give the deduplication pass to someone who knows the client base, because only they can tell which two records are the same person.

Why do instrument and EHR integrations break after launch?

Instrument interfaces break on change rather than on connection. An analyzer receives a firmware update, a new assay is added to the menu with a result code the mapping does not recognise, or a units convention changes. The message keeps flowing. Results land unmapped or, in the worst case, mapped to the nearest existing code, which is a patient safety issue rather than a data issue.

Two defences matter. Refuse unknown result codes into an exception queue rather than mapping them by proximity, and alert a named person. And treat every analyzer change, including firmware, as a trigger for a validation run rather than as maintenance, so the laboratory's change control and the software's change control are the same process.

Electronic health record integration breaks on the other side of the boundary. A hospital interface team upgrades, a message segment changes, or a new ordering location appears that maps to nothing. The failure that hurts is orders arriving that cannot be resolved to a client or a test, which look like a quiet morning until somebody calls. Monitor for absence as well as for errors: if an ordering client that normally sends messages hourly has sent none since lunchtime, that is an event.

Middleware such as Data Innovations Instrument Manager is a legitimate part of the answer where it is already in place, and building around it rather than replacing it lowers cost. Just be clear about who owns each mapping, because a mapping owned by nobody is a mapping that will be wrong after the next menu change.

What happens when audit trails and autoverification governance are not covered?

Two gaps produce inspection findings rather than inefficiency. The first is the audit trail. Inspectors expect to see who did what, when, what changed and why, across creation, edit, verification and correction. Systems that log some actions and not others cannot demonstrate that, and retrofitting immutable logging into records that were designed to be editable is close to rebuilding the data layer. Build it structurally from the first release, in the style expected of regulated systems, and make corrected reports carry a reason code with automatic notification to ordering providers.

The second is autoverification governance. Automatically releasing in range results is where the payroll mathematics changes, and it is also where a build can create risk quickly. The rules must be the medical director's, written down, versioned, and testable: delta checks against patient history, evaluation of the quality control that ran with the batch, and defined exclusions. Every automatically released result needs a record of which rule version released it, so a question about a result from six months ago has an answer.

Both belong in the first release for any department where autoverification is planned. The related discipline is quality control evidence: Levey Jennings charts and rule flags living inside the system next to the runs they describe, with review documented, so inspection evidence is an export rather than two weeks of assembly from binders and shared drives.

Should you build custom or configure what you already own?

Buy when you are a single site laboratory under roughly five hundred samples a day running a standard test menu. QBench, CrelioHealth or eLabNext will onboard you in weeks at a subscription cost far below any build, and your workflow does not diverge enough from their assumptions to hurt. Buy also when the pain is billing or client reporting alone, because a point solution or one integration is cheaper than a platform.

Keeping the incumbent is frequently right too. If LabWare, STARLIMS or Thermo Fisher SampleManager still fits and the pain is one missing capability, build that capability alongside rather than replacing a validated system. Middleware you already own should generally stay. The expensive mistake is replacing something that works to gain an interface refresh.

Build when the workflow is the business. The concrete signals: more than five operational spreadsheets orbiting the current system; paying twice for the same class of change order; multiple sites on divergent configurations; an interface backlog longer than a quarter; or a renewal quote for software your staff actively works around.

How do hidden costs get into the quote?

Interface count is the first, and the trap is that each interface carries a validation run, not just a connection. Ten analyzers is ten validations with documentation, scheduled around a working laboratory. Ask whether validation is included per interface or quoted separately, because the difference is substantial.

Second, electronic health record integration, which is a real line item requiring coordination with a hospital interface team on their schedule rather than yours. Third, migration, which regularly consumes about a fifth of the project and is often quoted as a data load. Fourth, the installation, operational and performance qualification documentation package regulated laboratories need to show inspectors. Fifth, molecular workflows with plate maps and batch structures, which are a genuinely different model from tube based chemistry.

Ask what is included per instrument interface, whether validation and documentation are inside that number, and how many years of history the migration figure assumes.

What separates a build that works from one that fails here?

Make them whiteboard the data model. Ask how they distinguish accession, specimen, aliquot and test order, and how a reflex test changes that graph. A team that answers with a generic orders table will rediscover laboratory medicine on your budget, and the discovery will arrive as the send out spreadsheet reappearing three months after go live.

Demand named interface experience with analyzer models attached, and ask whether they worked in raw ASTM, in HL7 version 2 result messages, or through middleware. Then ask them to describe their reconciliation approach for migration, because a partner who proposes staged migration with reconciliation reports and a parallel run period, and puts both in the timeline up front, has done this before.

The builds that work also make turnaround visible by timestamping every stage transition, so a client complaint about slower results becomes a question with an answer rather than an argument about which department is at fault. They add escalation queues that page a supervisor when a stat result sits unverified past a threshold. The builds that fail record received and resulted, nothing in between, and produce a system that is technically new and operationally identical to the one it replaced.