How many of your lab's current VUS classifications are quietly wrong? A 2024 study in Heart Rhythm reviewed real-world genetic testing records from 517 patients and found that 32.2% of VUS variants were reclassified on re-review, with 12.6% upgraded directly to pathogenic or likely pathogenic, changing patient management in those cases (1). A separate 2025 study in Heart Rhythm by researchers at Texas Children's Hospital and Baylor College of Medicine, focused specifically on pediatric probands tested for arrhythmia syndromes, found that 60% of VUS changed classification on re-analysis — in either direction. The same study noted that the proportion of VUS in their genetic test results grew from 9.3% to 29.9% as panel sizes expanded.
That means somewhere between 1 in 4 and 1 in 3 of your uncertain variants will eventually matter clinically. The question is whether your lab has a system to determine when, or whether those reclassifications are accumulating in ClinVar, disconnected from the patients who need to know. And somewhere in your lab right now, there's a Google Sheet tracking variant classification. Someone updated column G last Tuesday. No one logged why. Your CAP inspector arrives in nine weeks.
If that scenario made you uncomfortable - good. That discomfort is the exact moment when most labs start seriously considering a variant knowledge management system. We've seen it play out across US-based genomics labs in oncology, rare disease, and hereditary testing. The spreadsheet works beautifully until it doesn't. And when it stops working, it stops at the worst possible time: during an audit, after a reclassification, or when a senior analyst resigns, taking institutional memory with them.
This article is a practical guide that covers what a Variant KMS actually is (not a LIMS, not a pipeline), why the ACMG/AMP framework sets the design requirements, what the architecture looks like in production, and how to make the build vs. buy call honestly.
Most labs don't start with a spreadsheet by choice. They start with six pathologists, a shared OneDrive folder, and the best intentions. Three years later, they have four spreadsheets, one per variant type, a fifth for legacy variants before we reorganized, and a sixth someone created during a rush clinical case that never got merged.
CAP checklist item MGL.40900 requires documentation of who classified a variant, what evidence was used, and when the classification was last reviewed. "Last modified: J. Smith" in a spreadsheet footer doesn't satisfy this. During inspections, labs routinely scramble to reconstruct decision histories from email threads and Slack messages.
ACMG guidance recommends annual reclassification review for all VUS variants. Studies show 5–10% of VUS variants reclassify to pathogenic or likely pathogenic within three years. A lab with 8,000 VUS entries in a spreadsheet lacks mechanisms to schedule, queue, or track those reviews — so patient-relevant reclassifications are missed.
gnomAD v4.1 is meaningfully different from v2.1. A variant you classified as likely benign using a v2.1 allele frequency may now cross the BA1 threshold in v4.1 or fall below it. A spreadsheet has no version-aware database sync layer. The classification silently ages out of validity.
Variant spreadsheets often contain patient cross-references, accession numbers, MRN linkages, or sample identifiers tied to PHI elsewhere. Shared drives, CSV email attachments, and unmanaged file copies are recognized HIPAA breach vectors. Insufficient access controls and inadequate audit logging carry significant HIPAA penalties.
When variant knowledge lives in spreadsheets owned by two senior analysts, your interpretation throughput is capped by those two people. Vacation, turnover, or a volume spike collapses the pipeline instantly.
If any of the failure modes above feel familiar, we should talk before your next CAP cycle.
Tell me how NonStop approaches this ↗A Variant Knowledge Management System is the system of record for the interpretive layer of genomics — what a variant means clinically, what evidence supports that meaning, who made the determination, and how it has changed over time.
It is not your LIMS. Your LIMS tracks samples, workflows, and the chain of custody. It is not your variant calling pipeline. Your pipeline produces VCF output. The KMS is what happens after the VCF lands.
The accumulation, versioning, and governance of clinical knowledge about every variant your lab has ever seen. Most labs have strong LIMS and pipeline coverage. The KMS is the piece that's almost always missing.
| System | Primary Function | Key Data Stored | Compliance Role |
|---|---|---|---|
| Variant KMS | Interpretive knowledge governance | Classifications, evidence codes, reclassification history, ACMG rationale | CAP MGL.40900, CLIA subpart K, HIPAA PHI layer |
| LIMS | Sample and workflow tracking | Accession records, QC metrics, test orders, chain of custody | CLIA general laboratory requirements, 21 CFR Part 11 |
| Bioinformatics Pipeline | Variant calling and annotation | Raw reads, alignment files, VCF output, QC flags | Pipeline version control for CAP reproducibility |
A lab needs all three. Most labs have strong LIMS and pipeline coverage. The KMS is the piece that's almost always missing or living in a spreadsheet.
If you’ve read the Standards and Guidelines for the Interpretation of Sequence Variants (4), you know it defines classification logic and evidence codes.What it doesn’t define is how to implement this in a system.Below is how those guidelines translate into real operational requirements:
| Classification | Clinical Meaning | Evidence Codes | What Your System Must Handle |
|---|---|---|---|
| Pathogenic | Strong evidence variant causes disease | PVS1, PS1–PS4 | Store full evidence trail, classification rationale, submitter info, timestamps, external database links (e.g., ClinVar) |
| Likely Pathogenic | High probability of pathogenicity | PS, PM, PP combinations | Track confidence level, supporting evidence, review status, and enable easy upgrade/downgrade of classification |
| VUS | Conflicting or insufficient evidence | PM, PP | Maintain conflict logs, evidence history, reclassification workflows, and periodic review tracking |
| Likely Benign | High probability of benign impact | BS, BP | Track population frequency data (e.g., gnomAD), supporting benign evidence, and versioned data sources |
| Benign | Strong evidence variant is not disease-causing | BA1, BS | Record allele frequency thresholds, justification, and source/version of datasets used |
ACMG/AMP gives the rules, but your system still needs to manage the operational complexity at scale:
The Standards and Guidelines for the Interpretation of Sequence Variants explain how to classify a single variant, but in practice, labs deal with thousands of variants, continuous data updates, and ongoing reclassification. At that scale, it’s no longer just about applying guidelines - it becomes a system design problem.
VCF parser with pipeline-version tagging. HL7 FHIR specimen input from LIMS. Sample-agnostic design so a v1.2 and v2.0 pipeline VCF for the same variant reconcile cleanly.
Local versioned mirrors of ClinVar, gnomAD, OMIM, dbSNP, ClinGen. Never query external APIs with patient data in the request — that's a HIPAA exposure point most teams miss.
ACMG evidence code mapper. Conflict resolution logic with documented tie-breaker rules. AI-assisted pre-classification suggestion layer with mandatory pathologist override on every final call.
Clinical report API. Pathologist reviews UI with the evidence panel. EHR push via SMART on FHIR. LIMS write-back. ClinVar submission batch queue.
Clinical report API. Pathologist reviews UI with the evidence panel. EHR push via SMART on FHIR. LIMS write-back. ClinVar submission batch queue.
HIPAA audit log on every PHI-touching state change. Role-based access with PHI isolation. SOC 2 Type II access controls throughout.The annotation engine detail above trips up almost every homegrown build: sending variant queries directly to the ClinVar or gnomAD API while a patient identifier is in the session context is a potential HIPAA exposure. The right design caches local versioned copies of each database and syncs on a schedule - weekly for ClinVar, on major release for gnomAD. Every classification record then stores which version of each database it was made against. That's what makes the record auditable.
Our scoped architecture review takes 30 minutes and gives you a clear map of what your lab specifically needs to build.
There are many commercial options available in the market. If your lab is processing germline-only variants at moderate volume and doesn't have unusual LIMS integration requirements, they're worth evaluating seriously.
But here's when commercial platforms don't fit:
Use a commercial annotation layer for ClinVar/gnomAD sync, build the classification engine, custom reporting, and LIMS write-back. That pattern avoids reinventing commodity infrastructure while giving the lab control over the interpretive layer — the part that's actually proprietary to their clinical practice.
The variable that moves the timeline most is LIMS integration complexity, not the KMS core itself.
NonStop has built production Variant KMS platforms for US-based genomics leaders, including a lab that went from four disconnected spreadsheets to a CAP-audit-ready, HIPAA-compliant KMS in 18 weeks. We offer a free 30-minute architecture review where we map your specific variant types, LIMS, and EHR stack to a clear build/buy/hybrid recommendation. No pitch. Just an honest map.
Schedule your free 30-min review →A LIMS manages sample workflow and chain of custody. A Variant KMS manages the interpretive knowledge produced after the sample is processed — classifications, evidence rationale, reclassification history, and database sync records. They serve different compliance requirements and are complementary, not interchangeable. Most labs need both.
Volume isn't the trigger — complexity and compliance are. A lab classifying 200 unique variants per year across five gene panels still needs an immutable audit trail, annual VUS review scheduling, and versioned database citations to satisfy CAP MGL.40900. Spreadsheets struggle with all three regardless of volume.
At minimum: HIPAA Security Rule (for the PHI layer of variant-patient linkage), CAP checklist MGL.40900 (variant classification documentation and reclassification tracking), and CLIA subpart K (testing personnel and result reporting). Labs handling EU patient data additionally need a GDPR-compliant data architecture. Each of these standards has direct implications for KMS database design, audit logging, and access control.
The KMS should trigger an HL7 FHIR notification to the connected EHR when a VUS reclassifies to Pathogenic or Likely Pathogenic. This is increasingly treated as a patient safety requirement — several CAP accreditation programs explicitly ask how labs communicate reclassifications to ordering providers. The notification workflow is typically a separate module built on the KMS output API.
Based on NonStop's deployments: MVP in 8–10 weeks, CAP/CLIA-ready production in 16–20 weeks, full EHR and LIMS integration in 20–28 weeks. The primary variable is the complexity of LIMS integration. Labs with standard LIMS (LabVantage, Orchard) typically reach production faster than labs with heavily customized or legacy LIMS environments.
NonStop is a HIPAA-, SOC 2 Type II-, HITECH-, and GDPR-certified engineering partner specializing in genomics lab platforms. We have built production Variant KMS systems, bioinformatics pipeline deployment infrastructure, AI-assisted variant interpretation tools, and EHR/LIMS integration layers for US-based diagnostics leaders.
Our team of 130+ engineers operates from Pune, India and Dover, Delaware, giving you the cost structure of offshore development with the compliance oversight of a US-anchored partner. The next CAP inspection cycle starts sooner than you think. Let's make sure your variant knowledge system is ready for it.
Talk to NonStop about your Variant KMS ↗
