1. Randy Notestine, M.S. Laboratory of Cognitive Imaging UCSD Department of Psychiatry VA Healthcare System Veterans Medical Research Foundation

2.  B.S. and M.S. in Aerospace Engineering, MIT  Licensed Mechanical Engineer  Nine years experience as an engineering consultant in CAD/CAE/CAM, with an emphasis on custom software tools  Eight years experience in Neuroimaging research

3. 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

4.  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?

5.  Infrastructures typically utilize “groups” to control access, which is a necessary first step  But default permissions should allow group 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

6.  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 will work 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

7.  Stable control systems require feedback!  Design as much feedback into your informatics infrastructure as possible  Web interfacesvs.E-mail - Dynamic information- Static but archivable - Higher design effort- Lower design effort - Requires user action- Risk user filtering

8.  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

9.  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.