Draft checklist for fMRI methods reporting in the literature

It took a little longer to get to than I'd planned, but contained in this post is a first pass at a checklist for acquisition parameters that I think should be included in the methods section of fMRI papers. This draft is an attempt to expand and update the list that was given in the 2008 paper from Poldrack et al. (I have reproduced below the section on acquisition that appeared in that 2008 paper.) Here, I tried to focus on the bulk of fMRI experiments that use 1.5 to 3 T scanners with standard hardware today. 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 have to be added down the road.

In an attempt to make it didactic I have included explanatory notes. I went verbose instead of shorthand on the assumption that many fMRI papers don't include a lot of experimental detail perhaps because the authors don't possess that level of knowledge. We might as well learn something new whilst satisfying our collective desire for better manuscripts, eh? So, I haven't even tried to determine a shorthand notation yet. As others have already commented, having a checklist is probably more useful in the near term and the idea of a shorthand is a secondary consideration that has most value only if/when a journal is attempting to curtail the length of methods sections. But I'll take a stab at a shorthand notation once the checklist has been refined in light of feedback.

I've sorted the parameters into Essential, Useful and Supplemental categories in terms of value to a reader of a typical fMRI paper. Within each category the parameters are loosely sorted by functional similarity. In the Essential category are parameters whose omission would challenge a reader's ability to comprehend the experiment. Thus, there are several acquisition options - sparse EPI for auditory stimulus delivery is one example - that appear under Essential even though they are rarely used. The assumption is that everyone would report all the Essential parameters, i.e. that a reviewer should be expected to fault a paper that doesn't contain all the Essential parameters (and a journal should be held accountable for not permitting inclusion of all Essential parameters in the published methods section rather than consigning them to supplemental material).

Useful parameters are for anal types like me who want to be reasonably assured that the authors knew what they were doing when they ran their experiments. And a good way to provide that assurance is to get into a little bit of detail on parameters that have a fundamental, if infrequently considered, effect on the data. Perhaps the best example is the readout echo spacing. We all know that EPI is fundamentally distorted in one direction, so why wouldn't we include the parameter that allows a reader to qualitatively assess the effects of distortion on the images? If the experiment claims the X node was activated yet you know the X node is just millimeters away from the W and Y nodes then you'd probably be critically interested in the spatial accuracy.

Finally there are Supplemental parameters. Unless heavy customization is being used then a reader should be able to infer many of the Supplemental parameters from the scanner model and software version. However, if you are publishing data that you expect others to be able to use for their own analyses, e.g. data that will be made available via a public database, then I would argue that many of the Supplemental parameters become essential. Furthermore, some of the Supplemental parameters may be required in order for another lab to replicate your experiment. Perhaps the Supplemental (and Useful) parameters should be included routinely in the supplemental methods section of the paper?

_________________

Here is the list of parameters recommended for reporting according to Poldrack et al. in 2008:

The new draft list is a slightly more expansive version of this list, although some of the items included above don't feature in my draft list because in my opinion they are issues that relate more closely to the experimental design than the acquisition. Specifically, the number of experimental sessions and the volumes acquired per session (as well as the number of separate time series acquisitions per session, which wasn't included previously) is usually a function of the task, not the scanner performance. Likewise, the scanner's performance is the same whether the slice prescription is whole brain for an adolescent or part-brain for an adult. I think these sorts of issues should be described separately in the larger description of the experiment, leaving us with the task of what the scanner is doing during each time series acquisition. However, for the most part the Essential column of the new draft list matches the previous suggestions given above.

Here's the new draft list, with explanatory notes (and a glossary of abbreviations) below:

(Click to enlarge.)

Questions:

Are there better ways to separate parameters into families? Does it even matter yet? (Having an ordered system is critical for a shorthand but if it's just a checklist the order of reporting should matter far less.) Any glaring omissions? Are the parameters categorized appropriately? Have I permitted a full report of parameters independent of the scanner manufacturer?

_________________

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): This may be the biggest omission of the previous checklist. 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.


Useful - Hardware Options

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.


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


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


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


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.


Supplemental - Spatial Encoding

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

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.

_________________

Abbreviations:

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