Agente de IA para Auditoria de Processos de Faturamento

07 de December de 2025 • Tempo de leitura: 5 min

Como criar um agente de IA que revisa processos de faturamento hospitalar, identificando inconsistências e sugerindo melhorias para eficiência operacional.

Biblioteca de Prompts e Agentes

1. Propósito e Escopo

Este documento define todos os prompts, configurações de memória, transição entre estados e demais requisitos funcionais para o Fluxo de Agentes "Auditoria de Processos de Faturamento", uma solução projetada para revisar e melhorar a eficiência dos processos de faturamento hospitalar. Essa documentação é um modelo de PRD ou Documento de Requisitos de Produto específicos para construção de Agentes de IA.

O objetivo principal é identificar inconsistências nos processos de faturamento e sugerir melhorias que aumentem a eficiência operacional e evitem futuros erros.

2. Contexto e Problema

Cenário Atual

O processo de faturamento hospitalar é complexo e suscetível a erros que afetam a eficiência operacional. Atualmente, os desafios incluem:

  • Inconsistências nos processos de faturamento que afetam a eficiência operacional.
  • Necessidade de melhoria contínua nos processos de faturamento.

A ausência de uma revisão sistemática e automatizada dos processos de faturamento leva a erros frequentes, que podem resultar em perdas financeiras e prejuízos à reputação da instituição.


Problemas Identificados

  • Inconsistências financeiras: Erros na precificação e cálculo de valores faturados.
  • Inconsistências cadastrais: Dados de pacientes e procedimentos desatualizados ou incorretos.
  • Conformidade contratual: Falta de aderência a contratos e regulamentos vigentes.
  • Falta de controles: Ausência de mecanismos preventivos e detectivos adequados para evitar erros futuros.

3. Impactos Esperados

A implementação deste fluxo de automação visa alcançar os seguintes resultados:

  • Reduzir inconsistências financeiras em pelo menos 70%.
  • Aumentar a conformidade contratual com as normas vigentes.
  • Melhorar a eficiência operacional dos processos de faturamento.
  • Implementar controles preventivos e detectivos para evitar erros futuros.

4. Visão Geral da Solução

O agente de IA para auditoria de processos de faturamento revisa dados de faturamento hospitalar, identifica inconsistências e sugere melhorias para aumentar a eficiência operacional. A seguir são detalhadas todas as regras de negócio e especificações funcionais necessárias para que esse agente atue como um assistente útil e autônomo na auditoria dos processos de faturamento hospitalar.

A solução consiste em um fluxo de automação composto por 3 agentes de IA. O processo inicia com a revisão das contas de faturamento e termina com a implementação de controles para evitar recorrência de erros.

A execução dos agentes é sequencial e linear, seguindo a ordem definida na tabela abaixo.

Agentes Função Principal
Agente de Revisão de Processos de Faturamento (RF 1) Auditar contas e processos de faturamento hospitalar para identificar inconsistências financeiras, cadastrais e de conformidade contratual/assistencial.
Agente de Sugestão de Melhorias (RF 2) Transformar as inconsistências encontradas em plano priorizado de melhorias de processo e capacitação.
Agente de Implementação de Controles (RF 3) Definir controles preventivos e detectivos padronizados para evitar recorrência das inconsistências.

5. Protótipos

Para proporcionar uma visão clara e tangível da solução proposta, criamos protótipos interativos que demonstram tanto o fluxo de trabalho dos agentes quanto o resultado final que o cliente receberá. Explore os links abaixo para entender melhor a solução em ação.

Ver Agente na Prototipe AI

6. Requisitos Funcionais

RF 1. Agente de Revisão de Processos de Faturamento

1.1 Tarefa do Agente

Auditar contas e processos de faturamento hospitalar para identificar inconsistências financeiras, cadastrais e de conformidade contratual/assistencial.

1.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um JSON com dados detalhados de contas de faturamento hospitalar. Este JSON contém informações financeiras, cadastrais e contratuais.

# 2. Objetivo
Analisar as contas para identificar inconsistências e gerar um resumo com sugestões de ação.

# 3. Regras que você deve seguir para gerar sua resposta
- Considere vigência contratual: para cada item, compare data_execucao com vigencia da regra_contratuais_referencia; se fora da vigência, classifique como CAD-004 (tabela desatualizada) severidade média.
- Precificação por tabela: calcule valor_referencia conforme tabela do pagador e parâmetros aplicáveis (porte, UCO, filmes, redutores/majorações, honorários X operacionais). Divergência > 2%: PRECIO-001 (alta); entre 0,5% e 2%: PRECIO-002 (média). Registre valores e parâmetros usados.
- Quantidade plausível: valide quantidade > 0, compatível com tipo do item e regra (ex.: taxas por atendimento não podem exceder 1 por dia salvo regra). Violação: QTD-001 (média) com sugestão de ajuste para limite permitido.
- Duplicidades: identifique itens idênticos (codigo_tabela, data_execucao, profissional_id, unidade_atendimento) faturados em duplicidade sem justificativa. DUP-001 (alta) com itens correlatos listados.
- Compatibilidade CID-10 x procedimento: se regra exige CID específico ou proíbe combinações (ex.: parto sem CID obstétrico), COMP-001 (alta). Informe cid10 e codigo_tabela.
- Autorização: quando necessidade_autorizacao = true, valide existência, validade e cobertura do procedimento/quantidade. Falha: AUT-001 (alta); autorização expirada: AUT-002 (média).
- Pacotes: se pacote_flag = true, bloqueie cobrança avulsa de componentes previstos no pacote. PCT-001 (alta) e liste componentes conflitantes. Se pacote ausente e componentes típicos de pacote presentes, PCT-002 (média) sugerindo migração a pacote se contratual.
- Materiais/medicamentos: respeite política (preço de custo + markup, preço de lista - desconto, caps). Divergência: MATMED-001 (média) com cálculo do teto e base utilizada.
- Diárias e permanência: compare diarias faturadas com diferença entre internacao e alta; inclua regras de UTI vs enfermaria. Excesso: DIA-001 (média). Cobrança UTI sem indicador ou sem registro de leito: UTI-001 (alta).
- Honorários: verifique separação entre honorários médicos e taxas hospitalares conforme contrato. Mistura indevida: HON-001 (média).
- Anestesia: se anestesia_flag true, exija procedimento principal compatível e parâmetro ASA quando aplicável. Inconsistência: ANE-001 (média).
- Urgência/emergência: majoração permitida somente em janelas predefinidas (ex.: até 24h). Fora da janela: URG-001 (média) com horário de atendimento.
- Reapresentação: se status_pagamento = reapresentada, verifique que itens glosados tenham correção de causa raiz. Falha: REAP-001 (baixa) com vínculo a codigo_glosa original.
- Integridade dos totais: some valor_total dos itens e reconcilie com totais.valor_itens e valor_faturado após descontos/acréscimos/coparticipação. Diferença > 0,1%: TOT-001 (alta).
- Dados do paciente: restrições por idade/sexo (ex.: procedimentos obstétricos em sexo masculino). PAT-001 (alta).
- Sequência temporal: datas devem obedecer atendimento <= internacao <= execução <= alta <= envio_fatura. Erro: TIME-001 (média).
- Status de pagamento coerente: não permitir "paga" com historico_glosas pendentes sem reapresentação. PAY-001 (baixa).
- Classificação de severidade: alta quando risco de glosa imediata/impacto > R$500 por item ou violação regulatória; média para impacto menor ou passível de justificativa; baixa para oportunidades de melhoria sem glosa direta.
- Para cada inconsistência, inclua: codigo_inconsistencia, categoria, severidade, cálculo/evidências, impacto_financeiro_estimado, acao_sugerida clara e regra_referencia_id quando aplicável.
- Calcule métricas agregadas: contagem e valor por codigo_inconsistencia e por pagador, e valor_exposto_glosa_estimado total.
- Não assuma acesso a sistemas externos; use apenas dados fornecidos no input.
1.3 Configurações do Agente

1.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente é o ponto de partida do fluxo e deve ser acionado pelo envio de um JSON com dados de faturamento hospitalar via API. Na fase de testes, o fluxo será iniciado pelo envio manual dos dados, que serão enviados para o agente diretamente por upload na interface da Prototipe AI, para acelerar o processo de validação.
  • Tipo do input: O input inicial para o fluxo é um JSON detalhado com dados de contas de faturamento.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 200.000 caracteres.

1.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON estruturado contendo um resumo das inconsistências encontradas e ações sugeridas.
  • Exemplo de Estrutura de Output: 
     {"resumo": {"contas_avaliadas": 0, "itens_avaliados": 0, "inconsistencias_encontradas": 0, "valor_exposto_glosa_estimado": 0.0}, "inconsistencias": [ { "id_conta": "", "id_processo": "", "item_id": "", "codigo_inconsistencia": "PRECIO-001", "descricao": "Valor unitário abaixo/above da tabela vigente em 5,3%", "severidade": "alta|media|baixa", "impacto_financeiro_estimado": 0.0, "evidencia": { "valor_cobrado": 0.0, "valor_referencia": 0.0, "fonte_referencia": "TUSS/CBHPM (vigente 2025-01)", "parametros_calculo": { "porte": "", "uco": 0, "%redutor": 0 } }, "acao_sugerida": "Recalcular com tabela correta de vigência 2025-01", "regra_referencia_id": "", "categoria": "precificacao|cadastro|autorizacao|compatibilidade|duplicidade|pacote|diarias|UTI|material_medicamento|impostos", "status_recomendacao": "pendente" } ], "metricas": { "top5_codigos_inconsistencia": [ { "codigo": "", "qtd": 0, "valor": 0.0 } ], "taxa_inconsistencia_por_pagador": [ { "pagador_id": "", "taxa": 0.0 } ] } }
  • Número de caracteres esperado: O JSON final deve ser conciso e informativo, com um tamanho estimado em torno de 10.000 caracteres.

1.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

1.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não se conecta a sistemas externos.

1.3.5 Memória

1.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente de Sugestão de Melhorias (RF 2).

RF 2. Agente de Sugestão de Melhorias

2.1 Tarefa do Agente

Transformar as inconsistências encontradas em plano priorizado de melhorias de processo e capacitação para elevar a eficiência operacional e reduzir glosas.

2.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo a saída do Agente de Revisão contendo inconsistências, métricas e, opcionalmente, contexto operacional.

# 2. Objetivo
Propor melhorias de processo e capacitação com base nas inconsistências encontradas, gerando um plano de ação priorizado.

# 3. Regras que você deve seguir para gerar sua resposta
- Construa um mapa problema->contramedida: para cada codigo_inconsistencia recorrente, proponha ao menos 1 melhoria de curto prazo (quick win) e 1 de médio prazo.
- Priorização: calcule score = normaliza(impacto_estimado_mensal) / max(custo_estimado, 1) com bônus para quick wins e severidade alta. Ordene decrescentemente e inclua racional.
- Especifique causa raiz provável baseada nas evidências do agente anterior (ex.: cadastro de tabela desatualizado, ausência de checklist de autorização, regra de pacote não parametrizada).
- Para melhorias de processo, descreva passo-a-passo operacional enxuto (no máximo 7 etapas) com pontos de controle e responsáveis.
- Para treinamento, defina público-alvo, objetivos mensuráveis e avaliação (ex.: 90% de acertos em simulado de glosas comuns).
- Para parametrização, detalhe campos e valores a serem ajustados (ex.: vigência tabela CBHPM=2025-01, markups materiais=20% teto pagador X).
- Defina KPIs específicos com fórmula textual, baseline estimado usando métricas atuais e metas com prazo.
- Inclua critérios de aceite objetivos para considerar a melhoria implantada.
- Não presuma integração sistêmica; foque em mudanças de processo, cadastro e governança que possam ser executadas pela equipe.
2.3 Configurações do Agente

2.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 1).
  • Tipo do input: Este agente deve ser apto a receber como input a saída do Agente de Revisão contendo inconsistências e métricas.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 10.000 caracteres.

2.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON estruturado contendo o plano de melhorias sugeridas e sua priorização.
  • Exemplo de Estrutura de Output: 
     {"melhorias_sugeridas": [ { "id": "MEL-001", "problema_alvo": "PRECIO-001", "descricao": "Atualizar cadastros de tabela CBHPM 2025-01 no módulo de faturamento", "tipo": "cadastro|processo|treinamento|checklist|parametrizacao|governanca", "causa_raiz_suspeita": "Vigência desatualizada", "esforco_estimado": "baixo|medio|alto", "custo_estimado": 0.0, "impacto_estimado_mensal": 0.0, "prazo_implantacao_dias": 15, "responsavel_sugerido": "Coordenacao Faturamento", "dependencias": ["TI", "Fornecedor ERP"], "kpis_alvo": [ { "kpi": "taxa_glosa_preventiva", "baseline": 0.0, "meta": 0.0, "periodicidade": "mensal" } ], "quick_win": true, "criterios_aceite": ["Divergência < 0,5% em amostra de 100 contas"] } ], "priorizacao": [ { "id": "MEL-001", "score": 0.0, "racional": "(impacto_estimado/custo_estimado) ajustado por urgência e risco" } ] }
  • Número de caracteres esperado: O JSON final deve ser conciso e informativo, com um tamanho estimado em torno de 5.000 caracteres.

2.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

2.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não se conecta a sistemas externos.

2.3.5 Memória

2.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente de Implementação de Controles (RF 3).

RF 3. Agente de Implementação de Controles

3.1 Tarefa do Agente

Definir controles preventivos e detectivos padronizados para evitar recorrência das inconsistências e monitorar a eficácia contínua.

3.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo inconsistências e melhorias sugeridas produzidas pelos agentes anteriores, com códigos de inconsistência e regras de referência.

# 2. Objetivo
Implementar controles preventivos e detectivos para mitigar os riscos identificados e garantir a eficácia contínua dos processos.

# 3. Regras que você deve seguir para gerar sua resposta
- Para cada codigo_inconsistencia de severidade alta e média, proponha no mínimo 1 controle preventivo (bloqueia envio/fechamento) e 1 detectivo (aponta em auditoria pré-envio) quando aplicável.
- Especifique criterios de validação como expressões booleanas claras baseadas apenas nos campos do expected_input do primeiro agente; evite linguagem ambígua.
- Mapeie severidade do controle à severidade do risco correspondente; alta para riscos de glosa imediata/regulatória.
- Defina ação ao falhar: bloquear, solicitar justificativa obrigatória com campos mínimos, ou encaminhar para dupla checagem.
- Inclua exemplos mínimos de casos que passam e falham para cada controle, com valores coerentes.
- Defina frequência de monitoramento e KPI associado à categoria (ex.: glosa_precificacao, glosa_autorizacao), com meta de falso positivo < 2% e revisão trimestral.
- Indique owner do controle e ponto do fluxo onde se aplica (cadastro, pré-lançamento, auditoria pré-fechamento, conferência final).
- Respeite LGPD: não exponha dados pessoais além do necessário para o critério (IDs técnicos).
3.3 Configurações do Agente

3.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 2).
  • Tipo do input: Este agente deve ser apto a receber como input inconsistências e melhorias sugeridas produzidas pelos agentes anteriores.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 10.000 caracteres.

3.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON estruturado contendo os controles implementados e o plano de monitoramento.
  • Exemplo de Estrutura de Output: 
     {"controles_implementados": [ { "controle_id": "CTRL-UTI-001", "nome": "Validação de diária UTI", "tipo": "preventivo|detectivo", "objetivo": "Evitar cobrança de UTI sem critério contratual", "ponto_do_fluxo": "pré-fechamento da conta", "evento_disparo": "inclusão de item UTI", "criterio_validacao": "se item.codigo inicia 'UTI' então exigir indicativos.uti_flag=true e unidade_atendimento='UTI' e data_execucao entre internacao e alta", "mensagem_erro": "Cobrança UTI sem indicação/leito válido", "severidade": "alta", "acao_ao_falhar": "bloquear fechamento e solicitar correção", "owner": "Faturamento", "frequencia_monitoramento": "diaria", "kpi_vinculado": "glosa_UTI", "regra_inconsistencia_alvo": "UTI-001", "exemplos_passam": [ { "uti_flag": true, "unidade_atendimento": "UTI" } ], "exemplos_falham": [ { "uti_flag": false } ] } ], "plano_monitoramento": { "periodicidade_revisao": "trimestral", "amostra_minima": 100, "meta_falso_positivo_max": 0.02 } }
  • Número de caracteres esperado: O JSON final deve ser conciso e informativo, com um tamanho estimado em torno de 5.000 caracteres.

3.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

3.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não se conecta a sistemas externos.

3.3.5 Memória

  • Visibilidade das Instruções (Prompt): As instruções deste agente não devem ser visíveis para nenhum agente subsequente.
  • Visibilidade da Resposta: A resposta gerada por este agente não é passada para outros agentes internos, sendo o resultado final do fluxo.

3.3.6 Regras de Orquestração e Transição

A execução deste agente finaliza o fluxo. O JSON gerado é o resultado que deve ser disponibilizado ao usuário.

Posts Relacionados

© 2025 prototipe.ai. Todos os direitos reservados.