LOVD 2.0

Welcome to the LOVD 2.0 bug tracking system. Please note that this bug tracking system is not for LOVD 3.0!

If you have any issues, please read the documentation and Frequently Asked Questions.
Please note that you need to register before you can submit bugs or feature requests.

Information By default, all closed tasks are hidden from view.
Click here to see all tasks.

Tasklist

FS#41 - Variant colums for dbSNP amd OMIM

Attached to Project: LOVD 2.0
Opened by Raymond Dalgleish (rwmd) - Friday, 17 April 2009, 16:12 GMT+2
Last edited by Ivo F.A.C. Fokkema (ifokkema) - Tuesday, 05 February 2013, 12:22 GMT+2
Task Type Custom column (2.0)
Category Backend / Core → Setup area
Status Closed
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version 2.0-17
Due in Version 3.0-beta-01
Due Date 2011-12-31
Percent Complete 100%
Votes 0
Private No

Details

LOVD provides the ability to create links to dbSNP and OMIM and, by default, these two links are active in the Patient/Reference column. However, dBSNP and OMIM entries are properties of the variant rather than the patient. All patients who harbour the same variant should be linked to dbSNP, but by way of the variant that they share in common, not individually through the Reference column.

It would be useful to have decicated dbSNP and OMIM columns associated with Variants. The input fields would only require appropriate DBSNP or OMIM numbers to be inserted; nothing else.

I guess that I could create custom Variant columns myself and then make the dbSNP and OMIM links active in these columns. However, that\'s an untidy solution that perhaps might have unwanted consequences for data exchange. A field containg only a dbSNP rs number is easier to exchange that one that contains code for a link.
This task depends upon

Closed by  Ivo F.A.C. Fokkema (ifokkema)
Tuesday, 05 February 2013, 12:22 GMT+2
Reason for closing:  Implemented
Additional comments about closing:  Since no further comments have been made, I assume we agree the implementation in LOVD 3.0 is sufficient.
Comment by Marcus Minter (admin-info) - Tuesday, 26 June 2012, 16:43 GMT+2
It's true we would gain some time if both db & omim were associated with variants, as I've faced this issue once, but most of my IT needs aren't impacted by this architecture.

Regards,
M. Minter
Service informatique
Comment by Ivo F.A.C. Fokkema (ifokkema) - Friday, 13 July 2012, 16:01 GMT+2
LOVD 3.0 contains a dedicated dbSNP column on the variant side, where you can fill in just the rs ID. Personally, I think a dedicated OMIM column is a bit much since very few variants have an OMIM ID. However, both LOVD 2.0 and 3.0 have the OMIM variant custom link enabled by default in the Reference column on the variant side.
Would this be sufficient for you?

Loading...