Visit Website →
← Back to blog

HGVS Nomenclature: How to Read and Write Variant Names

August 28, 2026
HGVS Nomenclature: How to Read and Write Variant Names

HGVS nomenclature is the international standard for describing DNA, RNA, and protein sequence variants, maintained by the HGVS Variant Nomenclature Committee under HUGO. Every clinical or research variant description needs a reference sequence accession, a version number, and a description at the DNA level, formatted as accession.version:prefix.description. Skip the version number or the DNA-level anchor and you've created ambiguity a colleague, a database, or an FDA reviewer cannot resolve.

TL;DR:

  • Using accession and version numbers consistently ensures precise variant identification and avoids ambiguity across reports and databases.
  • Correct selection of reference sequence prefixes (g., c., r., p.) is critical, as mixing them leads to significant reporting errors.
  • Applying the 3' rule and normalization checks reduces discrepancies in indel descriptions, especially in repetitive sequences.
  • Automated validation tools and structured templates help enforce HGVS standards and prevent common mistakes in variant reporting.
  • Maintaining detailed records of HGVS version, date, and supporting references enhances report defensibility and consistency over time.

Table of Contents

What HGVS Nomenclature Covers and Why the Standard Exists

Labs use HGVS descriptions everywhere a variant needs to travel between systems: clinical reports, ClinVar submissions, pharmacogenomics annotations, and peer-reviewed publications. Without a shared syntax, the same substitution gets written five different ways across five labs, and cross-referencing becomes guesswork.

Governance sits with the HVNC, operating under HUGO's endorsement, which gives the standard the kind of institutional backing that ad hoc lab conventions never had. The specification now follows semantic versioning, with release notes tracking what changed and why, starting in 2024. That matters practically: a report generated under one version of the recommendations can differ subtly from one generated a year later.

A few habits keep reports defensible over time:

  • Always record which HGVS version and date informed the report's variant descriptions.
  • Store the accession.version alongside every variant, not just the transcript name.
  • Treat the HGVS site's recommendations as the tiebreaker when internal templates disagree with it.

The Format and Prefixes: g., c., r., p., and When Each Applies

Every HGVS description follows the same skeleton: reference sequence, a colon, then the variant description. NM_004006.3:c.4375C>T is the canonical example the HGVS background documentation uses, and it's worth memorizing the anatomy. NM_004006.3 is the versioned RefSeq transcript accession. c.4375C>T says position 4375 of the coding sequence changed from cytosine to thymine.

The prefix tells you the reference frame, and picking the wrong one is one of the more common errors in draft reports:

  • g. describes genomic DNA coordinates, referencing a chromosome or contig sequence such as NC_000023.11.
  • c. describes coding DNA, numbered from the A of the ATG start codon.
  • r. describes RNA, typically used when a variant's effect on splicing or transcript sequence needs explicit representation.
  • p. describes the protein consequence, always in parentheses when predicted rather than directly observed.
  • m., n., and o. cover mitochondrial DNA, non-coding RNA, and other specialized reference types.

A single missense variant might carry both a DNA-level and protein-level description: NM_004006.3:c.4375C>T paired with p.(Arg1459Ter). The parentheses aren't decorative. They flag that the protein consequence is predicted from the DNA change, not confirmed by direct protein sequencing, a distinction the general HGVS recommendations treat as mandatory.

Choosing the Right Reference Sequence and Why Versions Matter

Genomic accessions (NC_, NG_, LRG_) and transcript accessions (NM_, NR_) serve different purposes, and conflating them is where a lot of reporting errors start. NC_000023.11 anchors a variant to a specific chromosome build. NM_004006.3 anchors it to a specific transcript. Neither is a duplicate of the other; they're different coordinate systems that need to agree.

The version number after the decimal isn't cosmetic. RefSeq accessions get revised, and a coordinate that's correct under NM_004006.3 can shift under NM_004006.4 if the transcript model changed. A description missing that version number leaves a downstream reader guessing which sequence build the coordinates actually match.

A few reference-selection notes worth internalizing:

  • Pull accessions directly from NCBI's nucleotide database rather than copying them secondhand from an old report template.
  • LRG sequences exist specifically because locus-based references don't shift with genome assembly updates, which is valuable for variants tracked over years of clinical follow-up.
  • MANE (Matched Annotation from NCBI and EMBL-EBI) has become the practical answer to "which transcript should we default to," harmonizing RefSeq and Ensembl selections so labs stop debating which isoform is canonical.

Reading and Writing Variant Positions: Numbering, Ranges, and the 3' Rule

Coding DNA numbering starts at 1, and that 1 is always the A of the ATG start codon, per the HGVS simple background guide. Anything upstream of that A gets a negative number with a c.- prefix; anything past the stop codon gets a c.* prefix. Intronic positions use a different convention entirely: c.530+6 means six bases into the intron following coding position 530, while c.531-23 means 23 bases before the following exon starts.

Ranges use an underscore, not a hyphen, so a deletion spanning two positions reads as c.75_77del, never c.75-77del.

The 3' rule resolves a genuinely tricky problem: when an indel sits in a repetitive sequence, multiple positions could technically describe the same deletion. The rule mandates that the variant be placed at the most 3' position possible along the reference sequence, so every lab lands on the identical description regardless of how their alignment algorithm processed it.

  1. Identify the reference sequence and confirm its version.
  2. Locate the variant's most 3' equivalent position if it sits in a repeat or homopolymer.
  3. Apply the correct prefix and confirm parentheses are used for predicted (not confirmed) protein consequences.

Pro Tip: Run every variant description through an automated normalization check before it reaches a report template. Manual 3' rule application is where a surprising number of discordant ClinVar submissions originate.

Where Reports Go Wrong: Pitfalls and a Practical Checklist

The single largest source of ambiguity in variant reports is a missing accession.version or an unstated transcript. A report that says "c.4375C>T" with no reference attached is not a complete HGVS description. It's a fragment that means nothing outside the lab that wrote it.

A second recurring error: reporting only the protein consequence. A p.(Arg1459Ter) with no accompanying DNA-level description violates the core HGVS recommendation that DNA is the primary description, and protein notation is supplementary. Automation pipelines sometimes strip parentheses during formatting too, which silently converts a predicted consequence into what reads like a confirmed one.

A working checklist for any report leaving your lab:

  • Accession and version number present for every variant.
  • Transcript explicitly named, not implied by convention.
  • HGVS specification version or date referenced somewhere in methodology notes.
  • Parentheses preserved around predicted protein consequences.
  • A link to supporting evidence (ClinVar, internal validation data) where relevant.

Reports missing the reference sequence entirely are common enough that reviewers flag it as a top recurring defect in external audits of clinical variant reports, according to the HGVS reference-sequence guidance explaining how ambiguity compounds without it.

Turning HGVS Rules Into Lab Workflow: Templates, Validation, and Integrations

Rules on a webpage don't stop a tired reviewer from approving a report with a missing accession at 6 PM on a Friday. That's a workflow problem, not a knowledge problem, and it's solved with structure, not reminders.

Report templates should hard-require certain fields before a report can move to sign-off:

  • Accession.version field that can't be left blank.
  • Separate fields for c., g., and p. descriptions rather than one free-text box.
  • A transcript ID field distinct from the gene name.
  • A flag distinguishing predicted from confirmed protein consequences.

Validation gates matter as much as the fields themselves. Automated normalization that applies the 3' rule before a human ever reviews the variant catches inconsistencies that manual review misses. Integration with RefSeq and MANE lookups can auto-populate the correct transcript instead of relying on a reviewer's memory, and cross-links to ClinVar give reviewers instant context on prior classifications. Platforms like Labrynix build these checks directly into the reporting workflow, so the accession and version fields are structurally required rather than optional habits.

Pro Tip: Audit trails matter as much as validation rules. When a variant description changes between report versions, you need a timestamped record of what changed and under which HGVS specification version.

Naming Complex Variants: Inversions, Translocations, and Compound Indels

Simple substitutions are the easy case. Structural rearrangements test how well a lab actually understands the specification.

An inversion uses the inv suffix applied to a range: c.76_83inv describes an eight-base segment that flipped orientation. A deletion combined with an insertion, common in complex indels, uses delins: c.112_117delinsTG means six bases were deleted and replaced with a two-base insertion, which is different from writing separate del and ins events, since delins signals a single coordinated change.

Translocations require describing both breakpoints and referencing both chromosomes involved, since a single reference sequence can't capture a rearrangement spanning two loci. The convention places both derivative descriptions side by side, each anchored to its own genomic accession, connected with the specific nomenclature the HGVS recommendations define for chromosomal rearrangements.

Duplications get their own notation distinct from insertions: c.100_102dup means the three bases at 100 through 102 were copied and inserted immediately downstream, which is mechanistically different from an unrelated insertion at that position even though the resulting sequence might look similar on a quick read. Getting dup and ins confused is a subtle but real source of misclassification, since the two imply different mutational mechanisms even when the resulting sequence change looks identical on paper.

These complex cases are exactly where manual description breaks down fastest, and where automated normalization tools earn their keep, since a human eyeballing a 40-base rearrangement is far more likely to miscount a position than software applying the 3' rule programmatically.

HGVS Versus dbSNP and ClinVar: Different Jobs, Not Competing Standards

HGVS nomenclature, dbSNP identifiers, and ClinVar accession numbers solve different problems, and conflating them causes real confusion in reports.

An HGVS description like NM_004006.3:c.4375C>T tells you exactly what changed and where, referenced to a specific sequence. A dbSNP rs ID like rs28937894 is a population-level identifier assigned to a known polymorphism location, useful for cross-database lookup but silent on the actual sequence change unless you look it up. A ClinVar accession (an RCV number) identifies a specific submitted interpretation of a variant's clinical significance, tied to evidence and classification, not the sequence description itself.

The practical takeaway for report authors: HGVS format is the primary, unambiguous description of what changed. rs IDs and RCV numbers are secondary identifiers useful for tracing a variant's history across databases, but they should never replace the HGVS description in a clinical report. A report that cites only an rs ID has told the reader a population frequency exists somewhere, not what actually happened to the sequence.

How Databases Use HGVS Descriptions for Interpretation

ClinVar, gnomAD, and clinical variant databases all key their records to HGVS descriptions because it's the only format precise enough to unambiguously match a submitted variant against existing records. When a lab submits a classification to ClinVar, the HGVS description is what determines whether that submission gets matched to an existing record or creates a new one.

This is where reference sequence consistency stops being a theoretical concern. If your lab describes a variant against NM_004006.3 and a database record uses NM_004006.4, an automated matching system may not recognize them as the same variant unless it explicitly cross-maps versions. The HGVS background documentation notes that a single variant can have multiple valid descriptions depending on the reference used, and the safest practice is publishing the accession.version alongside cross-mapped coordinates (both c. and g. descriptions, for instance) so downstream systems can reconcile it regardless of which reference they default to.

Research databases lean even harder on this precision. A GWAS dataset referencing thousands of variants across multiple studies depends entirely on consistent HGVS formatting to merge records without manual curation, and inconsistent reference sequences across studies are a genuine barrier to meta-analysis.

Recent Changes to HGVS Recommendations and What They Mean for Labs

The move to semantic versioning starting in 2024 changed how labs need to think about the specification itself. Instead of a single evolving document, HGVS now issues discrete, numbered releases with changelogs, so a lab can state precisely which version informed a given report's nomenclature decisions.

That precision matters because recommendations do shift. Clarifications around parentheses usage for predicted protein consequences, guidance on complex indel notation, and refinements to how intronic positions near exon boundaries get numbered have all been addressed in recent updates documented on the HGVS recommendations site. A lab running report templates built five years ago may be technically non-compliant with current guidance without realizing it.

The practical impact on variant interpretation is real: a variant reclassified under updated nomenclature rules isn't necessarily a different variant biologically, but if the description format changed, automated matching against ClinVar or internal databases can fail silently unless someone is tracking version drift. This is precisely why the HGVS site's community forum exists, so labs facing an edge case (an unusual rearrangement, an ambiguous numbering scenario) can get guidance from the committee rather than guessing and creating yet another inconsistent local convention.

Recent Changes to HGVS Recommendations and What They Mean for Labs — overview diagram

What Strict HGVS Adherence Actually Buys a Lab

Precise nomenclature isn't bureaucratic overhead. It's the difference between a variant report that a second lab can independently verify and one that requires a phone call to clarify. Labs that treat accession capture and version tracking as optional discover the cost later, usually when a discordant classification surfaces during a ClinVar cross-check or a re-analysis years after the original report shipped.

The labs that get this right tend to build the discipline into their software rather than their staff's memory. Checklists help until someone is busy; structural requirements in a reporting template don't have that failure mode. If there's one habit worth adopting from this guide, it's treating the accession.version field as non-negotiable, then verifying the rest against the HGVS site whenever an edge case shows up.

— Tarek

Enforcing HGVS Compliance Without Adding Reviewer Workload

Manually policing accession fields, transcript IDs, and parenthesis placement across every report doesn't scale once your lab's variant volume grows, and that's exactly the gap Labrynix was built to close. Labrynix structures report templates so accession.version, transcript ID, and predicted-versus-confirmed markers are required fields, not habits reviewers have to remember.

Labrynix

Automated normalization checks catch 3' rule violations before a variant reaches sign-off, and integrations with RefSeq and ClinVar cross-links give reviewers immediate context without leaving the report screen. Every change carries an audit trail, so if a description shifts between report versions, there's a timestamped record of exactly what changed and why. For labs weighing what standardized reporting infrastructure actually looks like in practice, the Labrynix solutions overview walks through how templates, validation gates, and integrations fit together, and the team can walk you through a hands-on demo of how it applies to your specific reporting volume.

Where to Verify HGVS Rules and Find Canonical Examples

Keep these bookmarked for edge cases this guide doesn't cover:

This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.

Sources