As regras da operadora no XML TISS não são sinônimo do padrão TISS. Ao classificar cada apontamento como falha de estrutura, dado de origem, versão aplicável ou exigência operacional, a equipe evita alterar o XML por tentativa e erro e direciona a correção para a fonte certa.
Uma mensagem de erro XML TISS não deve ser tratada como um diagnóstico completo. Ela pode indicar que a estrutura do arquivo precisa de ajuste, que um dado foi registrado incorretamente antes da geração, que a versão usada não corresponde à referência aplicável ou que há uma exigência operacional específica da operadora. Separar essas hipóteses antes de editar o arquivo reduz correções superficiais e ajuda a equipe a encaminhar cada caso para cadastro, faturamento, tecnologia ou relacionamento com a operadora.
O padrão TISS é obrigatório para as trocas eletrônicas de dados de atenção à saúde dos beneficiários entre os agentes abrangidos na saúde suplementar. (Minist�rio da Sa�de) A norma também determina que a troca de dados ocorra eletronicamente e na versão vigente. (Minist�rio da Sa�de) Isso define uma referência comum, mas não elimina a necessidade de conferir os procedimentos administrativos, contratuais e operacionais envolvidos em uma cobrança concreta. (Minist�rio da Sa�de)
Neste artigo
Quatro camadas que explicam um apontamento
Padrão, versão, dado e regra operacional
A primeira camada é o padrão TISS: ele organiza a troca de informações e possui componentes organizacional, de conteúdo e estrutura, de representação de conceitos em saúde, de segurança e privacidade e de comunicação. Na prática, uma falha de padrão pode envolver a presença, a ordem, o formato ou o relacionamento esperado entre elementos do arquivo, conforme a documentação técnica aplicável. (Minist�rio da Sa�de)
A segunda camada é a versão aplicável. Uma mensagem de incompatibilidade pode resultar de um arquivo montado segundo uma referência anterior, de tabelas consultadas fora da vigência pertinente ou de uma configuração que não acompanhou a atualização. A ANS mantém uma página do padrão com acesso a versões e histórico dos componentes; consulte esse material para identificar a referência vigente e seus períodos, em vez de presumir a versão pelo último lote que funcionou. (TISS – Padrão para Troca de Informação de Saúde Suplementar — Agência Nacional de Saúde Suplementar)
A terceira camada é o dado de origem. Beneficiário, prestador, profissional, unidade, data, procedimento, quantidade, valor, autorização e demais informações são registrados em algum ponto do processo antes de aparecer no XML. Se a fonte estiver incompleta, desatualizada ou atribuída ao atendimento errado, editar apenas a saída pode resolver um arquivo isolado e manter a causa ativa para os próximos lotes. A correção mais segura é rastrear a informação até o cadastro, a guia, o registro assistencial ou a regra de lançamento que a produziu.
A quarta camada é a exigência operacional da operadora. Ela diz respeito ao modo como aquela relação de faturamento é conduzida: documentação complementar, autorização, prazo, canal, rotina de análise, convenção cadastral ou orientação aplicável ao contrato. Nem toda exigência operacional se converte em regra estrutural do XML, e nem todo XML tecnicamente consistente comprova que a conta cumpriu as condições administrativas ou contratuais. Por isso, “regra da operadora” é uma categoria relacionada ao padrão, não um sinônimo dele.
Matriz de triagem antes de corrigir o XML
| Sinal observado | Hipótese principal | Fonte de consulta | Próxima ação |
|---|---|---|---|
| Elemento ausente, formato inválido ou ordem inesperada | Estrutura ou conteúdo do arquivo | Mensagem completa, esquema e documentação técnica aplicável | Localizar o trecho apontado e corrigir a geração ou a configuração responsável |
| Arquivo aceito em uma referência e recusado em outra | Versão ou tabela fora da vigência aplicável | Histórico e materiais vigentes da ANS, além da referência operacional recebida | Confirmar competência, versão e datas antes de regenerar o lote |
| Informação do XML diverge da guia ou do atendimento | Dado de origem incorreto ou incompleto | Cadastro, guia, prontuário, autorização e lançamento de faturamento | Corrigir a fonte autorizada e gerar novo arquivo |
| Retorno pede documento, senha, prazo ou procedimento específico | Exigência operacional da operadora | Contrato, portal, manual operacional ou canal oficial da operadora | Registrar a regra, confirmar aplicabilidade e cumprir o fluxo indicado |
| Mensagem é genérica ou não identifica campo | Causa ainda não determinada | Retorno integral, identificadores do lote e comparação com caso semelhante | Preservar evidências e abrir investigação sem alterar campos por suposição |
Árvore de decisão para classificar o apontamento
Comece pela evidência disponível, e não pela correção imaginada. Guarde a mensagem literal, a data e hora, a identificação da operadora, o lote, a guia ou conta relacionada, a competência, a versão declarada e uma cópia controlada do arquivo analisado. Essa base permite distinguir um defeito repetível de uma ocorrência isolada e evita que uma nova geração apague elementos úteis para a investigação.
- A mensagem aponta uma tag, posição, tipo de dado, cardinalidade ou relação entre elementos? Trate primeiro como hipótese de estrutura e confira a documentação técnica da versão usada.
- A mensagem cita versão, layout, tabela ou incompatibilidade temporal? Suspenda a alteração do conteúdo até confirmar a referência aplicável à competência e ao fluxo.
- O valor no XML é diferente do que consta na guia, no cadastro ou no registro do atendimento? Classifique como dado de origem e corrija o registro que alimenta a geração.
- O retorno solicita senha, anexo, autorização, prazo, protocolo ou outra providência sem indicar defeito estrutural? Classifique como exigência operacional e consulte a fonte da operadora.
- Nenhuma hipótese está confirmada? Mantenha a classificação como investigação aberta, peça esclarecimento com o contexto completo e evite reutilizar uma solução de outro caso apenas por semelhança de texto.
Depois da classificação, complemente a investigação com um processo consistente de conferência. O material de checklist para validar XML TISS ajuda a organizar revisões de cadastro, guia, dados assistenciais e arquivo sem confundir uma checagem técnica com a aceitação operacional da conta.
Como registrar a investigação e evitar recorrência
Uma ocorrência bem registrada deixa de ser apenas um erro resolvido e passa a ser referência para casos futuros. Mantenha um registro por apontamento com a mensagem integral, categoria escolhida, hipótese inicial, fonte consultada, pessoa responsável, alteração realizada, versão do arquivo regenerado e resultado da nova conferência. Quando houver dependência da operadora, acrescente a data da consulta, o canal usado, a orientação recebida e a condição a que ela se aplica.
Campos úteis no controle interno
- Identificação do caso: operadora, prestador, competência, lote, guia ou conta conforme a política de acesso da instituição
- Evidência recebida: texto integral da mensagem, tela ou protocolo e momento do retorno
- Classificação: estrutura, versão, dado de origem, regra operacional ou investigação aberta
- Impacto: impedimento de validação, necessidade de documento, divergência cadastral ou outra consequência observada
- Tratamento: ação executada, origem corrigida, responsável e data
- Desfecho: resultado da nova validação, resposta obtida ou motivo para manter o caso pendente
- Prevenção: ajuste de cadastro, treinamento, regra de sistema ou revisão de rotina proposta
Para revisar a camada técnica com mais contexto, consulte também Layout TISS explicado: estrutura, regras e como evitar erros. A leitura é especialmente útil quando a equipe precisa separar um problema de composição do arquivo de uma divergência que nasceu no atendimento ou no cadastro.
Exemplo ilustrativo: evitar uma correção no arquivo sem corrigir a fonte
Exemplo ilustrativo — entrada: uma clínica recebe um retorno informando inconsistência em uma informação ligada ao procedimento de uma guia. A equipe encontra o valor no XML e pensa em substituir o conteúdo diretamente no arquivo para tentar eliminar a mensagem. Ainda não há evidência de que o problema seja uma regra universal do padrão ou uma exigência específica da operadora.
Mapeamento, erro e correção
- Mapeamento: a equipe compara o XML com a guia, o registro do atendimento, a autorização disponível e a referência de versão usada no lote.
- Classificação inicial: o procedimento no arquivo reproduz exatamente o dado salvo no sistema; portanto, a hipótese prioritária passa a ser dado de origem ou regra operacional, não erro de digitação no XML.
- Erro a evitar: alterar somente o arquivo exportado, sem saber se o dado cadastrado continuará gerando a mesma divergência nos próximos lotes.
- Correção: confirmar, pela documentação e pelo canal adequado, qual informação deve representar o atendimento naquele contexto; então ajustar o registro de origem autorizado, regenerar o XML e repetir a conferência técnica.
- Registro: anotar a regra consultada, a condição de aplicação e o resultado. Se a orientação depender de produto, contrato ou período, ela não deve ser generalizada para outras cobranças.
Limites da validação técnica e da confirmação operacional
A validação técnica é uma etapa de conferência do arquivo, não uma promessa de aceitação, cobertura, processamento ou pagamento. Ela pode apontar inconsistências de estrutura e conteúdo verificáveis na análise adotada, mas não substitui a conferência de autorizações, documentos, condições contratuais, prazos e demais regras aplicáveis ao relacionamento entre prestador e operadora. Use o resultado para qualificar a investigação, não para encerrar o caso antes de verificar a etapa operacional correspondente.
A ANS informa que o Monitora TISS trata do monitoramento da qualidade dos dados do padrão e apresenta orientações relacionadas à versão e à qualidade das informações. Para a rotina de faturamento, isso reforça a necessidade de registrar qual referência foi adotada e de revisar materiais vigentes sempre que houver atualização, em vez de transformar práticas antigas em regra permanente. (Monitora TISS — Agência Nacional de Saúde Suplementar)
Resumo para a rotina de validação
- Leia a mensagem completa antes de editar o XML e preserve o contexto do retorno.
- Classifique o caso entre estrutura, versão, dado de origem, exigência operacional ou investigação aberta.
- Confirme versão, competência e tabelas aplicáveis antes de atribuir uma falha ao arquivo.
- Quando o XML espelha uma informação incorreta, corrija primeiro o cadastro, a guia ou o lançamento de origem autorizado.
- Documente orientações específicas da operadora com canal, data, condição de aplicação e evidência.
- Repita a validação após a correção, sem interpretar o resultado técnico como garantia de aceite ou pagamento.
Perguntas frequentes sobre regras da operadora no XML TISS
Faça uma nova conferência depois da correção
Depois de classificar o apontamento, corrigir a fonte autorizada e regenerar o arquivo quando necessário, use o Validador TISS online para realizar uma nova conferência técnica. O resultado deve ser analisado junto com a versão aplicável e as exigências operacionais confirmadas para o caso.