Nel medical image computing ci sono ottime librerie di algoritmi e ottime librerie di visualizzazione, ma quasi nessun software che un radiologo o un neurochirurgo possa aprire e usare su un caso vero. 3D Slicer prova a occupare quello strato intermedio, e il finanziamento arrivato a settembre dal National Institutes of Health (NIH) ne ridisegna il modello di sviluppo.

Contesto

ITK (Insight Toolkit), il toolkit di riferimento per l’analisi di immagini biomediche, nasce nel 1999 da un contratto della National Library of Medicine statunitense, affidato a un consorzio che comprende Kitware e vari gruppi accademici. ITK dà segmentazione e registrazione: filtri, ottimizzatori, metriche. La visualizzazione la dà VTK (Visualization Toolkit), anch’esso mantenuto da Kitware, con le sue pipeline di rendering 2D e 3D e i suoi binding Tcl/Tk.

Sono entrambe librerie. Per costruire un esperimento devi scrivere codice C++ o Tcl, compilare, gestire l’I/O dei formati, tenere coerenti i sistemi di coordinate. Un clinico che vuole segmentare un tumore su una risonanza, misurarne il volume e ricostruirne la superficie 3D, in questo schema non ha nessun punto d’ingresso. Lo strato che manca è il software per l’utente finale: interfaccia grafica, gestione del caso, integrazione dei moduli di segmentazione, registrazione e misura sotto un unico modello di dati.

Architettura

3D Slicer è scritto in C++ con interfaccia Tcl/Tk, gira su Linux, Windows e Mac OS X, ed esce con licenza BSD. Per l’elaborazione usa ITK, per il rendering VTK. Tutto ruota attorno a un modello di dati centrale, MRML (Medical Reality Markup Language), che rappresenta un caso clinico come una scena: volumi di immagini, modelli di superficie segmentati, trasformazioni, annotazioni e fiduciali, salvati su un file XML.

La scelta architetturale decisiva è la separazione tra il modello e i moduli. Ogni funzionalità — un editor di segmentazione, un registratore deformabile, un tracciatore di fibre — è un modulo che legge e scrive nodi MRML senza sapere nulla degli altri moduli. Le viste 2D ortogonali (assiale, sagittale, coronale) e la vista 3D condividono lo stesso cursore e la stessa scena. Aggiungere una capacità vuol dire aggiungere un modulo che lavora su quel modello, non mettere mano all’applicazione.

Sul piano dei dati ci sono import ed export DICOM, segmentazione interattiva (soglia, region growing, rimozione di isole), registrazione rigida e affine, calcolo dei volumi, misure di distanze e angoli, e trattografia deterministica da DTI (Diffusion Tensor Imaging) per visualizzare i fasci di fibre della sostanza bianca. La descrizione di riferimento dell’architettura è il lavoro di Pieper, Halle e Kikinis presentato all’IEEE International Symposium on Biomedical Imaging del 2004.

Punto critico

La separazione tra modello dati e moduli è ciò che rende sostenibile lo sviluppo distribuito, ma da sola non basta: un modulo scritto in C++ contro le API interne di Slicer resta legato al ciclo di build e al linguaggio dell’applicazione. Chi ha sviluppato un algoritmo di registrazione in un altro ambiente, per integrarlo deve riscriverlo.

La strada che il progetto sta imboccando è staccare i moduli più pesanti dal processo dell’applicazione. Un modulo può essere un eseguibile esterno che dichiara i propri parametri in un descrittore formale; Slicer lo lancia passandogli ingressi e uscite e raccoglie i risultati nel modello MRML. Il vincolo non è più il linguaggio o il ciclo di build: è rispettare il contratto sui parametri. Un gruppo che mantiene già un proprio strumento da riga di comando lo espone a Slicer senza riscriverlo.

Così il problema si sposta dal codice all’interoperabilità dei formati e alla disciplina del modello dati. Regge finché MRML resta l’unico posto in cui un caso clinico è rappresentato per intero. Se i moduli cominciano a tenere stato proprio fuori dalla scena, la garanzia di componibilità salta.

Implicazioni

A settembre 2004 il NIH ha assegnato, attraverso il programma Roadmap for Medical Research e i National Centers for Biomedical Computing, il grant U54 EB005149 al consorzio NA-MIC (National Alliance for Medical Image Computing), con il Brigham and Women’s Hospital come contraente principale e Ron Kikinis tra i responsabili. Il consorzio mette insieme gruppi di Harvard, MIT, University of Utah, UNC Chapel Hill e partner industriali tra cui Kitware e Isomics, attorno a un’infrastruttura software Open Source per la ricerca traslazionale in image computing.

3D Slicer è la piattaforma applicativa di quell’infrastruttura, con ITK e VTK come librerie di base. Il software esiste dalla fine degli anni Novanta; quello che cambia adesso è la struttura di finanziamento e governance che lo regge. Lo sviluppo distribuito su più centri, gli incontri di co-sviluppo dove i gruppi lavorano fianco a fianco per giorni sulla piattaforma, la revisione del codice e l’integrazione continua sui build server multipiattaforma entrano in un programma finanziato. Smettono di essere attività volontarie ai margini dei singoli laboratori.

Per un centro di neurochirurgia o un gruppo di ricerca clinica, la conseguenza pratica è avere una piattaforma senza costo di licenza, con un modello dati documentato e la possibilità di aggiungere i propri algoritmi come moduli esterni. Il laboratorio del Brigham and Women’s da oltre dieci anni accumula casi e pubblicazioni su pianificazione neurochirurgica e neuroimaging con questo software, e la licenza BSD ne consente l’uso anche dentro prodotti commerciali.

Limiti

La curva di apprendimento è ripida: Slicer dà per scontata una certa familiarità con i concetti di volume, registrazione e segmentazione, e l’attuale interfaccia Tcl/Tk si porta addosso gli anni. È in programma un rifacimento dell’interfaccia con un toolkit più moderno e, più avanti, una release maggiore con architettura estesa, ma sono lavori in corso, non capacità già disponibili oggi.

Lo strumento serve la ricerca traslazionale, non è un dispositivo medico certificato: l’uso clinico resta responsabilità del centro che lo adotta e va tenuto dentro i propri protocolli. Esistono alternative con scopi diversi — MedINRIA per neuroimaging e DTI, MIPAV scritto in Java alla NIH, OsiriX come viewer DICOM su Mac OS X, e Amira sul versante commerciale — e la scelta dipende dal flusso di lavoro più che dalla profondità algoritmica. Quello che 3D Slicer offre oggi è un modello dati centrale e un meccanismo per agganciarci moduli scritti altrove; quanto regga su larga scala dipenderà da quanto disciplinata resterà quella separazione.

Immagine di copertina: Schermata di 3D Slicer del 2004: sezione di risonanza cerebrale con parcellazione corticale a colori e sigle dei giri (PrG, PoG, SFG)… — schermata di Wenples, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:3DSlicer-Park-AJNR2004-Fig1.jpg