Forgive what will be a series of very beginner questions.
I have never processed physiological data from scratch before. We use a GE Healthcare Discovery MR750 3T MR System and obtain PPG and RESP data.
My first issue is I have not been able to find online WHAT exactly the y-axis is when the data is obtained. I understand the PPG, “Pulse monitoring uses a photopulse sensor to detect blood flow in the vascular bed of the patient’s finger” so seemingly is a measure of heart beats while, “The Respiratory bellows detects the motion of the abdominal wall” but if anyone knows exactly what the numbers correspond to that would be really great to know. I’ve emailed a few scan techs and a physicist at my scanning location and surprisingly have not received any useful reply.
However that’s not the main issue. I would like to use these physiological signals as regressors when preprocessing my task data and understand I can get these regressors with RetroTS. However when I graphed the raw RESP and PPG data from 3 subjects from the same experimental run they look pretty different. I attached two screenshots showing each measure. I suppose I’m just wondering how to handle physiological data in general: Should either of these measure THEMSELVES be preprocessed or “cleaned” before running RetroTS? For example, subject 1’s (blue) RESP data drops to 0 sometimes. Is this bad? If so how should I handle it? Is there more information or resources anyone can provide about this?
To follow up on this - I read in a post on another forum that generally the raw physiological data should be used as input to a variety of software. If this is the case for RetroTS, my cardiac and respiratory data have different sampling rates (PPG: 10ms, RESP: 40ms). If I’m just inputting the raw data should I:
Downsample the PPG
Upsample the RESP
Run RetroRS separately for each measure with the raw data from each?
Also GE tacks on an additional 30s of data from before the start of the scan. I’m assuming this should be discarded before the processing?
I noticed no one and replied to you yet and wanted to write up a partial reply. The pulse oximeter output should be a measure of relative blood oxygenation. I wouldn’t try to give meaning to the raw values, but oxygenation fluctuates slightly with the cardiac cycle so you can get the heart rate from this output. Here are two articles I just searched for that might give you a better sense of what the fluctuations in a pulse oximeter time series can mean: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC137227/ https://www.sciencedirect.com/science/article/pii/S095461111300053X
Different respiratory belts work different ways. Some (I think the typical GE one) convert the length of a stretchy section of a belt into a range of values depending on the belt length. Others (I think the typical Siemens one) compress an air bladder or a plunger. In both cases, the values are relative so you should see a sine-like signal of the chest going in and out, but don’t worry about the raw value magnitudes. That said, for the plunger and air bladder styles, they are somes set to re-calibrate the range of values during data collection which could cause a relative magnitude shift. This can cause problems with RETROICOR.
I’m not completely sure what’s happening in your respiration traces, but, if the belt is too loose or in the wrong place on the chest, it might not reliably get the full chest expansion and contraction. I can’t interpret your pulse oximeter traces, but the typical issue with that data is that finger motion that wobbles the signal can mess up the traces. As the first link above shows, that’s pretty easy to notice when you look at the time series more closely.
The input to RetroTS.py should cover the exact same time window as the MRI scan. If you don’t know exactly when the scan began relative to your respiration & cardiac traces, that can cause issues. If you know there are exactly 30s at the beginning, that should be relatively easy to remove. Once you run RetroTS.py, it’s good to look at the output to make sure it ran correctly. Usually issues arise when there is hand motion and the pulse oximeter trace misses heart beats or adds to many. Depending on the situation, it might be possible to correct some of these mistakes. I haven’t dealt with this too recently so hopefully someone else can suggest best practices if you have a time series that’s good enough to use, but has a few mistakes that need to be corrected.
I’m not sure what to do with the different respiration and cardiac sampling rates. Upsampling the respiration data should be fairly harmless, but there might be more elegant solutions.
Just wanted to thank you for this. This is truly the clearest and most concise description of any of this data that I’ve gotten so far. I was able to get an appropriate RetroTS output from your guidance although I’m not exactly sure how useful the regressors will be given the issues with the data you specified.
I mostly just wanted to be able to make informed choices with the data and you’ve helped me do that I very much appreciate you sharing your knowledge. I would love to hear if anyone had an idea of best practices for physiological data that may be this variable or in instances where ‘outliers’ or ‘finger movement’ may be obvious.
Again thank you so much for your great explanation.
Lauren
P.S. I guess I DID have one final question - I understand that in the slibase output of RetroTS you get 13 regressors per slice. When you use these in your proc.py generated code (or in general) do you input the slibase file as-is? Or do you need to change it? In cases of 33 slices 429 “regressors” is a lot but I feel like I’m misunderstanding what this actually does.
The slibase regressor files should match the EPI data in
time point length, and there should be one such file per
run.
Pass them to afni_proc.py via -ricor_regs, and be sure
that -ricor_regs_nfirst (for the slibase regressors) and
-tcat_remove_first_trs (for the EPI runs) result in
correct time point matching between the two. They are
often the same, but that depends on how they are acquired.
Note that 429 regressors is not “a lot” in terms of degrees
of freedom, it is still just 13 DoF for 13 regressors. The
only special point is that there are different regressors
for different slices.
A farther example of such a thing would be ANATICOR, where
each voxel would get its own regressor for the average
local white matter signal. That would account for just 1
regressor/DoF, even though there might be 100,000 such
regressors in the dataset (one per voxel).
Does that seem reasonable?
rick
The
National Institute of Mental Health (NIMH) is part of the National Institutes of
Health (NIH), a component of the U.S. Department of Health and Human
Services.
