XML feeds can produce invalid output, notably by including unescaped ampersands (&).

Example gene feed:
<?xml version="1.0" encoding="ISO-8859-1"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>TSC2</title>
<link rel="alternate" type="text/html" href="http://chromium.liacs.nl/LOVD2/TSC/home.php?select_db=TSC2"/>
<id>tag:chromium.liacs.nl,2005-01-24:TSC2</id>
<author>
<name>Dr. Johan T. den Dunnen</name>
</author>
<contributor>
<name>Sue Povey & Rosemary Ekong</name>
</contributor>
<published>2005-01-24T00:00:00+01:00</published>
<updated>2012-07-02T16:34:29+02:00</updated>
<content type="text">
id:TSC2
entrez_id:7249
symbol:TSC2
name:Tuberous sclerosis 2
chromosome_location:16p13.3
position_start:chr16:2097990
position_end:chr16:2138712
refseq_genomic:NG_005895.1
refseq_mrna:NM_000548.3
refseq_build:hg19
</content>
</entry>

The ampersand in root>entry>contributor>name should be escaped. Unescaped ampersands can defeat XML parsers :(

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.

On the Configuration tab near the top right there is a 'Quicklink' to uncurated variants for the selected gene. More correctly, this seems to link instead to any variant that is Submitted, Non-public or Marked. I have instances of the latter two in my databases where the entries are curated, but not yet made public, or are marked to remind me to go back to them later.

I suggest that the Uncurated Quicklink be replaced by Quicklinks for 'Submitted', 'Non-public' and 'Marked'. This would improve the usability of LOVD.

Title: feature request to import variants reports often generated by high throughput technology such as next generation sequencing etc
Description of the problem: the current filed of genetic testing is moving from single gene testing to multi gene testing where handful of gene variants are reported at once. The current LOVD submission scheme is limited to uploading single gene variants. Thus if I have variants for 50 samples for 24 genes, the most efficient way is to create variant import file for each gene adding considerable time to the submission process while it is technically possible to do in one step
solution: add subsection to /config_import.php to identify gene and separate variant tables based on gene symbol allowing import of multiple genes from one file

We've set up LOVD at our institution using the network security mandated version 5.5 of PHP
and are having the following trouble with the installation:

when Im on a the gene home page,
http://hci-lovd.hci.utah.edu/home.php?select_db=MSH2
,and select type, or simple or advanced
the next page is the select gene database
which will send me back to a gene home page depending on which I select

another behavior:
If I go to a gene page and select Unique sequence variants it will take me to
http://hci-lovd.hci.utah.edu/variants.php?select_db=MSH2&action=view_unique


but if I click on Hide Specific Columns I get this error:
Error: NoCurrDB (Logged)
Currently, no gene was selected or sent, but the currdb class has been initiated. This is a in LOVD or in one of it's modules.
Debug: /views_columns.php?action=view_all&hide=true

any ideas would be greatly appreciated

In build 26, changes were made to LOVD 2.0 with regard to the "Detection" columns:

'In new LOVD installations, the following columns are now on the variant side: "Detection/Template", "Detection/Technique", "Detection/Tissue".'

I have just created a new installation of LOVD 2.0 and find that I cannot edit the contents of the "Detection/Technique" column now that it's "Variant/Detection/Technique" using the box at the bottom of 'LOVD Setup - Systems settings' page. Of course, the list of techniques can still be edited using the column data type wizard, but the box which was formerly used for editing the list now seems to be non-functional and redundant.

The "LOVD - Current system status" page displays the total "Total variants" and "Unique variants" for each gene. It would be useful to add an additional column to display the "Number of patients" for each gene.

LOVD creates tables (text and HTML) of exon coordinates which are stored in the /refseq sub-directory. It would be useful to provide a link to the HTML version of the table (to open in a new tab) on the variant submission form. At present, there is a link adjacent to the DNA change box (just below the "Check variant with Mutalyzer 2.0" button) that allows access to the HTML view of the cDNA and intron sequence. A link to the exon table would be useful too because most of the time I just want to work out (or confirm) the exon in which the variant lies. The data displayed in the table are a more convenient source of information for this task.

It is awkward to create a patient record with variants in different genes. Creating the record for the first variant is straightforward. If you then try to create a second variant immediately, LOVD assumes that the variant must be in the same gene. Their is no obvious way to select another gene before the patient details are entered. The workaround is to only enter the one variant for the pateint and then to finalize the submission. Once that\'s done, you can change the gene and create the variant entry in that gene. When that\'s complete you can then attempt to use the \"Using an existing patient\" button. The problem is that you then get prompted to enter the ID for that patient and there is no way to look it up. You have to have written it down (or have a photographic memory).

The ideal solution would be the ability to change gene, as necessary, for each additional variant to be recorded for a patient. Alternatively, there should be the ability to look-up the patient.

LOVD was modified in build 30 so that the Reply-To header in emails sent out by LOVD now points to the data submitter. Could this also be fixed for submitter registrations?