O que é automação (RPA) no faturamento hospitalar?
Automação no faturamento hospitalar é o uso de software para executar, sem digitação humana, tarefas repetitivas do ciclo de receita: consultar, copiar, conferir, enviar, baixar e registrar. A forma mais conhecida é a automação robótica de processos (RPA, na sigla em inglês), um robô que opera na tela como um usuário: abre o portal da operadora, faz login, preenche campos, baixa arquivos e grava o resultado no sistema do hospital.
O RPA é determinístico: segue um roteiro escrito (“se o status é X, registre Y”) e faz sempre a mesma coisa diante da mesma entrada. É fácil de auditar, mas frágil: se o portal muda um botão de lugar, o robô para.
Quem constrói e mantém os robôs é parte da decisão sobre o modelo de operação, tratada no guia Terceirização do faturamento hospitalar.
RPA, webservice TISS e IA resolvem problemas diferentes
RPA, integração por webservice do padrão de Troca de Informação de Saúde Suplementar (TISS) e IA não são graus da mesma tecnologia. Cada uma serve a um tipo de problema, e escolher a errada encarece o projeto.
| RPA (robô na tela) | Integração por webservice TISS | IA (modelos que aprendem) | |
|---|---|---|---|
| Como funciona | Imita cliques e digitação em sistemas e portais | Sistema do hospital troca mensagens XML com o da operadora | Estima probabilidades ou gera texto a partir do histórico |
| Melhor para | Portal sem integração; ponte entre sistemas internos | Trocas do padrão TISS: lote, protocolo, demonstrativos, recurso | Priorizar e prever onde regras fixas não bastam |
| Saída | Sempre a mesma para a mesma entrada | Mensagem padronizada, com protocolo | Probabilidade ou rascunho, com revisão humana |
| Ponto fraco | Quebra quando a tela muda; usa credencial de usuário | Exige versão vigente do padrão, certificado digital e implantação dos dois lados | Herda vícios do histórico; exige governança |
Na prática, a ordem costuma ser: integrar pelo padrão onde ele existe, usar robô onde só há tela e reservar a IA para priorizar. A IA na conferência de contas está nos guias IA no faturamento hospitalar e IA para prevenção de glosas; a troca de dados entre sistemas, no guia Interoperabilidade.
O que o padrão TISS já obriga a ser eletrônico?
O Componente Organizacional do padrão TISS, versão 202609, divide as trocas entre operadora e prestador em dois grupos [1]. Saber em qual grupo cada tarefa está muda a melhor forma de automatizá-la.
| Grupo | Processos | O que isso significa para a automação |
|---|---|---|
| Troca eletrônica obrigatória (item 33) | Cobrança de serviços; lote de anexos da autorização; comunicação de internação ou alta; demonstrativos de retorno; recurso de glosa | Webservice tende a ser o caminho mais estável |
| Troca eletrônica opcional (item 34) | Verificação de elegibilidade; autorização de procedimentos (exceto o lote de anexos); envio e recebimento de documentos | A mensagem eletrônica pode não existir; portal e robô aparecem mais |
O mesmo componente obriga a operadora a oferecer webservice e portal, e o prestador escolhe qual usar (itens 129 e 130) [1]. O portal deve ter upload e download de arquivos e entrada de dados para a cobrança (item 132), com os campos na mesma sequência das guias do plano de contingência (item 133) [1].
O protocolo gerado pela operadora comprova o recebimento do lote de guias, do lote de anexos e do recurso (item 55), e o demonstrativo é pedido pelo número desse protocolo (item 49) [1]. Guardar o protocolo de forma estruturada é o que permite automatizar a cobrança do retorno. As mensagens estão no guia Padrão TISS.
Seis tarefas candidatas à automação
As tarefas abaixo combinam volume alto, passos repetidos e regra escrita. A “via preferencial” indica o que costuma ser mais estável, não uma regra.
| Tarefa | Via preferencial | Cuidado |
|---|---|---|
| Verificação de elegibilidade | Mensagem TISS, se a operadora oferecer; senão, robô no portal | A negativa deve trazer o motivo (item 45) [5]; exceções vão para uma pessoa. Veja Verificação de elegibilidade |
| Captura de senhas e status de autorização | Robô de consulta periódica; mensagem TISS onde houver | Registrar a validade: a tabela 38 da Terminologia Unificada da Saúde Suplementar (TUSS) tem o motivo 1414, validade da senha expirada [6]. Veja Senha de autorização vencida |
| Montagem e envio do lote XML | Webservice TISS direto do sistema do hospital | Validar antes do envio; críticas como 5002 (XML não validado) e 1308 (guia já apresentada) devolvem lote ou guia [6]. Veja Lote XML TISS: erros |
| Registro do protocolo e status | Webservice (status de protocolo, item 47) [5] | Sem o protocolo guardado, não há como pedir o demonstrativo |
| Download e conciliação de demonstrativos | Webservice para o pedido; regra escrita para conciliar guia a guia | O demonstrativo de análise lista as guias do lote e, nas analisadas, só os itens glosados (item 56) [5]. Veja Demonstrativo de análise de conta e de pagamento e Conciliação de pagamentos |
| Acompanhamento de recursos de glosa | Webservice (mensagens de recurso, item 51) [5] + alerta por regra | O robô controla prazo e status; o argumento é humano. Motivo 2909: prazo de recurso prescrito [6]. Veja Prazo para recurso de glosa |
Conferência de conta e redação de recurso ficam fora da lista porque exigem julgamento. Antes do envio, também pesa o tempo entre a alta e o faturamento, tratado no guia Tempo entre alta e faturamento.
Como priorizar: a matriz de quatro critérios
A primeira automação deve ser a de maior volume, regra mais estável, menos julgamento e custo do erro conhecido. Pontue cada tarefa candidata de 1 a 3 em cada critério e comece pelas maiores somas.
| Critério | Pergunta | 1 ponto | 3 pontos |
|---|---|---|---|
| Volume | Quantas vezes por mês a tarefa se repete, somando operadoras? | Poucas, esporádicas | Diária, em todas as operadoras |
| Regra estável | O passo a passo e a tela mudam pouco? | Portal ou regra mudam com frequência | Roteiro e tela estáveis, ou mensagem padronizada TISS |
| Baixo julgamento | A tarefa pode ser descrita em “se X, então Y”? | Exige análise clínica ou de contrato | Só consulta, cópia ou comparação |
| Custo do erro | O erro é detectável e o prejuízo, limitado? | Erro silencioso com perda definitiva (ex.: prazo perdido sem alerta) | Erro aparece logo e pode ser refeito |
O custo do erro funciona ao contrário do que parece. Perder o prazo de recurso custa caro: a tarefa é boa para um alerta automático, mas não para um robô que age sozinho. Por isso o critério pontua alto o erro visível e reversível.
Ver a matriz em tabela
| Quadrante | Volume | Regra estável e baixo julgamento | Tarefas (exemplo ilustrativo) |
|---|---|---|---|
| Automatizar primeiro | Alto | Alta | Download de demonstrativos; status de protocolo de lote e recurso; captura de senhas de autorização; verificação de elegibilidade |
| Automatizar depois | Baixo | Alta | Atualização de códigos TUSS no cadastro |
| Padronizar antes | Alto | Baixa | Tarefas em portais que mudam com frequência; conciliação de demonstrativos (fronteira, depende do cadastro) |
| Manter com a equipe | Baixo | Baixa | Redação do recurso de glosa; conferência clínica da conta |
A posição de cada tarefa depende do hospital: número de operadoras, quantas oferecem webservice, qualidade do cadastro.
Quando não automatizar
Automatizar um processo ruim só produz o erro mais rápido. Costuma não valer a pena quando:
- o processo não está escrito: se cada faturista faz de um jeito, padronize antes;
- o portal muda com frequência: a manutenção pode superar o ganho; peça o webservice, que é direito do prestador [1];
- a tarefa exige julgamento: conferência clínica, argumento do recurso, negociação com o auditor;
- o volume é pequeno ou não há dono para o robô quando ele para.
Como medir o ganho da automação?
O ganho da automação se mede com a mesma tarefa, antes e depois, pelas mesmas fórmulas. Sem linha de base, não há como separar o efeito do robô de uma mudança da operadora ou do volume.
| Medida | Como calcular | Para que serve |
|---|---|---|
| Tempo por tarefa | Minutos por execução × execuções no mês, antes e depois | Horas liberadas da equipe |
| Taxa de exceção | Execuções que o robô não concluiu ÷ total | Mostra se o robô é estável ou vive parando |
| Taxa de erro | Erros encontrados na conferência amostral ÷ execuções conferidas | Compara a qualidade com a do processo manual |
| Prazo | Dias entre o evento e a conclusão (ex.: do pagamento à conciliação; da alta ao envio) | Mostra se a agilidade chegou ao caixa |
| Custo de manutenção | Horas de ajuste do robô e licenças por mês | Entra no cálculo do ganho líquido |
Exemplo ilustrativo (números hipotéticos). Um hospital trabalha com 12 operadoras. Baixar e lançar os demonstrativos leva 25 minutos por operadora, duas vezes por semana: 12 × 25 × 2 × 4,3 semanas ≈ 43 horas por mês. Com o robô, a equipe trata só as exceções (3 operadoras por semana, 15 minutos cada, ≈ 3 horas por mês) e gasta 4 horas em manutenção. O ganho seria de cerca de 36 horas por mês, desde que elas sejam usadas em análise de glosa e que a conciliação passe a ser feita em menos dias.
Duas armadilhas: contar horas “liberadas” que não mudaram de uso e esquecer a manutenção, já que toda nova versão do padrão TISS ou mudança de portal pede teste do robô. Os indicadores de prazo e glosa estão em Indicadores do ciclo de receita, e os números do setor, em Dados do setor. Para levar a conta ao comitê financeiro, o guia ROI de um projeto de ciclo de receita mostra como montar o business case.
LGPD e credenciais: o robô também é um usuário
O robô acessa guias, contas e demonstrativos, que contêm dados de saúde, classificados pela Lei Geral de Proteção de Dados (LGPD) como dados pessoais sensíveis (art. 5º, II) [3]. Ele precisa seguir as mesmas regras de acesso de qualquer pessoa da equipe.
Quem é controlador e quem é operador. O hospital, que decide por que e como os dados são tratados, costuma ser o controlador. A empresa que desenvolve ou opera o robô em nome do hospital costuma ser operadora e deve seguir as instruções do controlador (arts. 5º, VI e VII, e 39) [3]. O operador responde solidariamente pelos danos quando descumpre a lei ou as instruções lícitas do controlador (art. 42, § 1º, I) [3]. Os papéis precisam estar no contrato.
Credenciais dos portais. O robô entra no portal com login e senha. Cuidados práticos:
- usar um usuário próprio para o robô, quando a operadora permitir, e não a senha pessoal de um faturista;
- guardar as senhas em cofre de credenciais, com troca periódica e acesso restrito;
- registrar cada operação do robô (o que acessou, quando, com qual usuário), o que ajuda a cumprir o dever de registro das operações (art. 37) [3];
- conferir os termos de uso do portal e o contrato com a operadora antes de automatizar o acesso;
- prever no contrato com o fornecedor a segurança dos dados (art. 46) e o aviso de incidentes [3].
Incidentes. Se uma credencial vazar, o controlador deve comunicar o incidente que possa causar risco ou dano relevante à Autoridade Nacional de Proteção de Dados (ANPD) e aos titulares (art. 48) [3], em 3 dias úteis pela Resolução CD/ANPD nº 15/2024 [4]. A troca de dados com operadoras será detalhada no guia LGPD no faturamento.
No webservice, a segurança segue o padrão TISS: certificado digital e-CNPJ da instituição (item 21), e a operadora não pode exigir em papel o que foi trocado com certificado ICP-Brasil (item 20) [5].
O que vemos na operação
A Accrua presta serviço de ciclo de receita e automatiza parte da própria operação. A transmissão é feita, de preferência, por API e também por webservice, portal e arquivo, conforme o que cada operadora oferece, com baixa no sistema do hospital. As tarefas repetitivas com regra definida ficam com a automação: validação do XML, transmissão do lote, acompanhamento de prazo e de status, conciliação do demonstrativo e rascunho do recurso.
Ficam com a equipe as tarefas em que há decisão sobre valor: aceitar ou contestar uma glosa, desistir de um recurso, alterar item da conta. O limite entre as duas está no contrato com o hospital, e cada ação automática fica registrada, com o agente que a executou e a base usada, do mesmo jeito que as ações da equipe.
Por onde começar
- Liste as tarefas repetitivas do faturamento, com quantas vezes por mês cada uma ocorre e em quantas operadoras.
- Mapeie a via disponível por operadora: webservice TISS, só portal ou nenhuma. Onde só há portal para trocas obrigatórias, peça o webservice.
- Pontue cada tarefa nos quatro critérios (volume, regra estável, baixo julgamento, custo do erro) e escolha uma ou duas para começar.
- Meça a linha de base de tempo, exceções, erros e prazo da tarefa escolhida, por pelo menos um mês.
- Defina dono, credenciais e registro do robô antes de ligá-lo, e reavalie os números depois de um ou dois ciclos.