Commit 65431aec authored by Cassandra Gould van Praag's avatar Cassandra Gould van Praag
Browse files

add call summary for process4+

parent a17e4378
......@@ -9,7 +9,7 @@
**When**: TBC
**Contact**: Email Cass:
or message on Open WIN Slack #data-sharing-decision-tree
**Material we will be reviewing**:
......@@ -40,26 +40,12 @@ or message on Open WIN Slack #data-sharing-decision-tree
4. Christoph Arthofer/ he/his / WIN/FMRIB / [@cart]( / 0000-0003-1474-9963
5. Mats van Es/ he/his/ WIN-OHBA / [@psych1435](
6. Marieke Martens / she/her / Psychiatry / [@mmartens]( /
## Participation Guidelines
- We value the participation of every member of our community and want to ensure that every contributor has an enjoyable and fulfilling experience. Please show respect and courtesy to other community members at all times.
- We are dedicated to a harassment-free experience for everyone, regardless of gender, gender identity and expression, sexual orientation, disability, physical appearance, body size, race, age, religion, politics or technology choices. We do not tolerate harassment by and/or of members of our community in any form.
- We fall under the formal policy and reporting guidelines of the [University Bullying and Harassment Policy]( and we expect everyone to be a [responsible bystander](
## How do you feel about data sharing? How does your PI feel about data sharing?
**Imagine you are a WIN researcher asking "*Can I share my data?*", or "*How can I share my data?*"**
The "decision tree" document and appendices should guide you through the necessary stages to prepare your data for sharing.
**This is not a trivial process, but the purpose of this guide is to help you, not scare you!**
Today we are not writing a "user guide", simply determining whether the plans we have developed will work for you, if we have missed anything, or if there is anything we need to do to support you further.
**You are the ones who will be sharing and receiving credit for your data, so we want to make it easy for you!**
## Feedback on each step
......@@ -90,7 +76,7 @@ Add below any comments about each of the steps in this process.
- When sharing data with industry recently, industry partner was happy to keep year of birth only
- Radiographers really like to keep full date of birth.
- Sharing dicoms or nifti? P1vital wanted the dicoms.
- **table position is used in biobank pipeline (coordinate in the scanner)**. Used in an IDP.
- **table position is used in biobank pipeline (coordinate in the scanner)**. Used in an IDP. - emailed Fidel for list of dicom fields used to generate IDPs
##### Patient sex
- You would expect this to be somewhere else, but good for sanity check. +1
......@@ -113,6 +99,20 @@ Add below any comments about each of the steps in this process.
- Non-skull stripped images are used to create a reference space for creating them oxford template [Oxford-MM-1](; MMORF can be used to register non-skull stripped images to this template
- non-skull stripped images for olfactory bulb segmentation.
#### Update on Biobank dicom derived confounds
From [Alfaro-Almagro et al (2021)](
- "the Z-position of the coil (more specifically, the scanner table on which the coil is positioned) within the scanner, as read from the DICOM headers"
- "source" confounds derived from dicom headers. Items listed in supplementary tables:
- site
- Date of Service Pack change
- Protocol version (as read from DICOMs
- Date of Ramp-down event
- Date of Head Coil change
- Date of Miscellaneous scanner event
#### Quality control
- Mriqc can be run on XNAT. Would you run mriqc before your own analysis anyway?
......@@ -232,4 +232,49 @@ thank you for organising again Cass! :)
## Post-meeting summary
### Process 3: De-identification
#### dicom fields
Although most unique dicom fields aren't routinely used (except things for biobank confounds, etc.), they may come in handy when you need to "sanity check" factors such as participant sex or year of birth to confirm you are looking at the correct data, for example. Other fields which are required for analysis should be stored separately, but we should conform that before they are routinely scrubbed.
Fields to consider keeping (scrubbed on the LORIS list):
- time and date => time only
- Sex, size and weight
- Device serial number and institutional address
- study description
Alternatively we consider only hosting the dicoms in exceptional circumstanced and primarily nifti?
- nifti may be better for size?
- Anyone sharing dicoms will probably want to share nifti too, so would double up on storage.
- When sharing data with commercial partner (p1vital), they wanted nifti, so perhaps we have to plan for this eventuality any way.
#### Defacing
Avoid complete skull stripping. Preference would be to share defaced structural and the (unique) coregistration info that was derived from the non-defaced structural (transformation matrix).
### qc
People would be happy to run a simple qc as a recommended step.
### Process 4: Metadata
#### Electrophys
We're missing some knowledge here. Have people (e.g. Andrew Quinn) ready to contribute.
#### Data dictionary
Include as a recommendation.
#### Image metadata
Recommend BIDS.
Recommend acquisition protocol is also in mr protocols db.
#### Experimental protocol
Could recommend sharing ethics info (potentially study design section only) which would describe the study protocol (e.g. what data is acquired, testing order etc.)
Make sure people have a space (or are reminded to) share info about treatment groups for drug studies.
### Process 5: Sharing and attribution
#### Data freeze/releases
Some collaborators wanted new data on a rolling basis (e.g. with every 3 new participants).
Releasing a template might expect to come with versions.
#### DOI
Still unresolved. Thinking datalad representation on zenodo. Could build a plugin for xnat to run the datalad call and create the zenodo entry. Guided use of creating the required authorship info.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment