gostachowiak

I have discovered an issue with transcript NM_001278433.1 (gene PRKAR1A), which I believe is an example of this issue. If my understanding is incorrect, please let me know. Exon sets...

Reece: Thank you very much for your time-- that was helpful. I don't see uta_20190926 as a tag on the dockerhub page, so I wasn't sure if it was advisable...

@katiestahl when there's an insertion right at the intron/exon boundary, there is a choice to make. Should the inserted material be treated as part of the coding region (because the...

Would it be possible to re-open this issue? It is a flaw with a PR out to fix it.

@reece For the mutations affected by this pull request, the entire coding sequence is unchanged and the added material is within the 3' UTR. c.39_*1insA - material is inserted after...

@andreasprlic We are just attempting to follow the guidelines as they exist, which say that if you can represent something as a dup, it _must_ be represented as a dup,...

@andreasprlic @reece I think we probably all agree that returning `p.Met1?` is completely wrong for `NM_153223.3:c.2959_*1dup`. This pull request returns `p.?` instead, which is the same thing returned for `NM_153223.3:C.*1_*2insTAAT`...

@andreasprlic @reece by the way, the pull request also fixes non-duplication insertions just after the stop codon. The second unit test added is `NM_004985.4:c.567_*1insCCC` --> `p.?`

@andreasprlic yes I meant #716. Thanks!

@reece I am wondering who can help review this pull request? I believe the core pdot calculation logic is currently giving incorrect results, and we are under some pressure to...