Incorrect handling of odds ratio confidence interval when flipping alleles during harmonization

[trafalmadorian97]

Example:

Notice that how before GWASLAB harmonization, OR_95U is not equal to OR_95L, whereas after harmonization, both values are equal to one.

I believe the problem is here:

gwaslab/src/gwaslab/qc/qc_fix_sumstats.py

Lines 1633 to 1639 in 6e2527a

	if has_or_95l:
	log.write(" -Flipping column: OR_95U = 1 / OR_95L...", verbose=verbose)
	sumstats.loc[matched_index, "OR_95U"] = factor / sumstats.loc[matched_index, "OR_95L"].values
	if has_or_95u:
	log.write(" -Flipping column: OR_95L = 1 / OR_95U...", verbose=verbose)
	sumstats.loc[matched_index, "OR_95L"] = factor / sumstats.loc[matched_index, "OR_95U"].values

.

If both has_or_95l and has_or_95u are true, then OR_95U is updated using OR_95L, and then the new value of OR_95U is used to update OR_95L. Consequently, the old value of OR_95U is never used.

A solution would be to use a swap idiom:

    if has_or_95l:
        log.write(" -Flipping column: OR_95U = 1 / OR_95L...", verbose=verbose) 
        new_or95u=  factor / sumstats.loc[matched_index, "OR_95L"].values.copy()
    if has_or_95u:
        log.write(" -Flipping column: OR_95L = 1 / OR_95U...", verbose=verbose) 
        sumstats.loc[matched_index, "OR_95L"] = factor / sumstats.loc[matched_index, "OR_95U"].values
    if has_or_95l:
        sumstats.loc[matched_index, "OR_95U"] = new_or95u
         

I encountered this problem in gwaslab version 3.6.8, but I believe it still exists in the current version.

[Cloufield]

Thanks a lot for pointing out the bug. Indeed the logic here was wrong.
I just fixed it and update to v4.1.2.