Comparar versões de XML TISS depois de uma correção permite confirmar o que foi alterado, manter a evidência do problema inicial e decidir se o arquivo corrigido está pronto para uma nova validação.
Uma correção só é realmente compreendida quando a equipe consegue responder quatro perguntas: qual arquivo apresentava a ocorrência, que dado ou regra foi investigado, o que mudou na nova revisão e se a mudança responde à causa analisada. Comparar versões de XML TISS é o procedimento que conecta essas perguntas. Em vez de abrir o arquivo corrigido isoladamente e procurar visualmente uma tag, ele coloca lado a lado o XML original, a cópia usada no trabalho e o XML gerado após o ajuste. O resultado é um histórico objetivo para faturistas, cadastro, tecnologia e responsáveis pela conferência.
Neste artigo
Diferencie arquivo original, cópia de trabalho e versão corrigida
As três expressões não são sinônimos. O arquivo original é a evidência do estado que gerou a mensagem, a rejeição ou a divergência interna; por isso, não deve ser sobrescrito. A cópia de trabalho é a revisão manipulada durante a investigação, que pode receber testes, anotações e tentativas descartadas. A versão corrigida é o novo XML produzido depois de uma alteração deliberada na fonte, no cadastro, no mapeamento ou na configuração aplicável. Dar nomes distintos a esses artefatos evita comparar o arquivo errado ou concluir que um ajuste foi feito apenas porque existe uma cópia mais recente.
Papel de cada arquivo no controle da ocorrência
| Artefato | Como identificar | O que preservar | O que não fazer |
|---|---|---|---|
| Original | Identificador do lote ou guia, data de geração e revisão inicial | Conteúdo integral, mensagem recebida, data e contexto | Editar ou substituir pelo XML corrigido |
| Cópia de trabalho | Sufixo de rascunho ou identificação interna | Hipóteses, testes e responsável pela análise | Tratá-la como prova final da correção |
| Corrigido | Nova data ou revisão vinculada à ocorrência | Alteração aprovada, resultado da comparação e validação posterior | Assumir que é aceito sem nova conferência |
Preserve o contexto que iniciou a correção
A comparação fica frágil quando começa somente pelo conteúdo do XML. Antes de analisar diferenças, abra um registro da ocorrência com a mensagem completa, o identificador do arquivo, o lote ou guia relacionado, a data da análise, a referência de versão usada na geração e a pessoa ou área responsável. Se a ferramenta indicar tag, linha, caminho ou grupo, registre a indicação literalmente. Em outro campo, escreva a interpretação da equipe. Separar retorno original e hipótese interna impede que uma conclusão provisória substitua a evidência que precisa ser revisada depois.
Contexto mínimo para vincular aos dois arquivos
- Identificador interno da ocorrência e do XML original
- Mensagem ou crítica recebida, copiada sem resumir
- Operadora, competência, tipo de guia e lote quando forem pertinentes
- Referência técnica, parâmetro ou versão configurada no momento da geração
- Campo, grupo ou trecho apontado pela ferramenta, quando informado
- Fonte do dado consultada durante a investigação
- Responsável pela alteração e responsável pela revisão
- Decisão atual: corrigir, investigar, aguardar confirmação ou revalidar
Faça a comparação orientada à causa e ao resultado
A ordem de leitura importa. Comece pela ocorrência que motivou o ajuste, localize o grupo correspondente nos dois XMLs e confirme se a alteração esperada apareceu. Depois amplie a busca para elementos diretamente relacionados, como identificadores, datas, quantidades, códigos, valores, repetições e totalizadores. Só então examine mudanças fora do escopo. Essa sequência reduz o risco de celebrar uma diferença visual enquanto a relação entre os dados permanece incorreta, ou de ignorar uma alteração colateral gerada pelo mesmo processo.
Matriz prática de comparação
| Nível de análise | Pergunta de controle | Registro da diferença | Encaminhamento sugerido |
|---|---|---|---|
| Arquivo | Os dois arquivos representam o mesmo caso, guia ou lote? | Identificadores, data de geração e revisão | Interromper se os arquivos não forem comparáveis |
| Cabeçalho e referência | Mudou versão, namespace, prestador, lote ou outra referência estrutural? | Valor anterior, valor novo e motivo informado | Confirmar se a mudança era parte do escopo |
| Grupo afetado | A tag, grupo ou item citado na ocorrência foi alterado como previsto? | Caminho do XML, antes, depois e evidência de origem | Relacionar à causa investigada |
| Dados relacionados | Outros campos dependentes permaneceram coerentes? | Campos comparados e resultado da conferência | Revisar mapeamento ou dados de origem se houver divergência |
| Itens repetidos e totais | Houve inclusão, exclusão, duplicação ou alteração não prevista? | Quantidade de ocorrências e totais antes e depois | Investigar antes de liberar a nova revisão |
| Fora do escopo | Que diferença não era esperada? | Descrição literal, impacto ainda desconhecido e responsável | Abrir pendência separada ou devolver para análise |
Não confunda a revisão interna de um arquivo com a versão do padrão aplicável. A ANS organiza o padrão TISS em componentes distintos, incluindo conteúdo e estrutura e comunicação; o componente de comunicação adota XML para as mensagens eletrônicas. A própria ANS também publica referências de vigência e histórico dos componentes. (Padrão TISS – Histórico das versões dos Componentes do Padrão TISS — Agência Nacional de Saúde Suplementar) Quando a ocorrência envolver layout, namespace, esquema ou parâmetro de versão, registre qual referência foi consultada e o período considerado, em vez de inferir a resposta pela data do arquivo ou pelo nome de uma pasta. (Padrão TISS – Julho/2026 — Agência Nacional de Saúde Suplementar) (Padrão TISS – Histórico das versões dos Componentes do Padrão TISS — Agência Nacional de Saúde Suplementar)
Classifique mudanças esperadas, inesperadas e não explicadas
Uma diferença não é automaticamente um erro, assim como a ausência de uma diferença não prova que a causa foi resolvida. Marque como esperada a alteração vinculada a uma decisão documentada; como inesperada a mudança que não fazia parte do escopo; e como não explicada a diferença que ainda não possui origem confirmada. Para cada registro, mantenha o caminho ou grupo analisado, o valor antes e depois, a justificativa, a evidência consultada, o responsável e a situação. Evite apagar diferenças inesperadas para “limpar” a comparação: elas podem indicar efeito colateral, seleção de arquivo errada ou uma condição ainda não compreendida.
Quando uma mudança depende de teste interno, defina antes qual cenário ela precisa preservar e qual resultado seria suficiente para continuar a investigação. Os casos de teste XML TISS ajudam a documentar cenário, dados controlados, resultado esperado e evidência, sem transformar um teste local em confirmação de aceite por uma operadora.
Exemplo ilustrativo de comparação controlada
Exemplo ilustrativo: correção de campo e detecção de efeito colateral
Entrada: uma equipe recebe uma crítica interna que aponta a ausência de um dado em um item de guia. Ela preserva o XML original e registra o trecho apontado, o identificador do item e a fonte que deverá confirmar o dado. Mapeamento: a análise mostra que o campo no XML é preenchido por um cadastro mantido fora do gerador; a alteração deve ocorrer nessa origem, seguida de nova geração do arquivo. Erro: ao comparar o XML corrigido com o original, o campo esperado aparece preenchido, mas a quantidade de itens repetidos no mesmo grupo passou de dois para três. Correção: a equipe não encerra o caso pela primeira mudança; abre uma diferença inesperada, verifica o mapeamento da repetição, corrige a origem aplicável, gera outra revisão e repete a comparação. Este cenário é fictício e ilustra um método de análise, não uma regra universal nem uma execução de validação.
Use a comparação para orientar a nova validação
A comparação responde “o que mudou?”; a nova validação responde “qual resultado o arquivo corrigido apresenta sob os critérios usados?”. Uma etapa não substitui a outra. Se a diferença esperada não apareceu, retorne à fonte do dado ou ao processo de geração. Se apareceram diferenças inesperadas, investigue-as antes de considerar o caso encerrado. Se a comparação estiver coerente, associe ao registro o resultado da nova validação, a referência utilizada e a decisão interna. O resultado técnico deve ser tratado como evidência do arquivo e do critério conferido, não como promessa de processamento ou aceite posterior.
Após concluir a comparação, siga uma rotina para validar XML TISS que mantenha a identificação do arquivo, os apontamentos encontrados e o registro da nova conferência. Esse vínculo ajuda a equipe a não separar a correção técnica da revisão que a sucede.
Checklist final antes de encerrar a ocorrência
- Preservei o XML original e a mensagem que iniciou a investigação
- Identifiquei claramente a cópia de trabalho e a versão corrigida
- Comparei arquivos referentes ao mesmo caso, guia ou lote
- Registrei a alteração esperada com valor anterior, valor novo e justificativa
- Conferi campos, grupos e totais relacionados à alteração
- Classifiquei diferenças inesperadas sem apagá-las
- Vinculei a correção à fonte do dado, ao mapeamento ou à configuração investigada
- Registrei a referência consultada quando a ocorrência envolveu versão ou estrutura
- Realizei uma nova validação e associei o resultado ao mesmo registro
- Mantive a decisão interna distinta de qualquer expectativa de aceite posterior
Perguntas frequentes sobre comparação de XML TISS
Próximo passo: nova conferência do XML
Depois de revisar as alterações entre o original e a versão corrigida, faça uma nova conferência no Validador TISS online. Para conhecer os recursos e o apoio oferecidos, acesse o TISSXML.