Sample Identity and SNP Matching in WGS/WES

Most pipeline failures are loud. Alignment crashes on a corrupt FASTQ. Variant calling stalls on a truncated BAM. Coverage comes back at 3x instead of 100x and every downstream QC gate lights up red. A sample swap does none of this. The reads align cleanly, coverage looks fine, variants get called, and ACMG rules apply without complaint - the pipeline has no way to know it is looking at the right genome, only that it is looking at *a* genome. The output is a confident, well-formatted, entirely wrong answer attached to the wrong patient.

The mix-up almost never happens at the obvious step. It happens in the gaps between systems that do not talk to each other.

• Index collision in a multiplexed run: two libraries share an i5/i7 barcode combination closely enough that demultiplexing misassigns a fraction of reads
• A relabeled aliquot between DNA extraction and library prep, where the physical tube and the LIMS record diverge and nobody notices until results come back
• A sample sheet built by hand for a run, where one row is shifted relative to the physical plate layout
• A re-run or re-sequence of the same patient months later, submitted under a new sample ID with no link back to the original record

You do not need to compare two entire VCFs to confirm two sequencing runs came from the same person - and for a WGS/WES pair you could not, even if you wanted to. Instead, identity checking uses a small, fixed panel of a few thousand common, high-heterozygosity SNPs as a fingerprint, and measures the genotype concordance rate between two runs at those exact positions. Two runs from the same individual typically concord above 99%; unrelated individuals land near the 50% rate you would expect from chance allele sharing.

The WGS/WES-specific constraint

A fingerprint panel built for whole genome data is often intergenic or intronic, because that is where most common SNPs sit. Whole exome data was never sequenced there - there is no read coverage to compare against. Matching a WGS run against a WES run on the same patient only works if the fingerprint panel is restricted to sites that fall inside the exome capture footprint shared by both. This is the detail that trips up a same-patient, cross-platform check even when a same-platform, same-patient check works perfectly.

# Example: pairwise genotype concordance between a WGS and a WES VCF,
# restricted to a fingerprint panel intersected with the WES capture BED
bcftools isec -n=2 fingerprint_panel.vcf.gz capture_regions.bed.gz -O z -o usable_panel.vcf.gz

bcftools gtcheck \
  -g wes_sample.vcf.gz \
  usable_panel.vcf.gz \
  | grep -v "^#"

# Discordance score near 0 = same individual; a high score flags a mismatch
# before the sample reaches variant interpretation, not after

A SNP fingerprint confirms two runs match each other. It does not confirm either run matches the person named on the requisition form. Two cheap, independent signals catch what fingerprinting alone cannot.

• Genetic sex from X chromosome heterozygosity: a sample recorded as female with near-zero heterozygosity across chrX is either mislabeled or carries a finding that needs its own workup, not a silent pass-through
• Kinship coefficients for trio or family studies: a "mother" sample that does not share roughly half its genome with the proband is not the mother in the pedigree you think it is
• Both checks run in minutes on data you already have and catch errors that would otherwise surface only when a clinician notices a result does not fit the patient

A related but distinct check projects a sample's genotypes onto principal components built from a reference panel - typically 1000 Genomes or gnomAD - to place it near one or more reference superpopulations. This is genuinely useful for one specific purpose: picking the right population-frequency column when you filter variants, since a variant that is common in one population and rare in another will mislead ACMG frequency-based rules (BA1, PM2) if the wrong reference is used.

It is not a genealogy result and should never be reported as one. PCA-based ancestry resolves to broad superpopulation clusters, not countries, tribes, or recent family history, and samples with mixed or underrepresented ancestry can land ambiguously between clusters. Treat it as a QC input for variant filtering, not a finding to hand to a patient.

A fingerprint check that runs "when someone remembers" catches nothing, because the whole point of a silent failure is that nothing prompts anyone to remember. It needs to be a mandatory gate in the pipeline itself, positioned before interpretation, not an optional script someone runs after a result already looks suspicious.

The gate only has to answer one question before anything downstream is trusted: does this genome match the identity on record for this sample. Everything else in a WES or WGS pipeline assumes the answer is yes.