Como converter XML para a versão TISS 4.03.00 (tutorial)

Este é um tutorial de execução: sair de um XML em 4.02.00 (ou 4.01.00, 3.05.00, 2.02.03) e chegar a um lote aceito na versão TISS 4.03.00, com hash MD5 correto, somatórios fechados e campos condicionais preenchidos. São 7 passos, na ordem em que evitam retrabalho. Se quiser executar junto, abra o conversor TISS em outra aba e tenha um lote de teste à mão. Entenda antes o contexto em o que é a versão TISS 4.03.00.

Antes de começar: o que você precisa em mãos?

Conversão de versão falha quase sempre por falta de insumo, não por dificuldade técnica. Reúna estes quatro itens:

Um lote XML real, ainda não enviado, na versão atual do seu sistema.
A versão de destino confirmada com a operadora (hoje: versão TISS 4.03.00).
Acesso ao gerador do seu XML (sistema de gestão ou ERP), para corrigir a origem depois.
Um validador que use os XSDs oficiais da ANS — o validador TISS online serve.

Passo 1 — Como descobrir a versão atual do arquivo?

Abra o XML em um editor de texto (VS Code, Notepad++) e localize versaoPadrao no cabeçalho. O valor ali é a sua versão de origem. Se a tag estiver ausente ou com prefixo diferente (ans:versaoPadrao, tiss:versaoPadrao), o namespace do arquivo está mal declarado — corrija isso antes de converter.

Atalho: subindo o arquivo no validador, a versão é detectada automaticamente, inclusive em arquivos com prefixo de namespace incomum.

Passo 2 — Como validar o arquivo na versão de origem?

Valide antes de converter. Erro que já existia na origem reaparece na 4.03.00 e você perde tempo achando que a conversão o criou. Objetivo deste passo: chegar a zero erro estrutural na versão atual.

Erros comuns nesta etapa: hash MD5 desatualizado, somatório da guia diferente da soma dos procedimentos e código TUSS fora de vigência.

Passo 3 — Como executar a conversão para a versão TISS 4.03.00?

No conversor TISS: envie o arquivo, confirme a versão de origem detectada, selecione 4.03.00 como destino e execute. O conversor percorre a sequência oficial de versões (2.02.03 → 3.02.x → 3.03.x → 3.04.x → 3.05.00 → 4.00.00 → 4.00.01 → 4.01.00 → 4.02.00 → 4.03.00) aplicando as mudanças de cada degrau, em vez de um salto direto.

Por que isso importa: entre 3.x e 4.x há renomeação de tags e campos que só existem em uma das famílias. Salto direto costuma produzir arquivo bem formado, mas inválido no XSD.

Passo 4 — O que fazer com os campos que a 4.03.00 passou a exigir?

Nenhuma ferramenta honesta inventa dado clínico. Quando a versão de destino exige um campo que a origem não tinha, ele precisa ser informado — por exemplo caráter de atendimento em dados de internação, ou identificação complementar do profissional executante.

No fluxo do TISS Manager, esses campos aparecem em um formulário de campos faltando após a conversão: você preenche uma vez e o valor é aplicado às guias correspondentes.

Campo obrigatório novo → preencher no formulário de campos faltando.
Campo opcional novo (ex.: observação, centro de consumo) → só preencher se a operadora pedir.
Campo que não existe no destino → é removido na conversão, sem perda de valor financeiro.

Passo 5 — Como garantir que o hash MD5 e os somatórios continuam válidos?

Toda alteração no corpo do XML invalida o hash MD5 do epílogo. Depois de converter e preencher campos, o hash tem de ser recalculado sobre o conteúdo final, considerando a codificação correta (ISO-8859-1) e as entidades XML decodificadas — é aí que a maioria das implementações caseiras erra.

Os somatórios seguem a mesma lógica: valor total da guia = soma dos procedimentos, materiais, medicamentos, taxas e OPME; total do lote = soma das guias. Divergência de centavos é rejeição.

Sintoma	Causa provável	Correção
Hash inválido	edição manual após gerar o epílogo	recalcular o hash no arquivo final
Somatório divergente	arredondamento por item	somar com 2 decimais só no total
Código recusado	TUSS fora de vigência	substituir pelo código vigente
Erro de tipo	enum alterado entre versões	revalidar contra o XSD 4.03.00

Passo 6 — Como validar o resultado contra o XSD oficial 4.03.00?

Rode o arquivo convertido no validador TISS online. A meta é zero erro estrutural e zero divergência de somatório. Só depois disso vale enviar para a operadora — reenvio rejeitado consome mais tempo do que um ciclo extra de validação.

Se o seu volume é alto, vale também rodar as verificações de risco de glosa: elas apontam motivos administrativos (sexo/idade incompatível com procedimento, quantidade implausível, CBO incompatível, autorização ausente) que passam pelo XSD e reprovam na análise da operadora.

Passo 7 — Como evitar precisar converter de novo no mês que vem?

Conversão é remédio, não rotina. Depois do primeiro lote aceito em 4.03.00, ajuste a origem: atualize o gerador do seu sistema para emitir versaoPadrao 4.03.00 e as tabelas de domínio vigentes.

Peça ao fornecedor do sistema a versão do módulo TISS compatível com 4.03.00.
Documente para a equipe qual versão é a oficial e quem valida antes do envio.
Valide um lote-amostra por operadora no primeiro mês.
Mantenha o conversor apenas para exceções (recursos de competências antigas).

Vídeo: conversão de versão TISS na prática

Perguntas frequentes

Como converter um XML de 4.02.00 para a versão TISS 4.03.00?

Valide o arquivo na versão atual, envie ao conversor TISS indicando 4.03.00 como destino, preencha os campos que a nova versão exige, deixe o hash MD5 ser recalculado e valide o resultado contra o XSD oficial 4.03.00 antes de enviar à operadora.

Dá para converter de 3.05.00 direto para 4.03.00?

Sim, mas a conversão deve percorrer os degraus intermediários da sequência oficial. Entre as famílias 3.x e 4.x há tags renomeadas e campos exclusivos de cada família; salto direto normalmente gera arquivo inválido no XSD.

A conversão altera valores financeiros do lote?

Não. Procedimentos, quantidades e valores são preservados. O que muda são nomes de tags, campos estruturais e o hash MD5 recalculado sobre o conteúdo final.

Por que meu arquivo convertido acusa hash MD5 inválido?

Porque o hash foi calculado antes da última edição, ou com codificação/entidades tratadas de forma diferente da regra da ANS. Recalcule sobre o arquivo final em ISO-8859-1, com as entidades XML decodificadas.

Preciso converter lotes já enviados e pagos?

Não. Converta apenas o que ainda vai ser enviado e os recursos de glosa que a operadora exigir na versão vigente.

Quanto tempo leva converter um lote?

A conversão em si é de segundos. O tempo real fica no preenchimento dos campos novos na primeira vez — depois disso, lotes seguintes do mesmo perfil saem sem intervenção.

Conclusão

Convertendo na ordem certa — validar origem, converter degrau por degrau, preencher campos novos, recalcular hash, validar contra o XSD 4.03.00 — a migração deixa de ser evento e vira operação de rotina. Comece pelo conversor TISS, confirme no validador e, no mesmo mês, ajuste a origem para já emitir na versão TISS 4.03.00.

Tutorial: como converter seu XML para a versão TISS 4.03.00 em 7 passos