O Padrão TISS 4.03.00 é uma versão do componente de Comunicação usado nas trocas entre prestadores e planos de saúde. Para validar um XML, confira se ele segue o XSD da versão indicada, se o hash do epílogo confere e se os dados passam pelas regras aplicáveis. A versão precisa ser conferida na ANS e no contrato.

O que é o Padrão TISS?

Acesso remoto: a API e o MCP exigem uma chave da organização para operações fora do sandbox. Crie a chave no painel da organização, com os escopos necessários, e siga a documentação de autenticação. A biblioteca Python continua disponível para processamento local.

Consultar acesso e autenticação no README do tiss.

O Padrão TISS organiza a troca eletrônica de informações na saúde suplementar. Ele define formatos, terminologias, processos e regras operacionais para mensagens que circulam entre prestadores de serviços de saúde e planos de saúde, além de outras trocas previstas pela ANS.

TISS não é apenas um arquivo XML. A ANS descreve o padrão por componentes, cada qual com versão própria: Organizacional, Conteúdo e Estrutura, Representação de Conceitos em Saúde, Segurança e Privacidade e Comunicação. Um conjunto coerente de mensagens pode depender de versões distintas desses componentes. Por isso, dizer apenas “uso o TISS 4.03” pode não identificar todas as regras relevantes à troca.

O número 4.03.00 identifica uma versão do componente de Comunicação. Os arquivos XSD desse componente descrevem elementos permitidos, tipos de dados, ordem e estrutura das mensagens. Eles não substituem as demais partes do padrão, tabelas da TUSS, contratos nem regras de autorização.

O melhor ponto de partida é registrar qual versão aparece no XML e qual versão a rede de destino aceita. Não presuma que um arquivo válido em um XSD será recebido por todo canal ou plano. A versão pode ser reconhecida tecnicamente e ainda assim não estar implantada no sistema que receberá o lote.

Como as versões dos componentes funcionam?

A ANS publica atualizações por competência. Na página oficial de histórico, cada linha informa publicação, início de vigência, limite de implantação e versões dos componentes. A linha de setembro de 2026, por exemplo, registra início de vigência em 1º de outubro de 2026 e limite de implantação em 31 de dezembro de 2026. Nessa linha, o componente de Comunicação inclui as versões 04.03.00 e 01.06.00.

Essa tabela é mais útil do que olhar apenas o rótulo “TISS 4.03.00”. Uma linha pode combinar o componente de Comunicação com versões de Conteúdo e Estrutura, TUSS, Segurança e Privacidade e Organizacional de competências diferentes. A página de histórico mostra essa combinação. O componente organizacional correspondente detalha as mudanças e as regras operacionais da competência.

Há três datas que não devem ser confundidas:

1. Publicação: quando a ANS disponibilizou uma versão.

2. Início de vigência: quando a versão passou a valer segundo o histórico oficial.

3. Limite de implantação: a data-limite indicada para sua adoção.

O prazo de implantação não informa, por si só, qual versão um plano de saúde aceita hoje em cada integração. Confirme a versão ativa no canal de troca, no manual de integração e no contrato. Se houver divergência entre uma página explicativa antiga e o histórico atualizado, use a informação vigente publicada pela ANS e confirme com a rede de destino.

O que mudou entre 4.02.00 e 4.03.00?

Uma alteração concreta pode ser confirmada no histórico de mudanças do Componente Organizacional da ANS de julho de 2026. Ele descreve inclusões no componente de Comunicação para os schemas 4.03.00. Entre elas:

Essa lista é um recorte de alterações descritas pela própria ANS; não é um changelog exaustivo de tudo o que mudou entre duas pastas de XSD. Por exemplo, a presença de um elemento em um schema não significa que ele seja obrigatório em toda mensagem: a regra depende do tipo complexo, da sequência, da ocorrência e do contexto definidos pelo XSD.

O campo de Centro de Consumo ilustra por que vale ler o componente, e não apenas trocar o número da versão. A ANS descreve esse campo em tipos e mensagens determinados, incluindo informações de conta, itens e recurso de glosa. Uma integração deve mapear a estrutura exata que usa, validar o XML e testar a compatibilidade com o canal de destino.

A mesma publicação registra códigos novos da Tabela 38 no tipo simples de glosa. Isso não quer dizer que toda glosa mudou de significado ou que os códigos são intercambiáveis. A descrição de cada código deve ser consultada na Tabela 38 da competência aplicável. Um código de glosa é uma referência padronizada; não substitui a justificativa individual nem o contrato.

O pacote aberto tiss inclui schemas identificados como 4.02.00 e 4.03.00. O próprio manifesto de proveniência aponta a origem dos arquivos 4.03.00 para o pacote de Comunicação da ANS e registra hashes para verificar a integridade local. O software não transforma uma versão em outra. Ele seleciona o schema para validar a versão detectada ou indicada.

Quando a versão 4.03.00 entrou em vigor?

Consulte a competência da ANS, não um calendário replicado em terceiros. No histórico consultado para esta pauta, a linha de setembro de 2026 indica publicação em 30 de setembro de 2026, início de vigência em 1º de outubro de 2026 e limite de implantação em 31 de dezembro de 2026. A linha também lista 04.03.00 entre as versões do componente de Comunicação.

O histórico é atualizado. A competência mais nova pode alterar datas ou versões sem que seja preciso lançar um novo número do componente de Comunicação. Por isso, uma busca por “TISS 2026” pode retornar informações de diferentes competências do mesmo ano. Antes de programar uma migração, abra a linha atual da tabela e registre a data de consulta.

Há uma diferença entre vigência do padrão publicado pela ANS e disponibilidade de integração. Um sistema pode implementar uma versão antes da data-limite; outro pode precisar de período de homologação. A documentação técnica do receptor e a comunicação com a equipe de integração continuam necessárias. A validação local responde “o XML é compatível com este XSD?”, não “o destino está pronto para recebê-lo?”.

Se um prazo do contrato, da operação ou do canal exigir uma versão específica, documente essa condição separadamente. Um calendário de migração deve informar qual componente muda, qual versão de destino será usada e como os testes de compatibilidade serão feitos. Evite atualizar todo o fluxo apenas porque o número da versão mudou.

O que um validador consegue confirmar?

Uma validação útil separa camadas que respondem a perguntas diferentes:

1. Estrutura e tipos: o XML contém elementos, sequências e valores compatíveis com o XSD selecionado?

2. Integridade do epílogo: o digest armazenado no XML corresponde ao conteúdo calculado?

3. Regras de negócio: os dados atendem às verificações implementadas, incluindo as regras disponíveis para o plano de saúde?

4. Compatibilidade operacional: o canal de destino aceita a versão, o cadastro e a forma de envio?

O XSD pode apontar um elemento obrigatório ausente, um campo fora de ordem, um valor fora do tipo ou um código que não pertence ao domínio declarado. Ele não conhece todas as condições de cada contrato. Um XML estruturalmente válido pode conter uma autorização vencida, uma cobrança incompatível ou uma divergência que dependa de revisão.

O hash detecta que o conteúdo coberto pelo cálculo não corresponde ao digest informado. Ele não autentica a identidade de quem criou o XML, não substitui assinatura digital e não verifica se o procedimento foi autorizado. Depois de corrigir qualquer campo coberto pelo digest, recalcule o hash como etapa final.

Regras por plano de saúde dependem de um pacote de regras identificado no validador. Uma regra pode verificar autorização exigida ou uma condição de cobrança, mas só representa o que está documentado naquele pacote. Se o pacote estiver ausente, desatualizado ou for apenas demonstrativo, o resultado não é uma decisão oficial do plano.

Glosa é um resultado de auditoria ou de processamento da cobrança, enquanto erro de XSD é uma incompatibilidade estrutural. Eles podem se relacionar: o catálogo atribui o código 5014 a hash inválido, mas um achado interno como lote.hash_divergente é o identificador técnico usado pelo pacote. Não trate esses nomes como sinônimos nem presuma que o validador aplicará uma glosa.

Como validar um XML TISS 4.03.00?

No navegador: abra o playground do tiss, escolha um exemplo sintético ou carregue um XML de teste e solicite a validação. A página retorna a versão detectada e os achados que o serviço implementa. O navegador envia o arquivo à API remota; não use dados reais sem avaliar o fluxo e as regras de privacidade da sua organização.

Localmente com Python: o pacote é instalado com pip install tiss. A biblioteca trabalha no processo local e oferece funções para validar, interpretar lotes, consultar códigos, calcular o hash e aplicar correções previstas. Um exemplo mínimo, usando arquivo sintético que acompanha o pacote:

from tiss import examples, validate

xml = examples.load("lote-valido")
report = validate(xml)
print(report.version, report.valid, len(report.findings))

from tiss import examples, validate

xml = examples.load("lote-valido")
report = validate(xml)
print(report.version, report.valid, len(report.findings))

from tiss import examples, validate

xml = examples.load("lote-valido")
report = validate(xml)
print(report.version, report.valid, len(report.findings))

from tiss import examples, validate

xml = examples.load("lote-valido")
report = validate(xml)
print(report.version, report.valid, len(report.findings))

Saída executada no snapshot do projeto:

Esse resultado significa que aquele exemplo passou pelas verificações executadas com o schema selecionado. Não comprova elegibilidade do beneficiário, autorização, cobertura, valor contratual nem aceitação por uma operadora.

Via integração: a API e as ferramentas MCP expõem operações para validar XML, consultar glosas e conferir autorizações. Para ligar um coding agent ao MCP, use o comando publicado no README do repositório e verifique as permissões do cliente. A integração remota envia os dados ao serviço; para arquivos sensíveis, prefira executar a biblioteca no ambiente controlado pela organização.

Em qualquer caminho, mantenha o arquivo original, a versão selecionada e o relatório de achados. Corrija o dado na fonte, revalide e compare o XML final com a documentação do receptor. Não remova campos de forma automática só para fazer o XSD passar: a correção precisa preservar o significado assistencial e administrativo da mensagem.

O que conferir antes de migrar para 4.03.00?

Monte um inventário da integração: tipo de mensagem, versão do componente de Comunicação, versão de TUSS e componente organizacional aplicável. Registre de onde vêm os dados e quais campos o seu sistema envia. Isso ajuda a separar uma alteração de schema de um mapeamento interno ou de uma atualização de tabela.

Em seguida, compare os schemas usados no ambiente atual com os publicados pela ANS para a nova competência. O pacote do tiss contém apenas as versões que ele declara suportar, no estado consultado: 4.02.00 e 4.03.00. Confirme essa lista na documentação do pacote quando fizer uma atualização futura; não presuma que continuará igual.

Crie testes com dados sintéticos para cada mensagem que o seu sistema realmente troca. Inclua um XML válido, exemplos com campos ausentes, dados fora de tipo e um digest alterado. Um caso mínimo ajuda a detectar regressões sem carregar dados identificáveis. O teste valida o seu mapeamento, mas não substitui homologação com o destinatário.

Depois, verifique a compatibilidade dos dois lados: versão que o emissor gera e versão que o receptor recebe. Não altere namespace, sequência de elementos ou tabela de códigos manualmente sem referência. Se o schema não comportar uma informação necessária, consulte a documentação oficial e a equipe responsável pelo canal antes de criar uma extensão proprietária.

Por fim, documente o procedimento de retorno. Guarde amostras sintéticas, a data e a competência da ANS consultadas, a versão de cada componente, os testes executados e os responsáveis pela homologação. Se a ANS publicar uma nova competência ou o contrato mudar, essa trilha ajuda a localizar exatamente o ponto que precisa de revisão.

Como interpretar um erro sem confundir com glosa?

Use a camada que descreve o achado. Um erro como xsd.elemento_ausente informa que falta um campo esperado pelo schema naquele contexto. Já lote.hash_divergente indica diferença entre o digest informado e o calculado pela biblioteca. Um código da Tabela 38, como 5014, pertence ao vocabulário oficial de mensagens de glosa, negativa e outras mensagens; não é o nome do achado interno do validador.

Ao corrigir, não ajuste apenas o sintoma. Se falta um identificador, confira a fonte do dado e a obrigatoriedade do campo. Se o elemento está fora da ordem, verifique o tipo complexo correspondente. Se o hash diverge, finalize as mudanças no XML e recalcule o epílogo. Se aparece uma regra de autorização, confira a guia, o procedimento, a vigência e a regra aplicável.

O relatório do validador é uma ferramenta de triagem. Ele não decide se a cobrança será aprovada, se o pagamento ocorrerá ou se um recurso será aceito. Para contestar uma glosa, consulte o demonstrativo, o contrato e os prazos acordados. Para uma decisão clínica ou administrativa, preserve a análise profissional responsável.

Quais dúvidas aparecem sobre o TISS 4.03.00?

O TISS 4.03.00 é uma versão de todos os componentes?

Não. 04.03.00 identifica uma versão do componente de Comunicação. A ANS publica versões por competência para componentes diferentes. Consulte o histórico completo e a competência aplicável ao seu fluxo.

O que mudou no TISS 4.03.00?

A ANS descreve, entre outros itens, novas entradas de Centro de Consumo, o valor 027 de versão do prestador e 144 termos adicionais da Tabela 38 no schema de Comunicação. Consulte o histórico do componente organizacional para a lista completa daquela competência.

O prazo de vigência é o mesmo que o fim da implantação?

Não. A ANS apresenta início de vigência e limite de implantação como datas distintas. Use a linha mais recente do histórico e confira a versão aceita pelo destinatário.

Um XML válido no XSD será aceito pelo plano de saúde?

Não necessariamente. O XSD verifica estrutura e tipos. Regras contratuais, cadastro, autorização, cobertura, vigência e compatibilidade do canal podem exigir verificações adicionais.

O validador do tiss suporta 4.03.00?

No snapshot consultado, sim. A biblioteca declara suporte a 4.02.00 e 4.03.00 e carrega schemas empacotados com manifesto de proveniência. Confira a documentação para a lista atual quando atualizar o pacote.

Posso testar com dados reais de pacientes?

Prefira os exemplos sintéticos. A validação local do pacote não envia o XML à API; o playground remoto envia o arquivo ao serviço para processamento. Siga as políticas e controles de dados da sua organização.

Onde validar um lote de teste?

Use o playground do tiss para explorar achados com dados sintéticos. Para conferir o código e a licença, acesse o repositório no GitHub. O pilar se conecta a guias sobre validadores XML TISS, hash do epílogo, Tabela 38, recurso de glosa, glosas por plano de saúde e autorização prévia.

Autor: Solano Todeschini · Voa Health · Fundador, CEO

Conheça o Voa TISS para prestadores e operadoras e consulte a documentação de integração.