Feature request to bypass BadOutsideCallException for bad outside call

[songx]

• Do you want to request a feature or report a bug?

feature

• What is the current behavior?

reporter.BadOutsideCallException when outside CYP2D6 genotype call is an invalid format. ex. 4/4/*5

• If the current behavior is a bug, please provide the steps to reproduce and, if possible, your example input data via a Gist or similar.

N/A

• What is the expected behavior?

Is it possible to assign something like "Bad Outside Call" to the gene genotype with bad outside genotype call instead of stopping the pipeline?

• What is the motivation / use case for changing the behavior?

I still would like get PharmCat reporter output for other genes that does not have a bad outside call genotype input

• Please tell us about your environment:

  • PharmCAT Version: 2.12.0
  • JDK Version: OpenJDK 21.0.2
  • Environment: Linux distro RHEL

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, e.g. stackoverflow, gitter, etc.)

• org.pharmgkb.pharmcat.reporter.BadOutsideCallException: Line 1: Too many alleles specified in 4/4/*5 at org.pharmgkb.pharmcat.phenotype.model.OutsideCall.(OutsideCall.java:78) at org.pharmgkb.pharmcat.phenotype.OutsideCallParser.parse(OutsideCallParser.java:54) at org.pharmgkb.pharmcat.Pipeline.call(Pipeline.java:289) at org.pharmgkb.pharmcat.PharmCAT.main(PharmCAT.java:174)

[whaleyr]

What, logically, do you mean with that format? Does this sample have three strands for chromosome 22?

[songx]

Hi,

That is a wrong D6 genotype from a D6 genotyping tool that is no longer being supported. My pipeline feeds outside calls directly from genotyping tool to pharmcat so I was wondering if possible to not crash the pipeline if the outside genotype call is wrong or invalid.

[whaleyr]

Understood. We will bring it up for internal discussion.

[markwoon]

@songx What is your expectation when PharmCAT gets invalid data like this?

We would rather alert users earlier rather than later so that problems can be fixed instead of it being missed and becoming a problem later. This would be extra challenging if you're using it to process many samples and have to wait for the end to realize there's a problem with your input.

In this specific case, we also think that the surprise of not having CYP2D6 results in the reporter (if we just ignored the invalid input) is a bigger problem that refusing to process the data.

I would suggest that you should fix the input to PharmCAT. We want to try to accommodate different data syntaxes, but for outside calls, we ask for valid data.

I'm not sure what problems you're having with your D6 genotyper, but you could translate *4,*4 to *4x2 and that would be valid for PharmCAT.

We won't be making this change. The code downstream of this expects valid data and we don't have resources at this time change this behavior and fully test it. It would be simpler to just drop the offending outside call, but again, this means that it would disappear from the result, and that's not acceptable either.

[songx]

Hi @markwoon

Thanks for taking the time, totally understand.

If I want to implement a script to check if my outside genotype calls are valid for Pharmcat, do you have any suggestions? Is there a list of valid genotypes for Pharmcat?

[whaleyr]

@songx It's pretty simple. If it's a "standard" diploid gene then it contains only one / to separate two allele names. If it's a monoploid or optionally monoploid gene (e.g. G6PD, MT-RNR1) then no / is required. Having more than one / in a diplotype is always an error.

It will accept any allele names but if they're not one that on our valid alleles list then it won't match to any phenotype or recommendation.

[markwoon]

Full list of all valid values in outside calls fiel: https://pharmcat.org/Phenotypes-List. You can also download it all as a tsv file.

You get to this page by clicking on the genes in the link Genes & Drugs page

There's a bug right now where HLA genes aren't being included, but that'll be fixed soon.