Conferir a versão do padrão TISS antes de gerar o XML evita que a equipe compare o arquivo com uma referência inadequada. Este guia mostra como distinguir a referência oficial, as regras da operadora e a configuração do sistema para organizar uma rotina de controle de versão no faturamento.
A versão do padrão TISS é uma referência de trabalho para quem gera, revisa e valida arquivos no faturamento em saúde suplementar. Ela orienta a equipe sobre quais materiais técnicos devem ser consultados para a competência e o fluxo analisados. O ponto central não é decorar números de versão: é conseguir provar qual referência foi adotada, por que ela se aplica àquele lote e onde a decisão foi registrada. A ANS descreve o TISS como padrão obrigatório para trocas eletrônicas de dados de atenção à saúde entre os agentes da saúde suplementar e disponibiliza uma página com a versão publicada e o histórico dos componentes. (TISS – Padrão para Troca de Informação de Saúde Suplementar — 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)
Neste artigo
Por que conferir a versão antes de gerar o XML
Um XML pode estar bem formado e, mesmo assim, ter sido produzido com parâmetros que não correspondem à referência técnica aplicável ao caso. Por isso, a conferência de versão deve acontecer antes da geração do lote, e não somente depois de uma mensagem de erro. A RN nº 501 estabelece que a troca dos dados do padrão TISS deve ser eletrônica e realizada na versão vigente. (Minist�rio da Sa�de) A mesma norma informa que o padrão é organizado em componentes, entre eles o organizacional, o de conteúdo e estrutura, o de representação de conceitos em saúde, o de segurança e privacidade e o de comunicação. (Minist�rio da Sa�de) (Minist�rio da Sa�de)
O que a rotina de versão ajuda a evitar
- Comparar o XML com um schema ou manual de outra competência
- Corrigir tags no arquivo sem revisar a configuração que as gerou
- Tratar uma exigência operacional da operadora como se fosse alteração do padrão nacional
- Reutilizar um lote-modelo antigo sem confirmar sua adequação
- Perder o contexto da decisão quando o caso precisa ser investigado depois
Separe padrão TISS, regra da operadora e configuração do sistema
A conferência fica mais objetiva quando a equipe deixa de usar a palavra “versão” para tudo. Há uma referência pública do padrão, documentos técnicos associados a seus componentes, orientações operacionais recebidas da operadora e parâmetros internos do sistema gerador. Essas camadas se relacionam, mas não são intercambiáveis. A ANS mantém histórico que apresenta, por competência, publicação, início de vigência, limite de implantação e versões dos componentes. (Padrão TISS – Histórico das versões dos Componentes do Padrão TISS — Agência Nacional de Saúde Suplementar) Assim, a equipe deve conferir o componente pertinente em vez de supor que todo material muda ao mesmo tempo. (Padrão TISS – Histórico das versões dos Componentes do Padrão TISS — Agência Nacional de Saúde Suplementar)
Mapa de referências para a conferência
| Camada | Pergunta de controle | Evidência a registrar | Ação quando houver divergência |
|---|---|---|---|
| Padrão e componente aplicável | Qual competência, vigência e componente devem orientar o arquivo? | Página oficial, data de consulta e identificação do material | Confirmar a referência antes de mudar o XML |
| Regra operacional da operadora | Há manual, portal, prazo, canal ou instrução complementar para o relacionamento? | Documento, comunicado ou protocolo interno | Separar a regra local da regra estrutural |
| Sistema ou integração | Qual parâmetro, modelo ou rotina efetivamente gerou o lote? | Nome do ambiente, configuração e responsável técnico | Ajustar na origem e gerar novo arquivo |
| Dados da guia | Os dados retratam o atendimento e os documentos de origem? | Guia, cadastro, autorização quando aplicável e registro interno | Corrigir o lançamento ou cadastro antes de nova geração |
Onde verificar os materiais oficiais
Comece pela área do padrão TISS no portal da ANS e pelo histórico de versões dos componentes. A página principal publicada pela Agência direciona para a versão do padrão, para o histórico e para as tabelas relacionadas. (TISS – Padrão para Troca de Informação de Saúde Suplementar — Agência Nacional de Saúde Suplementar) O histórico é especialmente útil porque evita uma leitura isolada de um arquivo baixado em outra data: ele permite confrontar competência, início de vigência e limite de implantação. Ao localizar um pacote técnico, confira se seu nome, data e conteúdo correspondem à referência que a equipe registrou; a ANS também disponibiliza arquivos de componente de conteúdo e estrutura em seu portal. (TISS – Padrão para Troca de Informação de Saúde Suplementar — 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) (PadroTISS_ComponentedeContedoeEstrutura_202511.zip — Agência Nacional de Saúde Suplementar)
Sequência segura de consulta
Faça a conferência nesta ordem para reduzir interpretações apressadas.
- Defina a competência do lote e a data em que a geração será realizada
- Abra a página oficial do padrão e o histórico de versões dos componentes
- Identifique o componente e o material técnico relevantes para o tipo de mensagem
- Registre publicação, vigência e limite de implantação mostrados no histórico
- Consulte a documentação operacional da operadora para o fluxo específico
- Compare a decisão com a configuração efetiva do sistema antes de liberar o lote
Registre a decisão de versão no controle do faturamento
Um controle simples resolve boa parte da perda de contexto entre faturamento, cadastro e tecnologia. Ele não precisa reproduzir os documentos técnicos; deve mostrar a decisão e permitir que outra pessoa a reconstrua. Crie uma linha de controle por operadora, competência e tipo de mensagem ou lote. Se uma alteração atingir apenas parte da operação, registre o escopo com clareza, em vez de marcar o ambiente inteiro como “atualizado”. Para contextualizar a rotina de ponta a ponta, consulte também o material sobre
Campos mínimos do registro
- Competência, operadora, unidade e tipo de mensagem ou lote
- Referência oficial consultada e data da consulta
- Componente, publicação, início de vigência e limite de implantação identificados
- Regra operacional adicional da operadora, quando houver
- Sistema, ambiente, rotina ou integração que gera o XML
- Responsável pela análise, responsável pela alteração e responsável pela aprovação
- Resultado do teste interno, pendências conhecidas e data da próxima revisão
Checklist único antes de gerar e validar lotes
A validação é uma etapa de conferência, não uma autorização automática para qualquer regra comercial ou operacional. Um resultado técnico deve ser lido junto com a origem dos dados e com o processo da operadora. Depois de qualquer ajuste relevante, gere um novo XML a partir da fonte corrigida e mantenha o vínculo entre o arquivo, a referência usada e o resultado da revisão. Um roteiro complementar para
Conferência pré-geração e pré-validação
- Confirmar a competência do lote e a referência oficial registrada
- Confirmar que a regra operacional da operadora foi consultada para aquele fluxo
- Verificar se sistema, ambiente e rotina de geração usam os parâmetros aprovados
- Revisar dados de origem da guia, do beneficiário, do prestador, do atendimento e dos itens
- Gerar o arquivo em ambiente e momento identificáveis
- Validar o XML contra a referência adotada e guardar a mensagem completa em caso de apontamento
- Classificar o problema como dado de origem, estrutura, parâmetro, regra operacional ou dúvida de interpretação
- Corrigir a causa na origem sempre que possível, gerar novo arquivo e repetir a conferência
- Registrar a decisão final e qualquer exceção aprovada no controle interno
Como tratar uma mudança de versão sem interromper a operação
Uma atualização deve ser tratada como mudança controlada, não como simples troca de arquivo. Primeiro, identifique o que mudou no material aplicável e quais mensagens, cadastros, tabelas, integrações ou rotinas internas podem ser afetados. Depois, defina responsáveis para análise, parametrização, teste e liberação. O histórico da ANS distingue publicação, início de vigência e limite de implantação; portanto, a equipe deve usar esses marcos para planejar a transição e não confundir a data em que o documento foi publicado com o momento em que ele passa a orientar a operação. (Padrão TISS – Histórico das versões dos Componentes do Padrão TISS — Agência Nacional de Saúde Suplementar)
Plano prático de transição
- Abrir uma solicitação interna com escopo, referência consultada e data-alvo
- Mapear mensagens e tipos de guia potencialmente afetados
- Comparar a configuração atual com a configuração desejada sem substituir parâmetros sem registro
- Separar testes de estrutura XML de testes de dados e de fluxo operacional
- Revisar exemplos de cenários representativos antes de liberar novos lotes
- Comunicar à equipe o que muda, quando muda, quem aprova e onde registrar dúvidas
- Manter um plano de contingência interno para interrupções ou resultados inesperados
- Revisar os primeiros lotes gerados após a mudança e documentar os achados
Exemplo ilustrativo de conferência e correção
Exemplo ilustrativo: uma clínica prepara um lote para determinada competência. O faturista recebe uma crítica estrutural após a validação e encontra um material técnico salvo em uma pasta compartilhada. Em vez de editar a tag apontada de imediato, a equipe refaz a trilha de decisão.
Do apontamento à correção
| Etapa | Decisão no exemplo |
|---|---|
| Entrada | Competência do lote, operadora, tipo de mensagem, arquivo gerado, mensagem completa e data da geração são registrados. |
| Mapeamento | A equipe consulta a página oficial e o histórico, identifica a referência aplicável e compara essa decisão com o parâmetro do sistema. |
| Erro | O material salvo internamente pertence a outra referência ou o sistema permaneceu com configuração anterior. |
| Correção | O responsável ajusta o parâmetro ou o processo de geração aprovado, revisa os dados envolvidos, gera um novo XML e repete a validação. |
| Evidência final | O controle recebe a referência consultada, o responsável, a alteração realizada, o arquivo revisado e o resultado da nova conferência. |
Transforme a conferência em uma rotina de acompanhamento
A melhor rotina é a que cabe no calendário do faturamento. Defina uma pessoa ou função responsável por monitorar publicações oficiais e comunicações relevantes, mas não concentre todo o conhecimento nela. O registro de versão deve ficar acessível às pessoas que geram, conferem, corrigem e aprovam lotes. Em reuniões curtas, revise alterações pendentes, decisões em aberto, lotes em transição e apontamentos repetidos. Para nivelar conceitos básicos com novas pessoas da equipe, pode ser útil consultar o artigo
Pontos essenciais
- Conferir a versão do padrão TISS é confirmar a referência aplicável ao lote, não apenas localizar um número de versão
- Use o histórico da ANS para verificar competência, publicação, vigência e limite de implantação dos componentes
- Separe o que é referência do padrão, regra operacional da operadora, parâmetro do sistema e dado de origem
- Registre a decisão antes da geração e mantenha a evidência junto ao processo de faturamento
- Após uma mudança relevante, teste, gere novo XML e valide novamente antes de seguir o fluxo operacional
Perguntas frequentes sobre versão do padrão TISS
Valide depois de confirmar a referência
Depois de confirmar a versão aplicável, revisar a configuração e gerar um novo arquivo, use o Validador TISS online para conferir o XML e investigar inconsistências antes de seguir com o processo operacional.
Fontes e referências
TISS – Padrão para Troca de Informação de Saúde Suplementar — Agência Nacional de Saúde Suplementar