ACTIN-1966 add range rank to MolecularMatchDetails

[ArnoHMF]

See https://hartwigmedical.atlassian.net/browse/ACTIN-1966

In the OncoAct internal data model the affected Codon / affected Exon is passed on in a field called rangeRank. That naming I used here as well.

I did not see a way to get this information from the Serve datamodel (though it seems that it should be in there) so instead I pass it on from the Variant.

I'm not particularly happy with this solution, however I could not think of an alternative.

I did not add any tests yet as I first want to check if this is an acceptable solution, or if there are perhaps better alternatives before I spent more time on this approach

[ArnoHMF]

Discussed with Korneel: Best approach is to add this information back in Serve again (Korneel can you provide some input on how to do this) instead of passing the info from the variant deep into the ACTIN code.

The range rank will then still be returned through the MolecularMatchDetails. Question here is if rangeRank is the correct name?

[kduyvesteyn]

Discussed with Korneel: Best approach is to add this information back in Serve again (Korneel can you provide some input on how to do this) instead of passing the info from the variant deep into the ACTIN code.

The range rank will then still be returned through the MolecularMatchDetails. Question here is if rangeRank is the correct name?

You'd have to make the following changes in datamodel:

• Replace RangeAnnotation interface with CodonAnnotation and ExonAnnotation interfaces that take the extra fields that are currently in KnownCodon and KnownExon.
• KnownCodon should extend CodonAnnotation rather than RangeAnnotation and drop additional fields.
• KnownExon should extend ExonAnnotation rather than RangeAnnotation and drop additional fields
• ActionableRange should be split up in ActionableCodon and ActionableExon similar to their known classes.

(Note that this should imply no change in fields for KnownExon and KnownCodon)

In terms of algo, every usage of ActionableRange should be refactored, and everywhere instances are created the inputTranscript, inputCodonRank and inputExonRank should be provided (didn't check the details but assume this won't be hard). For ref genome converter you could either wipe these 2 fields (since they don't convert) or keep them knowing that they are "input" parameters in the space of the ref genome that the source has been defined in.