Relative Roles Core1a Core 1b Core2

Introduction

In 2007, NA-MIC DBP funding moved from the first generation of DBPs to a second generation. This change required a call for new DBPs and a formalization of the role of Core 3 partners, and provided opportunity to rethink the roles and functions of the Algorithm, Engineering, and DBP cores.

The relationships and responsibilities between the different partners and different Cores in NAMIC are influenced by several factors including: the original structure of the RFA and project proposal, the technical goals of providing a national infrastructure for medical image analysis, the scientific goals of the DBPs, and several years of experience within the current project.

The RFA says the following (excerpts):

• Core functions:

1. conducting core research in relevant science, such as algorithm creation and optimization
2. developing and deploying tools designed to solve particular biomedical problems
3. establishing Driving Biological Projects (DBP) to allow experimental biomedical and behavioral researchers to interact with and drive computational research in the NIH NCBC

Based on the experiences of the last 3 years, the RFA for the second generation of DBP's in NA-MIC defined the DBP role in NA-MIC to include the following:

• Willingness to adopt the NA-MIC kit
• Willingness to use DBP funds to hire at least one computer science person into the DBP to help translational efforts

An important mechanism for wide dissemination of the NA-MIC software infrastructure is the NA-MIC Kit. The Introduction for the NA-MIC kit describes the software in the NA-MIC kit as follows:

• It is our intention to include in the NA-MIC kit only software that is supported and comes with a BSD style license.

Based on this background and on conclusions drawn from the experience from the first three years of operation the following guidelines are emerging for the role of the each of the 3 main cores of NA-MIC.

Overall objective

The objective of NA-MIC is to establish, at a national level, an open-source software and computing infrastructure to facilitate medical research that relies on image analysis. The infrastructure will support experimental biomedical and behavior research utilizing medical image computing (applications of medical image computing) as well as support fundamental research in medical image computing itself (algorithms, data structures, computing platforms). This infrastructure includes a set of open source software tools for medical image computing along with the necessary supporting software development environment (source code repositories, bug trackers, dashboards, build environment, mailing lists, web site, wiki). The infrastructure is designed to support a range of biomedical and behavior research applications.

The NA-MIC Kit is the foundation of this infrastructure, providing an end-user application (Slicer3), and batch processing tools for large scale experiments (BatchMake, Grid) to support biomedical and behavior researchers. The NA-MIC Kit also includes ITK, which is an extensive set of libraries for image analysis, visualization tools in VTK, and a simple plugin architecture for Slicer3 to support research in medical image computing.

All the NA-MIC participants will use NA-MIC funding exclusively for this overall goal.

Core 1: Algorithms

NA-MIC funding in the algorithm core is used for work research and development of algorithms in the NA-MIC Kit. Algorithms will be driven by the specific needs of the DBPs, but with a preference for general solutions as opposed to algorithms that are only useful in a particular subdomain. The plan for Core 1 development is that Core 1 sites should implement algorithms in ITK and integrate into Slicer via the support for plugin modules. Core 1 participants are expected to request specific APIs, data structures and facilities from Core 2 to support this work.

Core 2: Engineering

Participants in this core are concentrating on developing the NA-MIC kit as an infrastructure. The infrastructure will provide the libraries and APIs needed by Core 1 to implement their algorithms and the user interfaces needed by Core 3 to make use of the tools. Core 2 participants will consult regularly with Core 1 sites, the Core 1 PI, and the NA-MIC PI in order to establish needs for software infrastructure. Major infrastructure developments will be documented on the Wiki and publicized, by email, to the site PIs.

Core 3: DBP's

Core 3 researchers serve as representatives of their fields and should make algorithm and tool requests that serve not just their current research needs, but will also benefit the larger community of users. The DBPs are responsible for developing and modifying NA-MIC-Kit applications to meet their specific needs. Thus second generation DBP's will use the NA-MIC funding to hire an engineer or software developer, qualified to work with the Slicer 3 application, who will help to use the tools developed by the algorithm core to perform biomedical research.

Case studies

There are several examples that demonstrate the expected or acceptable interactions between the cores. The prototypical example is one in which the Core 1 participants develop an algorithm that addresses specific needs of one or more Core 3 DBPs. In order to implement this algorithm in ITK and integrate it into Slicer, the Core 1 developers might need certain software infrastructure in the toolkit. They would approach Core 2 participants with their needs, make plans for a solution, work with Core 2 participants to test the solution and thereby achieve an implementation of the algorithm in the NA-MIC Kit.

There are several examples that follow this general paradigm. One example is the development at Georgia Tech of the DLPFC parcelation tool. This was done with clinical guidance from collaborators at UCI and Harvard (Core 3) The algorithm and the ITK implementation were done by students at Georgia Tech (Core 1). This required the development of a new Bayesian classification infrastructure, which was provided by Kitware (Core 2). Support for the development of the Slicer2 RuleBasedSegmentation module was also provided by Isomics (Core 2).

Another example is the integration of DWI/DTI filtering and estimation code, developed at Utah (Core 1). The initial development, by Utah students, was done in ITK. The integration of this capability into Slicer required support for collections of DWI images (one image for each gradient direction, and the baseline) in the MRML database and file I/O. The Utah team worked with Core 2 partners to develop and test this new capability. The final result is a command-line Slicer-3 module that is now in the NITRC software repository.

In some cases it might be impractical for Core 1 partners to work directly with ITK and Slicer. Thus, there are alternative paths to Core 1 softare integration. For instance, with the EM segmenter, developed at MIT (Core 1),

• • Algorithm research partially predates NA-MIC
  • Part of the tool creation was outsourced to kitware, using MIT NA-MIC funding
  • Algorithm has multiple applications (MR Neuro, CT Torso, Mircoscopy...) all available in a clean and documented user interface.
  • More details:

The students who develop the algorithms use different languages to write the code, but recently they increasingly use itk and vtk. They work with Core 3 groups to apply the algorithms; the initial set of publications is created between Core 1 and Core 3 groups. These papers demonstrate the usefulness of the approach on the applications of interest.

In the integration phase, MIT groups subcontracts to Kitware (or a different subcontractor with the necessary qualifications) to integrate the algorithms into NAMIC-kit. Depending on the application, this might mean incorporating the code into itk libraries, and/or providing a command-line interface to Slicer, or building a custom module in Slicer. The proposal is written by a Kitware engineer in collaboration with the student/researcher who created the original code. The proposal is reviewed by the Core 3 collaborator who has used the technology before or has a clear need for it in the future. It is then approved by site PI (typically after revisions to incorporate Core 3 requirements). This process ensures that the necessary and the useful features are implemented.

The testing of the implementation is done by Kitware in a very close collaboration with Core 3 (Core 3 runs tests to compare to their previous results, etc.). The integration stage of a large project (for example, EM segmenter) takes about 1 year: ~2months to develop a detailed proposal, ~6months to implement, ~4 months to test and refine.