Identifying FLT3-ITD with Pindel

Question

[DG]

Hi everyone,

Looking to see if anyone else has any experience in looking for somatic mutations in FLT3. I am working on some testing samples that we sequenced on a MiSeq with the Myeloid amplicon panel. I'm trying to identify the presence of the FLT3-ITD in the samples (that were previously tested by other means and the tandem duplication should be present) using Pindel and just am not seeing it in the data. Looking to see if anyone else has tackled this problem and may have suggestions for optimizing some of the pindel parameters, or anywhere upstream with BWA or the GATK workflow.

[talwar.avii]

Hi Dan,

I am also trying to find Tandem duplication in the same gene (FLT3) using pindel. My problem is that everytime I define a region for the pindel to analyse (Chr 13) it gives me a 'segmentation fault' error. My bam files are from a third source so i used this command to convert the files to the required pindel input format.

./samtools view input.bam | ./sam2pindel - Output4Pindel.txt 300 tumour 0

I am using the same reference genome I used for the mapping. However when I used the -c ALL options I get normal runs without the error. Also I see in the pindel input file that I do have reads mapping to the chr 13 region.

How did you manage to run pindel for this region? I am stuck and confused a bit.

[DG]

Hi Talwar,

I haven't restricted my analysis to a particular chromosome and have always run as -c all. I also didn't convert my bam files as it didn't make sense in my workflow (creating another potentially large file for one program is always silly to me). I just created the described config file and passed my bam directly to pindel.

Answer 1

[coldrecd]

Pindel is designed for hybrid capture data, and has not worked well with amplicon data in my hands.

Check out AmpliconIndelHunter, I've not tried it yet but plan to soon.

[DG]

I have that on my list of things to try as well, came across the paper a few weeks ago when it came out. Unfortunately I don't have access to the paper. Emailed the first author for it and the software weeks ago but haven't heard anything back. I have delly2 just about set up to run on the data.

As for hybridisation versus amplicon I thought that I have come across a number of papers specifically doing this in FLT3 with amplicon-based panels and not hybrid-capture ones. I'll have to check them in more detail. Unfortunately, command-line parameters are typically not reported in any of these papers or supplementary materials. Of course I've been guilty of that in the past as well.

Answer 2

[Chris Miller]

FLT3 ITD is notoriously hard to detect. Pindel is probably the best of the tools we've tried (some other algorithms, like Clever-SV seem promising in principle, but we haven't tested them extensively). As a matter of course, if we don't detect FLT3-ITD in an AML sample, we manually review the locus to make sure we haven't missed anything. Frequently, this is the only way we detect them.

If you find a tool that reliably detects the ITD at this locus, I'd love to hear about it.

[DG]

Oddly enough NPM1 small indels aren't routinely being detected in the pipeline either, and they are typically 5 bp insertions which should be fairly trivial. Pindel isn't spotting the FLT3-ITD at all. Running it on some additional samples now to see if there was just something off about the other two samples. Anything particular you are doing for manual review? Evidence of unexpected insert size, etc?

[Chris Miller]

Yeah, the canonical NPM is often hard to pick up too. The repetitive sequence there means that alignments often end up showing the 4bp insertion at several different start positions, and then none of the individual sites reaches high enough level to be significant. It's a pain.

Soft clipped reads in that locus are usually a good place to start. Pull it up in IGV, and you can start to get a sense of where the clipping starts, and what sequence is involved. The size of the ITD (~30-100) usually isn't big enough to register as outside the distribution of the insert size. Another tip is that the ITD is always in-frame, so the length should be a multiple of 3.

[DG]

Thanks Chris, that is helpful. Right now most of the variant callers I am using I am allowing quite low read-depths for reporting for just this reason. I'll dig into the NPM1 variants a bit deeper and see what is showing up around the location. From what I recall there were a few called nearby but they were shorter than the canonical 4bp. Luckily the canonical CALR deletion seems to be being picked up by Pindel. I'm testing CLEVER and LASER this week on our data and will let you know how it works out.

[talwar.avii]

Hello Guys,

Sorry for joining the party so late. I have been doing some testing myself with Pindel to see how it detects the insertions (ITD) in the FLT3 region. We have had confusing results: sometimes the insertions are predicted some times they are not.

and mostly always the predicted ones have a very frequency reported by pindel.

Moreover, I found this post where they say that the insertion if bigger than (read length -20 bases ) it will not be predicted by pindel. And indeed this was the case, we found two insertions ( 146 bp and 193 bp ) which were not predicted by Pindel but were confirmed using Roche (after manually looking for insertions).

I have tried multiple parameters but did not have any luck with it.

I wanted to ask this thing to @chris: what region do you generally define for the insertion in the FLT3 ? moreover what are the parameters you tweak for pindel which gives you the best results? moreover what is usual length of the Insertion you observe ? can we allow low read depth in pindel ? specifically how to predict insertions longer than 140 bp?

[Chris Miller]

The TCGA AML paper that we published is the best source for that info. Here's a quick grep of the data from that paper for FLT3 insertions (in build37 coordinates).

[talwar.avii]

Thanks!!

But unfortunately the link gives me an error.

[Chris Miller]

Is github blocked where you are for some reason? Here's the non-linked, non-embedded URL:

https://gist.github.com/chrisamiller/7a4c889baa7e51d9bef6#file-tcga-flt3-mutations

[LindseyKelly]

Just wondering how you manually review your FLT3-ITDs. I have cases that I know are positive through conventional methods (fragment analysis) that I have also run with the Myeloid panel on the MiSeq but when I load the BAM files onto IGV, I see no evidence of the insertion. I can see 4 or 5 bp insertions in NMP1 that are not always detected by Illumina's software in IGV, but not the longer insertions. Am I looking at the wrong files or do you do things differently??

Just in case anyone else is working with the Illumina software, I increased the "TruSeqAmpliconAlignerMaxIndelSize" to 60bp (default is 25) and reanalyzed in BaseSpace to find longer deletions in CALR (but no insertions in FLT3).

[Chris Miller]

It's usually a combination of IGV, and blatting reads. Often times you'll see softclipping at the ends of reads that read into the ITD and if you blat those softclipped bases, you'll see that they're part of the duplication event. They're tricky to spot even then. We've got some people who have been doing this type of manual review for years and I lean heavily on their expertise

[DG]

Sounds like what is being done by ScanIndel. That was fairly recently published and claimed a high success rate from Custom Amplicon data on FLT3-ITD. I'm waiting on more definitive positive samples to test it out as we suspect some of the positive case DNA we had from old assays were follow-up post treatment samples.

[DG]

Good to know. I also resolved my NPM1 issue, I think the samples we had were post-treatment and the mutation was no longer present in the sample. I let the Illumina onboard caller run but we have a custom pipeline running independently. BWA + MuTect and other callers (FreeBayes, Scalpel, etc) have no problem with CALR BTW.

Answer 3

[Tommy Au]

ITDseek is designed to detect FLT3 ITD in amplicon NGS reads https://github.com/tommyau/ITDseek

[DG]

Thanks for that. Definitely checking it out

Answer 4

[cpad0112]

I thought CGW from Wash U is capable of catching FLT3-ITD with their panel specific pipelines.

[DG]

Th problem being CGW is proprietary. Last time I looked into it I don't even know how much detail they provided on what programs and algorithms were being used at different points of the pipeline. Black boxes aren't appealing.

[Chris Miller]

Black boxes aren't appealing.

Agreed. That's one of the reasons that our group doesn't use it.