verify that liftover variants have the same sequence/sequence length as original variant

[jennifer-bowser]

Feature description

Kyle brought up an excellent point re: concerns about lifted-over variants potentially having different sequences/sequence lengths than the original variant.

James had a really good explanation of the problem so I'm copy/pasting it here for reference:

So let's say "Ref A" is GRCh37 and "Ref B" is GRCh38. In this figure, each colored block is supposed to be equivalent, ie anything in 0:100 on GRCh37 lifts over to the same position within 0:100 on GRCh38. But after 37, our scientists went looking and discovered that there was actually a whole other block (yellow) between (blue) and (orange) on The Real Human Genome, so they updated GRCh38 accordingly.
So then let's say I have a variant on GRCh37 with the location of {"start": 99, "end": 102}. If I liftover the start position, I'm gonna get 99, and if I lift over the end position, I get... 202. So now a 3 base deletion becomes a 103 base deletion. That seems worrisome

I guess the upshot is at minimum we probably need to do a double check that liftover doesn't alter the gap between location.start and location.end

Ideally we'd do something like verify that the sequence is the same but idk

Use case

We need to ensure that we're accurately lifting over variants

Acceptance Criteria

• If possible, verify that sequences are identical between the original variant and the lifted-over one
• If that's not feasible, then at least verify that the sequences lengths of both variants are the same
• If the variants' sequences are not the same (or at least the same length), then raise an Exception and do not complete the liftover operation.

Proposed solution

No response

Alternatives considered

No response

Implementation details

No response

Potential Impact

No response

Additional context

No response

Contribution

None

[jennifer-bowser]

@ahwagner and/or @larrybabb we could use your insight on this to ensure that a) this really is a problem that we should be accounting for, and b) that our proposed solution is the best way of going about it

[ahwagner]

Sorry about the delay–catching up on backlog post-travel.

In my opinion, we may perform such checks to warn the user if the reference region length has changed (by any amount), but perform the operation anyway. In many cases we will see such reference length changes at a 1-10nt scale. Rather than define an arbitrary threshold for what constitutes an acceptable vs. unacceptable reference length change for a region, we should acknowledge that the person detecting a variant on reference A had enough information to say the state was a 3nt deletion in the absence of the yellow nucleotide block; indicating it is indeed a large deletion when compared to reference B.

@larrybabb please give a 👍 if you agree or let us know if you feel differently.

[jsstevenson]

In my opinion, we may perform such checks to warn the user if the reference region length has changed (by any amount), but perform the operation anyway.

This makes me wonder -- what's the best way to do this in the context of AnyVar? So far, we're generally using liftover to register alternate-sequence-equivalents to user-provided variations within the DB, but the original user doesn't actually see that lifted-over variant. For example, here's the pydantic response model for PUT /vrs_variation:

class RegisterVrsVariationResponse(BaseModel):
    """Describe response for the PUT /vrs_variation endpoint"""

    messages: list[str]
    object: models.Variation | None
    object_id: str | None

• We could include the warning in messages, although it doesn't really affect object (we aren't returning the lifted-over variant)
• We could add an additional column to the liftover/mapping table that we've discussed for the new schema, and include it as a warning whenever some retrieval is performed that involves the mapping?

[ahwagner]

We could add an additional column to the liftover/mapping table that we've discussed for the new schema, and include it as a warning whenever some retrieval is performed that involves the mapping?

Yes, I was thinking something along these lines.