Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ClinVar conflicting evidence #9

Closed
vladsavelyev opened this issue Apr 8, 2019 · 8 comments
Closed

ClinVar conflicting evidence #9

vladsavelyev opened this issue Apr 8, 2019 · 8 comments

Comments

@vladsavelyev
Copy link
Contributor

vladsavelyev commented Apr 8, 2019

Hi Sigve,

Wondering what was the rationale behind skipping variants which have "conflicting_interpretations_of_pathogenicity" by ClinVar regardless of other annotations that can be (likely) pathogenic? Perhaps it makes the report too cluttered?

Thinking that such variants should still go under TIER3 (either VUS or Non-classified) - or below, but should show up in the report.

Perhaps in the following line, the check is.na(CLINVAR_CLINICAL_SIGNIFICANCE) should be removed?

https://github.com/sigven/pcgr/blob/b6ccae7fac4c86c472fdac6e0c9728edd930a189/src/R/pcgrr/R/cpsr.R#L169

cc @ohofmann

@vladsavelyev
Copy link
Contributor Author

Attaching an example VCF with such variant:
CHEK2.vcf.gz

@sigven
Copy link
Owner

sigven commented May 20, 2019

Hi Vlad,
Check out the new release, should place variants with conflicting interpretations of pathogenicity (from ClinVar) in the tier 3 table.

cheers,
Sigve

@sigven sigven closed this as completed May 20, 2019
@vladsavelyev
Copy link
Contributor Author

Wow, thanks so much for the release, Sigve! That's highly anticipated. Will give it it run

@sigven
Copy link
Owner

sigven commented May 21, 2019

Cool. Happy bug-hunting :D

@vladsavelyev
Copy link
Contributor Author

Had to adapt for the command line options, but otherwise no bugs noticed :)

One thing is that you removed the predisposition gene list from the toml. Currently we pre-subset the germline variants to our own gene list (which is a combination of your list and CancerGeneCensus germline) before feeding them into CPSR, so in a way wanted to avoid additional hard-filtering. Though that's not critical I think given that overall improvements are so significant.

Also check out the updates to PCGR as well. Nice that it reports purity and ploidy, I will take them from PURPLE caller that we use for CN calling. But curious if purity/ploidy are used only to show in the report, or also for filtering somehow?

Also you made tumor_type required now, but we don't yet specify it in our pipeline on a regular basis. I will just set it to Cancer_Unknown_Primary_NOS, do you think it is fine for a general case? A lot of our tumors are CUPs anyway and that's why we don't even parameterize our analysis by tumor type.

@vladsavelyev
Copy link
Contributor Author

And thanks for parametrizing vep_pick_order :)

@sigven
Copy link
Owner

sigven commented May 21, 2019

Yeah, the list of genes that are target for predisposition screening was simply a choice I made. The previous configuration was a bit too messy to handle. Either way, I'd be happy to create the specific gene set you are using as an additional virtual panel (aka UMCCR track:-))

Regarding ploidy and purity you are correct; these are not used in any way other than for display right now (I have no big clue as to how they could be used for filtering, as the purity and ploidy preferably should be taken into account when considering the variant set that is fed as input.

Wrt tumor type I believe I should add the option of not specifying any type, the 'Cancer_Unknown_Primary_NOS' is in fact a distinct cancer subtype, and should not be confused with not having specified a type at all. Sorry for not considering this.

Best,
Sigve

@vladsavelyev
Copy link
Contributor Author

Cool. Would be really awesome to have the option of generic cancer type!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants