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!

Wednesday, January 30, 2013

A checklist for fMRI acquisition methods reporting in the literature

This post updates the draft checklist that was presented back in October. Thanks to all who provided feedback. The updated checklist, denoted version 1.1, incorporates a lot of the suggestions made previously. The main difference is the reduction from three to two categories. The logic is that we should be encouraging reporting of "All of Essential plus any of Supplemental" parameters in the methods section of any fMRI publication.

(Click to enlarge.)

Explanatory notes, consolidated from the post on the draft list, and abbreviations appear below.

Note that the present list aims primarily at fMRI experiments conducted on 1.5 or 3 T scanners. I further assumed that you're reporting 2D multislice EPI or spiral scanning. Advanced and custom options, such as multiband EPI, 3D scans and 7 T, will be added in future versions. Please see the post on the draft list for a complete explanation of how the list evolved to this point.

Keep the comments coming. This is an ongoing process.


Explanatory notes:

Essential - Scanner

Magnetic field strength: In lieu of magnetic field strength the scanner operating frequency (in MHz) might be considered acceptable. I'm assuming we're all doing 1-H fMRI. If not, chances are the methods section's going to be very detailed anyway.

Essential - Hardware Options

Rx coil type: For standard coils provided by the scanner vendor a simple description consisting of the number of independent elements or channels should suffice, e.g. a 12-channel phased array coil, a 16-leg birdcage coil. Custom or third-party coils might warrant more detailed information, including the manufacturer. Most head-sized coils are Rx-only these days, but specifying Rx-only doesn't hurt if there could be any ambiguity, e.g. a birdcage coil could quite easily be Tx/Rx.

Essential - Spatial Encoding

Pulse sequence type: A generic name/descriptor is preferred, e.g. single-shot EPI, or spiral in/out.

Number of shots (if > 1): Multi-shot EPI isn't a common pulse sequence; single-shot EPI is by far the most common variant, even if acquired using parallel imaging acceleration. I include this option to reinforce the importance of reporting the spatial encoding accurately.

PE acceleration factor (if > 1): This is usually called the acceleration factor, R in the literature. Vendors use their own notation, e.g. iPAT factor, SENSE factor, etc.

PE acceleration type (if > 1): It seems that most vendors use the generic, or published, names for parallel imaging methods such as SENSE, mSENSE and GRAPPA. I would think that trade names would also be acceptable provided that the actual (published) method can be deciphered from the scanner vendor and scanner type fields. But generic names/acroynms are to be preferred.

PE partial Fourier scheme (if used): Convention suggests listing the acquired portion/fraction of k-space rather than the omitted fraction. Any fraction that makes sense could be used, e.g. 6/8 or 48/64 are clearly equivalent.

Note: I plan on adding a list of parameters suitable for slice direction acceleration - the so-called multiband sequences - in a future version.

Essential - Spatial Parameters

In-plane matrix: This should be the acquired matrix. If partial Fourier is used then I would suggest reporting the corresponding full k-space matrix and giving the partial Fourier scheme as listed above. But I wouldn't object to you reporting that you acquired a 64x48 partial Fourier matrix and later reported the reconstructed matrix size as 64x64. So long as everything is consistent it's all interpretable by a reader. (But see also the In-plane reconstructed matrix parameter in the Supplemental section.)

In-plane inline filtering (if any): Non-experts may be unaware that filtering might be applied to their "raw" images before they come off the scanner. It's imperative to check and report whether any spatial smoothing was applied on the scanner as well as during any "pre-processing" steps subsequent to porting the time series data offline.

Slice thickness and Inter-slice gap: For now I would use the numbers reported by the scanner, even though there may be some small variation across scanner vendors and across pulse sequences. For example, some vendors may use full width at half slice height while others may use a definition of width at or near the base, there may be pulse sequence options for RF excitation pulse shape and duration, etc. I see these details as secondary to the essential reporting improvements we're aiming for.

Slice acquisition order: Interleaved or contiguous would be sufficient, although explicit descending (e.g. head-to-foot) or ascending (e.g. foot-to-head) options for contiguous slices would be acceptable, too. Presumably, the subsequent use of slice timing correction will be reported under the post-processing steps (where most fMRIers call these "pre-processing" because they are applied before the statistical analysis).

Essential - Timing Parameters

TR: For single-shot EPI with no sparse sampling delay the TR also happens to be the acquisition time per volume of data. But if sparse sampling or multiple shot acquisition is being used then the TR should be clearly reported relative to these options. The conventional definition of TR is the time between successive RF excitations of the same slice. Thus, by this definition the reported TR would include any sparse sampling delay, but it would specify the time of each separate shot in a multi-shot acquisition and the per volume acquisition time would become TR x nshots.

No. of volumes in time series: Dummy scans (not saved to disk) should be reported separately. Likewise, the use or rejection of the first n volumes for task-related reasons, e.g. to allow a subject to acclimatize to the scanner sounds, should also be reported separately in the post-processing segment of the experiment. In this field we are only interested in the total quantity of data available to the experimenter.

No. of averages/volume (if > 1): I don't think I've ever seen anyone do anything but one average per TR for single-shot EPI/spiral (unless they've screwed something up) and I can't think of a reason why someone would want to do it for fMRI. But, if it happens for some reason then it's really, really important to specify it.

Essential - RF & Contrast

Fat suppression scheme: It's sufficient to state that fat saturation or fat suppression was used, for example. Further details aren't required unless the scheme was non-standard, e.g. a custom spatial-spectral excitation scheme. 

Essential - Customization

Sparse sampling delay (if used): Sometimes called "Delay in TR" on the scanner interface. Used most often for auditory stimulus or auditory response fMRI.

Prospective motion correction scheme (if used): PACE is one commercial option. These schemes fundamentally change the nature of the time series data that is available for subsequent processing and should be distinguished from retrospective (post-processing) corrections, e.g. affine registration such as MCFLIRT in FSL. It is also critical to know the difference between motion correction options on your scanner. On a Siemens Trio running VB15 or VB17, for instance, selecting the MoCo option enables PACE and a post hoc motion correction algorithm if you are using the sequence, ep2d_pace whereas only the post hoc motion correction algorithm - no PACE - is applied if you are using the ep2d_bold sequence. There's more detailed information on these options in my user training guide/FAQ.

Cardiac gating (if used): This isn't a common procedure for fMRI, and recording of cardiac information, e.g. using a pulse oximeter, is radically different from controlling the scanner acquisition via the subject's physiology. The recording of physiological information doesn't usually alter the MRI data acquisition, whereas gating does. Reporting of physio information is tangential to the reporting structure here, but if you are recording (and using) physio data then presumably you will report it accordingly somewhere in the experiment description.

Supplemental - Hardware Options

Gradient set type: It should be possible to infer the gradient coil from the scanner model. If not, e.g. because of a custom upgrade or use of a gradient insert set, then the specifications of the actual gradient coil should be reported independently.

Tx coil type (if non-standard): It should be possible to infer the Tx coil from the scanner model. If not, e.g. because of a custom upgrade or use of a combined Tx/Rx coil, then the new Tx coil should be reported independently. I would also advocate including the drive system used if the coil is used in anything but the typical quadrature mode.

Matrix coil mode (if used): There are typically default modes set on the scanner when one is using un-accelerated or accelerated (e.g. GRAPPA, SENSE) imaging.  If a non-standard coil element combination is used, e.g. acquisition of individual coil elements followed by an offline reconstruction using custom software, then that should be stated.

Coil combination method: Almost all fMRI studies using phased-array coils use root-sum-of-squares (rSOS) combination, but other methods exist. The image reconstruction is changed by the coil combination method (as for the matrix coil mode above), so anything non-standard should be reported.

Supplemental - Spatial Encoding

PE direction: If you've shown any examples of EPI in your paper then the PE direction can usually be determined from the image. If N/2 ghosts or distortions aren't obvious, however, then it's rather important that the phase encode direction is stated, in concert with the readout echo spacing, so that a reader can infer your spatial accuracy.

Phase oversampling (if used): There's no reason to use phase oversampling for EPI - you're wasting acquisition time - but if you are using it for some reason then it should be reported consistent with the acquired matrix, acquired FOV, echo spacing and associated parameters.

Read gradient bandwith: Not an intrinsically useful parameter on its own, it does have value if reported in conjunction with the echo spacing. (An alternative to this single parameter would be the read gradient strength (in mT/m) and the digitizer bandwidth (in kHz).)

Readout echo spacing: Rarely reported but really useful! This number, in conjunction with the FOV and acquired matrix size, allows a reader to estimate the likely distortion in the phase encode direction.

Pulse sequence name: Could be invaluable for someone wanting to replicate a study. There may be multiple similar pulse sequences available, all capable of attaining the specifications given, but it is entirely feasible that only one of the sequences has a particular quirk in it!

k-space scheme: Readers will assume linear (monotonic) k-space steps in the PE direction unless indicated to the contrary. Centric ordering or other atypical schemes should be indicated, especially in concert with multiple shots if the Number of shots parameter is greater than one.

Read gradient strength: Could be useful in conjunction with information about the ramp sampling percentage and echo spacing time, otherwise probably of limited value to most readers.

(Ramp sampling percentage:) Ramp sampling can increase the N/2 ghost level considerably if there is appreciable gradient and digitization (data readout) mismatch. But determining the percentage of readout data points that are acquired on the flat vs. the ramp portions of each readout gradient episode can be involved. And for routine studies, as opposed to method development studies, there's probably not a whole lot of value here. Maybe remove it?

(Ghost correction method:) N/2 ghost correction usually happens invisibly to the user, but there are some options becoming available, especially useful for large array coils (e.g. 32-channel coils) where there may be local instabilities with some ghost correction methods. If known, and if non-standard, then it would be nice to report. But perhaps more overkill for fMRI methods?

PE partial Fourier reconstruction method: If the scanner offers more than one reconstruction option then the chosen option should be reported.

Supplemental - Spatial Parameters

In-plane resolution: This field is redundant if the reconstructed matrix (In-plane matrix parameter) and FOV are reported, but I for one wouldn't object to seeing the nominal in-plane pixel size given anyway. It may make the paper a faster read. Probably not worth arguing about. (Cue extensive debate...!)

In-plane reconstructed matrix: This is for reporting of zero filling (beyond the default zero filling that may have been done for a partial Fourier acquisition) to a larger matrix than acquired, prior to 2D FT. There may be modeling issues associated with the number of voxels in the image, not least of which is the size of the data set to be manipulated! It could save someone a lot of angst if she knows what you did to the data prior to uploading it to the public database.

Supplemental - Timing Parameters

No. of dummy scans: This is the number of dummy scans used to establish the T1 steady state. Many fMRI experiments also use acquired volumes subsequent to the (unsaved) dummy scans for neuroscientific reasons, e.g. to allow definition of a BOLD baseline or adjustment to the scanner noise. These two parameters should be reported separately.

Supplemental - RF & Contrast

Excitation RF pulse shape and Excitation RF pulse duration:  Not critical for standard pulse sequences on commercial scanners, but if atypical values are set in order to achieve very thin slices, for example, then reporting these parameters may be benenficial. These two parameters will become essential, however, when considering multiband EPI in the future.

Supplemental - Customization

Image reconstruction type: Unless specified to the contrary, most readers will assume that magnitude images were taken from the 2D Fourier transform that yielded each individual EPI. If you use complex data - magnitude and phase - then that option should be specified along with the particular processing pipeline used to accommodate the atypical data type.

Shim routine: If manual shimming or an advanced phase map shimming routine is used, especially to improve the magnetic field over restricted brain volumes, then this information should be reported.

Receiver gain: Most scanners use some form of autogain to ensure that the dynamic range at the receiver is acceptable. If manual control over receiver gain is an option and is used then it should be reported because a mis-set gain could lead to artifacts that aren't typically seen in EPI, and a reader could subsequently attribute certain image features to other artifact sources.



FOV - field-of-view
N/2 - Half-FOV (for Nyquist ghosts)
PE - phase encode
Rx - Radiofrequency (RF) receiver
Tx - Radiofrequency (RF) transmitter
TE - echo time
TR - repetition time


  1. hi ben

    how much of this can we get straight from a dicom and which require specific observations on the protocol card.

    i think it would be great to add that info as well.

  2. Hi Satra,

    In my experience the DICOM header can be tricky to interpret. The information is in there, somewhere, but determining which field is which can be a serious headache. And once one is converting to other image types, all bets are off, of course.

    Thus, my suggestion would be for each experimenter to spend the fifteen minutes in front of the scanner with the facility physicist, and ensure that the information collated is accurate and (gasp!) understood by the experimenter!

    Now, the initial idea was to derive a shorthand notation such that no journal would be able to submerge the critical methods information into online supplemental material on the basis of space. (I fail to see how anyone can read and interpret a paper sans methods, but that's a separate discussion.) If someone wanted to create a script that could grab the info out of a DICOM header and produce a shorthand string that could be machine- or human-readable, I'd be all for it! Vendors' DICOM fields don't change quickly so it ought to be relatively trivial to keep things up-to-date. And there are only three major vendors to deal with in the first pass.


    (Anyone who missed the initial post on the shorthand, see

  3. This is a fantastic proposal and I'll definitely be following it in my future papers.

  4. That is great work. Can you post a pdf copy so I can share it more easily?

  5. Hi Brian, Blogger doesn't permit PDF so here's a link to the file on Dropbox:

    Just in case anyone wants to re-jig the list to their own format, here's the Word file, too:


  6. Ben

    How about a line for any image normalization (if used)? - eg. prescan normalization.

  7. Looks like you have the prescan norm issue covered in the "In-plane inline filtering" category.

  8. DS.... Oops. I actually intended the "In-plane inline filtering" to refer to kernels applied to either the k-space or the image data in isolation, e.g. a Fermi filter, and not to EPI normalized by another spatial map (however the latter is generated). So, you've come up with the first new term to add to version 1.2, clearly!

  9. For Tx coil with inhomogeneous exciting profile such as surface coil, the excitation flip angle is just a nominal value. So, maybe put nominal flip angle or the RF power instead of flip angle?
    One more thing, spatial saturation might be important and can be listed in supplemental.

    1. Hi Chern-Chyi,

      You raise two good points. There are basically two reasons why these sorts of advanced features aren't listed in the checklist now. Firstly, the aim at the moment is to capture the parameters being used in the large majority of fMRI studies on 1.5-3 T studies. Secondly, the checklist is aimed at those who may not have detailed understanding of the acquisition. There's a balance between having an exhaustive list and something that is useful to the fMRI masses. I'd hope that anyone using a Tx/Rx surface coil and/or spatial saturation would be relatively expert in the acquisition and would know what to include in a paper.

      In the next version I'll be including multiband (aka simultaneous multislice) parameters. I'll also assess the literature to see if including sat bands makes sense yet.