fMRIPRep: multiple sessions per subject

Software Support
1

Hello, we implemented an automated processing via fMRIPrep. Essentially, a specially named series acquired at the end of the protocol triggers a script on the DICOM server that starts BIDS import and fMRIPrep, using per-study configuration files.

Everithing works pretty well, until a second session is added for the same subject.

In this case, the first session had run as the only session of the subject, while the second one finds a session already processed.

The first question is: should I delete the derivatives of the first session before running again the subject after the second session has been acquired, or the pipeline has a built-in mechanism for this case? If not, I suppose I have to delete the fressuerfer derivatives, too?

Does it apply irrespective of the —longitudinal switch?

In both cases (i.e. whether I delete the first session derivatives or not) fMRIPrep currently stops with the error:

NotImplementedError: Sophisticated PEPOLAR schemes are unsupported

Indeed, the pipeline tries to setup the fieldmap estimation with:

Setting-up fieldmap "fmapFMRI" (EstimatorType.PEPOLAR) with <sub-00206465_ses-20210722_acq-SpinEchoFieldMapFMRI_dir-AP_epi.nii.gz, sub-00206465_ses-20210722_acq-SpinEchoFieldMapFMRI_dir-PA_epi.nii.gz, sub-00206465_ses-20211109_acq-SpinEchoFieldMapFMRI_dir-AP_epi.nii.gz, sub-00206465_ses-20211109_acq-SpinEchoFieldMapFMRI_dir-PA_epi.nii.gz>

that is, it is trying to merge the fieldmaps acquired in both sessions. I think it is a wrong behaviour, the field is certainly not the same across session.

jsons are crafted as follows

e.g., for session 20211109, for fieldmap data:

"IntendedFor": [
        "ses-20211109/func/sub-00206465_ses-20211109_task-rest_run-1_echo-1_bold.nii.gz",
        "ses-20211109/func/sub-00206465_ses-20211109_task-rest_run-1_echo-1_sbref.nii.gz",
        "ses-20211109/func/sub-00206465_ses-20211109_task-rest_run-1_echo-2_bold.nii.gz",
        "ses-20211109/func/sub-00206465_ses-20211109_task-rest_run-1_echo-2_sbref.nii.gz",
        "ses-20211109/func/sub-00206465_ses-20211109_task-rest_run-1_echo-3_bold.nii.gz",
        "ses-20211109/func/sub-00206465_ses-20211109_task-rest_run-1_echo-3_sbref.nii.gz"
    ],
    "B0FieldIdentifier": "fmapFMRI"

and for BOLD data:

"B0FieldSource": "fmapFMRI"

Do I have to specify a distinct B0FieldSource/B0FieldIdentifier between sessions? In any case, the pipeline should not attempt to mix fieldmaps from diffferent sessions…

Am I supposed to manage the issue with --bids-filter-file?

Best ragrds, Federico

Command used (and if a helper script was used, a link to the helper script or the command generated):

/opt/pip-safe/fmriprep-docker/bin/fmriprep-docker /opt/paminaprocessing/Prisma/BIDS/XXX/YY /opt/paminaprocessing/Prisma/BIDS/XXX/YY/derivatives participant --participant-label 00206465 --work-dir /tmp/tpa0bd5dfd_ab2a_4307_8685_48ed1526c82e --nprocs 16 --fs-license-file /opt/fmriprep/freesurfer_license.txt --md-only-boilerplate --write-graph --image nipreps/fmriprep:23.2.1 --output-spaces MNI152NLin2009cAsym:res-native func --me-output-echos --clean-workdir > /opt/paminaprocessing/Prisma/BIDS/XXX/YY/tmp_fmripreprunlogs/2024-03-15-19-07_shell.log 2>&1

Version:

23.2.1

Environment (Docker, Singularity / Apptainer, custom installation):

Docker

2

Hi @FedericoG, and welcome to neurostars!

This depends. If for some reason you want to keep anatomical processing separate for each session, then you would need to use bids filter files and run separate jobs for each session. This has the downside of your BOLD images across sessions not being optimally aligned to one another. One may consider doing this if brains are expected to change a lot between sessions (that is, many years have passed, there are tumors/lesions, etc…). What I recommend is to plan to process everything when all the data are collected. That way you can wait and incorporate future software changes, ensure that you aren’t mixing software versions between subjects/sessions, and use all anatomical data to create a good template and make sure BOLD images are all aligned to each other across sessions. You can of course process data piecewise in the meantime, but you should keep those limitations in mind if analyzing data longitudinally.

Longitudinal switch changes how the longitudinal template is formed. Without the flag, FreeSurfer uses the first session primarily to form the template. With the longitudinal flag, it uses an unbiased estimation from all images available.

Looks like you have multiple sessions of fieldmaps mapping to BOLD files. You should edit the IntendedFor mappings to make sure you are correctly associating fmap to BOLD files. If you tell fmriprep to map fieldmaps across sessions it will.

Best,
Steven

3

Hi, thank you for your clarification.

I understand that, according to the case, it may be preferable or not to run distinct processing across sessions, and I appreciate the flexibility.

Running again everithing when all data are collected is an option, but it can be slow with hundreds of sessions, to me it is preferable re-trigger the subject processign when a session is added

The point is that I would not re-import the data from DICOM, but apparently in my current implementation the json are not formed the way fMRIPrep expects

Actually, IntendedFor correctly points to the proper session fieldmaps, but apparently fMRIPrep is discarding the IntendedFor

It is B0FieldSource/B0FieldIdentifier that is the same across sessions, in my case, and it looks like fMRIPrep is following this hint

Given that the two ways (intendedFor and B0FieldSource/B0FieldIdentifier) are redundant, is it better to tweak per-session B0FieldSource/B0FieldIdentifier or to delete it and keep IntendedFor ?

Mi undertsnading is that B0FieldSource/B0FieldIdentifier is more appropriate, but I’m not sure.
thanks, federico

4

Hi @FedericoG

It would be best if each fmap had it’s own B0FieldIdentifier, so you can better control the mappings.

I think B0FieldSource/Identifier is given priority when both methods are available, but to be safe you can delete IntendedFor and just do B0FieldSource/Identifier

Best,
Steven

5

In fact, if there are any B0FieldIdentifiers in a dataset, IntendedFor will be ignored. It is too hard to guess what a mix-and-match approach might mean, so we don’t.