Atualização de versão do TISS: como não parar o faturamento

Um dia o lote que sempre foi aceito volta 100% rejeitado — não por erro de cadastro, não por falta de autorização, mas porque a versão do TISS mudou e o seu sistema ainda fala a versão antiga. A ANS publica atualizações do padrão TISS (Troca de Informação em Saúde Suplementar) com regularidade, cada uma com uma data a partir da qual passa a valer. Para quem se planeja, é um evento de calendário. Para quem descobre em cima da hora, é o faturamento inteiro parado por dias — ou semanas.

O que muda quando a versão do TISS troca

O padrão TISS não é só um formato de arquivo XML: é um conjunto de regras — schema, tabelas de domínio, campos obrigatórios, estrutura de guias — que define como laboratórios, clínicas e hospitais trocam informação com as operadoras de saúde suplementar. A ANS mantém esse padrão vivo, revisando-o para incorporar novos procedimentos, corrigir ambiguidades e acompanhar mudanças regulatórias do setor.

Cada nova versão publicada tem, tipicamente, três componentes que mudam ao mesmo tempo: o schema XSD que valida a estrutura do XML, as tabelas de domínio (TUSS, motivos de glosa, situações de guia) e as regras de preenchimento de campos específicos. Um XML gerado na versão antiga simplesmente não passa na validação estrutural da versão nova — e vice-versa.

Por que a ANS atualiza o padrão com regularidade

A saúde suplementar não é estática: novos procedimentos entram na Terminologia Unificada da Saúde Suplementar (TUSS), regras de autorização mudam, e a própria ANS aprende com o volume de glosas e dúvidas do setor. Atualizar a versão do TISS é como a agência corrige rota — sem isso, o padrão ficaria defasado em relação ao que realmente acontece no consultório e no laboratório.

• Novos procedimentos e materiais. Exames e insumos que não existiam na versão anterior precisam de código e regra de cobrança.
• Correção de inconsistências. Campos ambíguos ou regras que geravam interpretação divergente entre operadoras são fechados.
• Novas obrigações regulatórias. Mudanças de rol, de regras de autorização ou de segurança de dados que precisam de suporte estrutural no XML.
• Modernização técnica. Ajustes de schema para reduzir erro de preenchimento e melhorar a auditabilidade do lote.

Prazos da ANS: publicação, homologação e obrigatoriedade

A ANS não troca a versão da noite para o dia. O ciclo normal tem três marcos, e conhecer cada um é o que separa uma migração tranquila de um faturamento parado:

O ponto de atenção real é a janela de convivência: durante um período, a ANS aceita as duas versões, o que dá tempo para testar sem pressão. O problema é que essa janela tem prazo definido — e ela some sem aviso individual por laboratório. Quem trata a data de obrigatoriedade como "mais uma comunicação de operadora" descobre o problema só quando o lote volta rejeitado.

O que a troca de versão realmente mexe no seu sistema

Para quem opera o laboratório, a pergunta prática é: onde isso aparece na tela? A resposta é que a atualização de versão do TISS não fica restrita ao "módulo de faturamento" — ela se propaga por várias camadas do fluxo de geração da guia.

Isso explica por que "só trocar o número da versão no cabeçalho" nunca funciona: cada camada precisa ser revisada e testada de forma independente, porque uma guia pode estar estruturalmente válida e ainda assim ser glosada por um campo que ficou obrigatório na versão nova.

Como migrar de versão sem parar o faturamento

A diferença entre uma migração tranquila e um mês de caixa apertado está inteiramente no tempo de antecedência. O roteiro abaixo cabe confortavelmente dentro da janela de convivência que a ANS costuma abrir entre a publicação e a obrigatoriedade.

1. Leia o manual de especificações da nova versão assim que a ANS publica — não espere a operadora avisar, o prazo corre independente disso.
2. Confirme com o fornecedor do seu sistema (LIS) a data prevista de suporte à nova versão e se ela cobre o ambiente de homologação.
3. Gere lotes de teste na versão nova e envie ao ambiente de homologação das principais operadoras da sua carteira.
4. Compare o retorno entre versão antiga e nova para o mesmo conjunto de guias, isolando qualquer divergência de campo obrigatório.
5. Defina uma data interna de corte anterior à data de obrigatoriedade da ANS, com margem de segurança de pelo menos duas semanas.
6. Acompanhe o primeiro lote real na versão nova com atenção redobrada nos primeiros retornos de protocolo.

O papel do sistema (LIS) na hora da troca

Um laboratório não deveria precisar reprogramar nada internamente quando a ANS publica uma versão nova — essa é justamente a função de um LIS atualizado: absorver a mudança de schema, tabela de domínio e campo obrigatório no motor de geração de guia, sem que o gestor precise entender XML ou acompanhar manualmente cada nota técnica.

Na prática, isso significa três coisas concretas: o sistema já vem com a versão nova disponível antes da data de obrigatoriedade, oferece um modo de envio para homologação separado do envio de produção, e mostra com clareza qual versão está sendo usada em cada lote — para que nunca seja uma surpresa descoberta só na resposta da operadora.

A atualização de versão do TISS é um evento previsível: a ANS publica, abre uma janela de convivência e define uma data de corte. O laboratório que trata isso como item de calendário — lê o manual, testa em homologação, define corte interno com folga — atravessa a troca sem sentir. Quem espera a notificação da operadora chegar sozinha descobre o problema tarde demais, com o faturamento do mês inteiro parado. A diferença não é sorte, é antecedência.