Methods reporting in the fMRI literature

(Thanks to Micah Allen for the original Tweet and to Craig 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.

i-fMRI: Introducing a new post series

My colleague, MathematiCal Neuroimaging and I have been discussing what we see as flaws or limitations in current functional MRI scanners and methods, and what the future might look like were there ways to change things. So, in part to force us to consider each limitation with more rigor, and in part to stimulate thought and even activity within the neuroimaging community towards a brighter future, we decided to start a new series of posts that we'll cross-reference on our blogs. This blog will focus on the hand-wavy, conceptual side of things while at MathematiCal Neuroimaging you'll find the formal details and the mathematics.

We have loose plans at the moment to address the following topics: magnetic field strength considerations, gradient coil design considerations, RF coil design considerations, pulse sequences, contrast mechanisms, and motion and motion correction. We're going to hit a topic based on our developing interests and the issues that our local user community brings to us, so apologies if your fave doesn't actually appear in a post for months or years to come.


"You wanna go where? I wouldn't start from here, mate."

Blogs seem like the perfect vehicle for idle speculation about a fantasy future. The issues and limitations are very real, however, so that's where we will initiate the discussions. Then, wherever possible, we will gladly speculate on potential solutions and offer our opinions on the solutions that seem apparent today. But we're not going to try to predict the future; we will invariably be wrong. That would also be beside the point. What we want to do is motivate researchers, engineers and scanner vendors to consider the manifold ways an fMRI scanner and fMRI methods might evolve.

Note that in the last paragraph I referred specifically to an "fMRI scanner." A moment's consideration, however, reveals that most of the technology used for fMRI didn't arise out of dedicated efforts to produce a functional brain imager per se. Instead, we got lucky. Scanners are designed and built as clinical devices (worldwide sales in the hundreds to thousands) and not research tools for neuroscience (worldwide sales in the tens per year for pure research applications). A typical MRI scanner has compromises due to expense, size of subjects, stray magnetic field, applicability of methods to (paid) clinical markets, etc. Other forces are at work besides the quality and utility of fMRI. And these forces can be a mixed blessing.

Thus, part of the motivation for writing this post series is to provoke consideration of alternative current technologies; hardware or methods that exist right now but for whatever reason aren't available on the scanner you use for fMRI. Perhaps there are simple changes that can benefit fMRI applications even if these changes compromise a clinical application. For some facilities, like mine, that would be an acceptable trade.


What's in a name?

On this blog I'll use the moniker i-fMRI to label these op-ed posts. You can interpret the i however you like. Mathematicians might want to consider an imaginary scanner. Engineers might want to consider an impractical scanner. (This variant happens to be my preference.) Economists and business types might think of an inflationary fMRI scanner, because it's likely that the developments we seek will only drive the cost up, not down. And you neuroscientists? Well, we hope you'll consider your ideal fMRI scanner.

(Apple, if you're reading this - too late. We already sold the i-fMRI trademark to some company in China. Sorry.)