Hotspots data not grch38 compatible

[pieterlukasse]

Hotspots data is not ported to grch38 yet.

E.g. these two files still contain exactly the same transcript ids for both grch37 and grch38:

• https://github.com/genome-nexus/genome-nexus-importer/blob/master/data/grch38_ensembl95/export/hotspots_v2_and_3d.txt
• https://github.com/genome-nexus/genome-nexus-importer/blob/master/data/grch37_ensembl92/export/hotspots_v2_and_3d.txt

We need to update the grch38 version to contain the updated transcript ids.

E.g. for BRAF this would probably be ENST00000646891 instead of ENST00000288602. See also: https://ensembl.org/homo_sapiens/Transcript/Summary?t=ENST00000288602

[pieterlukasse]

@inodb, @zhx828, here are my latest findings:

• We already have a grch38 hotspots file here, but this file is not actually updated to contain grch38 transcript_ids. In fact it is exactly the same as the grch37 file here .
  • The main issue will be solved when we regenerate the grch38 hotspots file with updated transcript ids.
• There are override files that can be used to fill in transcript ids. These override files are used in the code Ino shared.
  • If we make the override files to be a complete Hugo -> transcript_id mapping containing respective grch38 transcript ids of transcripts that are identical in AA sequence to their grch37 counterparts, then we could use this mapping in this code (with some adjustment) to replace the transcript ids in the final output file
  • If I understand correctly, @zhx828 has such a mapping file already

Is this a good summary? If yes, where can we get this mapping file?

[inodb]

Thanks so much @pieterlukasse ! That looks correct to me

This should have the grch38 mappings you are looking for:

https://github.com/genome-nexus/genome-nexus-importer/blob/master/data/common_input/isoform_overrides_at_mskcc_grch38.txt

[zhx828]

@pieterlukasse I only have the mapping for OncoKB ~700 genes. But I remember I went through the hotspot list using the grch38 override list and only MYD88 is affected. So using the file Ino pointed above should be ok.

[pieterlukasse]

@inodb I noticed this gene is duplicated in the mapping you shared: CDKN2A

ENST00000304494 CDKN2A  NM_000077.4
ENST00000579755 CDKN2A  NM_058195.3

The first transcript is the canonical in grch38, and is also returned when using mskcc as the isoformOverrideSource here: https://grch38.genomenexus.org/swagger-ui.html#!/ensembl45controller/fetchCanonicalEnsemblTranscriptByHugoSymbolGET, so I'm guessing we can just remove the second one, correct?

[pieterlukasse]

@inodb , @leexgh looking at the mapping file https://github.com/genome-nexus/genome-nexus-importer/blob/master/data/grch38_ensembl95/export/ensembl_biomart_canonical_transcripts_per_hgnc.txt, I noticed that some genes do not have a value in ensembl_canonical_gene, but do have ensembl transcript ids set for mskcc_canonical_transcript and uniprot_canonical_transcript. Can you please help me understand these cases?

[inodb]

@pieterlukasse:

I noticed this gene is duplicated in the mapping you shared: CDKN2A ENST00000304494 CDKN2A NM_000077.4 ENST00000579755 CDKN2A NM_058195.3 The first transcript is the canonical in grch38, and is also returned when using mskcc as the isoformOverrideSource here: https://grch38.genomenexus.org/swagger-ui.html#!/ensembl45controller/fetchCanonicalEnsemblTranscriptByHugoSymbolGET, so I'm guessing we can just remove the second one, correct?

Yeah this is sort of a bug. The original vcf2maf that Genome Nexus is based on has a way to assign two canonical transcripts (in case one of them is not found for that particular variant). In our case for supporting cBioPortal this is not great (in the sense that protein changes would differ when querying for CDKN2A), so we only choose one. So yes let's stick with just ENST00000304494

looking at the mapping file https://github.com/genome-nexus/genome-nexus-importer/blob/master/data/grch38_ensembl95/export/ensembl_biomart_canonical_transcripts_per_hgnc.txt, I noticed that some genes do not have a value in ensembl_canonical_gene, but do have ensembl transcript ids set for mskcc_canonical_transcript and uniprot_canonical_transcript. Can you please help me understand these cases?

Hmm this sounds like a bug that we should solve. Not sure how you can have an ensembl transcript without a gene? One of the examples you shared does seem to have an associated ENSG gene id: https://grch37.ensembl.org/Homo_sapiens/Gene/Summary?g=ENSG00000221972;r=3:133646992-133648656;t=ENST00000408895

[pieterlukasse]

@inodb thanks for following up on these questions. Regarding CDKN2A: I noticed that ENST00000304494 was already the transcript id for CDKN2A in the grch37 hotspots file and this stayed the same in the new grch38 file. So fortunately the hotspots results of this PR are not affected.

Regarding the missing ENSG values: I've downloaded the previous version (https://github.com/genome-nexus/genome-nexus-importer/blob/c7217e17f88991e0cdb2d27be91fe54c76e327a8/data/grch38_ensembl95/export/ensembl_biomart_canonical_transcripts_per_hgnc.txt) and it has the same/similar issues:

It must be a bug in this code https://github.com/genome-nexus/genome-nexus-importer/blob/master/scripts/make_one_canonical_transcript_per_gene.py Interesting fact: empty ensembl_canonical_gene and non-empty transcript id only happens in the columns uniprot_canonical_transcript and mskcc_canonical_transcript...

IMO we need a new ticket to fix both these issues.

[pieterlukasse]

New ticket: https://github.com/genome-nexus/genome-nexus-importer/issues/61

[inodb]

@pieterlukasse thanks for filing!

[pieterlukasse]

shall we close this one?