Tuesday, July 29, 2014
UCLA has their excellent summer Neuroimaging Training Program (NITP) going on as I type. Most talks are streamed live, or you can watch the videos at your leisure. Slides may also be available. Check out the schedule here.
I am grateful to Lauren Atlas for tweeting about the NIH's summer fMRI course. It's put together by Peter Bandettini's FMRI Core Facility (FMRIF). It started in early June and runs to early September, 3-4 lectures a week. The schedule is here. Videos and slides are available a few days after each talk.
Know of others? Feel free to share by commenting!
Saturday, July 26, 2014
The majority of "scanner issues" are created by routine operation, most likely through error or omission. In a busy center with harried scientists who are invariably running late there is a tendency to rush procedures and cut corners. This is where a simple QA routine - something that can be run quickly by anyone - can pay huge dividends, perhaps allowing rapid diagnosis of a problem and permitting a scan to proceed after just a few minutes' extra effort.
A few examples to get you thinking about the sorts of common problems that might be caught by a simple test of the scanner's configuration - what I call User QA. Did the scanner boot properly, or have you introduced an error by doing something before the boot process completed? You've plugged in a head coil but have you done it properly? And what about the magnetic particles that get tracked into the bore, might they have become lodged in a critical location, such as at the back of the head coil or inside one of the coil sockets? Most, if not all, of these issues should be caught with a quick test that any trained operator should be able to interpret.
User QA is, therefore, one component of a checklist that can be employed to eliminate (or permit rapid diagnosis of) some of the mistakes caused by rushing, inexperience or carelessness. At my center the User QA should be run when the scanner is first started up, prior to shut down, and whenever there is a reason to suspect the scanner might not perform as intended. It may also be used proactively by a user who wishes to demonstrate to the next user (or the facility manager!) that the scanner was left in a usable state.
Monday, June 2, 2014
For such a short abbreviation QA sure is a huge, lumbering beast of a topic. Even the definition is complicated! It turns out that many people, myself included, invoke one term when they may mean another. Specifically, quality assurance (QA) is different from quality control (QC). This website has a side-by-side comparison if you want to try to understand the distinction. I read the definitions and I'm still lost. Anyway, I think it means that you, as an fMRIer, are primarily interested in QA whereas I, as a facility manager, am primarily interested in QC. Whatever. Let's just lump it all into the "QA" bucket and get down to practical matters. And as a practical matter you want to know that all is well when you scan, whereas I want to know what is breaking/broken and then I can get it fixed before your next scan.
The disparate aims of QA procedures
The first critical step is to know what you're doing and why you're doing it. This implies being aware of what you don't want to do. QA is always a compromise. You simply cannot measure everything at every point during the day, every day. Your bespoke solution(s) will depend on such issues as: the types of studies being conducted on your scanner, the sophistication of your scanner operators, how long your scanner has been installed, and your scanner's maintenance history. If you think of your scanner like a car then you can make some simple analogies. Aggressive or cautious drivers? Long or short journeys? Fast or slow traffic? Good or bad roads? New car with routine preventative maintenance by the vendor or used car taken to a mechanic only when it starts smoking or making a new noise?
Saturday, April 26, 2014
On Tuesday I became involved in a discussion about data sharing with JB Poline and Matthew Brett. Two days later the issue came up again, this time on Twitter. In both discussions I heard a lot of frustration with the status quo, but I also heard aspirations for a data nirvana where everything is shared willingly and any data set is never more than a couple of clicks away. What was absent from the conversations, it seemed to me, were reasonable, practical ways to improve our lot.* It got me thinking about the present ways we do business, and in particular where the incentives and the impediments can be found.
Now, it is undoubtedly the case that some scientists are more amenable to sharing than others. (Turns out scientists are humans first! Scary, but true.) Some scientists can be downright obdurate when faced with a request to make their data public. In response, a few folks in the pro-sharing camp have suggested that we lean on those who drag their feet, especially where individuals have previously agreed to share data as a condition of publishing in a particular journal; name and shame. It could work, but I'm not keen on this approach for a couple of reasons. Firstly, it makes the task personal which means it could mutate into outright war that extends far beyond the issue at hand and could have wide-ranging consequences for the combatants. Secondly, the number of targets is large, meaning that the process would be time-consuming.
Where might pressure be applied most productively?
Tuesday, April 1, 2014
Disclaimer: This isn't an April Fool!
I'd like to use the collective wisdom of the Internet to discuss the pros and cons of a general approach to simultaneous multislice (SMS) EPI that I've been thinking about recently, before anyone wastes time doing any actual programming or data acquisition.
Multi-echo EPI for de-noising fMRI data
There has been quite a lot of interest in using multi-echo EPI to characterize and de-noise time series data, e.g.
These methods rest on one critical aspect: they use in-plane parallel imaging (GRAPPA or SENSE, usually depending on the scanner vendor) to render the per slice acquisition time reasonable. For example, with R=2 acceleration it's possible to get three echo planar images per slice at TEs of around 15, 40 and 60 ms. The multiple echoes can then be used to characterize BOLD from non-BOLD signal variations, etc.
The immediate problem with this scheme is that the per slice acquisition time is still a lot longer than for normal EPI, meaning less brain coverage. The suggestion has been to use MB/SMS to regain speed in the slice dimension. This results in the combination of MB/SMS in the slice dimension and GRAPPA/SENSE in-plane, thereby complicating the reconstruction, possibly (probably) amplifying artifacts, enhancing motion sensitivity, etc. If we could eliminate the in-plane parallel imaging and do all the acceleration through MB/SMS then that would possibly reduce some of the artifact amplification, might simplify (slightly) the necessary reference data, etc.
A different approach?
Thursday, March 13, 2014
When running fMRI experiments it's not uncommon for the scanner to prohibit what you'd like to do because of a gradient stimulation limit. You may even hit the limit "out of the blue," e.g. when attempting an oblique slice prescription for a scan protocol that has run just fine for you in the past. I'd covered the anisotropy of the gradient stimulation limit as a footnote in an old post on coronal and sagittal fMRI, but it's an issue that causes untold stress and confusion when it happens so I decided to make a dedicated post.
Some of the following is take from Siemens manuals but the principles apply for all scanners. There may be vendor-specific differences in the way the safety checking is computed, however. Check your scanner manuals for details on the particular implementation of stimulus monitoring on your scanner.
According to Siemens, then:
The scanner monitors the physiological effects of the gradients and prohibits initiating scans that exceed some predefined thresholds. On a Siemens scanner the limits are established according to two models, used simultaneously:
The scanner computes the expected stimulation that will arise from the gradient waveforms in the sequence you are attempting to run. If one or both models suggests that a limit will be exceeded, you get an error message. I'll note here that the scanner also monitors in real time the actual gradients being played out in case some sort of fault occurs with the gradient control.
Thursday, February 27, 2014
There was quite a lot of activity yesterday in response to PLOS ONE's announcement regarding its data policy. Most of the discussion I saw concerned rights of use and credit, completeness of data (e.g. the need for stimulus scripts for task-based fMRI) and ethics (e.g. the need to get subjects' consent to permit further distribution of their fMRI data beyond the original purpose). I am leaving all of these very important issues to others. Instead, I want to pose a couple of questions to the fMRI community specifically, because they concern data quality and data quality is what I spend almost all of my time dealing with, directly or indirectly. Here goes.
1. Under what circumstances would you agree to use someone else's data to test a hypothesis of your own?
Possible concerns: scanner field strength and manufacturer, scan parameters, operator experience, reputation of acquiring lab.
2. What form of quality control would you insist on before relying on someone else's data?
Possible QA measures: independent verification of a simple task such as a button press response encoded in the same data, realignment "motion parameters" below/within some prior limit, temporal SNR above some prior value.
If anyone has other questions related to data quality that I haven't covered with these two, please let me know and I'll update the post. Until then I'll leave you with a couple of loaded comments. I wouldn't trust anyone's data if I didn't know the scanner operator personally and I knew first-hand that they had excellent standard operating procedures, a.k.a. excellent experimental technique. Furthermore, I wouldn't trust realignment algorithm reports (so-called motion parameters) as a reliable proxy for data quality in the same way that chemicals have purity values, for instance. The use of single value decomposition - "My motion is less than 0.5 mm over the entire run!" - is especially nonsensical in my opinion, considering that the typical voxel resolution exceeds 2 mm on a side. Okay, discuss.
UPDATE 13:35 PST
Someone just alerted me to the issue of data format. Raw? Filtered? And what about custom file types? One might expect to get image domain data, perhaps limited to the magnitude images that 99.9% of folks use. So, a third question is this: What data format(s) would you consider (un)acceptable for sharing, and why?