Feature #488

Allow non-nsSNP variants

Added by Tom Clegg about 9 years ago. Updated over 8 years ago.

Assigned To:
Target version:
Start date:
Due date:
% Done:


Estimated time:
Story points:


Need to stop restricting database to nsSNP variants.
  • Support lookup/create by dbSNP id
  • Support lookup/create by {chromosome, position, ref_seq, variant_seq}
  • Is "strand" helpful? Or should "chr1:1234:-:A:C" just be described as "chr1:1234:T:G"?
  • How to deal with different references?
    • Include a reference identifier in database key -- "hg18:chr:pos:refseq:varseq"
    • Extend database schema to include multiple identifiers per locus, so "hg18:chr1:1234" and "hg19:chr1:1235" can map to the same variant ID
  • Ensure only one page per variant. E.g., if rs1234 maps to chr1:1234:T:G and causes ABCD-A1T, then there should only be one GET-Evidence page regardless of which order those identifiers are looked up / used to create a page.


#1 Updated by Tom Clegg about 9 years ago

dbSNP rsid's can now be used by import robots. Non-nsSNP variants have been imported from PharmGKB and HuGENet GWAS.

In order to allow GET-Evidence to show genome hits for these variants, Trait-o-matic's "/browse/allsnps" report now includes all GET-Evidence hits -- even the "uninteresting" ones that don't appear on the Trait-o-matic result pages -- in addition to nsSNPs.

Example: http://evidence.personalgenomes.org/rs2664170

#2 Updated by Tom Clegg about 9 years ago

Need to prevent redundant entries -- for example, PharmGKB citations were attached to http://evidence.personalgenomes.org/rs1142345 instead of http://evidence.personalgenomes.org/TPMT-Tyr240Cys

#3 Updated by Ward Vandewege over 8 years ago

  • Project changed from External to GET-Evidence
  • Category deleted (GET-Evidence)

#4 Updated by Madeleine Ball over 8 years ago

  • Priority changed from High to Normal

Also available in: Atom PDF