Date post: | 03-Jan-2016 |
Category: |
Documents |
Upload: | patricia-fleming |
View: | 218 times |
Download: | 0 times |
Randy Notestine, M.S.Laboratory of Cognitive ImagingUCSD Department of Psychiatry
VA Healthcare SystemVeterans Medical Research Foundation
B.S. and M.S. in Aerospace Engineering, MIT
Licensed Mechanical Engineer
Nine years experience as anengineering consultant in CAD/CAE/CAM,with an emphasis on custom software tools
Eight years experience in Neuroimaging research
FBIRN (FUNCTION BIOMEDICAL INFORMATICS RESEARCH NETWORK)
CHARTER (CNS HIV ANTI-RETROVIRAL THERAPY EFFECTS RESEARCH)
Ten imaging sites One Picker scanner Two GE scanners Seven Siemens scanners
fMRI, sMRI, ASL datasets Joined the project in
2004 Contributed to Phase II
data processing and public release of data
Five imaging sites Originally all GE scanners Now one Phillips scanner
sMRI, MRS, DTI, CSI datasets
Participated in the proposal
Designed the informatics infrastructure for Neuroimaging Core
When will the data be created? be made public? be destroyed?
What level of data provenance is important? is a liability?
What steps need to be taken to protect the subjects? to protect the data?
Infrastructures typically utilize “groups” to control access, which is a necessary first step
But default permissions should allowgroup members access to group data
(e.g. “set group ID” in Linux)
Process “states” should also be utilized, to allow access permissions to be tailored f(t)
Uploaded -> Reviewed -> Analyzed
Collecting good data is hard enough
Uploading can be even harder, due to Scanner and Site specific details which are f(t)
No single solution willwork well for all projects
Two essentially opposite approaches are: Systems Engineer: Customize the process at each
site to improve uniformity of uploads Paranoid Engineer: Grab the data ASAP and
minimize operations at sites
Stable control systems require feedback!
Design as much feedback into your informatics infrastructure as possible
Web interfaces vs. E-mail- Dynamic information - Static but archivable- Higher design effort - Lower design
effort- Requires user action - Risk user
filtering
Establish goals for data provenance Document analysis steps Identify hardware and software used
Set limits and stick to them
Watch out for “quick sand” scenarios
Understand the data life cycle before you build infrastructure or collect data.
Understand the data collection process at each site before you write the upload scripts.
Design systems to fully utilize data access permissions, rather than fight them.
Feedback, feedback, feedback!
Data provenance is good … in moderation.