RayStation para fótons: collapsed cone e Monte Carlo lado a lado

Quando um fabricante mantém dois motores de fótons dentro do mesmo TPS, isso costuma dizer mais sobre a realidade da clínica do que muito material de marketing. No papel, é tentador resumir a história assim: um motor é o rápido, o outro é o preciso. Na prática, essa leitura é rasa. O que interessa é entender por que os dois continuam coexistindo, em que tipo de caso cada um faz sentido e o que o próprio fabricante aceita como limite de validação.

No RayStation, essa convivência aparece de forma particularmente clara. A documentação regulatória local de RayStation v2025 SP1 declara sem rodeios que o sistema opera com dois photon dose engines: collapsed cone (CC) e Monte Carlo (MC). Isso não é redundância. É uma decisão comercial e clínica ao mesmo tempo, pensada para equilibrar velocidade, cobertura de fluxo, modelagem física e responsabilidade metodológica.

Se o Acuros XB marcou a entrada do transporte determinístico no ecossistema Eclipse, o par CC/MC do RayStation mostra outra maturidade possível: manter um motor analítico muito forte como base clínica e reservar o Monte Carlo para os contextos em que a física mais explícita realmente compensa.

O que o próprio RayStation diz

O texto regulatório local é muito claro logo de saída: RayStation has two photon dose engines: collapsed cone (CC) and Monte Carlo (MC). Isso já elimina uma confusão comum. O sistema não trata o Monte Carlo como única forma séria de cálculo nem o collapsed cone como herança residual. Os dois motores fazem parte da arquitetura clínica do produto.

O white paper oficial da RaySearch ajuda a entender o papel do CC. Nele, o motor clínico de fótons é descrito como baseado nos princípios clássicos de collapsed cone convolution superposition. O mesmo documento resume a cadeia de cálculo em quatro passos:

1. cálculo da fluência a partir de um modelo multi-fonte;
2. transporte dos fótons incidentes por ray tracing através do paciente;
3. redistribuição da energia com kernels EGSnrc pré-computados;
4. cálculo separado da contaminação eletrônica, somado à dose de fótons.

Essa descrição é valiosa porque mostra que o CC do RayStation não é um algoritmo “leve” no sentido trivial. Ele é um motor clínico robusto, ancorado na tradição de collapsed cone, com modelagem multi-fonte e kernels Monte Carlo. Isso explica por que continua tão relevante mesmo em um sistema que também oferece Monte Carlo.

A importância de os dois motores compartilharem a mesma base de fluência

Talvez o aspecto mais interessante da arquitetura do RayStation seja este: o fabricante afirma que o motor Monte Carlo de fótons usa a mesma computação de fluência no cabeçote que o motor collapsed cone.

Isso muda bastante a forma de interpretar divergências entre os dois. Em muitos TPS, a tentação é supor que qualquer diferença grande entre motores nasce de uma cadeia completamente diferente desde a fonte. No RayStation, pelo menos conceitualmente, a parte de modelagem de fluência do LINAC permanece alinhada. O que muda de forma decisiva é a física de deposição no paciente.

Essa arquitetura tem duas consequências úteis:

• ela reduz a chance de que diferenças grosseiras entre CC e MC sejam atribuídas apenas a modelos de fonte incompatíveis;
• ela torna a comparação entre os dois motores mais informativa sobre a resposta do meio e o tipo de transporte empregado.

Isso não elimina o papel do beam model, claro. Mas ajuda a concentrar a discussão naquilo que o clínico realmente quer saber: quanto da diferença observada nasce do modo como a dose é calculada dentro do paciente.

O que significa usar collapsed cone no RayStation

O collapsed cone nasceu para resolver um problema clássico: como manter o coração físico da convolução/superposição sem pagar o custo integral de uma superposição completa voxel a voxel. Em vez de transportar energia em todas as direções possíveis com custo proibitivo, o método colapsa a energia em um conjunto finito de direções, preservando a energia total de forma eficiente.

No RayStation, essa filosofia aparece acoplada a um modelo multi-fonte da fluência. No white paper, a fonte primária é representada como uma gaussiana elíptica espacial; a secundária, como gaussiana circular; e ainda há duas fontes de elétrons contaminantes. A colimação é modelada em suas posições físicas, com descrição de offsets, leaf tips e tongue-and-groove.

Essa arquitetura explica uma parte importante do desempenho clínico do motor. O CC não depende apenas do kernel. Ele depende de:

• uma descrição fisicamente razoável do cabeçote;
• ray tracing divergente através do paciente;
• escalonamento da deposição de energia segundo propriedades locais;
• soma explícita da contribuição de contaminação eletrônica.

Em outras palavras, o CC do RayStation está longe de ser um algoritmo simplificado no sentido pejorativo. Ele é um motor clínico de alto nível, construído para resolver a maior parte da rotina com boa fidelidade e custo computacional controlado.

Como o RaySearch valida o collapsed cone

É aqui que o material local fica especialmente forte. O IFU de RayStation v2025 SP1 não fica apenas na descrição algorítmica; ele entra em validação com bastante detalhe.

Segundo a documentação, a validação do collapsed cone photon dose engine incluiu:

• doses pontuais em fantomas homogêneos e heterogêneos;
• doses em linha;
• filme;
• detectores como Delta4, MapCheck, ArcCheck, MatriXX, Octavius1500 e PTW 729;
• a IAEA test suite, com casos medidos para máquina Elekta em 6 MV, 10 MV e 18 MV.

Os critérios de aceitação são descritos em termos de gamma, diferença de dose pontual e níveis de confiança. O documento afirma que a acurácia global foi considerada aceitável e que as limitações algorítmicas identificadas são tratadas em avisos e na referência técnica do sistema.

Esse trecho é importante por duas razões.

A primeira é que ele reposiciona o CC como motor clinicamente sério, não como mero cálculo preliminar.

A segunda é que ele mostra uma atitude metodológica correta: a validação é apresentada por escopo, por técnica e por tipo de medição. Isso é exatamente o oposto da simplificação comercial que transforma todo algoritmo em promessa universal.

Comparação do CC com outros TPS

O mesmo documento informa que o collapsed cone do RayStation foi comparado a TPS independentes e bem estabelecidos, incluindo:

• Eclipse (Varian);
• Pinnacle³;
• Monaco (Elekta);
• Oncentra (Elekta);
• Precision (Accuray).

O texto também diz que, dentro dos critérios de aceitação usados, os cálculos do motor puderam ser considerados equivalentes aos sistemas clínicos com os quais foram comparados.

Esse ponto merece leitura cuidadosa. Não significa que todos os TPS sejam “iguais”. Significa que, dentro do escopo de validação utilizado, o RayStation CC alcançou concordância compatível com a prática clínica frente a sistemas comerciais já consolidados.

Isso é muito diferente de dizer que não há diferença entre motores. Há. Mas a comparação útil precisa sempre ser situada em:

• técnica de tratamento;
• geometria;
• máquina;
• tipo de heterogeneidade;
• beam model usado.

Escopo de máquina e técnica: onde o IFU é mais honesto que a propaganda

Uma virtude do IFU local é deixar claro que cobertura de algoritmo não é a mesma coisa que cobertura uniforme de validação. O RayStation descreve com bastante detalhe as máquinas e técnicas contempladas:

• Varian, Elekta e Siemens em várias configurações;
• FFF em exemplos como Siemens Artiste e Varian Halcyon;
• validação com m3 MLC em Varian Novalis;
• validação de VMAT padrão para Varian, Elekta e Vero;
• validação específica para wave arcs em Vero e OXRAY;
• validação de CyberKnife com cones fixos, iris e MLC;
• suporte a TomoTherapy para o motor apropriado.

Também aparecem limitações importantes:

• VMAT em campos pequenos é altamente sensível a parâmetros de MLC do beam model;
• certas técnicas devem ser tratadas como praticamente uma nova técnica, exigindo validação de modelo e QA por paciente;
• algumas máquinas ou modalidades têm cobertura parcial ou exigem cautela adicional.

Esse tipo de informação deveria orientar qualquer uso sério do sistema. A pergunta correta nunca é “o motor suporta VMAT?”, mas “qual VMAT, em qual máquina, com qual beam model, dentro de qual escopo de validação?”.

E o Monte Carlo do RayStation?

O IFU local também é claro ao descrever o motor Monte Carlo de fótons. O ponto conceitual mais interessante é este: o photon Monte Carlo dose engine uses the same fluence computation in the LINAC head as the collapsed cone dose engine.

Essa frase é decisiva porque mostra onde os motores se separam. O cabeçote e a descrição da fluência não são necessariamente o principal divisor. O grande divisor está na forma de calcular a deposição dentro do paciente.

O Monte Carlo do RayStation foi validado, segundo o documento, com:

• subconjunto representativo das medidas usadas para o CC;
• diferentes energias de 4 MV a 20 MV;
• diferentes modelos de LINAC;
• wedges, cones e blocks;
• geometrias homogêneas e heterogêneas;
• IAEA test suite;
• AAPM TG105 de alta resolução com inserções heterogêneas.

Além disso, o texto afirma que o cálculo MC em paciente foi cross-checked com EGSnrc em geometrias variadas, materiais como água, pulmão, osso, alumínio e titânio, campos de 0.4 x 0.4 cm² a 40 x 40 cm² e inclusive com e sem campo magnético.

Esse é o ponto em que o RayStation mostra uma filosofia forte: não basta dizer que há Monte Carlo; é preciso mostrar contra o que ele foi confrontado e em que contexto.

Onde o próprio IFU impõe limites ao entusiasmo com o MC

Outro mérito da documentação é não tratar o Monte Carlo como universalmente disponível ou universalmente validado para qualquer máquina. O texto local é explícito:

• o Monte Carlo de fótons não suporta TomoTherapy;
• não foi validado para Vero e Siemens LINACs;
• em certas plataformas, cabe ao usuário validar o uso clínico.

Esse tipo de frase deveria ser mais lembrado em discussões sobre motores “mais avançados”. Um algoritmo pode ser fisicamente mais forte e, ainda assim, ter cobertura prática mais limitada em parte do parque tecnológico. Para o serviço, isso significa uma coisa simples: não existe substituição automática de CC por MC só porque o segundo parece mais sofisticado.

Existe sempre uma pergunta anterior:

este motor está validado, nesta versão, para esta máquina e para esta técnica?

Sem essa pergunta, a comparação entre motores vira abstração.

Onde CC e MC convivem de forma inteligente

A convivência dos dois motores faz sentido porque eles respondem a perguntas um pouco diferentes.

O CC tende a ser a escolha natural quando:

• a rotina clínica exige alta velocidade;
• a geometria está dentro do território bem coberto por algoritmos de collapsed cone;
• o serviço precisa de um motor robusto para grande volume de planejamento;
• a diferença esperada para MC não deve alterar conduta.

O MC tende a ganhar terreno quando:

• há heterogeneidades mais agressivas;
• o caso envolve materiais mais desafiadores;
• o campo é muito pequeno;
• a incerteza residual do motor analítico pode ser clinicamente relevante;
• o serviço quer refinar o cálculo final em situações mais críticas.

Essa divisão não deve ser lida como regra rígida, mas como raciocínio clínico. O erro comum é transformar MC em símbolo automático de superioridade, quando o problema real muitas vezes está no beam model, no material mapping, no grid ou na técnica escolhida.

O aviso mais importante do IFU: compatibilidade de convenção de dose

Talvez o trecho mais clinicamente subestimado de todo o documento seja o aviso sobre comparação entre motores.

O RayStation alerta explicitamente que doses computadas com motores diferentes devem ser combinadas ou comparadas com cuidado quando a convenção de dose difere e o plano é sensível a materiais de alto número atômico.

O texto local afirma:

• o photon collapsed cone dose engine computa dose to water com transporte em água de densidade variável;
• o photon Monte Carlo dose engine em RayStation v2025 reporta dose to medium com transporte em meio;
• a diferença costuma ser pequena em tecidos que não sejam osso;
• em osso ou materiais de alto Z, a diferença pode ficar relativamente grande.

Essa observação vale ouro porque mostra como a coexistência entre motores exige maturidade metodológica. Não basta comparar duas curvas DVH se elas não representam exatamente a mesma convenção física.

O que o par CC/MC ensina sobre TPS comerciais

Talvez a principal lição editorial aqui seja esta: o RayStation deixa claro, de forma quase pedagógica, que a radioterapia moderna não se resume a “escolher o algoritmo mais sofisticado”. Ela depende de alinhar:

• o tipo de caso;
• o tipo de motor;
• o beam model;
• a técnica de entrega;
• o escopo de validação;
• a convenção de dose usada.

Ao manter CC e MC lado a lado, o sistema assume uma verdade clínica que às vezes é escondida em discursos simplistas: diferentes motores têm papeis diferentes, e a maturidade de um serviço aparece justamente na forma como ele decide quando cada um deve ser usado.

O que um serviço maduro faz com essa coexistência

Quando um serviço dispõe de CC e MC no mesmo TPS, a melhor estratégia não é eleger um vencedor universal. A melhor estratégia é estabelecer uma política explícita de uso. Algo como:

• em quais sítios o CC é o motor de rotina;
• em quais cenários o MC é usado como refinamento final;
• em quais casos a comparação entre ambos é mandatória;
• como interpretar discrepâncias em osso, implantes e heterogeneidades de baixa densidade;
• como registrar a convenção de dose de cada distribuição.

Sem essa política, a coexistência dos motores vira liberdade aparente e confusão prática. Com essa política, a instituição transforma a variedade algorítmica em capacidade clínica real.

Esse é o ponto principal do RayStation como exemplo comercial. O valor do sistema não está em oferecer dois motores para que o usuário escolha um campeão ideológico. O valor está em oferecer duas respostas fisicamente diferentes, cada uma com seu campo de força, seu custo e seu limite de validação.

Serviço maduro não usa essa coexistência para produzir comparações de vitrine. Usa para tomar decisão melhor.