O VoxTell é um modelo de visão-linguagem 3D que segmenta estruturas em imagens médicas volumétricas a partir de prompts em texto livre. Treinado em mais de 62 mil volumes de CT, RM e PET cobrindo mais de mil classes anatômicas e patológicas, o modelo representa um avanço concreto em segmentação automática. Integrações open source conectam o VoxTell a interfaces web interativas e ao Varian Eclipse ESAPI, criando protótipos de pesquisa que aproximam modelos acadêmicos do workflow real de radioterapia.
Este artigo detalha a arquitetura do modelo, as duas integrações públicas — web e ESAPI — e o pipeline de conversão de coordenadas DICOM que torna tudo possível. Todo o conteúdo se refere exclusivamente a ferramentas de pesquisa e avaliação técnica, nunca a software clínico.
O Que o VoxTell Muda na Segmentação 3D
Modelos convencionais de segmentação operam com rótulos fixos. Se o modelo não foi treinado para “tumor de fossa posterior”, ele simplesmente não segmenta. O VoxTell substitui esse paradigma por prompts em texto livre: o operador digita a estrutura desejada — de “fígado” a “rim esquerdo com cisto cortical” — e o modelo gera a máscara volumétrica correspondente.
A arquitetura combina um encoder de imagem 3D com o Qwen3-Embedding-4B como encoder de texto congelado. Um decoder de prompts transforma as consultas textuais e representações de imagem latentes em features textuais multi-escala. O decoder de imagem funde informação visual e textual em múltiplas resoluções usando fusão query-imagem no estilo MaskFormer com supervisão profunda. O resultado: segmentação zero-shot com desempenho estado-da-arte em estruturas familiares e generalização razoável para classes nunca vistas.
O paper original (arXiv:2511.11450) documenta treinamento em 158 datasets públicos cobrindo cérebro, cabeça e pescoço, tórax, abdômen, pelve e sistema musculoesquelético — incluindo estruturas vasculares, subestruturas de órgãos e lesões. Uma base que reflete a migração da IA de algoritmos isolados para integração no workflow.
Interface Web: Viewer 3D, RTStruct e Engenharia para GPU Limitada
O voxtell-web-plugin é uma aplicação FastAPI + React/TypeScript que coloca o modelo atrás de uma interface acessível. O operador faz upload de um volume (.nii, .nii.gz ou DICOM), digita um prompt como “liver” ou “prostate tumor”, e recebe a máscara 3D sobreposta no viewer NiiVue em tempo real.
A engenharia de baixo consumo de VRAM é o diferencial prático. O encoder de texto Qwen3-Embedding-4B roda em float16, reduzindo o uso de memória de ~15 GB para ~7,5 GB. O alocador de memória usa expandable_segments=True para reduzir fragmentação, e o sliding window opera com perform_everything_on_device=False para offload parcial para CPU. Com isso, GPUs de 12 GB já conseguem rodar inferência — hardware que se encontra em estações de trabalho de pesquisa, não só em clusters.
O viewer suporta acumulação de múltiplas segmentações (fígado + baço + rins na mesma sessão), desenho manual para refinamento, e exportação em NIfTI e RTStruct. A exportação RTStruct é particularmente relevante: ela produz um arquivo DICOM-RT que pode ser importado em sistemas de planejamento para avaliação comparativa — sempre em contexto de pesquisa.
Atenção à orientação: as imagens devem estar em orientação RAS para localização anatômica correta esquerda/direita. Discrepâncias de orientação produzem resultados espelhados ou incorretos. O PyTorch 2.9.0 apresenta um bug de OOM em convoluções 3D; a versão recomendada é 2.8.0 ou anterior.
Varian Eclipse ESAPI: Como Funciona a Integração
O VoxTell-ESAPI adiciona dois componentes ao ecossistema: um servidor Python/FastAPI que recebe dados CT via HTTP e roda inferência em GPU, e um plugin C# ESAPI que extrai CT do Varian Eclipse, envia ao servidor e reimporta os contornos resultantes como estruturas RT.
O workflow completo funciona assim:
- O operador abre um paciente no Eclipse com CT e structure set existente
- O plugin cria uma sessão no servidor, enviando geometria do volume (origin, row/column/slice direction, spacing)
- Para cada slice Z, os voxels são extraídos como
ushort[xSize, ySize], convertidos para int32, serializados em little-endian, comprimidos com gzip e codificados em base64 — reduzindo payload em ~4× - Após envio de todas as slices, o servidor assembla o volume NIfTI com conversão LPS→RAS
- O operador digita prompts (ex: “liver, left kidney, spleen”) e submete
- A inferência roda assincronamente — o Eclipse não trava
- O servidor extrai contornos 2D das máscaras e retorna coordenadas em LPS (paciente)
- O plugin importa via
structure.AddContourOnImagePlane(contour_points_lps, z_index)
Estruturas existentes são associadas por nome (exato, case-insensitive ou fuzzy). Estruturas não encontradas são auto-criadas com tipo DICOM CONTROL. Nomes são sanitizados para 16 caracteres (ex: “left kidney” → “left_kidney”).
Este plugin destina-se exclusivamente a ambientes não clínicos: ECNC (External Calculation and Non-Clinical) e Varian TBOX (training box). Nunca deve ser executado em ambiente clínico.
Pipeline de Conversão DICOM: LPS, RAS e a Matemática das Coordenadas
A conversão de coordenadas entre DICOM (LPS) e NIfTI (RAS) é o ponto técnico mais crítico de toda a integração. Um erro nesta etapa produz volumes espelhados, contornos invertidos anteroposterior ou estruturas no lado errado do paciente. O pipeline implementa a transformação rigorosamente.
Geometria DICOM → Afim LPS
O Eclipse expõe a geometria da imagem (origin, row direction, column direction, slice direction, spacing). O servidor constrói a matriz afim 4×4 que mapeia índices de voxel para posições em milímetros no sistema DICOM LPS (Left, Posterior, Superior):
$$x_{LPS} = A_{LPS} \begin{bmatrix} i \\ j \\ k \\ 1 \end{bmatrix}$$
Onde as colunas de $A_{LPS}$ são formadas por:
- Coluna 0:
row_direction × x_res(eixo coluna +X) - Coluna 1:
col_direction × y_res(eixo linha +Y) - Coluna 2:
slice_direction × z_res(eixo slice +Z) - Coluna 3:
origin(posição do voxel 0,0,0)
Conversão LPS → RAS
DICOM e NIfTI usam convenções opostas nos dois primeiros eixos:
| Sistema | X | Y | Z |
|---|---|---|---|
| DICOM/Eclipse (LPS) | Patient Left | Patient Posterior | Patient Superior |
| NIfTI/VoxTell (RAS) | Patient Right | Patient Anterior | Patient Superior |
A transformação exige inversão dos dois primeiros eixos:
$$A_{RAS} = \operatorname{diag}(-1,-1,1,1) \cdot A_{LPS}$$
No código, o volume é transposto de (Z,Y,X) para (X,Y,Z) para a convenção NIfTI, e os eixos X e Y do afim são invertidos. Uma cópia ingênua produz um volume espelhado e invertido anteroposterior — exatamente o tipo de erro que só aparece em revisão clínica rigorosa, não em testes automatizados.
Retorno: Máscaras RAS → Contornos LPS
Após inferência, o caminho inverso usa find_contours do scikit-image para extrair linhas de contorno 2D em cada slice, e projeta os índices de voxel de volta para milímetros LPS usando o afim armazenado na sessão:
$$\text{pts}_{LPS} = (\text{vox\_coords} \cdot A_{LPS}^T)[:, :3]$$
Os pontos são enviados ao Eclipse, que os aplica diretamente via AddContourOnImagePlane().
Métricas de Avaliação
Para avaliar a qualidade da segmentação, duas métricas são padrão:
O coeficiente Dice mede a sobreposição entre a segmentação predita $X$ e a referência $Y$:
$$DSC(X,Y) = \frac{2|X \cap Y|}{|X| + |Y|}$$
A distância de Hausdorff mede a pior divergência pontual entre superfícies:
$$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 Pesquisa, Fronteiras SaMD e Por Que a Linguagem Regulatória Importa
O mercado de software médico opera sob regulação rigorosa. Qualquer software que influencie decisões diagnósticas ou terapêuticas pode ser classificado como Software as a Medical Device (SaMD), sujeito a frameworks como IEC 62304, ISO 14971, IMDRF e regulações de agências como FDA, ANVISA e CE Marking.
Os plugins descritos neste artigo — web e ESAPI — são ferramentas de pesquisa, experimentação, prototipagem e avaliação técnica. Especificamente:
- O modelo VoxTell original é trabalho do grupo de pesquisa citado no paper (Rokuss et al., 2025), não da RT Medical Systems
- A RT Medical contribui com engenharia open source de integrações e extensões públicas ao redor do VoxTell
- O plugin ESAPI destina-se exclusivamente a ECNC e Varian TBOX — ambientes não clínicos
- Estes plugins nunca devem ser usados clinicamente
- Não são software médico aprovado, liberado, validado ou autorizado por qualquer agência reguladora
- Não há endosso formal de Varian, DKFZ, MIC-DKFZ ou dos autores originais do paper
Uso clínico de qualquer ferramenta de segmentação assistida por IA exigiria validação independente, sistema de gestão de qualidade, análise de risco (ISO 14971), processo de cybersecurity, e avaliação regulatória completa. Essas não são formalidades — são as barreiras que separam protótipos de pesquisa de dispositivos que influenciam tratamento de pacientes.
Para profissionais que trabalham com desenvolvimento de software DICOM ou com implementação e troubleshooting de infraestrutura DICOM, entender essa fronteira é essencial antes de avaliar qualquer ferramenta de IA.
Engenharia de Integração: O Que Radioterapia Exige de Software
O valor técnico dessas integrações não está no modelo em si — modelos de segmentação surgem a cada trimestre. O valor está em demonstrar as competências de engenharia que qualquer empresa de software para radioterapia precisa dominar:
- Interoperabilidade DICOM: conversão bidirecional entre formatos (NIfTI ↔ DICOM), manipulação de afins e orientação de volume, exportação RTStruct
- Integração com TPS: comunicação via ESAPI, serialização de voxels, importação de contornos em coordenadas de paciente
- Otimização de recursos: inferência em GPU de consumo, offload para CPU, compressão de payload
- Workflow assíncrono: sessões com TTL, polling sem bloquear UI, cancelamento e limpeza
- Governança: separação clara entre pesquisa e produto clínico, linguagem regulatória precisa
Cada um desses pontos é um requisito real em projetos como RTConnect e pipelines de revisão de contornos — não exercícios teóricos, mas problemas que aparecem em cada integração com equipamentos e sistemas de planejamento reais. A padronização de estruturas segundo TG-263 é outro ponto de convergência direta.
Próximos Passos e Contexto para Equipes
O roadmap público do VoxTell indica que suporte a fine-tuning ainda não foi liberado. Quando estiver disponível, abrirá possibilidade de adaptação para estruturas de interesse específico — por exemplo, estruturas OAR de cabeça e pescoço segundo protocolos institucionais — novamente em contexto de pesquisa.
Se sua equipe está avaliando workflows de contorno assistido por IA, pipelines de validação, ou camadas de revisão e governança em torno de segmentação, a RT Medical Systems pode ajudar a estruturar essa discussão.
Todas as informações técnicas deste artigo foram extraídas de fontes públicas: o paper VoxTell (arXiv:2511.11450, Rokuss et al., 2025) e os repositórios GitHub gomesgustavoo/voxtell-web-plugin e gomesgustavoo/VoxTell-ESAPI.
