Molecular Diagnostics and NGS Lab Software: How Do You Handle a Variant That Gets Reclassified Two Years After You Signed the Report?

Why a molecular lab breaks on general purpose systems

A solid tumour panel signed out in March 2024 reported a variant of uncertain significance. Eighteen months later the evidence has moved and the lab's own classification committee reclassifies it as likely pathogenic, which means a targeted therapy is now relevant for that patient. Who knows that the report exists? Who knows which ordering oncologist received it? Who decides whether an amended report goes out, and what is the record of that decision? At most laboratories the honest answer involves a director's memory and a query someone runs by hand against a results database.

The stack that produced the original report is usually a general laboratory information system for accessioning and billing, a set of spreadsheets and shared drives for batch tracking through extraction and library preparation, a bioinformatics pipeline running somewhere with versions tracked in a repository, an interpretation product such as PierianDx or Fabric Genomics, and a report template in a document tool. Each of those is defensible on its own. Together they mean nothing holds the one object a clinical molecular laboratory actually runs on: a case, pinned to an assay version, pinned to a pipeline version, pinned to a set of variant classifications as they stood on the day of sign out.

Without that pinned chain, three specific things become impossible. You cannot reproduce a two year old report exactly. You cannot answer a CAP inspector who asks which pipeline version produced a given result. And you cannot systematically surface the cases affected when a classification changes. Those are not reporting gaps. They are the operating substance of a clinical laboratory.

Problem 1: the assay is a version, and everything has to pin to it

A laboratory-developed panel is not a fixed product. The target region changes when a gene is added. The pipeline changes when an aligner or caller is updated. Quality thresholds move as the lab learns its own assay. The reportable range narrows or widens. Each of those changes creates a new assay version, and every case must record which version it ran under, because a result from version 3 is not necessarily comparable to a result from version 5.

This is a genuine gap in the packaged options. Velsera Seven Bridges is strong at pipeline execution and reproducibility but is not a clinical laboratory system, so accessioning, batch tracking and sign out live elsewhere. PierianDx is strong on somatic interpretation and its knowledge content, but the wet lab side of the workflow tends to remain outside it. Sunquest Mitogen comes from a laboratory information system lineage and is stronger on specimen handling than on interpretation depth. SOPHiA GENETICS bundles pipeline and interpretation together, which is efficient if your assays match their supported content and constraining if you are launching your own.

A custom build makes the assay definition a versioned configuration object: target regions, pipeline identifier and version, quality metric thresholds, reportable range, the gene list, and the report template that applies. Cases bind to a version at accessioning. Changing the definition creates a new version rather than editing the old one, and the system can tell you at any point which cases ran under which version. That single design decision is what makes reproducibility, inspection readiness and reclassification handling possible later.

Problem 2: batch and plate tracking is where the day actually happens

Between accessioning and a variant call sit extraction, quantification, library preparation, pooling, and a sequencing run, each with plate positions, reagent lots, instrument identifiers and quality checkpoints. A failed library at position D7 means one patient's case is delayed and the technician needs to know which case, whether it can be rescued from remaining nucleic acid, and whether the ordering physician has been told the turnaround time slipped.

Almost every lab we have worked with runs this part on spreadsheets, because interpretation products do not model it and general laboratory information systems do not model plates properly. The spreadsheet works right up until a plate map gets transposed and two patients' results are attributed to the wrong specimens. That is the failure mode that keeps laboratory directors awake, and it is not hypothetical in an industry that runs 96 well plates by hand.

A custom build models the plate as a real object. Specimens occupy positions, positions carry reagent lots and instrument runs, and every transfer between plates is a recorded operation rather than a copy paste. Quality gates hold a sample rather than a whole run where the failure is sample level, so one bad library does not stall 95 good ones. Chain of identity from tube barcode through every plate to the final variant call is queryable, which means the transposition either cannot happen or is caught immediately.

Problem 3: the variant knowledge base has to belong to the laboratory

Interpretation vendors bring content, and that content is real value, particularly for somatic oncology where the literature moves weekly. What they also bring is a dependency: your laboratory's own classifications, its own evidence citations, its own interpretation language and its own committee decisions live inside somebody else's product, priced per case.

Per case pricing has a specific consequence that laboratory directors feel as they grow. Success increases your cost linearly, and the asset accumulating value, which is your classified variant set, is the thing you do not fully control. When you want to change vendor, the classifications and the evidence trail behind them are what you struggle to take with you.

A custom build treats the knowledge base as laboratory property. Each variant carries the lab's classification under ACMG and AMP style criteria with the specific evidence codes applied, the citations behind them, the reviewer, the date and the full version history. Public sources are ingested as evidence rather than as truth, so a ClinVar submission is a signal that feeds a review, not an automatic reclassification. This is the one place where language models do a well defined job: triaging new literature against your variant list and drafting a structured evidence summary for a reviewer to accept, edit or reject. The classification decision stays with a qualified human, always, and the system records who made it.

Problem 4: reclassification is a professional duty with no system behind it

When a classification changes, the laboratory has to decide whether previously reported cases warrant an amended report. Making that decision requires knowing every case that reported the variant, what it said at the time, who ordered it, and whether the patient is still in active care. Very few laboratories can produce that list quickly, which means the decision is made informally or not at all.

None of the packaged tools solves this end to end, because solving it requires the pinned chain described above: case to assay version to reported variants to classification version to recipient. If any link is missing, the query cannot run.

A custom build makes reclassification an event with a workflow. A classification change fires an impact assessment listing affected cases with their sign out dates and ordering providers. The director reviews, decides per case or per cohort, and the system generates amended reports with a clear statement of what changed and why, delivers them through the same interfaces as the original, and keeps the decision record including cases where no amendment was warranted. Documenting the decision not to amend is as important as the amendment itself, and it is exactly what an inspector will ask about.

What this costs and how long it takes

Across the projects Digital Heroes has delivered, a focused first release covering accessioning, plate and batch tracking, assay versioning, pipeline orchestration with sample level quality gates and basic report generation runs $110,000 to $220,000 and ships in 16 to 22 weeks. A full platform adding the lab-owned variant knowledge base, reclassification surveillance and amended reports, per recipient report rendering, electronic health record interfaces and payer-aware billing handoff runs $300,000 to $700,000 phased over 9 to 15 months.

What drives cost up in this category specifically:

• Number of distinct assay types, because a somatic solid tumour panel, a germline hereditary panel and a heme malignancy assay have genuinely different reporting and classification models
• Instrument and pipeline diversity, since each sequencer and each pipeline stack brings its own run metadata and its own failure behaviour
• Electronic health record interfacing, where structured discrete result delivery is materially harder than sending a rendered document
• Accreditation expectations, if your CAP checklist responses require validation documentation for the software itself
• Historical case migration, particularly if you want reclassification surveillance to reach back over prior years of reports

What keeps cost down: launching with one assay end to end rather than three in parallel. The second assay costs a fraction of the first because the versioning model is already there.

Build versus buy, and when buying is the right call

Buy if you run two or three fixed, well supported panels at modest volume and do not develop your own assays. SOPHiA GENETICS and PierianDx bring curated content that would take you years to accumulate, and at low case volumes their pricing is cheaper than the engineering you would replace it with. There is no prize for building a worse knowledge base.

Build when two or more of these are true. You launch new assays yourself and vendor turnaround for supporting them sets your launch date. Your case volume makes per case interpretation pricing a visible line in your cost per test. Your wet lab still runs on spreadsheets between accessioning and results. You cannot currently produce the list of cases affected by a classification change. Or you are stitching three products together and the seams are where your errors happen.

Our position is narrower than the usual build everything advice: buy content, build the system. Licensing a curated knowledge source as an evidence feed is sensible. Letting a vendor hold your laboratory's own classifications and your case chain is what you should stop doing, because those are the assets that make your reports defensible.

How to choose a developer for molecular diagnostics software

Ask them to explain how a two year old report gets reproduced exactly. The answer must involve pinned assay version, pipeline version and classification version. If they talk about storing the PDF, they have not understood what a clinical laboratory is required to be able to do.

Ask how quality gates behave when one sample on a plate fails. A system that holds an entire run because of one failed library will be worked around within a week, and the workaround will be a spreadsheet again.

Ask what they will and will not automate in interpretation. The correct answer draws a firm line: automation triages evidence and drafts text, a qualified human classifies and signs out, and the system records who did what. A developer enthusiastic about automated classification is a liability in a CLIA environment.

Ask what they have integrated with on the instrument side and on the electronic health record side. Run metadata from a sequencer and discrete structured result delivery into an electronic health record are both specific pieces of work, and someone who has done them will describe the awkward parts unprompted.

Ask who owns the code and the knowledge base, and get it in writing before kickoff. You should hold the repository, the cloud accounts, and your variant classifications with their full evidence history in an exportable form. At Digital Heroes the code is yours from the first commit, and in this category the data ownership question matters just as much.