A pergunta veio no minuto quarenta de uma demo, de um coordenador de auditoria que tinha passado a reunião inteira calado. "E quando a TUSS muda de versão? Quem atualiza as regras?" Não era curiosidade técnica. A operadora dele tinha atravessado a última mudança de versão TUSS com uma planilha de de-para mantida à mão, e a auditoria passou seis semanas glosando procedimento legítimo como código inexistente. Ninguém naquela sala queria repetir a experiência.
Das últimas cinco demos que fizemos com operadoras de médio porte, três trouxeram alguma variação dessa pergunta. Minha leitura é que ela é menos sobre terminologia e mais sobre confiança: de que adianta automatizar a auditoria de contas médicas se cada atualização de tabela derruba a precisão do motor por um trimestre?
Este post é a resposta longa que uma demo não comporta. A tese: transição de versão de tabela é o teste de estresse do motor de regras, e quem trata a atualização como chamado de manutenção descobre isso tarde. A transição se desenrola em três momentos, cada um com um modo de falha próprio. Vale acompanhar pelo relógio.
T menos 60: a atualização sai e o relógio começa
A ANS publica a atualização da terminologia com antecedência em relação à vigência. Nesse intervalo, o trabalho técnico parece simples: comparar a versão nova com a atual e listar o que entrou, o que mudou de descrição e o que foi extinto. Quase toda operadora faz isso. O que quase nenhuma faz é a segunda pergunta, que é a que importa para a auditoria de entrada: quais das minhas regras referenciam códigos afetados?
Num motor maduro, regras acumulam. Regra de compatibilidade entre procedimento e caráter de atendimento, teto de quantidade por competência, exigência de laudo para determinados códigos, restrição por especialidade do executante. Depois de alguns anos, são centenas. Se as regras referenciam códigos de forma literal, sem camada de indireção, ninguém sabe dizer quantas quebram com a tabela nova sem varrer uma a uma. Já vimos time de TI descobrir regra órfã, apontando para código extinto havia dois anos, durante a preparação para a versão seguinte. A regra simplesmente nunca mais tinha disparado, e a validação que ela fazia sumiu junto, em silêncio.
O erro clássico dessa fase é editar a regra no lugar, sobrescrevendo a referência antiga pela nova. Funciona para a conta que chega amanhã. Destrói a capacidade de explicar a conta que foi julgada ontem. Guarde essa consequência, porque ela cobra caro no terceiro ato.
T zero: duas tabelas valem ao mesmo tempo
Aqui mora o engano mais comum, e ele é conceitual, não de implementação. A vigência da tabela nova não zera o passado. Uma conta se julga pela terminologia vigente na data do atendimento, não na data em que a conta chega para análise. E conta atrasa: prestador fecha faturamento no ciclo dele, recurso reabre discussão meses depois, internação longa atravessa a fronteira da vigência com diárias dos dois lados.
O volume torna isso estatisticamente inevitável. A base de dados abertos do Padrão TISS, que a ANS atualizou em junho de 2026 com os números de 2025, registra 558 milhões de registros de SP/SADT no ano e adesão de 78% das operadoras ao envio. Com esse fluxo, sempre haverá conta antiga entrando no motor depois da virada.
Um motor que valida contra uma tabela única, a atual, produz dois erros simétricos no T zero. Glosa procedimento legítimo apresentado com código da versão anterior, o falso positivo que enterra a área de recurso de glosa e desgasta a rede. E aceita código novo em atendimento anterior à vigência, o falso negativo que ninguém percebe porque não gera reclamação de ninguém. O primeiro erro faz barulho. O segundo vaza margem calado.
A resposta técnica é vigência por competência: cada versão da tabela existe no motor como registro com data de início e fim, e a conta seleciona a versão pela data do atendimento. Não é conceito exótico. É o mesmo effective dating que sistema atuarial usa há décadas. O que surpreende é quantos motores de auditoria em produção não o implementam.
T mais 90: a cauda longa e a pergunta do recurso
Três meses depois da virada, chega o teste que quase ninguém ensaia. Um prestador recorre de uma glosa aplicada semanas antes da mudança. Para sustentar ou reverter a decisão, a operadora precisa reconstituir o julgamento: qual versão da tabela valia para aquele atendimento, qual versão da regra estava ativa naquele dia, e o que exatamente ela verificou.
Se as regras foram editadas no lugar durante o T menos 60, essa reconstituição é impossível. O motor atual dá a resposta de hoje para uma pergunta de ontem. Pelo que percebemos em operações reais, é nesse momento que a área jurídica e a de relacionamento com a rede descobrem, juntas, que a trilha de auditoria não existia. Frente a um recurso bem montado, glosa sem reconstituição tende a ser revertida, e cada reversão vira precedente que a rede aprende a explorar.
A cauda é mais longa do que parece. Recurso administrativo, depois eventual judicialização, depois fiscalização. Em todos esses foros a pergunta é a mesma: prove que a decisão automática estava correta segundo as referências vigentes à época. Um motor sem versionamento de regras responde com silêncio.
Mudança de versão TUSS tratada como deploy, não como chamado
A engenharia que resolve os três momentos é conhecida de qualquer time que faz software: versionamento e processo de release. Aplicada à auditoria de entrada, ela tem quatro peças.
Tabelas com vigência, como descrito acima. De-para como artefato de dado versionado, com dono, revisão e teste, nunca como planilha avulsa no drive de alguém. Regras que referenciam conceitos com indireção, para que a troca de código não exija caçar referências literais. E execução em sombra: a configuração nova roda em paralelo sobre o fluxo real, sem efeito, por um período definido, e a comparação entre as duas saídas diz o que a virada vai causar antes de causar.
Vale aterrissar o que indireção significa, porque o termo assusta mais do que deveria. Em vez de a regra listar três códigos de oito dígitos um a um, ela referencia um conjunto nomeado, algo como "diárias de terapia intensiva", que existe no motor como objeto próprio, versionado, apontando para os códigos vigentes em cada versão da tabela. Quando a TUSS vira, quem muda é o conjunto, uma única vez, e todas as regras que o referenciam seguem válidas sem edição. A varredura do T menos 60 deixa de ser caça por referência literal espalhada em centenas de regras e vira revisão de algumas dezenas de conjuntos com dono definido.
E o que medir na sombra? Duas séries bastam para a decisão de ativar: a taxa de divergência entre a configuração atual e a nova, conta a conta, e o valor financeiro agregado dessas divergências por tipo de regra. Divergência alta concentrada numa regra só costuma indicar de-para incompleto naquele grupo de códigos, não regra errada. Pelo que vemos em fluxos de alto volume, uma janela de duas a três semanas de sombra é suficiente para o padrão estabilizar.
Esse desenho é exatamente o que o AI.AUDITAMED implementa no seu Gerenciador de Regras. Cada regra é um objeto com histórico e vigência que se liga e desliga por toggle, sem release de software. Antes de ativar uma mudança, o gestor simula o impacto financeiro sobre o fluxo real e vê quanto de glosa aquela configuração teria gerado ou deixado de gerar. E regras customizadas da operadora convivem com o pacote padrão TISS e ANS, com a mesma trilha. A transição de versão deixa de ser um chamado urgente de TI e vira uma operação de rotina do próprio time de auditoria, com ensaio e medição. Esse trabalho, vale dizer, depende de o dado chegar normalizado ao motor; sobre essa camada anterior, escrevemos em detalhe em o gargalo da auditoria não é o modelo.
Duas honestidades antes da síntese. Primeira: o de-para automatizado resolve bem renomeação e fusão de códigos, mas falha na divisão, quando um código extinto se abre em vários mais específicos. Decidir qual dos novos corresponde ao atendimento é leitura clínica, não mapeamento mecânico, e esse resíduo continua precisando de gente. Segunda, e contraintuitiva: durante a janela de convivência, a decisão certa às vezes é glosar menos automaticamente, roteando os casos ambíguos para revisão humana em vez de sustentar a taxa de automação a qualquer custo. Precisão que se mantém às custas de falso positivo não é precisão, é ruído com convicção.
A pergunta do coordenador da demo tinha resposta curta, no fim: sua auditoria sabe da mudança se o motor foi desenhado para versionar. A mudança de versão TUSS não é um evento externo que atrapalha a auditoria automatizada. É parte do domínio, previsível e ensaiável, e o AI.AUDITAMED foi construído com essa premissa: tabelas com vigência por competência, de-para versionado e um Gerenciador de Regras que simula o impacto financeiro de qualquer mudança antes de ativá-la.
Se a sua operadora vai atravessar a próxima atualização de terminologia com planilha e sobrescrita de regra, vale ver o outro caminho funcionando. Nossa avaliação prática roda o AI.AUDITAMED sobre uma amostra das suas contas cobrindo uma transição de versão passada, compara as decisões do motor com o que a sua auditoria decidiu à época, e entrega um relatório de onde o versionamento teria evitado glosa indevida e recuperado glosa perdida. Solicitar avaliação do AI.AUDITAMED.
"Sozinhos, combatemos uma fraude. Unidos, eliminamos o problema."