Why Genome Builds Matter
An imputation method uses observed study variants to locate corresponding variants and haplotypes in a reference panel. That comparison depends on knowing where each variant lies in the reference genome. A position is therefore not a complete variant description by itself: it is a position on a specified genome assembly, also called a genome build.
Genome assemblies are reference sequences assembled from DNA. Different releases can represent the same chromosome with different sequence, gaps, or local structure. Consequently, a biological variant may have one coordinate in GRCh37 and another in GRCh38. The difference is not generally a constant offset across a chromosome, or even across a whole region. If study data and a reference panel use different builds, direct position matching can fail or, in some cases, connect records that are not the same variant.
In a VCF file, the POS field uses 1-based coordinates: the first base of a chromosome is position 1. Other formats, such as BED, commonly use 0-based, half-open intervals. Thus two files can describe the same location but show position numbers differing by one if their coordinate conventions are mistaken for one another. This is a coordinate-format issue, not necessarily a genome-build difference.
Build compatibility is separate from allele harmonization. Allele harmonization concerns whether allele labels and orientations agree; build matching concerns whether the records refer to the same reference assembly and genomic location. Both checks matter before imputation, but one does not substitute for the other. The earlier material on allele harmonization addresses allele orientation and representation.
What Must Match
A practical matching key for a normalized, biallelic variant is the tuple \((\text{chromosome},\text{position},\text{REF},\text{ALT})\), interpreted on a named build. For example, “chr2, 19,997,810, A, G” is not an assembly-independent identity. It is a record at that coordinate with those alleles on the build specified by the file or accompanying metadata. Chromosome naming conventions, such as “2” versus “chr2,” should also be made consistent before matching.
For matching by direct coordinates, the study data and reference panel need compatible build definitions, contig conventions, and coordinate conventions. Matching coordinates and alleles is useful evidence that records correspond, but it does not prove that every record has been prepared correctly. Conversely, different positions do not prove that two records represent different biological variants if they are on different builds.
Build labels need to be read from reliable metadata, not inferred from coordinate values or a file name alone. “hg19” is commonly used to refer to GRCh37, and “hg38” to GRCh38, but pipelines can differ in patch levels, contigs, and conventions. Confirm the exact assembly expected by the reference panel and by any conversion resource being used.
How Coordinate Conversion Works
A conversion tool uses an alignment between two assemblies to propose a target-build location for each source-build record. Conceptually, it applies a mapping \(f\) from source coordinates to target coordinates. This mapping is local and may not exist for every source position. Some positions map uniquely, some fail to map, and some have multiple possible target locations. The output must therefore be inspected rather than treated as a guaranteed one-to-one coordinate update.
The justification for converting before matching is straightforward. Suppose the study and panel records refer to the same biological locus, but the source and target assemblies place it at positions \(p_s\) and \(p_t\). Direct comparison tests whether \(p_s=p_t\), which need not hold. After conversion, comparison tests whether \(f(p_s)=p_t\), which is the relevant positional condition. This is necessary for coordinate-based matching, but it is not sufficient: chromosome, alleles, representation, and reference sequence still need checking.
A reliable workflow checks the conversion outcome and validates REF alleles against the target reference sequence when available. A REF disagreement can indicate a wrong build, an incorrect conversion, a strand or representation issue, a contig naming problem, or an input error. It is a warning to investigate—not an instruction to change alleles automatically. Indels and complex variants may require careful normalization because their record representation can depend on the surrounding reference sequence.
Worked Example: A Uniform Local Coordinate Shift
Consider hypothetical records from a study on GRCh37 and a reference panel on GRCh38. The records are biallelic SNPs, and the metadata confirms that chromosome naming and allele conventions are consistent. A validated conversion resource gives the mappings below.
| Study, GRCh37 | Panel, GRCh38 | Converted study position |
|---|---|---|
| chr2:20,000,100 A>G | chr2:19,997,810 A>G | 19,997,810 |
| chr2:20,000,250 C>T | chr2:19,997,960 C>T | 19,997,960 |
| chr2:20,000,400 G>A | chr2:19,998,110 G>A | 19,998,110 |
Before conversion, none of the three study positions equals the corresponding panel position. For the first record, for example, \(20{,}000{,}100 \ne 19{,}997{,}810\). After conversion, the position difference is \(20{,}000{,}100-19{,}997{,}810=2{,}290\) bases, and the converted study position equals the panel position. The same calculation gives \(20{,}000{,}250-19{,}997{,}960=2{,}290\) and \(20{,}000{,}400-19{,}998{,}110=2{,}290\).
Thus, in this small hypothetical region, all three converted coordinate-and-allele keys match. The repeated difference is a feature of these illustrative records only; it must not be used as a general build-conversion rule. The conversion is accepted here because the records map as expected and their allele records agree, not because a fixed offset has been assumed.
Diagnosing Coordinate Mismatches
A surprisingly small overlap between study variants and a panel can be a clue to incompatible builds, but it is not a diagnosis by itself. First verify the build metadata for both data sets. Then check chromosome naming, coordinate convention, and whether positions are reported in the same units and format. Only after these checks should differences be attributed to missing panel variants or other biological and technical causes.
Worked Example: Testing an Unexpectedly Low Direct Overlap
Suppose five hypothetical study records are documented as GRCh37, while five panel records are documented as GRCh38. Their alleles correspond, and a validated conversion gives the positions shown below. For this simple diagnostic, define the overlap fraction as the number of study keys matched in the panel divided by the five study keys being checked.
| Study position, GRCh37 | Panel position, GRCh38 | Converted position |
|---|---|---|
| chr6:10,100 A>C | chr6:10,050 A>C | 10,050 |
| chr6:10,200 C>T | chr6:10,150 C>T | 10,150 |
| chr6:10,300 G>A | chr6:10,250 G>A | 10,250 |
| chr6:10,400 T>C | chr6:10,350 T>C | 10,350 |
| chr6:10,500 A>G | chr6:10,450 A>G | 10,450 |
A direct coordinate-key comparison gives \(0\) matches among \(5\) study records, so the direct overlap fraction is \(0/5=0\). After conversion, the five positions equal the corresponding panel positions and the allele keys agree, giving \(5/5=1\), or 100% in this illustrative set. This sharp change, together with confirmed build metadata and valid mappings, supports a build mismatch as the explanation for the poor direct overlap. It does not establish that the full data sets are error-free.
A different pattern can point to a coordinate-format issue instead. For example, if a study VCF lists a 1-based POS of 8,400,021 and a BED interval starts at 8,400,020, the positions may describe the same first base because the BED start is 0-based. Check the format specification before treating that one-base difference as a build mismatch.
Worked Example: What to Do With Uncertain Mappings
A hypothetical study has three GRCh37 records. A conversion attempt reports: (1) chr9:100,000 A>C maps uniquely to chr9:98,765 on GRCh38; (2) chr9:120,000 C>T has two possible target locations; and (3) chr9:150,000 G>A has no target location. The panel contains chr9:98,765 A>C.
Record 1: The unique mapping reaches the panel position, and the alleles agree. It is a candidate coordinate match. Confirm the target REF allele and the remaining file conventions before using it.
Record 2: Two possible locations do not define a unique coordinate transformation. Do not choose one simply because it creates a panel match; investigate the conversion output and reference context. Until resolved, this record is not a confirmed coordinate match.
Record 3: No target location was returned, so no coordinate-based match can be established by this conversion. The failure may reflect assembly differences or limitations of the mapping, among other causes. Do not invent a target position.
Of the three records, one has a unique, provisionally matching location, one is ambiguous, and one is unmapped. The usable confirmed count is not automatically three, nor should the latter two be forced into the panel. This example shows why conversion results need statuses and validation, not only a new position column.
A Practical Check and Common Pitfalls
Record the study and panel build from trusted metadata, along with any patch, contig, and coordinate-format details that affect interpretation.
Standardize chromosome names and confirm whether positions are 1-based or 0-based before comparing records.
If builds differ, use an appropriate source-to-target mapping or obtain a compatible panel or study file. Retain mapping status and original coordinates.
Check unique mappings, target positions, and REF alleles against the target reference where possible. Resolve warnings rather than silently discarding or modifying records.
Compare chromosome, converted position, and allele representation only after build and convention checks. Keep build compatibility separate from allele harmonization.
A common mistake is to see that a study and panel have different position numbers and add or subtract one constant from every study coordinate. The reasoning is wrong because assembly changes are not generally uniform, and local mappings may be ambiguous or absent. Use an assembly-aware conversion and validate its results; a guessed offset can produce plausible-looking but incorrect matches.
Another mistake is to interpret a low overlap as proof that the reference panel lacks the study variants. If builds or coordinate conventions differ, the variants may be present but fail direct key comparison. The alternative is to check metadata and matching conventions first, then examine genuinely unmatched variants. A third option is to use a panel on the study build, when available, which can avoid conversion—but it does not remove the need to verify the panel’s build and record conventions.
Build conversion also has limits. Some source positions cannot be mapped reliably, and some variants may not have a simple equivalent record on the target assembly. No method can make an ambiguous mapping unique merely by relabeling the build. Preserve a record of converted, ambiguous, and unmapped variants so later decisions are reproducible.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions below.
- A study record is at chr4:7,200,000 on GRCh37 and a panel record is at chr4:7,198,500 on GRCh38. Can the unequal positions alone show that the records are different variants?
- A VCF reports POS 31,001, while a BED interval starts at 31,000. What should be checked before calling this a build mismatch?
- A conversion tool reports two possible target positions for a study variant. Should the analyst choose whichever position matches a panel record? Why or why not?
- What does a low direct overlap between study and panel records establish if their build metadata has not been checked?
Solutions. (1) No. The positions are on different builds; convert to a common build and validate the resulting record before deciding whether they correspond. (2) Check the file formats and coordinate conventions: VCF POS is 1-based, whereas BED starts are commonly 0-based, so these values may refer to the same base. (3) No. A multiple-location result is ambiguous, and selecting a location because it creates a match would not validate the mapping. Investigate the conversion and reference context or leave the record unresolved. (4) It establishes only that few records matched under the comparison performed. Without build and convention checks, it does not distinguish a true absence of variants from a coordinate incompatibility.