How to Choose a Molecular Pathology Data Management System: A Lab Director's Guide

At some point in the procurement process, every lab director ends up in much the same place. There is an RFP on the desk, three vendor demos have come and gone, and each vendor has presented their system as the obvious answer. The price points differ, the feature lists differ, the implementation timelines differ, and the truth is that sitting with all of this it is genuinely difficult to know what to weigh, what to discount, and what to push back on.

This guide is an attempt to make that decision easier, and to make it on the basis of evidence rather than vendor marketing. The good news is that the question has been studied. Two leading US academic medical centres — Cleveland Clinic and the University of Chicago — have separately published their experiences trying to procure commercial laboratory information software for molecular pathology, and a 2025 comparative study from Italy has examined the three major LIS platforms used across more than 90% of Italian pathology laboratories. Read together, these papers say something specific about how the decision should actually be made.

What follows is what that research tells us, and what it ought to mean for any lab director choosing a molecular pathology data management system in 2026.

What is a molecular pathology data management system?

A molecular pathology data management system is the software platform a laboratory uses to manage cases from order intake through sample tracking, sequencing, variant curation, multi-tier review, and final sign-out. In practice it may take any of several forms: a traditional Laboratory Information System (LIS), a specialised Laboratory Information Management System (LIMS), a custom-built solution, or a workflow middleware layer that connects to existing systems. The right shape for any particular lab depends on the workflow it actually runs, the scale at which it operates, and the regulatory framework it operates under.

Because molecular pathology workflows differ structurally from general laboratory workflows — they revolve around cases, samples, panels, runs, variants, and family relationships rather than individual specimens or encounters — the question of which system fits a given lab is not the same as choosing a general LIS. This guide is concerned specifically with that more particular decision.

What the published evidence tells us

The first paper worth knowing about comes from the Molecular Pathology Division at the University of Chicago Medicine. In 2018 they published their work on a system they called SIMPL (System for Informatics in the Molecular Pathology Laboratory). Their starting point was an honest survey of what was available commercially. Their conclusion, in their own published words, was that the available commercial LIS and LIMS options did not meet all of the requirements of their NGS workflows, and were frequently extremely cost-prohibitive. They built an open-source platform of their own, validated it clinically against College of American Pathologists requirements, and later installed and tested it at the University of Colorado.

The second paper comes from Cleveland Clinic's Molecular Pathology Section, published in 2022. A different academic medical centre, four years later, almost identical finding. The team there set out to replace an Excel-and-paper data-management system with a commercial LIMS. Their conclusion, after surveying the available products, was that a customised approach was required because, in a survey of commercially available off-the-shelf software products, none met the diverse and complex needs of this molecular diagnostics service. They ended up combining a base LIMS with custom test-interpretation applications, a separate bioinformatics platform, customised sample accessioning, and a results-releasing application. Five integrated pieces from multiple sources, because no single vendor could deliver what the lab actually needed.

The third paper, from 2025, approaches the question differently. Rather than asking whether off-the-shelf options can be made to work, it directly compares three major LIS platforms (Armonia, Pathox Web, and WinSAP 3.0) that between them are used in more than 90% of Italian public and private pathology laboratories. The analysis examines them across the parameters that genuinely matter to a buyer: sample traceability, integration with hospital systems, digital reporting, user interface, and compliance with regulatory frameworks including ISO 15189 and GDPR. The result is not that one of the systems is best. The result is that each is best for a different kind of laboratory, and that the parameters distinguishing them are precisely the parameters a lab director should be examining during procurement.

The pattern across all three papers is consistent. Molecular pathology has needs that generic laboratory software does not naturally meet. The right system for any given lab depends on a clear evaluation of a small number of criteria, and the labs that have done this work well have been very deliberate about what those criteria are.

Six criteria that actually matter

Across the published case studies, vendor questionnaires used by other labs, and our own experience working with molecular pathology teams, the criteria that genuinely separate suitable systems from unsuitable ones come down to six. They are listed below in roughly the order they should be weighted.

1. Does the data model fit how your lab actually works?

This is the most important question, because everything else is downstream of it. Generic laboratory software systems are typically built around patient encounters, visits, or specimens. Molecular pathology workflows are built around cases, samples, panels, runs, variants, and family relationships. If the data model of the software does not naturally represent the unit of work the lab does every day, every workflow turns into a workaround, and over time those workarounds become the system.

There is a simple practical test for this. In the vendor demo, ask to see how a paediatric NGS case with family member testing flows through the system from order to sign-out, without preparing the data ahead of time. If the system cannot represent that case natively — if the demonstration involves opening multiple modules or describing how a workaround could be configured — the data model is the wrong shape for molecular pathology. This is precisely the gap that drove the Chicago and Cleveland Clinic teams toward custom solutions, and it has not narrowed in the years since. (For more on why generic systems struggle with this, see our earlier post on why pathology labs need dedicated case management.)

2. How fast can the system change when your workflow changes?

Speed of change matters more than initial feature completeness, and this is the criterion that vendors tend to underestimate most consistently. Molecular pathology workflows evolve continuously. New gene panels are added, ACMG classification guidance is updated, sign-out checklists are revised, new QC steps are introduced. The Cleveland Clinic team's experience is instructive here: they could not find a single off-the-shelf option that could keep up with these changes, which is why their final architecture required five integrated pieces and a multidisciplinary internal team to maintain it.

The practical test is to ask, during the procurement process, exactly what it costs and how long it takes to add a new gene panel, a new case status, a new report template, or a new QC step. If any of those answers involves a formal vendor quote and a project plan, the system is not configurable in the way that genuinely matters. A configuration change that requires a project plan to action is a change that, in practice, will not happen in time.

3. Will it integrate with what you already have?

Lab software does not exist in isolation. There is the hospital EMR, possibly an existing LIS, sequencing instruments, bioinformatics pipelines for variant calling and annotation, third-party variant interpretation tools, and increasingly a digital pathology system as well. A 2017 paper from a large academic medical centre catalogued the top ten challenges in interfacing an LIS to an EHR, and the list is sobering. None of the challenges were trivial, and none were resolved without significant effort.

The position worth holding here is that the right system is the one that connects cleanly to the existing stack, not the one that demands the most ground for itself. A vendor that insists on owning the patient registry, or that positions its platform as a replacement for the EMR rather than a complement to it, has misunderstood where it fits in the architecture. The Italian comparative study uses integration with hospital systems as a primary evaluation parameter for the same reason. For a deeper treatment of what cleanly designed integration actually looks like, see our piece on why labs need a fast middleware layer.

4. Does it produce audit trails that satisfy your regulator?

This criterion is non-negotiable, but it is also commonly underestimated during vendor evaluations because the audit trail looks the same in every demo. The reality only emerges during a NATA or ISO 15189 audit, when the lab discovers what is actually logged, what is logged at sufficient granularity, and what has to be reconstructed manually.

The Italian 2025 study uses ISO 15189 compliance as one of its core evaluation parameters for a reason: it is one of the dimensions on which the three major Italian LIS platforms differ meaningfully. The question worth asking explicitly during procurement is whether the system automatically logs every status change, every variant classification decision, every panel version update, and every sign-out — with user, timestamp, and context attached, immutably, by default. The answer should always be yes, automatically. An audit trail that requires manual logging by lab staff will not survive contact with reality, regardless of what the vendor's compliance documentation claims.

5. What is the realistic implementation time and total cost?

Vendor-quoted implementation timelines and vendor-quoted prices have well-known relationships to reality. The published case studies are useful here. The Cleveland Clinic customised solution required clinical laboratorians, pathologists, genetic counsellors, bioinformaticians, systems analysts, and external software engineering consultants working together to deliver. That is the realistic baseline for what a heavy implementation costs in people and time, regardless of what the upfront price quote says.

There are two practical positions to take. The first is that any platform that cannot be operational in weeks is too heavy, and the staff time, opportunity cost, and consulting cost of a long implementation will usually exceed the licence cost itself. The second is that the relevant cost figure is not the year-one quote, but the five-year total — including every customisation, every change request, every interface, and the ongoing internal staff time required to maintain the system. That figure tells the real story.

6. Who owns the data, and where does it live?

Data sovereignty matters, and not only for compliance reasons. Multi-tenant SaaS architectures, where the lab's data sits in shared tables alongside every other lab's data, create real risks even where the access controls work correctly. For Australian labs specifically, the location of patient data is regulated. For any lab, the question of what happens to the data if the vendor is acquired, goes bankrupt, or changes its commercial terms, deserves a clear written answer before the contract is signed, rather than a clarification afterwards.

The position worth holding here is straightforward. Each lab should have its own database and its own infrastructure, with full read access to its own data in a portable format. Anything less is a compliance and continuity risk that has been dressed up as cost savings.

Five red flags during vendor evaluation

Some signals during a procurement process indicate a poor fit clearly enough that they justify excluding a system from further consideration.

Seven questions to ask every vendor

A short list of practical questions, phrased to elicit specific rather than aspirational answers. The right system will provide direct answers to all of them in writing.

1. Can you show us, in this demo, an NGS case with family member testing flowing from order to sign-out without preparing data ahead of time?
2. What does it cost, and how long does it take, to add a new gene panel? A new case status? A new report template?
3. How does the system integrate with our existing EMR? What does that integration look like in practice for HL7, CSV, and API exchange?
4. What is logged automatically, at what level of detail, and with what immutability guarantees, against NATA and ISO 15189 requirements?
5. What is the realistic five-year total cost of ownership, including customisations, change requests, and ongoing support?
6. Will our data live on dedicated infrastructure, in our preferred hosting jurisdiction, with full read access in a portable format?
7. What happens to our data and our system if you are acquired, restructure, or change commercial terms?

What the evidence really tells us

The convergence between the Chicago and Cleveland Clinic experiences is the part of the published evidence that should genuinely change how this procurement is approached. Two of the most sophisticated buyers in the field, working independently and several years apart, both surveyed the commercial market and concluded that none of the off-the-shelf options fit. This is not a failure of those laboratories to find the right vendor. It is a structural mismatch between how molecular pathology workflows actually run and how generic laboratory software is built.

The labs that have made this work — and the Italian comparative study suggests there are several — have done so by being deliberate about a small number of criteria, and by refusing to compromise on the ones that genuinely matter. The data model has to fit. The system has to change at the speed the workflow changes. Integration has to be cleanly designed rather than fought for. Audit trails have to be automatic. Implementation timelines and total costs have to be honest. And the lab has to retain real ownership of its data.

When those six things are right, the right system becomes obvious. When even one of them is wrong, no amount of additional features makes up for it. For labs that want a parallel reading on the workflow side — how case management and sample tracking ought to be designed once those six criteria are met — that is where we would point you next.