Cat-VRS: Adjacency constraint

[brendanreardon]

Submitter Name

Brendan Reardon and @DanielPuthawala

Submitter Affiliation

No response

Project Details

Drafting a constraint to model fusions, rearrangements, and translocations is a Planned feature for cat-vrs. This constraint is likely to build off of VRS' Adjacency object, introduced in their 2.0 release. A Discussion was opened in October to discuss this potential new constraint.

While we are still developing an SOP for drafting new constraints, we'll explore using GKS Think Tank to (virtually) whiteboard what modeling an Adjacency constraint may look like.

Required Maintainer(s) Attendance

@DanielPuthawala, @brendanreardon

Required Skills

An interest in representing fusions, translocations, and rearrangements within cat-vrs

[brendanreardon]

@bpitel12, @DanielPuthawala, @mdperry, @rrfreimuth, and myself participated in the Think Tank today. An Adjacency constraint is a common request from implementers, especially because fusions are very clinically actionable, often supported by high quality evidence items. The main output that we produced is a work in progress sketch of a potential Adjacency constraint 👇 (Thank you Daniel and LucidCharts!).

There were several design decisions that were discussed, which remain unresolved:

What is the scope of this constraint? In addition to fusions, rearrangements, and translocations, we want this constraint to be flexible to support any movement of genomic location, such as cytoband translocations or alternative splicing. The constraint should not presume any effect of the adjacency (e.g., it is different from reference). @rrfreimuth articulated, "Focus on the expression of the state that we want to assert instead of the events that led to them".

Should the elements property be hard coded as ordered: true, or should we incorporate a way to specify ordering for flexibility? While specifying an ordered list would enable users to distinguish 5' and 3' partners in the case of fusions, it may be more advantageous to be able to specify alternative orderings such as forward, reverse, unknown, not specified, etc.

Should we include an unknownElement as a potential object? Doing so enables us to represent cases where a partner is unknown, such as MET:: and ABL1::something::MET.

What list length do we support? VRS's Adjacency class requires two, and only two, objects for the adjoinedSequences representation. The group seemed in favor of supporting a flexible list length.

Based on these use cases, what should exist within a constraint object and what should within a Recipe? For example, the constraint could have special properties to support special types of Recipes, as the DefiningAllele and DefiningLocation constraints do for CanonicalAllele and ProteinSequenceConsequence through the relations property.

We also want to be sure that we are not reinventing anything from either VRS or other standards such as HGVS or ISCN. Of course, naming of constraint attributes. Of course names of properties are always up for discussion too.

[brendanreardon]

For the 2025-09-24 Think Tank, we'll continue engaging with the above open questions with particular focus on:

• the scope of this constraint
• test set variants that fall inside and outside of the scope of the constraint

[brendanreardon]

This breakout session had a fruitful call today that included myself, @DanielPuthawala, @mdperry, @ahwagner, @jarbesfeld, and Sadeem Qdaisat. Daniel moved the LucidChart for the Adjacency constraint to this link. Here is a screenshot of it 👇

We intended to discuss scope and test set variants. Our outcomes were:

• Design decision junction: Do we limit the scope of the Adjacency constraint to 2 members, as VRS did with their Adjacency object, and punt to complex categorical variant, or use an open array, like we decided upon last week? We'll reach out to @bpitel12, @rrfreimuth, and @wesleygoar, who are our implementers for this constraint, to further discuss this.
• Alex and Jeremy provided nice information from VRS, the VICC Fusion guidelines, Fusor, and a VICC fusion generator. There was also conversation about the Unknown Gene Element and Multiple Possible Gene Compnent values.
• Conversation about what additional properties of the VRS:Adjency object that we want to import. For example, linkerSequence.
• Test cases: simple fusions and simple rearrangements. Sadeem brought up a triple fusion in Ewing Sarcoma, which was identified by two breakpoints. We also have chromothripsis and inversions in the test set document, but these do not seem to be "implementer backed" examples, at the moment, at least.

Thank you everyone!

[brendanreardon]

For the 2025-10-22 meeting, we will focus on drafting this as a constraint within the schema and generating examples. Based on feedback from our implementers of this feature (Wes, Bob, and Beth), we are going to focus on gene fusions.