Positioning for added annotations - UTRAnnotator and SpliceRegion

[karynne7]

In our local Seqr instance at UW we are going to try to implement two VEP plugins for filtering annotations. We want to add these plugin options under the Annotations section in Variant Search, see rough screenshot attached or word doc. This is in reference to these tickets:
#2274
#2275

UTRAnnotator:
uAUGgain
uAUGlost
uSTOP lost
uSTOP gain
uFrameshift

Extended Splice Site:
SpliceDonor: splice_donor_5th_base_variant
SpliceDonor: splice_donor_region_variant
SpliceDonor: splice_polypyrimidine_tract_variant
SpliceDonor: extended_intronic_splice_region_variant_5prime
SpliceDonor: extended_intronic_splice_region_variant_3prime

For displaying in the Variant Results, we are less sure of the best move. We are thinking about adding any UTRAnnotator or Splice Region annotations to the end of the variant impact, or beneath it. (e.g. intron variant / uAUG gain OR intron variant / extended_intronic_splice_region_variant_5prime ) Would your team prefer us add the annotations where the in silico scores are? We didn't think that made as much biological sense, but it might collapse better and make the page fit. Looking forward to your feedback.

[SeqrSpec111623.docx](https://github.com/broadinstitute/seqr/files/13384349/SeqrSpec111623.docx)

[hanars]

I think we would want these to look/ behave similar to how SCREEN works now, with their own sections in the "annotations" panel of the search interface, and then displaying below the VEP-predicted consequence on the variant:

[jxchong]

Makes sense for displaying the consequence. For the "annotations" panel of the search interface, the reason we thought we might added the SpliceRegion annotations under Extended Splice Site header is that the SpliceRegion annotations are types of "Extended Splice Site" variants, i.e. providing detail in addition to the existing "splice_region_variant" annotation. But we're open to keeping them separate if it's less confusing.

[hanars]

Yeah, but on the backend thats going to make parsing the search parameters really messy. Since these need to be constructing a different backend query, they should be in their own frontend group

[jxchong]

Ah I see, ok, that's fine with us.