Skip to content

VCFToJSON: recognise all HGMD accession prefixes in xref - #6

Open
ChristopheH wants to merge 1 commit into
bialimed:masterfrom
ChristopheH:fix/hgmd-xref-prefixes
Open

VCFToJSON: recognise all HGMD accession prefixes in xref#6
ChristopheH wants to merge 1 commit into
bialimed:masterfrom
ChristopheH:fix/hgmd-xref-prefixes

Conversation

@ChristopheH

Copy link
Copy Markdown

Problem

getAnnotSummary() classifies the IDs of the VEP field Existing_variation into
xref using the prefix of each ID. HGMD is only detected through the prefix CM.

HGMD encodes the variant class in the second letter of the accession, so CM only
covers missense and nonsense variants:

Prefix HGMD variant class
CM Missense / nonsense
CS Splicing
CD Small deletion
CI Small insertion
CX Small indel
CR Regulatory
CG Gross deletion
CN Gross insertion / duplication
CL Complex rearrangement

All the other classes fall in xref["Unknown"] and raise, for each ID of each
variant, the warning:

The database using the variant ID "CS1414230" is not managed by ".../VCFToJSON.py"

Two consequences: the downstream consumers of the JSON lose the HGMD cross
reference for every non-missense HGMD variant, and the logs of an exome-scale run
are flooded with warnings.

Solution

Replace the chain of startswith() by a table of patterns and a small
getXrefDB() helper:

XREF_DB_BY_PATTERN = [
    ("dbSNP", re.compile(r"^rs")),
    ("cosmic", re.compile(r"^COS")),
    ("HGMD", re.compile(r"^C[MSDIXRGNL]\d+$"))
]

The dbSNP and COSMIC patterns are strictly equivalent to the previous
startswith() calls, so their behaviour is unchanged: only the HGMD detection is
modified, which keeps the review surface minimal. The HGMD pattern is anchored on
the trailing digits, since an HGMD accession is always two letters followed by
digits. This recognises every class without capturing the IDs of another database
starting with the same letters.

The xref dictionary already declares the HGMD key: the JSON schema is
unchanged.

Behaviour change

One case is classified differently than before: an ID matching CM but not
followed only by digits (for example the GenBank accession CM000663.2) was
previously reported as HGMD and is now reported as unknown. This is the intended
outcome, but it is a change and is worth a look during review.

Testing

getXrefDB() returns the expected database on:

  • dbSNP: rs587776767
  • COSMIC: COSV57482192, COSM476, COSN123
  • HGMD: CM1414230, CS1414230, CD094312, CI012345, CX1234, CR930125,
    CG1234, CN1234, CL1234
  • None (unknown, as expected): CIVIC123, CM000663.2, ENST00000123,
    TMP_ESP_1_123, VCV000012345, esv3364878, C1234

Version

__version__ of the script bumped from 2.9.2 to 2.10.0, since the content of
xref changes for files containing non-missense HGMD IDs. Tell me if you would
rather also bump the package version.

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

Successfully merging this pull request may close these issues.

1 participant