Education, tips and tricks to help you conduct better fMRI experiments.
Sure, you can try to fix it during data processing, but you're usually better off fixing the acquisition!

Thursday, July 26, 2012

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:


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

Friday, July 6, 2012

Siemens slice ordering

I've heard on the wind that there is still confusion or even a total lack of awareness of the change in slice ordering for interleaved slices when going from an odd number to an even number of slices, or vice versa. It makes a big difference for slice timing correction. So I though I'd post below a section from my user training guide/FAQ as a ready reference. Note that as far as I know this change in slice ordering is only an issue for Siemens scanners running VB15 or VB17 software, I can't comment on VD11 or other versions, and I haven't actually tested any scanner platform except a TIM Trio. Furthermore, it's only an issue if you're using interleaved slices. If anyone has additional information, especially if it conflicts with the situation posted here, then the field would probably appreciate a comment!


In what order does the scanner acquire EPI slices?

There are three options for slice ordering for EPI. To understand the ordering you first need to know the Siemens reference frame for the slice axis: the negative direction is [Right, Anterior, Foot] and the positive direction is [Left, Posterior, Head]. The modes are then:
  • Ascending - In this mode, slices are acquired from the negative direction to the positive direction.
  • Descending - In this mode, slices are acquired from the positive direction to the negative direction.
  • Interleaved - In this mode, the order of acquisition depends on the number of slices acquired:
    • If there is an odd number of slices, say 27, the slices will be collected as:
1 3 5 7 9 11 13 15 17 19 21 23 25 27 2 4 6 8 10 12 14 16 18 20 22 24 26.
    • If there is an even number of slices (say 28) the slices will be collected as:
2 4 6 8 10 12 14 16 18 20 22 24 26 28 1 3 5 7 9 11 13 15 17 19 21 23 25 27.

Interleaved always goes in the negative to positive direction, e.g. foot-to-head for transverse slices.

So, if you are doing 28 interleaved axial slices the order will be evens then odds in the foot-to-head direction. 27 interleaved axial slices would also be acquired in the foot-to-head direction but would be in the order odds then evens. If you switch to 28 descending axial slices the acquisition order will become 1,2,3,4,5…28 and the direction will swap to being head-to-foot.

Tuesday, July 3, 2012

Physics for understanding fMRI artifacts: Part Thirteen

A tour through a real EPI pulse sequence

In some posts I've got planned it will be important for you to know something about all of the different functional modules that are included in a real EPI pulse sequence. So far in this PFUFA series I've used schematics of the particular segment of the sequence that I was writing about, e.g. the echo train that covers 2D k-space for single-shot EPI. Except that there comes a time when you need to know about the sequence in its entirety, as it is implemented on a scanner. Why? Because there are various events that I've given short shrift - fat saturation and N/2 ghost correction, for instance - that have significant temporal overheads in the sequence, and these additional delays obviously affect how quickly one can scan a brain.

So, without further ado, here is a pulse sequence for fat-suppressed, single-shot gradient echo EPI, as used for fMRI:

(Click to enlarge.)

Okay, so it's not the entire pulse sequence. The readout gradient echo train in this diagram has been curtailed after just nine of 64 total gradient echoes that will be acquired, for EPI with a matrix of 64x64 pixels. The omitted 55 echoes are simply clones of the nine echoes that you can see. (Note that there are no additional gradient episodes at the end of this particular EPI sequence; all the crusher gradients occur at the start of the sequence and these are visible in the above figure. More on crusher gradients below.) I should also point out that this is the timing diagram for acquisition of a single 64x64 matrix EPI slice. The pulse sequence as shown would be repeated n times for n slices within each TR. (See Note 1.)

Interpreting what you see

Let's first determine what information is being displayed on the figure above. There are five axes, all handily labeled on the far right-hand side of the figure. The top axis is the RF transmit channel; we've got two RF pulses in this sequence. The second axis down is the receiver, or analog-to-digital converter (ADC) channel. The scanner is receiving signals only when there's a rectangle specified on the second axis. Finally, the bottom three axes represent the pulsed field gradients, in the order X, Y, Z.

Just for fun, let's quickly determine what the scanner is doing in the logical frame of reference, before we delve into the nitty-gritty. The slice selection gradient will occur in concert with an RF excitation pulse, and we have two RF pulses to choose from. Slice selection can't be the first RF pulse because that pulse occurs without any concomitant gradients. Thus, the slice excitation pulse must be the second one and we can deduce that slice selection is along the Z axis, which is the magnet bore axis. We're doing axial slices.