Thanks for the detailed answer!
By false-positive I mean that our variant callers called a mutation there based on NGS data, but when inspected in the sanger results, the peaks (according to the lab) indicated that the mutation wasn't real.
By "2-based deletion and 1-base insertion" I mean with regard to hg19, 2 bases from that position in hg19 were deleted and then there was an insertion of a single base (that wasn't in hg19).
I will definitely look at chr22:17052975 and see if it was aligned there.
By "flanking sequences" you mean 5' flanking region and/or 3' flanking region? How does one go about cutting them - remove them from the .fastq files?
The Sanger PCR the lab has done was based on primers they created from the gene the position's in, PIK3CA gene.
Was this a germline or somatic mutation?
We're not sure, the only sample was from the tumor.
You do not provide much detail, you would probably get more helpful replies if you provide a better description of your analysis. Do you perform realignment around indels? You are aligning with bwa mem, but how are you calling the variants? Do you perform quality filtering on your NGS variants?
You're right, thanks. I've edited my question, hopefully now the info is sufficient.
I developed an analysis pipeline that has 100% sensitivity with Sanger. It's currently being used in a laboratory of the National Health Service England.
100% agreement sounds suspicious (no offence intended). Is this pipeline publicly accessible? Would be great to learn from well-tested procedures that used other than the standard test datasets like NA12878.
EDIT: If it is not public, could you tell which variant caller it uses as a workhorse?
Yes, it is quite suspicious - when we presented the results at conferences (I presented in Manchester, England, and Dundee, Scotland), there was usually silence. Whilst it's got 100% agreement in the sense that it detects all Sanger-confirmed variants when the sample passes QC, it equally calls variants not encountered by Sanger, which could be false-positives or ones that Sanger missed.
We originally just used the GATK whilst validating/researching, but had to move variant caller due to licensing issues with the GATK for going live. So, now it's just open source samtools. The key (on top of good QC) is merely the 'random' selection of reads from your final aligned BAM to produce multiple 'sub-BAMs', each from which variants are then called independently. What you'll always find is a high quality variant(s) called in a lower sub-BAM that was seemingly missed in the original BAM. Try it out.
By producing sub-BAMs in this way, you increase your chances of calling all genuine variants. Unfortunately, when you do this, you're also calling variants from lower read-depths, so QC is always critical. We never called anything from below total read depth 18 (~97% sensitivity to Sanger at this depth), with the optimum total depth being 30 (100% sensitivity to Sanger).
To 'randomly' select reads like we did/do, one can use Picard DownsampleSam
[Edit: I never researched properly how/why seemingly blatant variants were not being called, but I put it down to genotype prior probabilities, i.e., prior probabilities of calling a variant at each position, which is influenced by read-depth. When you produce sub-BAMS, you 'reshuffle' the reads and give yourself a new chance of calling].
I am a little confused about what you said in EDIT.
The prior probability, P(Genotype), is defined in early study, such as 1KB or dbSNP, and the probability is fixed (sure the probability value depends on the read depth in that vcf file).
When using sub-BAM instead of entire BAM, the read-depth / allele frequency of your current sample changes. That changes the P(Data) and therefore changes the final P(Genotype|Data)
Is this what we are talking about?
There are 2 kinds of prior / posterior probabilities here:
I am referring to the first type in my posting (above). As mentioned, I never had time to explore this further.
Yes, the first type is what I was talking about. It is a fixed probability depending on which reference you use.
I am not sure about the second type you mention. In my expression, GATK also use the first type as prior. That is why --dbsnp arguments is used in HC / Mutect