(Thanks to Micah Allen for the original Tweet and toCraig Bennett for the Retweet.)
If you do fMRI you should read this paper by Joshua Carp asap:
"The secret lives of experiments: Methods reporting in the fMRI literature."
It's a fascinating and sometimes troubling view of fMRI as a scientific method. Doubtless there will be many reviews of this paper and hopefully a few suggestions of ways to improve our lot. I'm hoping other bloggers take a stab at it, especially on the post-processing and stats/modeling issues.
At the end the author suggests adopting some sort of new reporting structure. I concur. We have many variables for sure, but not an infinite number. With a little thought we could devise a simple, logical reporting structure that could be decoded by a reader just like a header can be interpreted from a headed file. (Dicom and numerous other file types manage it, you'd think we could do it too!)
To get things started I propose a shorthand notation for the acquisition side of the methods; this is the only part I'm intimately involved with. All we need to do is make an exhaustive list of the parameters and sequence options that can be used for fMRI, then sort them into a logical order and decide on how to encode each one. Thus, if I am doing single-shot EPI on a 3 T Siemens TIM/Trio with a 12-channel receive-only head coil, 150 volumes, two dummy scans, a TR of 2000 ms, TE of 30 ms, 30 descending 3 mm slices with 10% gap, echo spacing 0.50 ms, 22 degrees axial-coronal prescription, FOV 22.4x22.4 cm, 64x64 matrix, etc. then I might have a reporting string that looks something like this:
3T/SIEM/TRIO/VB17/12CH/TR2000/TE30/150V/2DS/30SLD/THK3/GAP0.3/ESP050/22AXCOR/FOV224x224/MAT64x64
Interleaved or ascending slices? Well, SLI or SLA, of course!
Next we add in options for parallel imaging, then options for inline motion correction such as PACE, and extend the string until we have exhausted all the options that Siemens has to offer for EPI. All the information is available from the scanner, much of it is included in the data header.
But that's just the first pass. Now we consider a GE running spiral, then we consider a GE running SENSE-EPI, then a Philips running SENSE-EPI, etc. Sure, it's a teeny bit involved but I'm pretty sure it wouldn't take a whole lot of work to collect all the information used in 99% of the fMRI studies out there. Some of the stuff that could be included is rarely if ever reported, so we could actually be doing a whole lot better than even the most thorough methods sections today. Did you notice how I included the software version in my Siemens string example above? VB17? I could even include the specific type of shimming routine used, even the number and type of shim coils!
If an option is unused then it is simply included with a blank entry: /-/ And if we include a few well-positioned blanks in the sequence for future development then we can insert some options and append those we can't envisage today. With sufficient thought we could encapsulate everything that is required to replicate a study in a few lines of text in a process that should see us through the next several years. (We just review and revise the reporting structure periodically, and we naturally include a version number at the very start so that we immediately know what we're looking at!)
There, that's my contribution to the common good for today. I just made up a silly syntax by way of example. The precise separators, use of decimal points, etc. would have to be thrashed out. But if this effort has legs then count me in as a willing participant in capturing the acquisition side of this business. We clearly need to do better for a litany of reasons. One of them is purely selfish: I find it hard or impossible to evaluate many fMRI papers for wont of just a few key parameters. I think we can fix that. We really don't have an excuse not to.