How to analyze DCE-MRI data

@mschwier indeed, this can’t be correct! That’s a good lead …

I’m trying to see smth in the debugger with the unusual trigger times in mind. @kirezgik, if you have any info about the trigger times in the data or could double check your data with regard to this, that would be great.

@mschwier I think we should figure out the temporal resolution first.

@kirezgik can you please let us know (or ask the manufacturer of the equipment) how to properly interpret the temporal resolution of this DCE acquisition from the DICOM data they generate?

Basically, when we parse DCE series, we look for certain attributes to provide information about time stamps for the individual time frames. In this particular case, TriggerTime appears to be the attribute that seems to indicate time, but it jumps from 0 to 9074472.1875 for the second time frame. According to the standard, TriggerTime units is msec, and in the case of your data it does not appear to be the case.

Temporal Resolution (0020,0110) is 77196.0256347656 ≈ 1,29 minutes according to the DICOM tags. This seems more reasonable.

Indeed, but not “reasonable enough”. Temporal resolution should be on the order of 5 sec (the smaller the better) for a meaningful analysis. 1.29 min can’t be right, we would not see the dynamics we see in the data with that resolution.

Hi,
Thanks @mschwier and @fedorov for your investigations. I`ve just contacted with someone who oversees the MRI equipment. He said the following:

  1. The images are not gated so you can ignore the trigger times.
  2. The DICOM headers from this system aren’t always perfectly accurate.
  3. The temporal resolution will be the TR x the number of phase encoding repetitions. (You’ll have to check the TR for each individial DCE scan because most are 53.335 but some are 69.746 because there were more slices added to the slice package) To calculate the temporal resolution it would be 53.335 x 96= 5120.16 ms.

Hi @kirezgik,

@fedorov changed the temporal resolution manually to see if this fixes the problem. Unfortunately the curve fitting still looks as wrong as before. This means we’ll have to debug deeper into the computations to see what is the cause for this. We’ll try to extract a tiny sample from your image and see if we can reproduce the error with this sample. With a small sample it is a bit easier to retrace the computations.

1 Like

Hello!
I had a look at the data. First of all, I could not visually identify any ROIs that could be used to define the AIF, so possibly you may need to estimate that. Just for testing, I used some voxels that exhibited AIF characteristics (sharp peak etc.) but were probably more related to motion than to blood vessels.
With this ‘AIF’ I was able to calculate a Ktrans map in the kidney - see below - albeit the values were higher than expected, probably due to the AIF being extremely innaccurate, and the T1 values unknown. Remember to input a BAT frame number in the Advanced options. The Output Fitted data did not align with the actual data but perhaps that is a problem with the fitted data output of the module and not with the fitting procedure.


Sharon

@kirezgik, @fedorov and @mschwier - I did find some vessels for the AIF and analyzed the mouse data using my own DCE analysis program using MatlabBridge in Slicer and the results look fine - see below Ktrans map and fitted data graph. After giving it some more thought, I think that in the PkModeling module perhaps the function that generates the fitted data reads parameters from the Bruker perfusion dataset header incorrectly e.g. reads the sequence TR in msec when it is expecting seconds or something like that.
-Sharon05 PM

2 Likes

Hi Sharon @speled,

Based on the ROIs we identified, it seems difficult to define the AIF manually because of the small spatial dimensions or the location of the tumor in mice. So we will try to use some proposed algoritms to automatically define the AIFs, that way we can have a more accurate AIF and Ktrans map, hopefully.
Could you please share the Matlab script you used for your analysis? Then we can try it here in our Slicer.

Thanks for your help,
Ezgi

Hi. fedorov!
How can I change the original DCE-MR datas into MRMLMultiVolume, and when I use the MultiVolumeImporter to get the data, but I don’t kown how to fill in the parameters in advanced setting, thanks very much!

You need to load the DICOM series from the DICOM Browser module. How do you load the data right now and what happens?

Which parameter are you trying to set? All except the first two are for creating output volumes. “Constant BAT” applies only to UseCostantBAT, and should be set to the multivolume frame where you see the beginning of the contrast uptake.

image

Thanks for help!When I use the MultiVolumeImporter to acquire the 4D image, I get some parameter like RE, RT and FA, etc, but I don’t know the Initial value, step, Frame identifying DICOM tag, how can I get those parameter?
The original DICOM data contain 1920 slices, and 60 frames. 1512479061(1)b
Can I send the data to you?

And when I load the data from the DICOM Browser, I get some deformation images, and it can not be used in pkmodeling.c

Sure, you can send me your de-identified dataset and I can take a look.

@kirezgik we are preparing for the NA-MIC Project week that will take place at MIT Jan 8-12 (see https://na-mic.github.io/ProjectWeek/PW27_2018_Boston). We will have a focused project to investigate issues in PkModeling, and will specifically look into the issues that are reproducible with the dataset you kindly shared (see specific project here: https://na-mic.github.io/ProjectWeek/PW27_2018_Boston/Projects/ModelFittingTools/).

You are more than welcome to join project week - this will give you a great opportunity to learn more about Slicer, work with the developers, and refine Slicer DCE analysis implementation. We would be very happy to see you at the project week!

If you are not there, following the project week we should have more understanding, if not the solution, to the problems you identified.

1 Like

Hi @fedorov, I am sorry I missed this message and have not seen earlier. I could not join anyways, but I appreciate your effort and helps to solve this issue. Hope you can have a better idea and maybe solution to that at the end of the project week. I look forward to hearing your updates soon.
Thanks.

Hi @fedorov, I was wondering if you have any updates regarding to this issue.

@kirezgik no, unfortunately we do not have any new results. @speled and @mschwier did not identify the issue at the project week, and I have not been able to make time to investigate this myself. I am sorry!

Are you a developer yourself? Would you be comfortable investigating this issue? We could perhaps give you some pointers?

Hello @kirezgik, (cc: @fedorov,@mschwier)
The issue is probably not in the PK Modeling module, but in the multivolume loading of Bruker data - specifically in recognition of the frametime. I will probably be working on correcting this during Project Week in June. I do not have your problematic original data anymore - if you share it I think I can send you a solution.
all best
Sharon