The Medical Imaging Interaction Toolkit (MITK) is open-source software for building interactive medical image-processing applications, developed by the German Cancer Research Center (DKFZ) in Heidelberg and distributed under a BSD licence. The current version is MITK 2016.03, out these days; the project ships stable releases every few months, with the YYYY.MM naming scheme. Here I look at how the code is organised and where the line falls between what the toolkit gives you ready-made and what the user has to add.

Context

MITK started in 2003 in a working group oriented towards oncology — segmenting masses, planning liver interventions — and the first description of its architecture is the 2005 paper in Medical Image Analysis, which already set the underlying idea: extend the Insight Toolkit (ITK) and the Visualization Toolkit (VTK) with an interaction layer and a common data model, rather than rewriting segmentation and rendering from scratch. ITK and VTK, born in the late 1990s in the context of the Visible Human Project and since maintained by Kitware, cover analysis (filters, registration, algorithmic segmentation) and visualisation (2D and 3D rendering pipelines) respectively. MITK does not replace them: it works on top of them.

The copyright belongs to the DKFZ and the licence is BSD-style. For anyone weighing the toolkit with a product in mind, it is the first fact that weighs: there is no copyleft obligation, so you can derive closed commercial software from it without any obligation to redistribute your own changes.

Architecture

Underneath MITK 2016.03 there is a stack of well-tested libraries: ITK for analysis, VTK for rendering, Qt for the C++ interface, DCMTK for DICOM (Digital Imaging and Communications in Medicine) I/O, the Common Toolkit (CTK) for components shared across imaging projects, and CppMicroServices as a C++ implementation of the OSGi-inspired service model (OSGi being the Open Services Gateway initiative).

On top of these dependencies, the heart of MITK is the DataStorage: a single repository holding every object loaded into memory. Each object — an image volume, a surface, a point set, a segmentation — lives inside a DataNode, and each DataNode carries an arbitrary set of properties (colour, opacity, visibility, and whatever key the application wants to add). The DataStorage is not a flat list: it keeps a graph of relations between nodes, so a segmentation can be registered as derived from the volume it comes from, and a query can walk back to a node’s sources or its derivations. The views — the three orthogonal planes (axial, sagittal, coronal) plus the 3D view — read from the DataStorage and refresh when the model changes. It is an ordinary Model-View scheme, but applied consistently all the way through: every render window observes the same repository, and that is what keeps the views in sync without any hand-written synchronisation code.

The plugin layer

What I call MitkWorkbench — the full application, with its menus, perspectives and modules — rests on BlueBerry, a plugin framework that takes Eclipse’s bundle model and carries it into C++ and Qt. The clinical features do not sit in the core: they sit in plugins that declare their own contributions (views, menu entries, toolbars, perspectives) and their own dependencies, and that are resolved and activated at runtime.

The point worth clarifying, because it often causes confusion, is that BlueBerry no longer handles plugin resolution itself. In recent versions it relies on the CTK Plugin Framework for plugin registration and activation: an OSGi-like implementation that CTK provides in fuller form than BlueBerry’s old code. CppMicroServices are another thing: they give the finer-grained service registry (one module publishes a service, another consumes it) and have nothing to do with plugin registration. Concretely: the plugin is the unit of distribution and lifecycle, managed by the CTK Plugin Framework; the microservice is the unit of interaction between components, managed by CppMicroServices. They are two overlapping layers, and it pays to keep them distinct when reading the code or writing a new module.

For anyone extending the toolkit, this layering means that a specific clinical module — say volumetric analysis of a given kind of lesion — is written as a plugin that hooks into the extension points, without touching the core and without recompiling the whole application.

The critical point

The separation between plugin registration (CTK) and the service registry (CppMicroServices) is the architectural detail that repays the most when reading the code, and the one people trip over most often. An MITK module can depend on a service without statically depending on the plugin that provides it: resolution happens at runtime, against the registry. It is a good decoupling, but it moves to runtime errors that a linker would catch at compile time — an unavailable service is not a build error, it is a null reference at the moment you use it. Anyone building on MITK has to treat the absence of a service as an expected state rather than a case that cannot happen, and this holds all the more once the software ends up under risk assessment.

Regulatory implications

MITK is a development toolkit and in itself is not a medical device. The distinction matters. Building a certified clinical product on top of it removes none of the manufacturer’s obligations: the software life cycle has to be run under the IEC 62304 standard, risk management under ISO 14971, the technical documentation is specific to the final product, and in Europe CE marking is required under the Medical Devices Directive 93/42/EEC — with the new regulation, under European discussion at just this time, set to redraw those obligations.

Starting from an inspectable, maintained open-source base cuts down the amount of code to write and verify from scratch, but it does not cut down the responsibility: product qualification rests entirely with whoever places it on the market. A BSD library pulled from a public repository carries no process evidence usable in a certification file; that evidence has to be produced separately, on top.

Limits

Python scripting in MITK 2016.03 is limited compared with other open-source imaging platforms, where extending via script is the more common way to work: here the main road remains C++ with the plugin model, and that raises the barrier for anyone prototyping. Public architectural documentation is uneven — the release overview page cites ITK and VTK but does not show the plugin stack, and to understand the relationship between BlueBerry, CTK and CppMicroServices you have to go through the wiki, the mailing lists and the code. The community is international but German-centred and academic, and adoption outside research groups stays narrow: for routine diagnostic workstations, hospitals keep using the products of the large vendors.

Cover image: Modern building of the Deutsches Krebsforschungszentrum (DKFZ) in Heidelberg under a clear sky, with a horizontally banded facade — photo by Rudolf Stricker, free license (attribution required) — https://commons.wikimedia.org/wiki/File:Heidelberg_DKFZ_Neuenheimer_Feld_20120501.jpg