Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HGVS C dot not using right most aligned option #1741

Open
namiller2015 opened this issue Aug 13, 2024 · 6 comments
Open

HGVS C dot not using right most aligned option #1741

namiller2015 opened this issue Aug 13, 2024 · 6 comments
Assignees

Comments

@namiller2015
Copy link

Hello,

For the following variant in VCF format
chr19 1219320 . CACGTATATG CCCG

This represents a variant that looks like this
CACGTATATGGTG REF CCCG--------GTG ALT

We have a SNP A->C at the 2nd nucleotide and a deletion of TATAT and a deletion of a G.
VCF formatting would have the left most G deleted. HGVS standards would have the right most G deleted

Online web VEP using refseq transcripts gives the following C Dot
c.375-2_380delinsCC
for transcript NM_000455.5

but HGVS should be right most aligned giving a cdot of
c.375-2_381delinsCCG

I'm having difficulty understanding the correct way to resolve the inherit discrepancy between VCF standards and HGVS standards.
Is this an issue with the VCF representation, the way VEP's HGVS annotation is working, or something else?

Thanks!

@namiller2015
Copy link
Author

Some additional detail.

Using online web VEP I entered 2 HGVS entries for just the deletion.
NM_000455.5:c.375-380del
AND
NM_000455.5:c.376-381del

both had the HGVS C dot output as NM_000455.5:c.375-380del.
but according to HGVS standards this should be 3 prime shifted and result in 376-381.

I don't understand why the 376-381del is getting reworked to 375-380.

VEP output results
https://grch37.ensembl.org/Homo_sapiens/Tools/VEP/Results?tl=0I7ML6omyVC7jwHN-10322036

@namiller2015
Copy link
Author

I put this deletion into LUMC Mutalyzer 3's normalizer and got the expected 3 prime shifted C dot.

input: (NM_000455.5):c.375_380del
https://mutalyzer.nl/

image

@dglemos dglemos self-assigned this Aug 15, 2024
@dglemos
Copy link
Contributor

dglemos commented Aug 15, 2024

Hi @namiller2015,
Thank you for reporting this issue.
We are still investigating the output, I'll let you know when we have any updates.

Best wishes,
Diana

@namiller2015
Copy link
Author

Thanks!

Just adding some more details. Maybe this is a order of operations issue?

If you assess if the change is one indel or two different alterations AND THEN AFTER THAT three-prime you get delinsCC, because they are 2 (not less than 2) bp apart (Order operations A)

BUT

If you assess 3’ needs first AND THEN AFTER THAT assess if the alterations are three or more nucleotides apart you get SNV change at -2 and a 6 basepair del (376_381) (Order operations B)

This could explain why when I just put in the 6 base pair del into mutalyzer it 3-primes correctly, but when I put in the sequence it does order of operations A

The HGVS standards are also in the process of changing so it depends on which set of standards are currently being used.

HGVS_standards (1)

@namiller2015
Copy link
Author

any updates on this? Thanks

@dglemos
Copy link
Contributor

dglemos commented Sep 16, 2024

This represents a variant that looks like this
CACGTATATGGTG REF CCCG--------GTG ALT

The 3' representation is the following:
CACGTATATGGTG REF CCC---------GGTG ALT

Which looks like this:
Screenshot 2024-09-16 at 12 45 44

The order is:

  1. deletion of ACGTATAT
    CCC--------GGTG

  2. insertion of CC
    CCCCCGGTG

If you input ENST00000326873.7:c.375-2_381delinsCCG in mutalyzer, it corrects the representation to ENST00000326873.7:c.375-2_380delinsCC (link).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants