Variant Reclassification in Clinical Pipelines
Zetobit Bioinformatics Insight Series · Clinical Genomics · June 2026
Clinical OperationsVariant Reclassification in Clinical Pipelines
Building reclassification workflows, amended-report logic, and re-contact policy into CAP/CLIA-compliant NGS pipelines
A clinical genomics report is often treated as a final answer. In practice, it is a snapshot — an interpretation made with the evidence available on the day it was signed out. Evidence accumulates. Population databases grow, functional studies are published, ClinVar submissions reconcile, and ACMG/AMP criteria are refined. A variant called a Variant of Uncertain Significance in 2022 may become pathogenic in 2026 — and that change can carry real clinical weight for the patient it was reported in.
For laboratories operating under CAP and CLIA, reclassification is not an optional courtesy. It sits at the intersection of pipeline design, quality management, and clinical ethics, and it is one of the most underbuilt parts of most clinical NGS operations. This piece walks through what a defensible reclassification program actually requires — technically and operationally.
Why reclassification is a systems problem
The instinct is to treat a reclassification as an isolated event: someone notices new evidence, the lab re-reviews, an amended report goes out. That works for a handful of cases. It does not scale to a lab running thousands of exomes or panels per year, where the relevant question is not "did this one variant change?" but "across every variant we have ever reported, which ones now warrant re-review — and how would we even know?"
That reframing has architectural consequences. A reclassification-ready lab needs three things a report-and-forget lab does not:
- A queryable archive of every reported variant, linked to the patient, report version, the classification at sign-out, and the exact evidence and criteria applied.
- A monitoring mechanism that periodically re-evaluates archived variants against current evidence sources.
- A governed decision process that decides which changes trigger re-review, which trigger an amended report, and which trigger patient re-contact.
Each has technical and policy dimensions, and the failure modes usually live at the seams between them.
The variant archive: design it for the question you'll ask later
Most LIMS and pipeline outputs store classifications, but few store the basis for a classification in a form you can re-interrogate. When a dispute or audit arises, "the variant was a VUS" is far weaker than "the variant was a VUS on 2022-03-14 under ACMG criteria PM2_Supporting and PP3, with gnomAD v2 allele frequency 0.0008 and no ClinVar entries above one star."
A reclassification-ready archive should capture, per reported variant:
- Genomic coordinates on an explicit reference build — GRCh37 vs GRCh38 matters here, as liftover ambiguity is a common source of reclassification error — plus transcript-level HGVS with the transcript and version pinned.
- The classification and the specific ACMG/AMP criteria codes invoked, including strength modifiers.
- The evidence values behind each criterion: population frequencies with database version, in-silico scores with tool version, functional study citations, segregation data.
- The knowledge-base versions in effect at sign-out: ClinVar release, gnomAD version, internal database snapshot.
- Report identifier, version, ordering provider, and date.
Version-pinning is the part labs most often skip and most often regret. If you cannot reconstruct what the world looked like when you made a call, you cannot cleanly explain why the call changed — and you cannot distinguish a genuine evidence shift from a pipeline or database-drift artifact.
If you cannot reconstruct what the world looked like when you made a call, you cannot explain why the call changed.
Monitoring: how variants get flagged for re-review
Once the archive exists, the monitoring layer answers "what changed?" A mature lab combines several triggers rather than relying on any one.
Scheduled batch re-evaluation
On a defined cadence — many labs use quarterly or biannual — the archived variant list is re-run against current evidence. The output is not a new classification; it is a delta report: variants whose underlying evidence has moved enough that the prior call may no longer hold. This is where automation earns its keep, because hand-reviewing every variant is infeasible, but a rules engine comparing stored evidence values against current ones is very tractable.
ClinVar and external database surveillance
ClinVar submissions are a leading indicator. A variant you called VUS that now carries multiple high-confidence pathogenic submissions is a clear re-review candidate. Subscribing to ClinVar's periodic releases and diffing against your archive catches these. The caveat: ClinVar is a submission aggregator, not an oracle — a hit is a trigger for human review, never an automatic reclassification.
Targeted reanalysis on clinical request
Providers sometimes request reanalysis when a patient's phenotype evolves or a new family member is tested. This is event-driven rather than scheduled, and the workflow should make it easy for a clinician to request and for the lab to fulfill without rebuilding the case from scratch.
The design principle across all three: monitoring produces candidates for human review, not classifications. The automation narrows the haystack; a qualified variant scientist or lab director still makes the call.
The decision tier: not every change is an amended report
A flagged variant enters a governed review process, and the outcome is genuinely tiered. A useful framing distinguishes three thresholds — defined in advance, in an SOP, not improvised per case:
Tiered review outcomes
The governance point: these thresholds should be defined ahead of time, with the lab director's sign-off authority and documentation requirements specified. Deciding case-by-case whether something "feels" report-worthy invites inconsistency — and inconsistency is exactly what a CAP inspector or a plaintiff's attorney looks for.
Re-contact: the hardest part, and it isn't technical
Re-contact — whether and how a patient learns their result has changed — is the most ethically and legally fraught element, and it is largely unsettled in professional consensus. A few realities worth being clear-eyed about:
What's actually true about re-contact duty
- No uniform US mandate establishes an affirmative, indefinite duty for labs to re-contact patients about reclassifications. Bodies including ACMG have issued points-to-consider rather than firm requirements, and responsibility is frequently shared between lab and ordering clinician.
- The lab usually has no direct patient relationship. Results flow to the ordering provider, who holds the clinical relationship — so a lab's obligation is often discharged by notifying that provider, with the downstream duty to reach the patient resting there. This should be made explicit in policy and requisition agreements, not assumed.
- Whatever the policy is, it must be stated and consistent. A lab that promises re-contact and fails to deliver has a problem; a lab that explicitly scopes its responsibility and follows that policy stands on far firmer ground.
The practical recommendation for most clinical and consulting clients: define the re-contact policy explicitly, communicate it in test documentation, build the operational capability to execute it (provider contact captured at order time, a mechanism to generate and route amended reports), and document every step when a reclassification occurs. The exposure here comes less from the reclassification itself than from a gap between what the lab said it would do and what it actually did.
How this maps to CAP/CLIA expectations
CAP's molecular and NGS checklists, and CLIA's general quality-system requirements, don't prescribe a specific reclassification algorithm — but they do expect defined, documented, and followed procedures across the lifecycle of a result. In practice, an inspector-ready program demonstrates:
- A written SOP covering the archive, monitoring cadence, review thresholds, and amended-report and re-contact policies.
- Evidence of execution — that scheduled re-evaluations actually happen on the stated cadence, with records.
- Traceability — that any amended report ties back to the specific evidence change that triggered it, the criteria reapplied, and who authorized it.
- Version control across pipeline and knowledge bases, so classification changes are attributable to evidence, not silent infrastructure drift.
The throughline: reclassification is a quality-system function. It belongs in the same conceptual space as proficiency testing and validation — a defined process, executed on schedule, with records that prove it happened.
A pragmatic starting point
Labs that haven't formalized this don't need to build everything at once. A sensible sequence:
- Capture basis-of-classification, not just the classification. The foundation; without it the rest is unreliable. Retrofitting evidence capture onto historical cases is painful, so prioritize making it true going forward.
- Stand up ClinVar-diff surveillance as the first monitoring layer — high-yield, relatively low-effort.
- Write the tiered-review and re-contact SOP before you need it, with the lab director and, ideally, counsel involved.
- Add scheduled batch re-evaluation once the archive is rich enough to support it.
Each step is independently valuable and independently inspectable, which makes the program easier to build incrementally and easier to defend.
Closing
Reclassification turns a clinical genomics lab from a system that produces answers into one that maintains them. That is a meaningful shift in responsibility, touching pipeline architecture, quality management, and clinical ethics at once. The labs that handle it well aren't the ones with the smartest algorithm — they're the ones that treated it as a designed, documented, governed process from the start, and built their archive so that years later they can still account for exactly why a classification changed.
Zetobit LLC Bioinformatics Insight Series · June 2026
Building or auditing a reclassification workflow?
Zetobit designs CAP/CLIA-compliant clinical pipelines, variant-archive architecture, and quality-system documentation for genomics labs.
→ contact@zetobit.com