cancervariants / cancervariants/variation-normalization

VRS ID mismatches for same concept

Open
#672 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
15
Forks
2
PR merge metrics
No merged PRs in 30d

Description

`ga4gh:VA.qXcjEs7sqOLLVJ_4QxBLMM3zJmVJAnj4` is the VRS ID for `/normalize?q=PPP6C Arg264Cys`.
`ga4gh:VA.GBgHSEiIT9N89paEpxufTeW9_M0gYoC-` is the VRS ID for `/gnomad_vcf_to_protein?q=9-125149801-G-A` (for the context of this variant - I believe this is what the correct VRS ID is) - see comment below for responses

`PPP6C Arg264Cys` is the protein representation for `9-125149801-G-A`. I would expect the VRS IDs returned by both endpoints to be the same, as these should both be returning the same concept.

This seems to work properly for some variants, like `7-140753336-A-T` / `BRAF Val600Glu` - both endpoints return the same VRS ID.

Related discussion/background context:
https://github.com/GenomicMedLab/igm-varcat-api/discussions/238
We use VRS ID as a lookup for Cancer Hotspots data (evidence-normalizer). In VarCat, we use the VRS ID retrieved from the `gnomad_vcf_to_protein` endpoint as the key, which isn't matching for some records (like the above variant)

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reproducing the two endpoint requests for PPP6C Arg264Cys and 9-125149801-G-A, then compare their normalization paths and outputs. Read the linked discussion for background and use the BRAF Val600Glu example as a working comparison. Done means equivalent representations return the same VRS ID, including the reported variant.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
api, backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.