A análise da causa raiz de glosas permite transformar uma rejeição ou glosa recorrente em aprendizado operacional: em vez de apenas corrigir a conta devolvida, a equipe identifica onde a falha nasce, define uma prevenção verificável e acompanha se o problema deixa de se repetir.
Uma mesma crítica pode voltar em dezenas de guias por um motivo simples: o dado é corrigido no caso devolvido, mas a origem permanece igual no cadastro, no roteiro de atendimento, no lançamento ou na geração do arquivo. Este artigo apresenta um método para investigar a causa raiz de glosas e rejeições no faturamento sem presumir que todas as operadoras usam os mesmos motivos, prazos ou regras. O foco é criar um registro que ajude faturamento, cadastro, recepção, áreas assistenciais e gestão a tomar decisões consistentes.
Neste artigo
Correção pontual não é análise de causa raiz
Correção pontual é a providência que viabiliza o tratamento de uma guia, de um lote ou de uma cobrança específica: complementar uma informação, ajustar um lançamento, substituir um arquivo ou decidir pela contestação. Ela é necessária, mas responde apenas ao caso atual. Causa raiz, neste método, é a condição do processo que tornou possível a ocorrência e que, se mantida, tende a reproduzir a mesma falha em situações semelhantes.
Não transforme o código ou a descrição recebida em diagnóstico final. Um motivo como “campo inválido”, “divergência de valor” ou “autorização ausente” é um sinal para começar a investigação. A causa pode estar em uma fonte cadastral desatualizada, em uma etapa sem dupla conferência, em uma instrução interna ambígua, em um parâmetro técnico ou em uma regra operacional que não foi incorporada ao fluxo. Separe o que a operadora apontou, o que a equipe observou e o que foi comprovado.
Quando uma ocorrência merece investigação estruturada
Nem toda devolução exige uma reunião longa. A triagem deve reservar investigação estruturada para eventos que se repetem, afetam mais de uma pessoa ou unidade, envolvem valor ou volume relevante para a organização, criam risco de prazo, não têm motivo compreendido ou reaparecem depois de uma correção anterior. A regra prática é simples: se a equipe não consegue explicar por que o caso aconteceu e como impedirá outro igual, o caso ainda não está encerrado como aprendizado.
Sinais para abrir uma análise de causa
- O mesmo motivo retorna em guias, itens ou lotes diferentes
- A correção depende sempre de intervenção manual
- A ocorrência começou após mudança de cadastro, processo, tabela, sistema ou orientação
- Há divergência entre o motivo recebido e o que consta na guia ou no documento de origem
- A equipe não sabe quem é dono da etapa em que a falha nasceu
- O retorno pode comprometer prazo de apresentação, contestação ou resposta
Reúna evidências antes de buscar culpados
Comece por um caso representativo e reconstrua seu caminho. Preserve o retorno recebido, a guia ou conta, o item afetado, os dados de origem consultados, a versão ou referência técnica usada, o arquivo quando aplicável, as mensagens de validação e a regra contratual ou operacional pertinente. Registre também a data, a operadora, a competência, a unidade e o responsável atual. O objetivo não é acumular anexos: é permitir que outra pessoa compreenda a sequência sem depender da memória de quem tratou o caso.
O Padrão TISS é obrigatório para as trocas eletrônicas de dados de atenção à saúde dos beneficiários entre agentes da saúde suplementar. (TISS – Padrão para Troca de Informação de Saúde Suplementar — Agência Nacional de Saúde Suplementar) A ANS também informa que prazos e procedimentos de faturamento, pagamento, auditoria e contestação devem constar da relação contratual entre prestador e operadora. (Faturamento e Pagamento dos Serviços Prestados — Agência Nacional de Saúde Suplementar) Portanto, a evidência técnica não substitui a consulta às regras aplicáveis ao relacionamento específico. (TISS – Padrão para Troca de Informação de Saúde Suplementar — Agência Nacional de Saúde Suplementar) (Faturamento e Pagamento dos Serviços Prestados — Agência Nacional de Saúde Suplementar)
Classifique a causa para orientar a investigação
Categorias práticas de causa
| Categoria | O que verificar | Ação preventiva possível |
|---|---|---|
| Dados de origem | Cadastro, agenda, guia, autorização, documento assistencial e valores lançados | Definir fonte oficial, campo obrigatório e revisão antes do fechamento |
| Processo | Sequência de trabalho, passagem de bastão, checklist e exceções | Redesenhar a etapa, registrar critérios e treinar quem executa |
| Responsabilidade | Área que produz o dado, aprova exceção ou acompanha retorno | Nomear dono da atividade e substituto |
| Regra operacional | Contrato, manual, portal ou orientação da operadora | Atualizar matriz por operadora e comunicar a mudança |
| Técnica ou XML | Estrutura, versão, formato, integração, mapeamento ou parâmetro | Corrigir a origem do dado ou o mapeamento e testar novamente |
| Comunicação | Informação não repassada, instrução ambígua ou decisão sem registro | Padronizar o canal, o registro e o critério de escalonamento |
A classificação não serve para encerrar o diagnóstico com um rótulo amplo, como “erro humano”. Esse rótulo não informa qual dado foi produzido de forma incorreta, por qual etapa, sob qual condição e qual barreira falhou. Prefira uma descrição observável: “a data de atendimento foi digitada manualmente sem confronto com a agenda” ou “o parâmetro de exportação permaneceu associado a uma referência anterior”. Assim, a prevenção pode ser desenhada sobre o processo, e não sobre a culpa individual.
Faça perguntas que levem à origem da falha
Roteiro de investigação
- Qual foi o motivo literal recebido e em qual etapa ele apareceu?
- Qual guia, conta, item, lote, competência e operadora estão envolvidos?
- Qual informação foi considerada incorreta, ausente ou incompatível?
- Qual é a fonte que deveria comprovar essa informação?
- Em que ponto o dado foi criado, copiado, transformado ou aprovado?
- O caso é isolado ou existem outros com o mesmo padrão?
- O que mudou antes do início da recorrência?
- Que controle deveria ter impedido a falha e por que ele não funcionou?
- Qual ação removerá a condição que permitiu o problema?
- Qual evidência mostrará que a ação foi executada e qual período será observado depois?
Use a técnica dos “porquês” com cuidado. Perguntar “por quê?” várias vezes pode revelar uma sequência útil, mas não dispensa evidência. Pare quando chegar a uma condição controlável pela organização, confirmada pelos registros, e capaz de orientar uma medida concreta. Se a resposta for uma hipótese, marque-a como hipótese e defina como ela será verificada; não a registre como causa concluída.
Converta o diagnóstico em ação preventiva
Uma ação preventiva deve alterar a condição que gerou a ocorrência. “Orientar a equipe” sozinho costuma ser insuficiente porque não informa o que muda na rotina, quem verifica a aplicação e como o processo continuará funcionando quando houver troca de pessoas. Combine orientação com uma mudança visível: campo com fonte definida, checklist em momento específico, bloqueio interno, revisão por amostragem, atualização de matriz de regras ou correção de mapeamento.
Registro mínimo do plano preventivo
| Campo | Como preencher |
|---|---|
| Ocorrência | Motivo literal, identificador do caso, operadora, competência e item afetado |
| Evidência | Retorno, guia, documento de origem, regra consultada e resultado da conferência |
| Causa confirmada | Descrição objetiva da condição encontrada |
| Ação corretiva do caso | O que foi feito para tratar a ocorrência já recebida |
| Ação preventiva | Mudança de processo, dado, regra, mapeamento ou controle |
| Responsável | Pessoa ou função dona da entrega |
| Prazo | Data ou marco operacional para conclusão |
| Evidência de execução | Registro que comprova a implantação |
| Verificação | Indicador, amostra ou período de acompanhamento |
| Status | Aberto, em execução, verificado ou encerrado com ressalva |
Defina responsável, prazo e critério de encerramento
O responsável pela investigação não precisa ser a pessoa que executará a mudança. Em uma divergência cadastral, por exemplo, faturamento pode registrar e analisar o retorno, cadastro pode corrigir a fonte, a coordenação pode aprovar o novo controle e a gestão pode remover um impedimento. O essencial é que cada entrega tenha um dono explícito, um prazo e uma evidência de conclusão. Uma matriz de responsabilidades evita que o caso fique parado entre áreas ou seja encerrado sem prevenção.
Verifique se a ação funcionou depois da implantação
Implantar uma ação não prova que ela resolveu a causa. Defina antes da implantação o que será observado: ausência do mesmo motivo em um período determinado, redução do padrão em uma amostra, preenchimento correto de um campo, adesão ao novo checklist ou resultado de nova validação. Compare casos semelhantes antes e depois da mudança, preservando o contexto da operadora, do tipo de guia e da competência. Se a ocorrência persistir, reabra a análise: a causa pode ter sido parcial, a ação pode não ter sido executada como planejado ou existir uma segunda causa.
Quando a hipótese envolver dado ou estrutura XML, a validação prévia pode integrar o controle, mas deve ser interpretada na camada certa. Um arquivo estruturalmente consistente não substitui a conferência de dados de origem, autorizações, regras contratuais ou exigências operacionais da operadora. Para organizar essa revisão, consulte o guia sobre
Exemplo ilustrativo de registro de ocorrência
Ilustrativo: divergência repetida em data de atendimento
Entrada: três guias da mesma unidade retornaram com crítica relacionada à data de atendimento. Mapeamento: o faturamento comparou o retorno com a guia e encontrou datas diferentes da agenda; a equipe identificou que o lançamento era digitado manualmente a partir de uma lista impressa. Erro: a causa inicialmente registrada foi “desatenção do faturista”. Correção: a investigação foi refeita e registrou como causa confirmada a ausência de uma fonte única e de confronto obrigatório com a agenda. Ação preventiva: definir a agenda como fonte de referência, criar conferência antes do fechamento e registrar responsável pela revisão. Verificação: acompanhar as guias do mesmo fluxo por período previamente definido e verificar se a divergência reaparece. Este cenário demonstra um método de análise e não descreve uma regra universal de operadora.
Pontos essenciais
- Registre o motivo literal e preserve as evidências antes de concluir a causa
- Diferencie o tratamento da guia devolvida da prevenção de novas ocorrências
- Classifique a causa por dados, processo, responsabilidade, regra, técnica ou comunicação
- Transforme hipóteses em conclusões apenas após confrontá-las com registros
- Defina ação preventiva, responsável, prazo, evidência de execução e critério de verificação
- Reabra a análise se o padrão persistir após a mudança
Organize a prevenção antes do próximo retorno
Registre a causa identificada, mantenha a evidência vinculada ao caso e use a validação prévia como controle quando a falha envolver dados ou XML. Conheça o TISSXML para apoiar a digitação e emissão de Guias TISS, a geração de XML TISS e o faturamento de guias.
Perguntas frequentes sobre causa raiz de glosas
Fontes e referências
TISS – Padrão para Troca de Informação de Saúde Suplementar — Agência Nacional de Saúde Suplementar
Faturamento e Pagamento dos Serviços Prestados — Agência Nacional de Saúde Suplementar