Hi! I have ran a case we have through both OA v2.2 and OA v3.0. In OA v2.2 the case had a QC PASS and a purity of 98% (13%-100%). In OA v3.0 The QC check fails with FAIL_NO_TUMOR and a purity of 100% (14%-100%). This also leads to the remaining of the Orange report being empty. • How can the two versions differ so significantly in the QC check? • Related to that, why is the purity range so large, and contradictory with the QC check? • Is there a way of forcing the Orange report generation?

Hi @Kristine Bilgrav Sæther, this looks quite stark

Hi Kristine, thanks for your message. Do you know/suspect this sample to be a low-tumor-content one ? Is this information you could get ? Would you be able to share the

.command.log

of the PURPLE task for both runs (each sample, the 2 different versions of the pipeline) as well as the PURPLE output if possible? At the very least, the qc, purity and purity range ones (and the plots/pngs as well for the range and the somatic clonality) - Thanks ! 🙂

@Rayan Hassaïne purple does run and completes succesfully, what do you mean here?

PURPLE will use a placeholder 100% tumor purity and ploidy 2 if it cannot pick up any signal - those numbers are therefore unreliable. The fact that Orange is empty is due to these results not being trustworthy. I therefore meant, a "successful" Purple QC, i.e. a tumor signal detected, above our limits of detection (on various levels) for an Orange PDF report to be populated. The JSON should already be populated but also unreliable in the current shape (FAIL_NO_TUMOR)

this is a tumor only case without matched normal, I wonder if these QC checks are not optimal for those. Would it be possible to add the option to force the Orange report generation?

PURPLE 4.4 (OA 3.0) removed a fallback that used to discard a "no tumour" verdict when it implied an implausible deleted fraction (a post-hoc sanity check, replaced by a proper aneuploidy pre-check), and it now excludes hotspots under 5% VAF from the tumour-only somatic fit - so low-purity tumour-only cases can lose their only signal. Agreed the check is blunt without a matched normal. The 100% purity is a placeholder PURPLE writes on that verdict, not an estimate; the 14-100% range is just the spread of equally-scoring CN fits, meaning the fit was flat - so the 98% in 2.2 wasn't a real measurement either. You're right that 2.2 reported regardless but that could be misleading, hence the changes. I'll take a deeper dive into what you've sent and get back to you!

Thanks @Kristine Bilgrav Sæther and @Eva Caceres for sending those files over

Hi @Rayan Hassaïne thanks a lot for your answer! We are seeing more cases of empty reports due to QC fails for tumor only hematological cases, which is quite problematic. Specially since variants are still reported in the summary of the report, and therefore we would still like look at those variants in the tables below (which no longer appears) so it would be great to be able to at least force the report to produce all the output (even if that is not the default option). We also know that some these hematological samples have donor DNA since they have received a transplant, so QC can be tricky Let us know if this is something that could be done and thanks for looking into this @Rayan Hassaïne and @Stephen Watts

Hi @Eva Caceres I think that you're observing 'expected' behaviour which is more correct than what you previously had (unless orthogonal data verified a purity > 13%, then let us know), the only thing we could come up with is to add the mutated genes (seems like there are few events) to the driver panel and see if that changes the behaviour to what you expect

1. PURPLE now sets the purity notionally as 100% (instead of 8%) in the case of NO_TUMOR. This makes the CIRCOS and other residual variant data much easier to intepret. We will replace the displayed 100% with ‘NA’ in the tumor purity column in v3.1 2. It was not expected for me to produce an empty Orange report in the case of a FAIL. I agree this is very annoying. We intend to revert this behaviour in v3.1.

Hi thanks a lot for your answers! Great to know about planned changes for 3.1, is there a timeline for the 3.1 release?

I think they were aiming fro end of the year but will leave the dev team to confirm