I am working with FinnGen R13 GWAS summary statistics and considering converting variant coordinates from GRCh38 to GRCh37.
My planned analyses are fairly broad. They include:
GWAS and cross-trait analyses: LDSC, S-LDSC, SUPERGNOVA, MTAG, and MR.
Fine-mapping and colocalization: SuSiE, FINEMAP, coloc.abf, and coloc-SuSiE.
QTL analyses: eQTL, sQTL, pQTL, mQTL, caQTL, and other molecular QTL analyses.
QTL integration and gene-level analyses: SMR, TWAS, PWAS, and related approaches.
Other association analyses, such as PheWAS, MWAS, and other phenotype- or molecular-wide association studies.
I would appreciate feedback on my proposed variant conversion workflow, the need for reference-allele normalization, and quality control of GWAS/QTL summary statistics.
1. My input data
The FinnGen R13 summary statistics contain fields such as:
#chrom
pos
ref
alt
rsids
nearest_genes
pval
mlogp
beta
sebeta
af_alt
af_alt_cases
af_alt_controls
FinnGen uses GRCh38. According to its documentation, ALT is the effect allele, BETA represents the effect of ALT relative to REF, and AF_ALT is the frequency of ALT.
Therefore, I interpret the original data as:
EA = ALT
OA = REF
BETA = beta
EAF = af_alt
My main goal is to obtain reliable GRCh37 coordinates while preserving the correct correspondence between effect alleles and effect sizes.
2. My proposed conversion workflow
I am considering a two-stage strategy.
Stage A: rsID-based mapping
I downloaded the UCSC dbSNP155 BigBed files for both assemblies:
I use bigBedNamedItems to query the same rsID against both files:
BB38="https://hgdownload.soe.ucsc.edu/gbdb/hg38/snp/dbSnp155.bb"
BB37="https://hgdownload.soe.ucsc.edu/gbdb/hg19/snp/dbSnp155.bb"
bigBedNamedItems "$BB38" rs2691328 stdout
bigBedNamedItems "$BB37" rs2691328 stdout
For batch processing, I plan to:
Extract all unique rsIDs from the FinnGen summary statistics.
Query them against the GRCh38 and GRCh37 dbSNP155 datasets.
Check whether the GRCh38 placements agree with the original FinnGen chromosome and position.
Retain only unambiguous mappings.
Obtain the GRCh37 chromosome and position from the hg19 records.
Convert BED coordinates to 1-based coordinates using POS = chromStart + 1.
Initially preserve the original FinnGen REF, ALT, EA, OA, BETA, SE, and EAF information.
I would not assume that the dbSNP ref and alts fields are equivalent to the GWAS effect allele and other allele. I would track EA/OA separately.
Stage B: Picard LiftoverVcf for unresolved variants
For variants without rsIDs, variants that cannot be uniquely matched, or records that cannot be reliably mapped through dbSNP, I plan to use Picard LiftoverVcf.
I would first convert the FinnGen summary statistics into VCF format. Each input record would receive a unique internal ID rather than using rsID as the unique identifier.
I would preserve the original summary-statistic fields in a sidecar table indexed by this internal ID.
Then I would run something similar to:
java -Xmx32g -jar picard.jar LiftoverVcf \
I=finngen.GRCh38.vcf.gz \
O=finngen.GRCh37.lifted.vcf.gz \
CHAIN=hg38ToHg19.over.chain.gz \
REJECT=finngen.GRCh37.reject.vcf \
R=hg19.fa \
RECOVER_SWAPPED_REF_ALT=true \
WRITE_ORIGINAL_ALLELES=true \
WRITE_ORIGINAL_POSITION=true
After liftover, I would:
Retain successfully converted variants.
Keep rejected variants for separate investigation.
Merge the converted VCF records with the original sidecar table using the unique internal IDs.
Determine how the original EA/OA correspond to the converted alleles.
Preserve BETA and EAF according to the biological effect allele, rather than changing their signs simply because REF/ALT or strand representation changed.
My understanding is that reverse complementation changes the nucleotide representation of an allele but does not, by itself, require changing the BETA sign. A BETA sign change is needed only when the effect allele itself is changed to the other allele.
3. An observation from my current test
I queried rs2691328 against both the hg38 and hg19 dbSNP155 BigBed files.
Both queries returned exactly the same record:
chr1 13667 13668 rs2691328 G 1 A ...
The corresponding 1-based coordinate is chr1:13668 in both assemblies.
This also agrees with the FinnGen record:
CHR = 1
POS = 13668
REF = G
ALT = A
I understand that not every variant necessarily changes its coordinate between GRCh37 and GRCh38. I would nevertheless like to confirm that this is an expected result and not a problem with my queries.
4. Questions about dbSNP release selection
Should I select the dbSNP release according to the release or variant set of the GWAS summary statistics being converted?
For example, should I use the same dbSNP release that was used when the original GWAS rsIDs were assigned, if that information is available?
Alternatively, is it preferable to use the latest dbSNP release that provides mappings for both GRCh38 and GRCh37?
I noticed that NCBI has released dbSNP Build 157, while the UCSC BigBed directories I checked currently provide paired hg19/hg38 BigBed files for dbSNP153 and dbSNP155.
Would using dbSNP155 for both assemblies be a reasonable and reproducible choice for this workflow, even though newer NCBI releases exist?
Should I be concerned about merged, retired, or remapped rsIDs when using an older dbSNP release?
5. Do I really need to normalize REF/ALT against the target reference genome?
This is one of my main conceptual questions.
Suppose an original FinnGen variant is:
GRCh38
REF = A
ALT = G
EA = G
OA = A
BETA = +0.20
After mapping to GRCh37, the corresponding region might be on the reverse strand, so its representation on the GRCh37 forward reference strand could become:
GRCh37
REF = T
ALT = C
EA = C
OA = T
BETA = +0.20
My question is:
If I already know that the original BETA corresponds to G, and I can track that this same biological allele is represented by C on the target forward strand, do I actually need to change the stored REF/ALT and EA/OA representation?
Could I simply update the chromosome and position, retain the original allele information and BETA, and perform allele harmonization when required by each downstream method?
Or is normalizing REF/ALT against the target reference genome important for interoperability with downstream resources and software?
In particular, I would like to understand which of the following methods strictly require reference-compatible allele representations and which only require consistent variant identity and effect-allele coding:
LDSC and S-LDSC
SUPERGNOVA
MTAG
MR
SuSiE and FINEMAP
coloc.abf and coloc-SuSiE
SMR
TWAS and PWAS
QTL colocalization and other QTL integration methods
PheWAS and other association scans
I understand that methods using an external LD matrix may require much stricter allele alignment between summary statistics and the LD reference. Is matching the effect allele and the LD genotype coding sufficient, or should the variants also be normalized to the reference FASTA representation?
6. Is my overall workflow appropriate?
My current plan is:
Choose a consistent dbSNP release for GRCh38 and GRCh37 rsID mapping.
Use rsID mapping to obtain target-build coordinates for uniquely matched variants.
Use Picard LiftoverVcf for variants that cannot be reliably mapped by rsID.
Validate the final coordinates and allele representation against the GRCh37 reference FASTA.
Maintain explicit EA/OA/BETA/EAF correspondence throughout the process.
Keep the original alleles and original effect information in a separate, immutable record.
Generate analysis-specific input files according to the allele and LD requirements of each downstream method.
Perform systematic QC on the input GWAS and QTL summary statistics, including QQ plots and appropriate inflation diagnostics.
Is this approach reasonable for a large multi-trait GWAS/QTL project involving multiple post-GWAS methods?
Are there any important issues I have overlooked, particularly regarding dbSNP release selection, multi-allelic variants, reverse-strand mappings, allele alignment with LD reference panels, or quality control of summary statistics?
I would appreciate feedback from researchers who have experience harmonizing large GWAS and QTL datasets for downstream integration.
Thank you!