Constructing a database for NGS data

Question

[Swimming bird]

I need to construct a biological database to store NGS data obtained from patients (clinical diagnostics). Concretely, I want to create the following records:

• Capture-kits versions used for each sample.
• Detection parameters and programs employed.
• Coverage quality.
• Detected variants.
• Databases employed in each analysis.
• Sample/patient info.

My idea is to use MySQL but I don't know if other database management systems are more suitable for this purpose. In addition, after creating the database, I want to construct an user-friendly interface to consult the data.

I would be grateful if anyone could provide any paper, review or tutorial related to this matter.

[cpad0112]

consider data from patients as PHI and that may save you in future from regulatory actions. Look at domain models from HL-7/FHIR. They have clinical genomics template and domain model in storing patient information and standard vocabulary. I think they have necessary place holders for provenance information. eudald.t

[steve]

What you are describing is called a LIMS or LIS. There are a million already available, you're better off trying them first instead of reinventing the wheel

Answer 1

[Devon Ryan]

You're basically creating a LIMs, so the database is the trivial part (use whatever software is convenient), the front-end is where all of the effort will be devoted. We've used django and postgresql for similar sorts of needs, something like that could be applicable in your case too. If you don't need users to be able to login or submit data themselves then just make a shiny app so things are simpler.

[Swimming bird]

Ok, I'll take a look to the paper. I think that I only need to let the users consult the data but not submit or edit it.

Thanks!

[Kevin Blighe]

I have gone the Shiny App route recently, with a SQlite backend. It's quite quick in how it pulls data from the database and you still have the option to make writes to the database, too, including the creation of new tables. It is safer to prevent users from actually modifying the data, though. A way around it, if needed, is to have a 'staging' area where submitted data is held prior to a final write commit, and obviously by having backups that can be restored.

I had recently implemented all of this, including a DB table restore button and a 'crash prevention' button, but eventually decided to pull all rights from the users for writing. Experience tells me that users will be users!

[GenoMax]

I think that I only need to let the users consult the data but not submit or edit it.

Unless you are planning to do all the work yourself that does not make sense. One of the benefits of such a system is to allow users to keep track of their work (like an electronic notebook) so it is updated in real time (or as close to real as feasible). You also mention patient info so you will need to build in a good security model to ensure integrity of data and proper access.

[Swimming bird]

Yes, you're right,

Thanks for the info.