2017 Winter Project Week/PkModeling

• 
• 

  Projects List

Key Investigators

• Andrew Beers, Jayashree Kalpathy-Cramer, MGH
• Jim Miller, GE

Project Description

Objective	Approach and Plan	Progress and Next Steps
PkModeling, a Slicer module meant to derive DCE pharmokinetic parameters via the two and three parameter Tofts model, has not had perfect accuracy on phantoms for the Tofts model. We intend to troubleshoot and address these errors, which we have determined from our previous research to be problems with the implementations of the Tofts model. Make the module more usable and/or intuitive to casual users. Although it may be a larger Slicer infrastructure project, add support to Slicer for 4D Niftis, the main file format of our lab.	Debug the module with several test cases and deconstruct the models steps to see where error is introduced to its calculations. Model UI off of successful modules, and seek advice from attendants of Project Week. Probe conversion between MultiVolumes and 4D Nifti files.	The PkModeling now achieves perfect results on the Tofts v6 Phantom, with a caveat. By changing the way numerical integration is done in the curve-fitting procedure, we were able to achieve good results on low-ve high-ktrans areas that the previous PkModeling had trouble with. However, there is a now a new problem of individual points sometimes not fitting correctly. This seems to be because the fitting algorithm we use is non-deterministic -- the same input data leads to different results. Further edits will need to be made to fix this problem, but at least the results are for the large part accurate! We've also found that the automatic bolus arrival time portion of the code leads to bad results on the Tofts v6 phantom. Seeing as this code is meant for real data where we may not know the bolus arrival time, this may not matter. However, there are probably many situations where a patient visit has a pre-determined BAT, and using that pre-determined time, even if it is off by a few seconds, may end up introducing less error than trying to automatically determine it via gradients. More tests will be needed on this front. This project talk me much about C++ coding, building Slicer and extensions applications, and Visual Studio. However, the ultimate goal was to replicate in C++ changes applied to an existing Python script. While the Python script was assumed to be slower, this may have been because of the slower integration methods it used and not because of optimization programs in the code. It may be better to, rather than altering the existing C++ code, to wrap the Python code into a Slicer module. This is especially so if the Python code can be rewritten in Cython, likely conferring more speed benefits.