VoxTell es un modelo de visión-lenguaje 3D que segmenta estructuras en imágenes médicas volumétricas a partir de prompts en texto libre. Entrenado con más de 62.000 volúmenes de TC, RM y PET que abarcan más de mil clases anatómicas y patológicas, el modelo representa un avance concreto en segmentación automática. Integraciones open source conectan VoxTell a interfaces web interactivas y al Varian Eclipse ESAPI, creando prototipos de investigación que acercan modelos académicos al workflow real de radioterapia.
Este artículo detalla la arquitectura del modelo, las dos integraciones públicas — web y ESAPI — y el pipeline de conversión de coordenadas DICOM que hace todo posible. Todo el contenido se refiere exclusivamente a herramientas de investigación y evaluación técnica, nunca a software clínico.
Qué Cambia VoxTell en la Segmentación 3D
Los modelos convencionales de segmentación operan con etiquetas fijas. Si el modelo no fue entrenado para «tumor de fosa posterior», simplemente no segmenta. VoxTell sustituye este paradigma por prompts en texto libre: el operador escribe la estructura deseada — desde «hígado» hasta «riñón izquierdo con quiste cortical» — y el modelo genera la máscara volumétrica correspondiente.
La arquitectura combina un encoder de imagen 3D con Qwen3-Embedding-4B como encoder de texto congelado. Un decoder de prompts transforma las consultas textuales y representaciones de imagen latentes en features textuales multi-escala. El decoder de imagen fusiona información visual y textual en múltiples resoluciones usando fusión query-imagen estilo MaskFormer con supervisión profunda. El resultado: segmentación zero-shot con rendimiento estado del arte en estructuras conocidas y generalización razonable a clases nunca vistas.
El paper original (arXiv:2511.11450) documenta entrenamiento en 158 datasets públicos que cubren cerebro, cabeza y cuello, tórax, abdomen, pelvis y sistema musculoesquelético — incluyendo estructuras vasculares, subestructuras de órganos y lesiones. Una base que refleja la migración de la IA de algoritmos aislados a integración en el workflow.
Interfaz Web: Viewer 3D, RTStruct e Ingeniería para GPU Limitada
El voxtell-web-plugin es una aplicación FastAPI + React/TypeScript que pone el modelo detrás de una interfaz accesible. El operador sube un volumen (.nii, .nii.gz o DICOM), escribe un prompt como «liver» o «prostate tumor», y recibe la máscara 3D superpuesta en el viewer NiiVue en tiempo real.
La ingeniería de bajo consumo de VRAM es el diferencial práctico. El encoder de texto Qwen3-Embedding-4B corre en float16, reduciendo el uso de memoria de ~15 GB a ~7,5 GB. El asignador de memoria usa expandable_segments=True para reducir fragmentación, y el sliding window opera con perform_everything_on_device=False para offload parcial a CPU. Con esto, GPUs de 12 GB ya pueden ejecutar inferencia — hardware que se encuentra en estaciones de trabajo de investigación, no solo en clusters.
El viewer soporta acumulación de múltiples segmentaciones (hígado + bazo + riñones en la misma sesión), dibujo manual para refinamiento, y exportación en NIfTI y RTStruct. La exportación RTStruct es particularmente relevante: produce un archivo DICOM-RT que puede importarse en sistemas de planificación para evaluación comparativa — siempre en contexto de investigación.
Atención a la orientación: las imágenes deben estar en orientación RAS para localización anatómica correcta izquierda/derecha. Discrepancias de orientación producen resultados espejados o incorrectos. PyTorch 2.9.0 presenta un bug de OOM en convoluciones 3D; la versión recomendada es 2.8.0 o anterior.
Varian Eclipse ESAPI: Cómo Funciona la Integración
El VoxTell-ESAPI agrega dos componentes al ecosistema: un servidor Python/FastAPI que recibe datos CT vía HTTP y ejecuta inferencia en GPU, y un plugin C# ESAPI que extrae CT del Varian Eclipse, lo envía al servidor y reimporta los contornos resultantes como estructuras RT.
El workflow completo funciona así:
- El operador abre un paciente en Eclipse con CT y structure set existente
- El plugin crea una sesión en el servidor, enviando geometría del volumen (origin, row/column/slice direction, spacing)
- Para cada slice Z, los voxels se extraen como
ushort[xSize, ySize], se convierten a int32, serializan en little-endian, comprimen con gzip y codifican en base64 — reduciendo el payload ~4× - Tras enviar todas las slices, el servidor ensambla el volumen NIfTI con conversión LPS→RAS
- El operador escribe prompts (ej: «liver, left kidney, spleen») y envía
- La inferencia se ejecuta asincrónicamente — Eclipse no se bloquea
- El servidor extrae contornos 2D de las máscaras y devuelve coordenadas en LPS (paciente)
- El plugin importa vía
structure.AddContourOnImagePlane(contour_points_lps, z_index)
Estructuras existentes se asocian por nombre (exacto, case-insensitive o fuzzy). Estructuras no encontradas se auto-crean con tipo DICOM CONTROL. Los nombres se sanitizan a 16 caracteres (ej: «left kidney» → «left_kidney»).
Este plugin está destinado exclusivamente a entornos no clínicos: ECNC (External Calculation and Non-Clinical) y Varian TBOX (training box). Nunca debe ejecutarse en entorno clínico.
Pipeline de Conversión DICOM: LPS, RAS y la Matemática de las Coordenadas
La conversión de coordenadas entre DICOM (LPS) y NIfTI (RAS) es el punto técnico más crítico de toda la integración. Un error en esta etapa produce volúmenes espejados, contornos invertidos anteroposteriormente o estructuras del lado equivocado del paciente. El pipeline implementa la transformación rigurosamente.
Geometría DICOM → Afín LPS
Eclipse expone la geometría de la imagen (origin, row direction, column direction, slice direction, spacing). El servidor construye la matriz afín 4×4 que mapea índices de voxel a posiciones en milímetros en el sistema DICOM LPS (Left, Posterior, Superior):
$$x_{LPS} = A_{LPS} \begin{bmatrix} i \\ j \\ k \\ 1 \end{bmatrix}$$
Donde las columnas de $A_{LPS}$ se forman con:
- Columna 0:
row_direction × x_res(eje columna +X) - Columna 1:
col_direction × y_res(eje fila +Y) - Columna 2:
slice_direction × z_res(eje slice +Z) - Columna 3:
origin(posición del voxel 0,0,0)
Conversión LPS → RAS
DICOM y NIfTI usan convenciones opuestas en los dos primeros ejes:
| Sistema | X | Y | Z |
|---|---|---|---|
| DICOM/Eclipse (LPS) | Patient Left | Patient Posterior | Patient Superior |
| NIfTI/VoxTell (RAS) | Patient Right | Patient Anterior | Patient Superior |
La transformación requiere invertir los dos primeros ejes:
$$A_{RAS} = \operatorname{diag}(-1,-1,1,1) \cdot A_{LPS}$$
En código, el volumen se transpone de (Z,Y,X) a (X,Y,Z) para la convención NIfTI, y los ejes X e Y del afín se invierten. Una copia ingenua produce un volumen espejado e invertido anteroposteriormente — exactamente el tipo de error que solo aparece en revisión clínica rigurosa, no en tests automatizados.
Retorno: Máscaras RAS → Puntos de Contorno LPS
Tras la inferencia, el camino inverso usa find_contours de scikit-image para extraer líneas de contorno 2D en cada slice, y proyecta los índices de voxel de vuelta a milímetros LPS usando el afín almacenado en la sesión:
$$\text{pts}_{LPS} = (\text{vox\_coords} \cdot A_{LPS}^T)[:, :3]$$
Los puntos se envían a Eclipse, que los aplica directamente vía AddContourOnImagePlane().
Métricas de Evaluación
Dos métricas estándar evalúan la calidad de la segmentación:
El coeficiente Dice mide la superposición entre la segmentación predicha $X$ y la referencia $Y$:
$$DSC(X,Y) = \frac{2|X \cap Y|}{|X| + |Y|}$$
La distancia de Hausdorff mide la peor divergencia puntual entre superficies:
$$HD(X,Y) = \max\left\{\sup_{x \in X}\inf_{y \in Y} d(x,y),\; \sup_{y \in Y}\inf_{x \in X} d(x,y)\right\}$$
Plugins de Investigación, Fronteras SaMD y Por Qué el Lenguaje Regulatorio Importa
El mercado de software médico opera bajo regulación rigurosa. Cualquier software que influya en decisiones diagnósticas o terapéuticas puede clasificarse como Software as a Medical Device (SaMD), sujeto a frameworks como IEC 62304, ISO 14971, IMDRF y regulaciones de agencias como FDA, ANVISA y marcado CE.
Los plugins descritos en este artículo — web y ESAPI — son herramientas de investigación, experimentación, prototipado y evaluación técnica. Específicamente:
- El modelo VoxTell original es trabajo del grupo de investigación citado en el paper (Rokuss et al., 2025), no de RT Medical Systems
- RT Medical contribuye con ingeniería open source de integraciones y extensiones públicas alrededor de VoxTell
- El plugin ESAPI está destinado exclusivamente a ECNC y Varian TBOX — entornos no clínicos
- Estos plugins nunca deben usarse clínicamente
- No son software médico aprobado, liberado, validado o autorizado por ninguna agencia reguladora
- No hay respaldo formal de Varian, DKFZ, MIC-DKFZ ni de los autores originales del paper
El uso clínico de cualquier herramienta de segmentación asistida por IA requeriría validación independiente, sistema de gestión de calidad, análisis de riesgo (ISO 14971), revisión de ciberseguridad y evaluación regulatoria completa. No son formalidades — son las barreras que separan prototipos de investigación de dispositivos que influyen en el tratamiento de pacientes.
Para profesionales que trabajan con desarrollo de software DICOM o con implementación de infraestructura DICOM, entender esta frontera es esencial antes de evaluar cualquier herramienta de IA.
Ingeniería de Integración: Lo Que Radioterapia Exige del Software
El valor técnico de estas integraciones no está en el modelo en sí — modelos de segmentación aparecen cada trimestre. El valor está en demostrar las competencias de ingeniería que cualquier empresa de software para radioterapia necesita dominar:
- Interoperabilidad DICOM: conversión bidireccional entre formatos (NIfTI ↔ DICOM), manipulación de afines, orientación de volumen, exportación RTStruct
- Integración con TPS: comunicación vía ESAPI, serialización de voxels, importación de contornos en coordenadas de paciente
- Optimización de recursos: inferencia en GPU de consumo, offload a CPU, compresión de payload
- Workflow asincrónico: sesiones con TTL, polling sin bloquear UI, cancelación y limpieza
- Gobernanza: separación clara entre investigación y producto clínico, lenguaje regulatorio preciso
Cada uno de estos puntos es un requisito real en proyectos como RTConnect y pipelines de revisión de contornos — no ejercicios teóricos, sino problemas que aparecen en cada integración con equipos y sistemas de planificación reales. La estandarización de estructuras según TG-263 es otro punto de convergencia directa.
Próximos Pasos y Contexto para Equipos
El roadmap público de VoxTell indica que el soporte para fine-tuning aún no ha sido liberado. Cuando esté disponible, abrirá posibilidades de adaptación a estructuras de interés específico — por ejemplo, estructuras OAR de cabeza y cuello según protocolos institucionales — nuevamente en contexto de investigación.
Si su equipo está evaluando workflows de contorno asistido por IA, pipelines de validación, o capas de revisión y gobernanza en torno a segmentación, RT Medical Systems puede ayudar a estructurar esa discusión.
Toda la información técnica de este artículo fue extraída de fuentes públicas: el paper VoxTell (arXiv:2511.11450, Rokuss et al., 2025) y los repositorios GitHub gomesgustavoo/voxtell-web-plugin y gomesgustavoo/VoxTell-ESAPI.
