4D Nucleome Network Wiki

Notes drafted by Kathia Zaleta

03-13-2017 4DN POLICY MINUTES

Next meeting April 10th, 2017

AGENDA:

1. Comments on updated flow chart and draft policy (to be distributed ahead of the call)

2. Discussion of mechanisms to approve QC metrics and standards

3. If time permits: ideas for evaluating how well our policies are working

\ 1. Comments on updated flow chart and draft policy (to be distributed ahead of the call). 2. Discussion of mechanisms to approve QC metrics and standards \

• Question: Should the data set be released because it has automated QC or because the released date has passed?
• For the automated QC pipeline, has been proposed to give the submitter a week to sign off on the results of QC, but if they do not sign off, we have proposed that the DCIC withdraws the data set from the release pipeline (for submitter their data set is not in the pipeline and they have to re-submit asap and negotiate with the program officer)
• In the case when there is not automated QC pipeline, there are three cases: 1.- the submitter does not want to release data, 2.-the submitter submit a manuscript referred to the data set and made it public and 3.-Data that has been submitted with an anticipated release data. What should we do in these cases?
• Are the QC data metrics associated with metadata? Yes
• Are the QC metrics are visible? Yes
• When do you initiate a QC pipeline for a new technology? In cases where data is ready to be released but there is no QC pipeline or DCIC is not ready to accept the data, the first step is to contact DCIC ahead of their submissions (~3 months before the investigator want to publish the data), the second is to provide QC standards (we have a question here about who is going to be responsible to provide the QC standards and need to be in agreement of the assessment) and third is to implement the metrics that need to be applied to the data sets (network and DCIC are responsible).
• An investigator that have generated a new protocol and new data type need to reach first to the Digital Curation Innovation Center (DCIC) and second reach the OMICS or DATA Analysis working groups to agree in some standards.
• Concern: \New technologies should not wait for extensive QC pipeline and the process should be with a basic set of QC standards to allow them to keep the data available. * In the case where not automated QC is available, the submitter will provide an assessment of the quality of the data and DCIC will review it. * In the case where the submitter has a manuscript that refers the data, the lab/PI have to make it available to DCIC. * In the case where there is a conversation between the PI (data generated lab) and NIH program officers, they have negotiated release dates for the data. * In the case where there is new data type and DCIC knows about it (because the submitter has to reach out DCIC), then DCIC could propose a QC pipeline and if the OMICS group can’t act on it this will become automated QC pipeline. \
• Although, the working groups (Data analysis and Omics) shouldn’t have the power about new submissions at this point, discussion about new technologies with the working groups could provide feedbacks to the PI about the QCs of the new technology.
• Is ok to Involve more people in the network to comment in new technologies? Individuals groups developing new technologies will have very good feedback from the network because there is a lot of expertise on technology development, so the lab or PI developing new technologies will be in the best position to decide what type of QC need to be done. Also, the Lab/PI can present and share in the working groups (OMICS) their new technologies with the goal to get input to continue to define new QC metrics.
• Presentation of the new technologies should be a standing action item with the very strong focus on QC and data standards.
• Should we ever release data without explicit confirmation of the submitter? Is difficult to release data without permission from the people that produce the data, however we need to do something to prevent it from been released if issues are discovered. Someone has to released or not released or we can have an automatic released.

\__

3. If time permits: ideas for evaluating how well our policies are working

• 4DN channel is working!
• Software sharing policy: we don’t know about this policy stands at the moment and we need to look at it.

Submission and release workflow_v2