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.