Molecular Diagnostics and NGS Lab Software Problems: The 7 That Fail an Inspection, and How to Avoid Them

Why does a case never get pinned to an assay and pipeline version?

Because the assay feels like a fixed product when the first system is designed. A panel has a name, a gene list and a report template, so it gets modelled as a reference row, and cases point at it. Then a gene is added, an aligner is updated, a quality threshold moves as the laboratory learns its own assay, and the reportable range narrows. Every one of those edits changes what the panel is, and every case that already ran now points at a definition that no longer describes it.

This is the gap that no single packaged option closes cleanly. Pipeline platforms are strong at execution and reproducibility but are not clinical laboratory systems, so accessioning, batching and sign out live elsewhere. Interpretation products are strong on somatic content while the wet lab workflow stays outside them. Products with laboratory information system origins handle specimens well and go shallower on interpretation. The seam between them is exactly where the version chain gets lost.

Make the assay definition a versioned configuration object holding target regions, pipeline identifier and version, quality metric thresholds, reportable range, gene list and report template. Cases bind to a version at accessioning. Changing the definition creates a new version rather than editing the old one, and the system can answer at any time which cases ran under which version.

Ask any developer how a two year old report is reproduced exactly. The answer must involve pinned assay, pipeline and classification versions. If they talk about storing the signed document, they have understood the archive requirement and missed what a clinical laboratory is actually required to be able to do.

What goes wrong when you migrate historical cases and classifications?

The instinct is to bring everything and the honest answer is that you cannot bring what was never recorded. Historical cases ran under assay definitions that existed only as a document and a memory, so retrofitting a version identifier onto them is an invention rather than a migration. Doing it anyway creates a record that looks authoritative and is not, which is worse than an obvious gap.

Classifications are the harder half. Your current interpretation vendor holds them, and what exports cleanly is usually the classification label. What tends not to export is the part that matters: which evidence codes your committee applied, the citations behind them, the reviewer, the date and the version history of the decision. That trail is the asset, and rebuilding it after the fact is not possible.

Do three things in order. Extract the classification set with its full evidence history first, before any other migration work, and confirm what you actually received rather than what was promised. Set a defined date from which the pinned version chain begins and treat everything earlier as legacy, with cases carrying a reference to how they were produced rather than a fabricated version. Then decide, deliberately and in writing, how far back reclassification surveillance will reach, because that decision drives how much historical case data has to be structured rather than archived.

That last decision is a medical one as much as a technical one, and it belongs to your laboratory director rather than to a project plan.

Why do the instrument, pipeline and health record integrations break after launch?

Instrument integrations break on run metadata. Sequencers expose run level information in formats that change with software updates, and the failure is rarely an error. It is a field that stops populating, so run quality metrics quietly go missing for a subset of cases and nobody notices until an audit asks for them.

Pipeline integrations break on identity and on partial failure. A pipeline is updated for good reasons, the version string format changes, and cases start recording something your system cannot map back to a definition. Separately, a run that fails halfway leaves outputs for some samples and not others, and a system that assumes a run either succeeds or fails will either lose good data or reprocess it twice.

Electronic health record integrations break on structure. Sending a rendered report as a document is comparatively straightforward. Delivering discrete structured results, meaning individual variants with their interpretation as coded fields the receiving system can act on, is materially harder, and the receiving site will change its own configuration without telling you.

Build the defences accordingly. Treat every incoming metadata field as optional and validate on completeness against expectation, raising a ticket when a field that normally populates stops. Make results idempotent at sample level so reprocessing cannot duplicate a case. Keep raw instrument and pipeline outputs for a defined window so reprocessing is possible when a format changes. And monitor delivery acknowledgements per receiving system rather than per message, because the failure that matters is one ordering site quietly not receiving anything.

What happens when reclassification surveillance and amended reports are not covered?

This is the gap most often deferred and the one an inspector will find. A variant reported as uncertain significance eighteen months ago is reclassified by your committee as likely pathogenic, which may make a targeted therapy relevant for a patient whose report says otherwise. The laboratory has to decide whether an amended report is warranted, and making that decision requires knowing every case that reported the variant, what each said at the time, and who ordered it.

Without the pinned chain the query cannot run, so the decision gets made informally, on the cases somebody happens to remember, or not at all. That is not a reporting deficiency. It is a professional duty being discharged on the basis of recall.

Make 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 and decides per case or per cohort. The system generates amended reports stating plainly what changed and why, delivers them through the same interfaces as the original, and retains the decision record.

Include the cases where no amendment was warranted, with the reasoning and the decider. Documenting the decision not to amend is as important as the amendment itself, and it is exactly what you will be asked about. A system that records only the amendments has recorded the easy half.

Should you build custom or configure what you already own?

If you run two or three fixed, well supported panels at modest volume and do not develop your own assays, do not build. SOPHiA GENETICS and PierianDx bring curated content that would take 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.

Before concluding your current tools have failed you, check the seams rather than the tools. Most laboratories in this position have three good products and no owner of the space between them, and a meaningful share of the pain is unconfigured integration and manual re entry rather than product limitation. Mapping exactly where data is retyped, and by whom, is a week of work that will either produce a cheap fix or produce your business case.

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

Build when you launch assays yourself and vendor turnaround sets your launch date, when per case pricing is a visible line in your cost per test, when the wet lab between accessioning and results still runs on spreadsheets, or when you cannot currently produce the list of cases a reclassification affects.

How do hidden costs get into the quote?

Assay count is the largest driver and the most commonly under scoped. A somatic solid tumour panel, a germline hereditary panel and a haematological malignancy assay have genuinely different reporting and classification models, so a quote priced against one is not a quote for three. Ask for the price of assay two explicitly and expect the second to cost a fraction of the first only if the versioning model was built properly.

Electronic health record interfacing is the second. Discrete structured result delivery is a different piece of work from sending a rendered document, and the scheduling constraint is usually the receiving site rather than your developer, which puts it on the critical path in a way nobody accounts for. Start those conversations before engineering kickoff.

Then four more. Software validation, if your accreditation responses require validation documentation for the system itself. Instrument and pipeline diversity, since each sequencer and each pipeline stack brings its own metadata and its own failure behaviour. Historical case structuring, driven by how far back you want surveillance to reach. And the parallel period, where the wet lab runs both the spreadsheets and the new system and does more work rather than less.

What separates a molecular laboratory build that works from one that fails?

Quality gates that hold a sample rather than a run. A system that stalls ninety five good libraries because one failed at a single well will be worked around within a week, and the workaround will be a spreadsheet, which is where you started. Sample level gating is not a refinement, it is the difference between a system technicians use and one they route around.

The plate modelled as a real object, with specimens occupying positions, positions carrying reagent lots and instrument runs, and every transfer between plates recorded as an operation rather than a copy and paste. Chain of identity from tube barcode through each plate to the final variant call becomes queryable, which means a transposition is either impossible or caught immediately rather than discovered in a signed report.

A firm line on automation, written into the specification. 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, which saves genuine curation hours. The classification decision and the sign out stay with a qualified human and the system records who decided, when and on what evidence. A developer enthusiastic about automated classification is a liability in this environment rather than an asset.

One assay launched end to end rather than three in parallel. The second costs a fraction of the first because the versioning and batching model already exists, and shipping one thing that works is what earns the funding for the rest.

And ownership settled before kickoff, covering the repository, the cloud accounts and your classification data with its full evidence history in an exportable form. In this category the data ownership question matters at least as much as the code, because the classified variant set accumulates value every month and is precisely the asset that makes switching painful when it lives inside somebody else's platform.