I think it is important that if no filters are set then all the variants
and genes get prioritised and reported i.e the current default of
passedFilters of true is necessary unless we can keep this behaviour some
other way.
People will want to filter exomes in their own pipeline and just use
exomiser for ranking. This is what we do for udp most of tge time
On Dec 12, 2014 4:24 PM, "Jules Jacobsen" notifications@github.com wrote:

Since issue #2 #2 the
VcfWriter so output is now more compatible with the actual VCF spec, in
particular, if a variant has not been filtered the FILTER column should be
empty for that variant:

##fileformat=VCFv4.1
#CHROM POS ID REF ALT QUAL FILTER INFO FORMAT GENOTYPE
chr3 4 . G C 2.2 ;VARIANT NOT ANALYSED - NO GENE ANNOTATIONS GT 0/1
chr1 1 . A T 2.2 PASS ;EXOMISER_GENE=ABC1;EXOMISER_VARIANT_SCORE=1.0;EXOMISER_GENE_PHENO_SCORE=0.0;EXOMISER_GENE_VARIANT_SCORE=0.0;EXOMISER_GENE_COMBINED_SCORE=0.0 GT 0/1
chr1 2 . T - 2.2 Target ;EXOMISER_GENE=ABC1;EXOMISER_VARIANT_SCORE=0.0;EXOMISER_GENE_PHENO_SCORE=0.0;EXOMISER_GENE_VARIANT_SCORE=0.0;EXOMISER_GENE_COMBINED_SCORE=0.0 GT 0/1
chr2 3 . C T 2.2 Frequency;Target ;EXOMISER_GENE=CDE2;EXOMISER_VARIANT_SCORE=0.0;EXOMISER_GENE_PHENO_SCORE=0.0;EXOMISER_GENE_VARIANT_SCORE=0.0;EXOMISER_GENE_COMBINED_SCORE=0.0 GT 0/1
chr3 5 . G C 2.2 ;EXOMISER_GENE=CDE2;EXOMISER_VARIANT_SCORE=1.0;EXOMISER_GENE_PHENO_SCORE=0.0;EXOMISER_GENE_VARIANT_SCORE=0.0;EXOMISER_GENE_COMBINED_SCORE=0.0 GT 0/1

However this has raised a question about the Filterable interface which
I'd like some feedback on as it impacts a fundamental behaviour. Currently
a Filterable either passes or fails, but really it can exist in one of
three states - passed, failed and unfiltered/not yet filtered. Given this:

Should a Filterable (VariantEvaluation or Gene) report true or false
to passedFilters if no filters have been applied? (I think this should
really be false - however, this is a reversal of the current behaviour
which is always true until a filter has been failed and passedFilters is
quite well used- a more accurate name would be hasNotFailedFilters )
2.

Should a Filterable be able to report its actual state -
PASSED/FAILED/UNFILTERED? (I vote yes as it is quite explicit and prevents
you from having to combine passedFilters and a newly added isUnFiltered
Booleans in order to infer a missing failedFilters or add the failedFilters
Boolean too)
3.

Given the first two points is there any point in having any other
methods in the Filterable interface other than passedFilter(FilterType) and
getFilterStatus?

It would be possible to keep the existing behaviour of passedFilters and
add getFilterStatus for ease of use and backwards compatibility at the
expense of some potential confusion. But this all depends on what people
are using - will any of these changes actually have any direct impact on
you? If not I suggest clean logic should be applied as this tends to keeps
things simpler and simple is good.

—
Reply to this email directly or view it on GitHub
#4.

Can't be important - not been an issue, might have fxed it. Dunno really.