Tratar rejeição TISS de modo consistente exige mais do que alterar um campo: a equipe precisa preservar o retorno, encontrar a origem da divergência, corrigir com responsável definido, gerar outro XML e fazer uma nova validação antes de seguir o fluxo aplicável à operadora.
Uma rejeição técnica interrompe a rotina e costuma criar pressão para corrigir o arquivo rapidamente. Ainda assim, tratar rejeição TISS com segurança operacional pede uma sequência rastreável: identificar o que retornou, registrar o contexto, separar hipótese de evidência, corrigir a fonte do dado e conferir o novo resultado. Esse método ajuda clínicas, consultórios, hospitais, laboratórios e equipes de faturamento a evitar alterações por tentativa e erro, preservar o histórico do caso e distribuir responsabilidades entre cadastro, área assistencial, faturamento e tecnologia quando necessário.
Neste artigo
Receba e registre a rejeição antes de alterar o arquivo
O primeiro cuidado é não sobrescrever o XML ou a guia que originou a ocorrência. Guarde uma cópia identificável do arquivo analisado e preserve a mensagem completa recebida, incluindo código, descrição, data, referência de lote ou guia e canal de retorno. Se a mensagem vier em tela, e-mail, relatório ou portal, registre também de onde ela foi obtida. A descrição curta do erro deve ser mantida como foi apresentada; uma interpretação interna pode ser adicionada em campo separado, mas não deve substituir o texto original.
Registro mínimo para cada ocorrência
| Campo | O que registrar | Finalidade operacional |
|---|---|---|
| Identificador interno | Número da ocorrência e vínculo com guia, conta, lote ou arquivo | Localizar o caso sem depender de memória ou mensagens dispersas |
| Retorno recebido | Mensagem integral, código quando houver e canal de origem | Distinguir o retorno original da análise interna |
| Contexto | Operadora, unidade, competência, tipo de guia e data de identificação | Delimitar onde a falha ocorreu |
| Arquivo e revisão | Nome ou identificador do XML original e das revisões posteriores | Evitar corrigir ou validar a versão errada |
| Responsável atual | Pessoa ou área que deverá executar o próximo passo | Impedir que o item fique sem dono |
| Status | Registrado, em investigação, aguardando dado, corrigido, revalidado ou encerrado | Mostrar a situação atual do tratamento |
O registro não precisa ser complexo para ser útil. Uma planilha controlada, um chamado interno ou um módulo do sistema pode cumprir essa função, desde que permita recuperar o histórico e indique o próximo passo. Quando houver dados pessoais ou assistenciais, aplique os controles de acesso e as práticas de privacidade definidos pela organização. O objetivo é dar contexto suficiente a quem revisará o caso, sem replicar informações sensíveis em locais desnecessários.
Classifique a falha e investigue a informação de origem
A mensagem de rejeição é um ponto de partida, não um diagnóstico definitivo. Antes de editar o XML, classifique provisoriamente a ocorrência conforme o tipo de investigação que ela exige: dado ausente ou divergente, estrutura do arquivo, código ou terminologia, regra operacional, versão ou parâmetro de geração. Essa classificação organiza a busca, mas pode ser revista quando novas evidências aparecerem. O Padrão TISS possui componentes distintos para regras operacionais, conteúdo e estrutura, representação de conceitos em saúde, segurança e privacidade e comunicação; portanto, uma ocorrência não deve ser tratada como se todo problema estivesse necessariamente na estrutura do XML. (Minist�rio da Sa�de)
Perguntas para localizar a origem
Faça a investigação seguindo uma ordem simples, da evidência mais próxima do atendimento até a geração do arquivo. Não altere informações apenas para eliminar uma crítica sem confirmar qual fonte sustenta o valor correto.
- Qual campo, item, guia ou segmento é citado pela mensagem ou pela conferência interna?
- Qual cadastro, documento, registro assistencial, agenda, autorização ou lançamento alimentou aquela informação?
- A informação da guia corresponde à fonte definida pela organização para esse dado?
- A regra consultada é aplicável à operadora, ao contrato, à competência e ao tipo de atendimento do caso?
- A falha aparece somente neste registro ou também em outros arquivos gerados pelo mesmo processo?
- Quem pode confirmar ou alterar a origem sem criar uma divergência entre sistemas?
Também é importante separar rejeição, pendência e glosa no controle interno, porque cada situação pode demandar encaminhamentos diferentes. A rejeição técnica tratada neste roteiro ocorre antes de considerar qualquer desfecho financeiro; ela sinaliza que existe algo a examinar no arquivo ou no processo que o produziu. Para aprofundar essa distinção e evitar que os termos sejam usados como sinônimos na fila de trabalho, consulte
Corrija a causa confirmada e gere uma nova revisão do XML
Após confirmar a origem, defina uma ação concreta, um responsável e uma evidência esperada de conclusão. Se o problema estiver em dado cadastral, corrija-o na fonte autorizada e atualize os registros dependentes conforme a rotina interna. Se estiver no mapeamento ou na parametrização, encaminhe a correção a quem responde tecnicamente pelo gerador. Se faltar confirmação documental ou operacional, mantenha o item em espera explícita, em vez de preencher o campo por suposição. A correção deve explicar o que mudou, por que mudou e qual evidência sustentou a decisão.
Matriz de ação por natureza da falha
| Natureza identificada | Fonte a revisar | Ação de correção | Evidência a registrar |
|---|---|---|---|
| Dado de origem | Cadastro, documento ou registro do atendimento | Corrigir ou confirmar a informação na fonte responsável | Fonte consultada, responsável e data da alteração |
| Lançamento da guia | Guia em preparação e documentos de apoio | Ajustar o lançamento para refletir a informação confirmada | Campo alterado e motivo da alteração |
| Geração ou mapeamento | Parâmetro, integração ou sistema gerador | Solicitar ajuste técnico e testar a revisão gerada | Chamado, versão interna e resultado do teste |
| Regra operacional | Contrato, manual, comunicado ou canal aplicável | Confirmar a orientação e atualizar a rotina quando necessário | Referência consultada e decisão adotada |
| Informação insuficiente | Área que detém a evidência necessária | Solicitar esclarecimento com pergunta objetiva | Pendência, destinatário e prazo interno de retorno |
Somente depois de a alteração estar concluída na origem adequada, gere um novo XML. Dê à nova geração um identificador de revisão ligado ao arquivo original, sem substituir a referência anterior no controle. Compare o conteúdo alterado com a evidência que motivou a correção e verifique se a geração incorporou efetivamente o dado novo. Essa etapa é particularmente importante quando a mudança depende de sincronização entre cadastros, integrações ou parâmetros: corrigir uma tela não prova, por si só, que o arquivo produzido já mudou.
Faça a nova validação e registre seu alcance
A nova validação XML TISS deve ocorrer sobre a revisão recém-gerada, e não sobre um arquivo anterior com o mesmo nome ou conteúdo parecido. Registre a data, a pessoa responsável, a ferramenta utilizada, a referência técnica adotada quando aplicável e o resultado encontrado. O componente de comunicação do Padrão TISS adota XML para as mensagens eletrônicas, enquanto o componente de conteúdo e estrutura trata da arquitetura dos dados usados nessas mensagens. (Padrão TISS – Janeiro/2025 — Agência Nacional de Saúde Suplementar) Essa divisão reforça a necessidade de conferir tanto o arquivo refeito quanto a origem do dado que ele representa. (Padrão TISS – Janeiro/2025 — Agência Nacional de Saúde Suplementar)
Uma validação sem crítica técnica é uma evidência relevante para a conferência interna, mas não é promessa de aceitação, pagamento ou processamento pela operadora. Regras operacionais, condições contratuais, dados assistenciais e procedimentos do relacionamento específico precisam ser avaliados no fluxo aplicável. A norma da ANS estabelece que a troca dos dados do Padrão TISS deve ser eletrônica e na versão vigente; por isso, antes de concluir a rotina, confirme a referência aplicável ao caso em vez de reutilizar uma versão anotada em procedimento antigo. (Minist�rio da Sa�de)
Como apoio à conferência técnica, o
Encerre o caso com aprendizado e previna repetições
Encerrar uma ocorrência não é apenas marcar “corrigido”. O registro final deve indicar qual era a falha observada, qual hipótese foi confirmada ou descartada, onde a correção foi aplicada, qual XML foi revalidado e qual resultado foi obtido na conferência interna. Se ainda existir uma etapa externa a cumprir, mantenha o status como acompanhamento, não como concluído. Essa distinção evita que a equipe confunda a correção técnica do arquivo com um desfecho que depende de outro fluxo.
Checklist único de fechamento e prevenção
Use a mesma lista para cada ocorrência e consolide as causas recorrentes em uma revisão periódica da rotina.
- Manter a mensagem original e o contexto vinculados ao registro
- Identificar a fonte do dado e o responsável pela correção
- Descrever a alteração efetuada e a evidência que a sustentou
- Relacionar o XML original à revisão gerada após a correção
- Registrar o resultado da nova validação e seu responsável
- Indicar claramente se o caso está corrigido, revalidado, aguardando informação ou em acompanhamento
- Verificar se há outros arquivos, guias ou cadastros afetados pela mesma causa
- Atualizar checklist, instrução, parâmetro ou treinamento quando a causa for recorrente
- Definir dono e data para acompanhar a ação preventiva
- Revisar periodicamente os motivos mais frequentes sem atribuir causa apenas pela repetição do código
Ao perceber repetição, não conclua automaticamente que todos os casos têm a mesma causa. Agrupe ocorrências semelhantes, compare as fontes de origem, verifique mudanças recentes no processo e procure um padrão verificável. Uma ocorrência isolada pode exigir apenas tratamento pontual; uma causa que reaparece em várias guias, unidades ou períodos merece ação preventiva com responsável e data de revisão. Para conectar esse acompanhamento a uma rotina mais ampla de análise e prevenção, veja o conteúdo sobre
Exemplo ilustrativo de tratamento de uma rejeição
O cenário abaixo é ilustrativo e não representa uma mensagem oficial, uma regra universal de operadora ou uma confirmação de processamento. Ele mostra como registrar o raciocínio sem transformar uma crítica em diagnóstico automático.
Caso ilustrativo: dado divergente entre cadastro e guia
| Etapa | Registro ilustrativo |
|---|---|
| Entrada | O controle recebe uma crítica referente a um identificador do beneficiário e vincula a mensagem ao XML, à guia e ao lote. |
| Investigação | A equipe compara o identificador exibido na guia com a fonte cadastral definida pela organização e percebe divergência entre os dois registros. |
| Mapeamento | A análise mostra que o XML reproduziu o valor presente na guia; portanto, o ponto imediato de correção não é a tag do XML, mas o lançamento que alimentou a guia. |
| Erro a evitar | Editar diretamente o XML para trocar o identificador, mantendo a guia e a fonte interna com o valor divergente. |
| Correção | O responsável confirma o dado na fonte apropriada, atualiza a guia conforme a evidência e registra quem realizou a alteração. |
| Nova geração | A equipe gera uma revisão do XML, associa-a ao arquivo original e confere se o identificador corrigido foi incorporado. |
| Nova validação | A revisão é validada, o resultado é registrado e o caso permanece em acompanhamento caso exista etapa posterior no fluxo da operadora. |
Pontos principais
- Registre a mensagem completa, o arquivo original e o contexto antes de qualquer alteração
- Use a rejeição como sinal de investigação, não como diagnóstico definitivo
- Corrija a fonte confirmada do problema antes de gerar outro XML
- Mantenha vínculo entre o XML original, a revisão corrigida e o resultado da nova validação
- Diferencie validação técnica interna de aceite ou processamento pela operadora
- Transforme causas recorrentes em ações preventivas com responsável, prazo e revisão
Perguntas frequentes
Revise o XML corrigido antes de avançar
Depois de corrigir a origem e gerar uma nova revisão, use o Validador TISS online para conferir o XML antes de prosseguir no fluxo aplicável à operadora.
Fontes e referências
Padrão TISS – Janeiro/2025 — Agência Nacional de Saúde Suplementar