In medical image computing there are excellent algorithm libraries and excellent visualisation libraries, but almost no software a radiologist or neurosurgeon can open and use on a real case. 3D Slicer tries to occupy that intermediate layer, and the funding that arrived in September from the National Institutes of Health (NIH) redraws how it is developed.

Context

ITK (Insight Toolkit), the reference toolkit for biomedical image analysis, began in 1999 from a US National Library of Medicine contract awarded to a consortium that includes Kitware and several academic groups. ITK gives you segmentation and registration: filters, optimisers, metrics. Visualisation comes from VTK (Visualization Toolkit), also maintained by Kitware, with its 2D and 3D rendering pipelines and its Tcl/Tk bindings.

Both are libraries. To build an experiment you write C++ or Tcl, compile, handle format I/O, and keep coordinate systems consistent. A clinician who wants to segment a tumour on an MRI scan, measure its volume and reconstruct its 3D surface has, in this scheme, no entry point at all. The missing layer is end-user software: a graphical interface, case management, and the integration of segmentation, registration and measurement modules under a single data model.

Architecture

3D Slicer is written in C++ with a Tcl/Tk interface, runs on Linux, Windows and Mac OS X, and ships under a BSD licence. It uses ITK for processing and VTK for rendering. Everything turns on a central data model, MRML (Medical Reality Markup Language), which represents a clinical case as a scene: image volumes, segmented surface models, transforms, annotations and fiducials, saved to an XML file.

The architectural decision that settles things is the split between the model and the modules. Each capability ā€” a segmentation editor, a deformable registration, a fibre tracker ā€” is a module that reads and writes MRML nodes without knowing anything about the other modules. The orthogonal 2D views (axial, sagittal, coronal) and the 3D view share one cursor and one scene. Adding a capability means adding a module that works on that model, not touching the application.

On the data side there is DICOM import and export, interactive segmentation (thresholding, region growing, island removal), rigid and affine registration, volume computation, distance and angle measurements, and deterministic tractography from DTI (Diffusion Tensor Imaging) to display white-matter fibre tracts. The reference description of the architecture is the work by Pieper, Halle and Kikinis presented at the IEEE International Symposium on Biomedical Imaging in 2004.

The critical point

The separation between data model and modules is what makes distributed development sustainable, but on its own it is not enough: a module written in C++ against Slicerā€™s internal APIs stays tied to the applicationā€™s build cycle and to the applicationā€™s language. Someone who has developed a registration algorithm in another environment has to rewrite it to integrate it.

The road the project is taking is to detach the heavier modules from the application process. A module can be an external executable that declares its parameters in a formal descriptor; Slicer launches it, passing inputs and outputs, and collects the results into the MRML model. The constraint is no longer the language or the build cycle: it is honouring the parameter contract. A group already maintaining its own command-line tool exposes it to Slicer without a rewrite.

This shifts the problem from code to format interoperability and to discipline around the data model. It holds as long as MRML stays the only place where a clinical case is represented in full. If modules start holding their own state outside the scene, the composability guarantee breaks.

Implications

In September 2004 the NIH awarded, through the Roadmap for Medical Research programme and the National Centers for Biomedical Computing, grant U54 EB005149 to the NA-MIC consortium (National Alliance for Medical Image Computing), with Brigham and Womenā€™s Hospital as prime contractor and Ron Kikinis among the principal investigators. The consortium brings together groups from Harvard, MIT, the University of Utah, UNC Chapel Hill and industrial partners including Kitware and Isomics, around an Open Source software infrastructure for translational research in image computing.

3D Slicer is the application platform of that infrastructure, with ITK and VTK as the base libraries. The software has existed since the late 1990s; what changes now is the funding and governance structure that holds it up. Development distributed across several centres, the co-development meetings where groups work side by side for days on the platform, code review and continuous integration on multi-platform build servers all move into a funded programme. They stop being volunteer activity at the margins of individual labs.

For a neurosurgery centre or a clinical research group, the practical consequence is having a platform with no licence cost, a documented data model, and the option to add oneā€™s own algorithms as external modules. For more than ten years the Brigham and Womenā€™s lab has accumulated cases and publications on neurosurgical planning and neuroimaging with this software, and the BSD licence permits use inside commercial products as well.

Limits

The learning curve is steep: Slicer takes for granted a degree of familiarity with the notions of volume, registration and segmentation, and the current Tcl/Tk interface carries its age. A rewrite of the interface with a more modern toolkit and, later on, a major release with an extended architecture are planned, but these are work in progress, not capabilities available today.

The tool serves translational research; it is not a certified medical device: clinical use remains the responsibility of the adopting centre and has to be kept within its own protocols. Alternatives exist with different aims ā€” MedINRIA for neuroimaging and DTI, MIPAV written in Java at the NIH, OsiriX as a DICOM viewer on Mac OS X, and Amira on the commercial side ā€” and the choice depends on workflow more than on algorithmic depth. What 3D Slicer offers today is a central data model and a mechanism for attaching modules written elsewhere; how well it holds up at scale will depend on how disciplined that separation stays.

Cover image: 2004 screenshot of 3D Slicer: a brain MRI slice with colored cortical parcellation and gyrus labels (PrG, PoG, SFG) from a tumorā€¦ ā€” screenshot by Wenples, CC BY-SA 3.0 ā€” https://commons.wikimedia.org/wiki/File:3DSlicer-Park-AJNR2004-Fig1.jpg