Commissioning, QA e leitura crítica: como comparar algoritmos sem cair em erro metodológico

Existe uma forma muito eficiente de produzir confusão em física clínica: recalcular o mesmo caso em dois motores, abrir DVHs lado a lado e tratar qualquer diferença como prova. Em quase todo serviço, é assim que nascem frases como “o algoritmo X calcula mais dose” ou “o algoritmo Y é mais conservador”. Quase nunca a comparação está limpa o suficiente para sustentar isso.

O motivo é simples. Quando dois resultados divergem, o que está sendo comparado não é só o nome do motor. Normalmente entram junto beam model, resolução de grade, material mapping, convenção de dose, parâmetros de MLC e até o escopo de validação daquela técnica na máquina real.

É por isso que esta parte do cluster pesa tanto na rotina. Entender AAA, Acuros XB, collapsed cone e Monte Carlo é importante. Saber comparar esses motores sem se enganar com a própria metodologia é o que realmente muda a prática.

O primeiro erro: achar que algoritmo é igual a resultado

O algoritmo importa muito, mas ele nunca trabalha sozinho. Em qualquer TPS comercial sério, o resultado que aparece na tela depende de pelo menos cinco camadas:

1. modelo de feixe (beam model);
2. dados de commissioning e medição;
3. resolução e discretização;
4. representação do paciente e dos materiais;
5. convenção de reporte da dose.

Quando alguém diz que “o algoritmo X deu dose maior que o algoritmo Y”, a frase está incompleta. O que deu dose maior foi um conjunto inteiro de escolhas: motor, modelo, grid, material mapping, técnica, máquina e, às vezes, grandeza de dose diferente.

Beam model: a parte invisível da comparação

O beam model é um dos fatores mais subestimados em comparações entre TPS. Ele define como o sistema descreve:

• a fonte primária;
• fótons extra-focais;
• contaminação eletrônica;
• colimadores;
• MLC;
• wedges;
• fatores de saída;
• parâmetros geométricos e dosimétricos do feixe.

O Eclipse deixa isso evidente ao mostrar que AAA e Acuros XB compartilham o mesmo photon beam source model. Já o RayStation insiste, em seu IFU, que certos cenários, especialmente small field rotational plans, são altamente sensíveis a parâmetros de MLC do beam model.

Essa observação é decisiva. Às vezes, o físico acredita estar vendo uma diferença de família algorítmica, quando na verdade está vendo:

• diferença de MLC modeling;
• diferença de commissioning;
• diferença de parametrização de fonte.

Sem isolar essas camadas, a comparação vira mistura de causas.

O segundo erro: comparar grids diferentes como se fossem a mesma coisa

Resolução de dose não é detalhe cosmético. Ela muda:

• amostragem de gradiente;
• definição da penumbra;
• dose em volumes pequenos;
• comportamento em interfaces;
• aparência do acordo entre algoritmos.

O AAA usa grade divergente internamente e depende da relação entre resolução escolhida, pixel spacing e separação entre cortes. O Acuros XB usa discretização espacial variável com refinamento adaptativo. Monte Carlo, por sua vez, ainda traz o componente adicional do ruído estatístico por voxel.

Isso significa que comparar dois algoritmos sem equalizar a malha de saída, ou sem ao menos entender como cada um discretiza o problema internamente, é metodologicamente frágil.

Uma regra prática útil é esta: antes de discutir física, alinhe discretização.

O terceiro erro: ignorar a convenção de dose

Esse ponto fica cada vez mais importante à medida que os serviços passam a usar algoritmos material-explícitos.

O Acuros XB permite dose to medium e dose to water. O RayStation, no material local, alerta que o photon collapsed cone computa dose para água, enquanto o photon Monte Carlo reporta dose para meio. O mesmo documento adverte explicitamente sobre o risco de combinar ou comparar distribuições de motores diferentes quando o caso é sensível a materiais de alto Z.

Se o serviço ignora isso, o que parece divergência algorítmica pode ser, em parte, divergência de grandeza física reportada.

Em termos práticos, antes de comparar qualquer dose entre motores, o físico precisa responder:

1. os dois motores estão reportando a mesma convenção?
2. a diferença esperada entre as convenções é pequena neste material?
3. há osso, implante ou outro material que amplifique essa discrepância?

Sem essas perguntas, até um DVH bonito pode estar sendo interpretado de forma errada.

O quarto erro: tratar a técnica como se fosse automaticamente validada

O IFU do RayStation é muito útil porque fala a linguagem que todo serviço deveria adotar. O documento lembra que certas técnicas, como VMAT sequencing, devem ser tratadas como praticamente uma nova técnica, exigindo:

• validação do beam model;
• validação do comportamento da máquina;
• QA por paciente.

Essa observação deveria ser universalizada. O fato de um algoritmo funcionar muito bem em 3D-CRT não garante automaticamente o mesmo comportamento em:

• IMRT fixa;
• VMAT;
• wave arcs;
• campos muito pequenos;
• técnicas específicas de plataforma.

Sempre que a técnica muda, a validade do conjunto algoritmo + beam model + entrega precisa ser reavaliada.

O que commissioning realmente deveria responder

Em vez de tratar commissioning como checklist genérico, vale formular as perguntas certas.

Um commissioning sério precisa mostrar:

• se o motor reproduz profundidade dose, perfis e fatores de saída da máquina;
• se o comportamento se mantém em campos pequenos;
• se o algoritmo responde corretamente em meios heterogêneos relevantes para a clínica local;
• se a modelagem de MLC está adequada;
• se as escolhas de grid e de imagem não introduzem artefatos relevantes;
• se a convenção de dose adotada é conhecida e consistente.

Em outras palavras, commissioning não é “fazer o algoritmo passar”. É descobrir em que território aquele conjunto pode ser usado com confiança.

Uma matriz de testes é melhor do que uma pilha de medições desconectadas

Em vez de pensar commissioning como coleção de dados, vale pensar como matriz de perguntas. Uma matriz mínima útil costuma cruzar:

• campo aberto e campo pequeno;
• homogêneo e heterogêneo;
• eixo central e fora do eixo;
• técnica simples e técnica modulada;
• material água-equivalente e material clinicamente desafiador.

Quando a equipe monta essa matriz, fica mais fácil perceber se o algoritmo está falhando em uma fronteira específica do uso clínico ou se o problema é global. Sem essa organização, o serviço pode ter muitas medições e pouca clareza.

O papel dos fantomas heterogêneos

Heterogeneidade não pode ser deixada apenas para o caso clínico real. Quando um serviço pretende usar algoritmos mais sofisticados justamente por causa de pulmão, osso, cavidades ou implantes, precisa testar o conjunto em geometrias que obriguem o motor a lidar com esses fenômenos.

Os materiais locais usados aqui reforçam essa necessidade:

• o Eclipse explicita limitações em pulmão;
• o RayStation descreve validações em geometrias homogêneas e heterogêneas, inclusive com IAEA test suite, AAPM TG105 e comparação com EGSnrc;
• o handbook mostra benchmarks em que a diferença entre AAA e Acuros XB aparece de forma clara em heterogeneidades de baixa densidade.

Isso sugere uma regra simples: se o serviço quer se apoiar em ganho de performance em heterogeneidade, precisa validar heterogeneidade com intenção, não por inferência.

Gamma não resolve tudo

Gamma continua útil, mas é frequentemente usado como atalho mental. Um motor pode passar em gamma global e ainda esconder diferenças clinicamente relevantes em regiões pequenas, interfaces ou materiais específicos.

O RayStation usa critérios como 95% dos pontos com gamma 3%, 3 mm < 1, e isso faz sentido como parte do processo de validação. Mas a leitura madura não para aí. Um conjunto de testes precisa combinar:

• gamma;
• diferenças pontuais;
• leitura de perfis;
• atenção a regiões de gradiente;
• análise em heterogeneidades;
• interpretação clínica do local da discrepância.

Se o gamma passa, mas a diferença relevante está exatamente no pulmão distal, no osso ou junto a um implante, o problema não desaparece.

QA por paciente não substitui QA do algoritmo

Outro equívoco frequente é usar QA por paciente como se ele pudesse compensar qualquer lacuna no entendimento do motor de dose. Não pode.

QA por paciente responde, em geral, a uma pergunta mais restrita: se o plano calculado e entregue mantém coerência dentro de um arranjo específico de medição e critério de comparação.

Ele não substitui:

• validação do algoritmo em heterogeneidade;
• entendimento da convenção de dose;
• análise do beam model;
• escopo formal de commissioning da técnica.

Quando o serviço usa QA por paciente como muleta para uma dúvida algorítmica estrutural, ele corre o risco de validar repetidamente a mesma hipótese frágil.

Quando a comparação entre algoritmos é realmente útil

Comparar motores faz sentido quando a instituição quer responder perguntas concretas, por exemplo:

• AAA e Acuros XB mudam a cobertura em pulmão pequeno de alta energia?
• o CC e o MC do RayStation divergem em um sítio com osso ou alto Z?
• a mudança de motor altera interpretação de background dose ou reirradiação?
• a diferença observada pertence ao transporte ou à convenção de dose?

Essa é a comparação boa: orientada por hipótese.

A comparação ruim é a que busca provar, de forma genérica, que “algoritmo A é melhor que algoritmo B” sem declarar cenário, técnica, material e beam model.

Um roteiro mínimo para comparar algoritmos com rigor

Se a instituição quiser fazer isso direito, um roteiro mínimo inclui:

1. igualar ou justificar grid e imagem;
2. verificar se os beam models estão maduros;
3. declarar a convenção de dose de cada motor;
4. separar testes homogêneos de testes heterogêneos;
5. incluir ao menos um cenário clinicamente crítico para o serviço;
6. avaliar perfis, profundidade, dose local e não só DVH;
7. registrar em que situações a diferença muda decisão e em quais não muda.

Esse roteiro já filtra boa parte do ruído metodológico que costuma aparecer em discussões informais sobre TPS.

O que a literatura e os manuais ensinam em conjunto

Lendo lado a lado os documentos locais usados neste cluster, aparece uma mensagem convergente.

O Eclipse mostra que algoritmos diferentes têm fundamentos diferentes e limitações conhecidas. O RayStation mostra que motores distintos convivem com escopos de validação específicos e convenções de dose potencialmente diferentes. O handbook mostra que o desempenho relativo entre famílias algorítmicas muda de acordo com a heterogeneidade e a física dominante do caso.

Juntos, esses materiais deixam uma conclusão incômoda, mas importante: se a comparação entre algoritmos foi feita sem declarar o restante da cadeia de modelagem, a conclusão provavelmente está superinterpretada.

O ganho real de uma comparação bem feita

Quando a comparação é bem montada, ela deixa de produzir slogans e começa a produzir fronteiras de confiança. Ou seja:

• em quais cenários o algoritmo A já é suficiente;
• em quais cenários vale recalcular com B;
• em quais cenários a diferença observada é física de fato;
• em quais cenários ela é apenas metodológica.

Esse tipo de resposta vale mais para a clínica do que qualquer ranking genérico entre TPS. No fim, é isso que um commissioning decente deveria entregar: não um “algoritmo vencedor”, mas um mapa honesto de onde cada combinação motor + beam model + técnica ainda responde bem e onde ela já precisa de validação extra, recalculação ou mudança de estratégia.