Erros Mais Comuns no Preenchimento de Guias TISS/TUSS

Os erros mais comuns no preenchimento de guias TISS/TUSS se dividem em quatro grupos: erros cadastrais e de autorização, erros de codificação TUSS, inconsistências entre TUSS e CID, e falhas operacionais no processo de faturamento. Praticamente toda glosa administrativa nasce de um desses quatro pontos — e a maioria é evitável com revisão e validação antes do envio à operadora.

A guia TISS é um arquivo estruturado (XML) que carrega dados do beneficiário, do prestador, do atendimento e dos códigos TUSS utilizados. Qualquer campo ausente, incoerente ou fora do formato esperado pode levar à rejeição do arquivo pela operadora, mesmo quando o atendimento em si foi realizado corretamente. Entender onde esses erros costumam acontecer é o primeiro passo para reduzir glosas administrativas.

É a causa mais básica e mais comum de rejeição: campos deixados em branco, ausência de assinatura do profissional ou do beneficiário, ou falta de informações que o sistema deveria ter preenchido automaticamente. Guias incompletas costumam ser identificadas já na validação estrutural do XML, antes mesmo de chegar à análise da operadora.

Cada tipo de guia (consulta, SP/SADT, internação, honorários) tem seu próprio conjunto de campos obrigatórios, definidos pelo schema oficial do Padrão TISS. Preencher um campo obrigatório com formato incorreto — uma data fora do padrão esperado, um valor numérico com formatação inválida, um código fora do domínio permitido — invalida a guia da mesma forma que deixá-la em branco.

Divergências entre o número da carteirinha informado na guia e o cadastro do beneficiário na operadora, nome digitado de forma diferente do cadastro, ou dados de elegibilidade desatualizados geram rejeição por incompatibilidade cadastral. Esse tipo de erro é especialmente comum quando o atendimento é registrado às pressas ou quando o sistema da clínica não faz verificação automática de elegibilidade antes do atendimento.

Acontece quando a descrição do procedimento informada não corresponde exatamente ao código TUSS utilizado, ou quando o profissional detalha o atendimento com termos próprios em vez de usar a nomenclatura padronizada. Como a validação compara código e descrição, uma divergência entre os dois campos pode gerar rejeição mesmo que o código em si esteja correto.

• CPF, CNS ou número de carteirinha do beneficiário incorretos ou incompletos

• Dados do prestador (CNPJ, CNES, código na operadora) desatualizados no cadastro

• Ausência do número de autorização em procedimentos que exigem autorização prévia da operadora

• Data de atendimento posterior à data de autorização, ou fora do prazo de validade da guia

• Código TUSS desatualizado, copiado de uma versão antiga da tabela

• Uso de código de uma tabela errada (por exemplo, um código de medicamento lançado como se fosse um procedimento)

• Código de procedimento não coberto pelo contrato daquela operadora específica

• Confusão entre códigos parecidos, especialmente em procedimentos com pequenas variações de técnica ou complexidade

A TUSS identifica o procedimento realizado; o CID identifica o diagnóstico que justifica esse procedimento. Um erro comum é o descompasso entre os dois: um código CID que não tem relação clínica plausível com o procedimento TUSS informado, ou a ausência do CID em guias que exigem essa informação para autorização. Como vimos no artigo sobre glosas, esse tipo de divergência costuma gerar glosa técnica, não apenas administrativa, porque questiona a pertinência clínica do procedimento.

• Cobrança em duplicidade do mesmo procedimento

• Envio da guia fora do prazo de validade definido em contrato

• Uso de uma versão desatualizada do schema XML do Padrão TISS

• Lote de faturamento montado incorretamente, com hash de integridade divergente

Na prática, uma guia com erro segue um de dois caminhos: é rejeitada antes mesmo de entrar na fila de análise da operadora (erro estrutural ou de schema), ou é aceita, processada e depois glosada (erro de conteúdo, como código incorreto ou incompatibilidade CID x TUSS). Em qualquer um dos dois casos, o resultado é o mesmo: atraso no recebimento e retrabalho da equipe de faturamento para identificar, corrigir e reenviar a guia.

Um Validador TISS é uma ferramenta que analisa o arquivo XML antes do envio à operadora, comparando-o com o schema oficial publicado pela ANS e sinalizando campos obrigatórios ausentes, formatos inválidos, códigos fora do domínio esperado e inconsistências de hash no lote de guias. Usar essa validação como uma etapa padrão do processo — antes de transmitir o lote, nunca depois — transforma erros que seriam descobertos como rejeição ou glosa em correções feitas ainda dentro de casa, sem impacto no prazo de recebimento.

• O sistema de gestão da clínica gera o arquivo XML no padrão TISS vigente, com os dados do atendimento, procedimentos e códigos TUSS utilizados.

• O arquivo é carregado em um validador TISS, que o compara à estrutura (schema) oficial exigida pela ANS.

• O validador retorna um relatório indicando exatamente qual campo, guia ou linha do XML apresenta problema.

• A equipe corrige o dado na origem (no sistema de gestão) e gera o XML novamente.

• O arquivo corrigido é validado outra vez antes do envio definitivo à operadora.

Quer saber mais? Aproveite para ler outros artigos no nosso blog:

• Tabela TUSS: o que é, como consultar a versão atualizada | Blog IDOMED

• Como Consultar a Tabela TUSS Passo a Passo | Blog IDOMED

• TUSS na Prática: Faturamento Médico para Quem Está se Formando

Quais são os erros mais comuns no preenchimento da guia TISS?

É uma ferramenta que verifica se o arquivo XML de uma guia TISS segue corretamente o schema oficial da ANS antes do envio à operadora, sinalizando erros estruturais, campos ausentes e inconsistências de codificação.

O erro de codificação TUSS está no código do procedimento em si — incorreto, desatualizado ou de tabela errada. O erro de CID está na justificativa clínica do procedimento; quando os dois não são compatíveis entre si, a guia pode ser glosada por divergência técnica, não apenas administrativa.

Não. A rejeição acontece antes da análise, geralmente por erro estrutural no XML. A glosa acontece depois que a guia foi aceita e analisada, quando a operadora identifica um problema de conteúdo, como código incorreto ou falta de autorização.

Mantendo o cadastro de beneficiários e prestadores atualizado, usando sempre a versão vigente da Tabela TUSS, conferindo a compatibilidade entre CID e procedimento, e validando o arquivo XML antes do envio, não depois.