BIDS - implying condition with taskname label and run index across counterbalance orders

1

If I have a functional MRI task where each run is a different condition that is also a different scan length, and they are run in different counterbalanced orders across subjects, what is best practice for implying task condition using the task label and run index.

There are three methods that jump out to me:

Method 1:
Counterbalance 1:
“…task-audio_run-01…”, “…task-audio_run-02…”, “…task-audio_run-03…”, “…task-audio_run-04…”
Counterbalance 2:
“…task-audio_run-01…”, “…task-audio_run-02…”, “…task-audio_run-03…”, “…task-audio_run-04…”
where run numbers are in chronological order for all counterbalance orders, such that run number is chronological but refers to different conditions across subjects based on counterbalance order. Task condition is not implied by scan name, and only available by referencing an external list of subject counterbalance assignments.

Method 2:
Counterbalance 1:
“…task-audio30…”, “…task-audio50…”, “…task-audio70…”, “…task-audio90…”
Counterbalance 2:
“…task-audio50…”, “…task-audio70…”, “…task-audio90…”, “…task-audio30…”
where we refer to each condition by a different task label, and we re-order task names for each counterbalance order so that condition is implied by task name and consistent across subjects.

Method 3:
Counterbalance 1:
“…task-audio_run-01…”, “…task-audio_run-02…”, “…task-audio_run-03…”, “…task-audio_run-04…”
Counterbalance 2:
“…task-audio_run-02…”, “…task-audio_run-03…”, “…task-audio_run-04…”, “…task-audio_run-01…”
where run number always refers to a specific condition, and are out of chronological order for each counterbalance.

The concepts I was unclear on from the BIDS spec were:
-Whether task conditions with different scan lengths should justify separate task names? The Common Principles state that Run should distinguish only between scans with matched parameters, but it’s not obvious to me if scan length should be included in that list.
-Whether run indexes should always be chronological, or if their acquisition order was irrelevant and they could instead be used to reference something like condition order.

For reference I am setting up protocols on a Siemens MRI using the ReproIn naming spec to allow semi-automated BIDS conversion with HeuDiConv. So we’re setting up multiple protocols for each counterbalance order, and I need to decide on the final BIDS organization in advance to map back to a consistent protocol naming and organization scheme on the scanner console.

2

Interesting problem

The ground truth for what data file was acquired when will be captured in the scans.tsv and heudiconv should create those for you.

I would say no to this one.

It is definitely one of those things (run only applies if ALL parameters are the same) where I personally make an exception for when it comes to scan length. The validator will throw a warning but there are some experimental paradigm where you will inevitably get different scan length (for example self paced experiments where rate of presentation of stimuli may depend on subject’s responses).

Although this is not in the BIDS specification, I would very much expect run indices to reflect the order in which runs we acquired. I don’t think I am alone here, so I would not recommend using runs indices in another way, as it may confuse users and may make scripting more complicated.

So I would avoid method 3.

Against method 2 unless the task is sufficiently different. For example, if for each task you would give them a different cognitive atlas ID (Cognitive Atlas) then you may be justified in using different task name.

Method 1 seems acceptable to me, as the name of your conditions should hopefully be captured in the trial_type columns of your events.tsv files.

Maybe for better book keeping I would also put in the participants.tsv the counterbalance that each subject got:

participant_id	sex	age	counterbalance
sub-01	M	22	A
sub-02	F	24	B

With some annotations in the json

{
    "age": {
        "Description": "Age of the participant",
        "Units": "years"
    },
    "sex": {
        "Description": "Sex of the participant",
        "Levels": {
            "M": "Male",
            "F": "Female"
        }
    },
    "counterbalance": {
        "Description": "order of conditions presented across runs for each participant",
        "Levels": {
            "A": "30_50_70_90",
            "B": "50_70_90_30"
        }
    }
}

Not a 100% about all of this so curious to hear what others have to say.

1 Like
3

Thanks for your reply @Remi-Gau!

I was initially leaning towards method 3, but your arguments are good. I think as the MRI side person, I put too much emphasis on setting up the protocol to include as much encoded high-level information as possible, to increase the amount of work done with the automated conversion. But the researcher will always have to finish the work on completing the BIDS directory, and it makes sense that the run numbers will intuitively be chronological to most people, and that we already have to reference the various tsv’s for this type of information.

I agree also that method 2 is a dangerous road. There are already enough grey areas about what distinguishes tasks from conditions that it feels like we should avoid this choice until clearly necessary.

I am proceeding with method 1, which already seemed the most intuitive to set up, although creating seemingly less transparency and more necessity to read tsv’s in the final BIDS directory (probably not a bad thing!).

Still interested to hear how others have approached this, or expect it to be done, if anyone has further input.