BUG: Delay estimation drops subjects when dataset mixes run-specific PET files with session-level blood files

[mnoergaard]

Delay estimation appears to omit some subjects/measurements when a dataset contains a mix of PET files with and without a run entity, especially when run-specific PET scans share a session-level blood file.

Example structure:

sub-50419_ses-01_pet.nii.gz
sub-50419_ses-01_recording-manual_blood.tsv

sub-50507_ses-01_run-01_pet.nii.gz
sub-50507_ses-01_run-02_pet.nii.gz
sub-50507_ses-01_recording-manual_blood.tsv

The data definition and weights steps seem to detect and process the measurements correctly, but the delay estimation report/output only contains delay estimates for a subset of subjects.

Expected behavior: session-level blood/inputfunction data without run should be matched to all relevant run-specific PET measurements for the same subject/session.

Likely cause: the delay report joins TAC data and blood data using exact shared BIDS entities. When TAC rows contain run but blood rows do not, the join can silently drop run-specific measurements. This may also affect later plasma model reports that reuse the same TAC/blood joining pattern.

[mnoergaard]

One additional detail that may be relevant: I think this may originate earlier in the region definition step when PETPrep derivatives contain both combined-run and run-specific outputs.

In my case, for some subjects I have both no-run and run-specific PETPrep TACs in the same derivatives folder, e.g.:

sub-50507_ses-01_desc-preproc_seg-gtm_tacs.tsv
sub-50507_ses-01_run-01_desc-preproc_seg-gtm_tacs.tsv
sub-50507_ses-01_run-02_desc-preproc_seg-gtm_tacs.tsv

whereas other subjects only have the no-run/combined output, e.g.:

sub-50509_ses-01_desc-preproc_seg-gtm_tacs.tsv

This happened because PETPrep was run with and without --combine-runs.

So the issue may not only be the delay report join. The region definition app may also be discovering both the combined-run TACs and the per-run TACs as valid inputs with the same segmentation/description, which then creates a mixed analysis dataset containing some PET identifiers with run and some without.

It would be useful if PETFit either:

1. warned when both combined-run and per-run TACs are present for the same subject/session/segmentation,
2. allowed the user to explicitly choose combined-run versus per-run TACs, or
3. handled this hierarchy consistently downstream when matching TACs, weights, blood/inputfunction data, and delay estimates.

This may explain why data definition and weights seem to work, but delay estimation only produces outputs for a subset of measurements.

[mathesong]

@mnoergaard Any chance you could zip up and share your PETFit folder (and tell me about the timing of the split runs)? I suspect that the runs are being matched to the blood data just fine, but I think they'll be combined as separate measurements when there's both run-01 and run-02. And that would mean that the second run can't be delay-fitted because there's no TAC data at the beginning where the delay is estimated. But I'd like to check and make sure.

Though, on the other hand, if you've run it without combine-runs, and you get a run-01 and run-02, then you're running delay fit on both separately, then maybe that's the problem. You simply can't estimate the delay for run-02 because you don't have data at the start.

[mnoergaard]

@mathesong - of course. Just forwarded you the zipped PETFit folder. Let me know if you need anything else.

[mnoergaard]

@mnoergaard Any chance you could zip up and share your PETFit folder (and tell me about the timing of the split runs)? I suspect that the runs are being matched to the blood data just fine, but I think they'll be combined as separate measurements when there's both run-01 and run-02. And that would mean that the second run can't be delay-fitted because there's no TAC data at the beginning where the delay is estimated. But I'd like to check and make sure.

Though, on the other hand, if you've run it without combine-runs, and you get a run-01 and run-02, then you're running delay fit on both separately, then maybe that's the problem. You simply can't estimate the delay for run-02 because you don't have data at the start.

That makes sense! I have tried to come up with a solution targeting the joining of the data, when blood data exists at the session level, and not at the run level. Another potential solution would be to be able to exclude runs when generating the data structure in the beginning of PETFit? For example, in the use case described here, 18 out of 20 subjects have a full session (i.e. no runs), and then two subjects have a run 1 (which is comparable to the other 18 subjects) and also a run 2 (extended scan time, or where the subject has been out of the scanner and going back). PETPrep was subsequently executed with --combine-runs to create session-level processing for these two subjects, so session-level data exists for all 20 subjects. But the run-01 and run-02 preprocessed data still remains in the PETPrep derivatives.

Curious to know how you would approach this from a user perspective?

[mnoergaard]

This dataset also contributed to extend support for reconciling PET data when multiple runs are present

nipreps/petprep#325
nipreps/petprep#326

The tricky thing here is that the two runs have been reconstructed to different time zeros, and so bringing them into the same timing axis, it is required to take care of decay correction. Not sure if you had thought of providing similar support in PETFit, when multiple runs are present, but where the user wants to model the data together? Other data use cases might be data from the AMYPAD consortium, with subjects having early and late acquired data.