Credible set contains inconsistent NULLs in the locus column

Community Feedback
1

Hello,

I noticed that many credible sets have a problem, where pValueMantissa and pValueExponent columns contain non-NULL values, while when you look up the lead variant in the locus column, you see NULL values despite it’s the same variant. At the same time, beta always matches between the beta column and the corresponding value in the locus column. Example studyLocusId to reproduce: c6a7aaa880e5ccbebb1ed0d52ecf5f9e

You can see the bug both in the downloadable files and on the OT platform page. E.g., on Credible set around 17_42416098_T_C for UKB_PPP_EUR_AARSD1_Q9BTE6_OID21311_v1 | Open Targets Platform (same locus as above), you can see P-value: 7.680×10-17 in the top widget, but NULL in the “Credible Set Variants” one.

2

Hi @Stepan_Nersisyan,

This is an artefact of our current fine-mapping/ingestion pipelines. Depending on whether the credible set is susie, susie-inf, or PICS, it may have different information available in the locus object for each variant. In the example you provided, it is a UKB-PPP credible set which we fine-mapped ourselves with susie-inf. This means that the ‘beta’ column represents the conditional beta from susie (and is available for every variant in the locus) but we only retain the P-value for the lead variant in our current pipeline.

This is something we are looking to improve moving forwards, where we hope to retain the P-value, univariate beta/se, and conditional beta/se for every variant in the credible set. However, this requires quite large changes to our schemas and pipelines, and has many consequences downstream. Therefore it’s something we can’t give an ETA for, but it is high on our list of priorities.

Hope this answers your question.

3

Hi Daniel,

This makes sense - I just want to re-emphasize that p-value for the lead variant is NULL in locus array and not NULL outside of the array, while it should be exactly the same value. This is slightly different issue from the fact that non-lead variants have no p-value, and could (IMHO) be classified more like data quality issue.

Would be great if you can put somewhere into documentation that statistics for the lead variant should not be taken from the locus array - this would help for use cases like mine, where I was “exploding” the locus array and thinking that it’d have exactly the same lead variant stats as the parental, non-locus columns.

Thanks for such a prompt reply!

4

In our current SuSiE-inf pipeline the locus objects are generated directly from the raw susie output, which doesn’t include P-values. For our downstream pipelines/frontend the only P-value we consider is that of the lead variant, which we retain outside of the locus array. This is why we originally didn’t append the original P-values back to every variant (including the lead) in the locus object.

I completely understand how this is inconvenient for a use case like you described though. This is one of the reasons we are looking to improve the data model, and ensure all credible sets have consistent/complete information.

I’ll be sure to give you a notification when we have updates to this :+1: