Agente de IA para Gerenciamento de Autorizações de Procedimentos

30 de November de 2025 • Tempo de leitura: 5 min

Como criar um agente de IA que verifica e gerencia autorizações de procedimentos médicos.

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 agente de IA "Gerenciamento de Autorizações de Procedimentos", que visa automatizar a verificação e gerenciamento de autorizações de procedimentos médicos, garantindo que todo o processo de autorização seja eficiente e documentado corretamente. 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 é reduzir atrasos e erros no processo de autorização de procedimentos médicos, além de assegurar a documentação adequada das autorizações para fins de conformidade.

2. Contexto e Problema

Cenário Atual

O processo de autorização de procedimentos médicos em muitas instituições de saúde enfrenta desafios significativos, incluindo:

  • Atrasos na aprovação de autorizações devido a verificações manuais demoradas.
  • Erros frequentes na documentação das autorizações, levando a problemas de conformidade.

Esses problemas não apenas afetam a eficiência operacional, mas também podem levar a complicações legais e financeiras para as instituições de saúde.


Problemas Identificados

  • Ineficiência: Processos manuais são demorados e propensos a erros humanos, resultando em atrasos na aprovação de autorizações.
  • Problemas de Conformidade: A documentação inadequada das autorizações pode levar a não conformidades e penalidades.

3. Impactos Esperados

A implementação deste agente de IA visa alcançar os seguintes resultados:

  • Aumentar a eficiência do processo de autorização em pelo menos 70%.
  • Reduzir erros na documentação de autorizações em 90%.
  • Garantir conformidade com as regulamentações de documentação de autorizações.

4. Visão Geral da Solução

O agente de IA para gerenciamento de autorizações de procedimentos verifica automaticamente as autorizações necessárias, documenta cada etapa do processo e garante que todas as conformidades sejam atendidas. 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 eficaz e autônomo no gerenciamento de autorizações médicas.

A solução consiste em um fluxo de automação composto por 6 agentes de IA. O processo inicia com a preparação da verificação de autorização e termina com a geração de documentos de conformidade e apelações, quando necessário.

A execução dos agentes é sequencial e linear, seguindo a ordem definida na tabela abaixo. O fluxo inclui etapas condicionais que são executadas apenas se critérios específicos forem atendidos, conforme detalhado após a tabela.

Agentes Função Principal
Agente de Preparação de Verificação de Autorização (RF 1) Consolidar o pedido de autorização e preparar o payload para consulta no sistema de autorizações.
Agente de Execução de Chamada à API do Sistema de Autorizações (RF 2) Realizar chamada à API do Sistema de Autorizações para verificar status e gerar número de autorização.
Agente de Tratamento e Normalização da Resposta de Autorização (RF 3) Tratar a resposta da API, normalizar status e atualizar o checklist de conformidade.
Agente de Geração de Dossiê de Autorização e Registro de Conformidade (RF 4) Produzir o dossiê de autorização para conformidade e auditoria.
Agente de Geração de Solicitação de Documentos (RFI) para Autorização Pendente Agente Condicionado (RF 5) Gerar checklist e mensagem para solicitar documentos adicionais quando a autorização estiver pendente.
Agente de Geração de Carta de Recurso/Apelação para Negativa Agente Condicionado (RF 6) Produzir minuta de apelação técnica quando a autorização for negada.


Regras de Execução Condicional ou Edges

  • Ativação do Agente de Geração de Solicitação de Documentos (RFI) para Autorização Pendente (RF 5): Este agente só será executado se a propriedade "status_requires_additional_docs" do objeto JSON gerado pelo Agente de Tratamento e Normalização da Resposta de Autorização (RF 3) for true.
  • Ativação do Agente de Geração de Carta de Recurso/Apelação para Negativa (RF 6): Este agente só será executado se a propriedade "authorization_denied" do objeto JSON gerado pelo Agente de Tratamento e Normalização da Resposta de Autorização (RF 3) for true.

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 Preparação de Verificação de Autorização

1.1 Tarefa do Agente

Consolidar o pedido de autorização e preparar, em JSON, o payload para consulta no sistema de autorizações e a matriz de checagens de conformidade.

1.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um objeto JSON com os dados do pedido de autorização. Este objeto contém informações detalhadas sobre o paciente, prestador e procedimentos solicitados.

# 2. Objetivo
Consolidar as informações recebidas e preparar o payload para consulta no sistema de autorizações, além de criar uma matriz de checagens de conformidade.

# 3. Regras que você deve seguir para gerar sua resposta
- Validar presença mínima dos campos obrigatórios: id_pedido, paciente.id, paciente.plano, prestador.id, ao menos 1 procedimento com tuss e quantidade ≥ 1, contexto_atendimento e justificativa_clinica. Se algum estiver ausente, preencher com null no payload_api e manter o campo existente na estrutura sem criar novos campos.
- Normalizar datas de entrada (data_nascimento, data_solicitacao) para ISO 8601 (YYYY-MM-DD) e mapear contexto_atendimento para contexto esperado pela API: ambulatorial→"AMBULATORIAL", hospitalar→"HOSPITALAR", internacao→"INTERNACAO". Sexo deve ser mapeado para "M", "F" ou "O" quando necessário, sem alterar a estrutura do payload.
- Deduplicar procedimentos por TUSS (case-insensitive, ignorando zeros à esquerda) somando quantidade como inteiro positivo; se quantidade não for número inteiro positivo, definir 1 como padrão. Preservar ordem de primeira ocorrência da TUSS.
- Montar payload_api apenas com os campos especificados, renomeando: paciente.id→beneficiario_id; prestador.id→prestador_id; contexto_atendimento→contexto; justificativa_clinica→justificativa; procedimentos[].quantidade→procedimentos[].qtd; diagnósticos ausentes devem resultar em lista vazia.
- Construir checklist_conformidade inicial exatamente com os quatro itens: elegibilidade_beneficiario, cobertura_procedimento, requisitos_pre_autorizacao, documentacao_obrigatoria, todos com status_inicial="pendente".
- Preencher metadados com id_pedido do input e data_preparacao como timestamp UTC ISO 8601 com segundos.
- Não incluir comentários, textos livres ou chaves adicionais fora da estrutura definida em expected_output. Retornar somente o JSON especificado.
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 objeto JSON com os dados do pedido de autorização 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 do JSON na interface da Prototipe AI, para acelerar o processo de validação.
  • Tipo do input: O input inicial para o fluxo é um objeto JSON com dados estruturados do pedido de autorização.
  • 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.

1.3.2 Especificação do Output

  • Formato de output: O output deve ser um objeto JSON contendo o payload para a API e a matriz de checagens de conformidade.
  • Exemplo de Estrutura de Output: 
     {"payload_api":{"id_pedido":"string","beneficiario_id":"string","plano":"string","prestador_id":"string","procedimentos":[{"tuss":"string","qtd":1}],"contexto":"string","justificativa":"string","diagnosticos":["string"]},"checklist_conformidade":[{"item":"elegibilidade_beneficiario","status_inicial":"pendente"},{"item":"cobertura_procedimento","status_inicial":"pendente"},{"item":"requisitos_pre_autorizacao","status_inicial":"pendente"},{"item":"documentacao_obrigatoria","status_inicial":"pendente"}],"metadados":{"id_pedido":"string","data_preparacao":"YYYY-MM-DDTHH:MM:SSZ"}}
  • Número de caracteres esperado: O JSON final deve ser conciso e informativo, com um tamanho estimado em torno de 2.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 Execução de Chamada à API do Sistema de Autorizações (RF 2).

RF 2. Agente de Execução de Chamada à API do Sistema de Autorizações

2.1 Tarefa do Agente

Realizar chamada à API do Sistema de Autorizações para verificar status, exigências e gerar número de autorização quando aplicável.

2.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um objeto JSON pronto para execução contendo payload_api e metadados. Este objeto contém todas as informações necessárias para a chamada à API do Sistema de Autorizações.

# 2. Objetivo
Realizar a chamada à API do Sistema de Autorizações e retornar os dados brutos obtidos.

# 3. Regras que você deve seguir para gerar sua resposta
- Esse agente não precisa de instruções para chamadas ao LLM, pois sua única função é executar a chamada à API cujo payload ele já recebe pronto.
- Após a execução da chamada, o agente deve retornar os dados brutos conforme recebido da API.
- Em caso de falha na chamada da API, registrar o erro para análise manual.
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 um objeto JSON contendo payload_api e metadados.
  • 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é 5.000 caracteres.

2.3.2 Especificação do Output

  • Formato de output: O output deve ser um objeto JSON com os dados brutos retornados pela API do Sistema de Autorizações.
  • Exemplo de Estrutura de Output: 
     {"status":"approved|pended|denied","auth_number":"string opcional","valid_from":"YYYY-MM-DD","valid_to":"YYYY-MM-DD","coparticipacao":"number opcional","exigencias":[{"tipo":"documento","descricao":"Laudo atualizado"}],"motivos":["string"],"raw":{...}}
  • Número de caracteres esperado: O JSON final terá um tamanho aproximado de 1.500 caracteres.

2.3.3 Parâmetros de Geração

  • Modelo: Não se aplica (uso de ferramenta)
  • Temperatura: Não se aplica (uso de ferramenta)

2.3.4 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: O agente deverá enviar o JSON recebido para a API externa e retornar o JSON recebido como resposta.

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 Tratamento e Normalização da Resposta de Autorização (RF 3).

RF 3. Agente de Tratamento e Normalização da Resposta de Autorização

3.1 Tarefa do Agente

Tratar a resposta bruta da API, normalizar status e atualizar o checklist de conformidade com base nas exigências retornadas.

3.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um objeto JSON com o retorno da API de autorizações e o checklist inicial. Este objeto contém informações sobre o status da autorização e exigências adicionais.

# 2. Objetivo
Tratar e normalizar a resposta da API, atualizar o checklist de conformidade e identificar sinais para o fluxo seguinte.

# 3. Regras que você deve seguir para gerar sua resposta
- Normalizar o status técnico para a taxonomia: approved→"aprovado"; pended|pending|additional_info→"pendente"; denied→"negado". Se status não reconhecido, definir "pendente" e prosseguir com extração.
- Extrair auth_number quando presente; vigência: mapear valid_from→vigencia.inicio e valid_to→vigencia.fim no formato YYYY-MM-DD; se ausentes, manter campos vazios (null/strings vazias conforme estrutura). coparticipacao: se não numérico, deixar ausente ou 0 conforme a estrutura prevista.
- Atualizar checklist_atualizado: 
  - elegibilidade_beneficiario="ok" quando a resposta indicar beneficiário ativo/elegível; "falha" quando inelegível/expirado; caso não informado, "pendente".
  - cobertura_procedimento="ok" quando a resposta indicar cobertura autorizada para todos os TUSS solicitados; "falha" quando apontar exclusão de cobertura; sem indicação explícita, "pendente".
  - requisitos_pre_autorizacao="pendente" sempre que houver exigência processual (ex.: auditoria médica, guia específica); "ok" quando explicitamente dispensado/atendido; "falha" quando explicitamente não atendido.
  - documentacao_obrigatoria="pendente" quando houver qualquer exigência de documentos; "ok" se nenhuma exigência; "falha" quando documento requerido foi indicado como não conforme.
- Popular exigencias convertendo cada exigência da API em detalhe acionável, mantendo foco no que falta (ex.: "Laudo médico assinado ≤ 30 dias com CID"). Se API trouxer motivos sem exigências e status for negado, não criar exigencias por inferência.
- Definir sinais_para_fluxo.status_requires_additional_docs=true se existir ao menos uma exigência de documento/informação adicional. Caso contrário, false.
- Definir sinais_para_fluxo.authorization_denied=true quando status normalizado for "negado"; caso contrário, false.
- Preservar metadados.id_pedido em resumo_normalizado.id_pedido. Não adicionar chaves fora da estrutura de expected_output.
- Conteúdo textuais devem ser objetivos, sem opiniões ou promessas de aprovação. Priorizar termos de conformidade e auditabilidade.
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 um objeto JSON com retorno da API de autorizações e checklist inicial.
  • 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é 8.000 caracteres.

3.3.2 Especificação do Output

  • Formato de output: O output deve ser um objeto JSON contendo o resumo normalizado, checklist atualizado e sinais para o fluxo.
  • Exemplo de Estrutura de Output: 
     {"resumo_normalizado":{"id_pedido":"string","status":"aprovado|pendente|negado","auth_number":"string opcional","vigencia":{"inicio":"YYYY-MM-DD","fim":"YYYY-MM-DD"},"coparticipacao":0},"exigencias":[{"item":"documentacao_obrigatoria","detalhe":"Laudo atualizado"}],"checklist_atualizado":[{"item":"elegibilidade_beneficiario","status":"ok|falha|pendente"},{"item":"cobertura_procedimento","status":"ok|falha|pendente"},{"item":"requisitos_pre_autorizacao","status":"ok|falha|pendente"},{"item":"documentacao_obrigatoria","status":"ok|falha|pendente"}],"sinais_para_fluxo":{"status_requires_additional_docs":false,"authorization_denied":false}}
  • Número de caracteres esperado: O JSON final terá um tamanho aproximado de 2.500 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.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

3.3.5 Memória

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

Ao concluir sua execução, esse agente aciona o Agente de Geração de Dossiê de Autorização e Registro de Conformidade (RF 4).

RF 4. Agente de Geração de Dossiê de Autorização e Registro de Conformidade

4.1 Tarefa do Agente

Produzir o dossiê de autorização para conformidade e auditoria, consolidando status, número da autorização, vigência, exigências e checklist final.

4.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um objeto JSON com resumo_normalizado, checklist_atualizado, exigencias e metadados do pedido. Este objeto contém todas as informações necessárias para a geração do dossiê de autorização.

# 2. Objetivo
Produzir um dossiê de autorização completo e detalhado para fins de conformidade e auditoria.

# 3. Regras que você deve seguir para gerar sua resposta
- Preencher auditoria com valores provenientes de resumo_normalizado e checklist_atualizado, copiando os itens sem alterar nomenclaturas. Timestamp em UTC ISO 8601 com segundos.
- No dossie_markdown, apresentar: identificação (id_pedido e data de preparação se disponível nos metadados), status, número de autorização (ou "não informado"), vigência (inicio e fim, ou "não informado"), coparticipação (ou "não informado"), checklist (um item por linha com status) e exigências listadas.
- Quando um campo estiver ausente ou nulo, escrever literalmente "não informado" no markdown; não introduzir esse rótulo no JSON de auditoria.
- Manter a fidelidade aos dados; não inferir auth_number, vigência ou coparticipação quando ausentes.
- Linguagem neutra e técnica; evitar julgamentos. O objetivo é garantir documentação adequada para conformidade, com trilha de auditoria completa.
4.3 Configurações do Agente

4.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 3).
  • Tipo do input: Este agente deve ser apto a receber como input um objeto JSON com resumo_normalizado, checklist_atualizado, exigencias e metadados do pedido.
  • 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.

4.3.2 Especificação do Output

  • Formato de output: O output deve ser um objeto JSON contendo a auditoria e o dossiê em formato Markdown.
  • Exemplo de Estrutura de Output: 
     {"auditoria":{"id_pedido":"string","timestamp":"YYYY-MM-DDTHH:MM:SSZ","status":"aprovado|pendente|negado","auth_number":"string opcional","vigencia":{"inicio":"YYYY-MM-DD","fim":"YYYY-MM-DD"},"coparticipacao":0,"checklist":[{"item":"string","status":"ok|falha|pendente"}],"exigencias":[{"detalhe":"string"}]},"dossie_markdown":"# Dossiê de Autorização\n\n## Identificação do Pedido\n- ID: ...\n- Data: ...\n\n## Status da Autorização\n- Status: ...\n- Nº Autorização: ...\n- Vigência: ... a ...\n- Coparticipação: ...\n\n## Checklist de Conformidade\n- Elegibilidade: ...\n- Cobertura: ...\n- Requisitos de Pré-autorização: ...\n- Documentação Obrigatória: ...\n\n## Exigências/Observações\n- ...\n\n## Rastreabilidade\n- Fonte: Sistema de Autorizações\n- Gerado por: Agentes de IA\n- Protocolo: ..."}
  • Número de caracteres esperado: O JSON final terá um tamanho aproximado de 3.500 caracteres.

4.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

4.3.4 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

4.3.5 Memória

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

Ao concluir sua execução, esse agente não aciona diretamente o próximo agente, pois o fluxo depende dos sinais definidos pelo Agente de Tratamento e Normalização da Resposta de Autorização (RF 3).

RF 5. Agente de Geração de Solicitação de Documentos (RFI) para Autorização Pendente Agente Condicionado

5.1 Tarefa do Agente

Gerar checklist detalhado e mensagem padrão para solicitar documentos/informações adicionais quando a autorização estiver pendente.

5.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um objeto JSON com exigencias, resumo_normalizado (status pendente) e dados mínimos do pedido. Este objeto contém informações sobre as exigências de documentos adicionais.

# 2. Objetivo
Gerar um checklist detalhado e uma mensagem padrão para solicitar documentos/informações adicionais necessários.

# 3. Regras que você deve seguir para gerar sua resposta
- Converter cada exigência em um item objetivo do rfi_checklist, com título curto (item) e descricao acionável que inclua requisitos mínimos como assinatura, data máxima (ex.: ≤ 30 dias), identificação do paciente e correlação com procedimento/diagnóstico quando aplicável.
- A mensagem_markdown deve ser direcionada ao responsável adequado (prestador ou central, se informado), conter: saudação, contexto do pedido (ID), lista de documentos solicitados em bullets, orientação de envio (placeholder de canal) e prazo sugerido em dias úteis (sem datas específicas), mantendo tom profissional e de conformidade.
- Em orientacoes_internas, instruir a equipe a: registrar a tarefa no sistema interno, definir SLA padrão (por exemplo, 2 dias úteis) e atualizar o status do caso para "Aguardando Documentação". Não adicionar dados fora do campo definido.
- Não prometer aprovação; evitar linguagem coercitiva. Deixar explícito que a análise será retomada após o recebimento integral da documentação.
- Retornar somente as chaves definidas em expected_output, sem adicionar campos extras.
5.3 Configurações do Agente

5.3.1 Condições de Ativação

Este agente é acionado somente se a seguinte condição for atendida:

5.3.2 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado condicionalmente após a conclusão do agente anterior (RF 4), apenas se a condição de ativação for atendida.
  • Tipo do input: Este agente deve ser apto a receber como input um objeto JSON com exigencias, resumo_normalizado e dados mínimos do pedido.
  • 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é 7.000 caracteres.

5.3.3 Especificação do Output

  • Formato de output: O output deve ser um objeto JSON contendo o checklist detalhado e a mensagem padrão em Markdown para solicitação de documentos.
  • Exemplo de Estrutura de Output: 
     {"rfi_checklist":[{"item":"string","descricao":"string"}],"mensagem_markdown":"Prezado(a) ... segue a relação de documentos necessários: ...","orientacoes_internas":"Texto curto com instruções operacionais para a equipe."}
  • Número de caracteres esperado: O JSON final terá um tamanho aproximado de 2.000 caracteres.

5.3.4 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

5.3.5 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

5.3.6 Memória

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

Ao concluir sua execução, esse agente não aciona diretamente o próximo agente, pois o fluxo depende dos sinais definidos pelo Agente de Tratamento e Normalização da Resposta de Autorização (RF 3).

RF 6. Agente de Geração de Carta de Recurso/Apelação para Negativa Agente Condicionado

6.1 Tarefa do Agente

Produzir minuta de apelação técnica quando a autorização for negada, com base na justificativa clínica e nos motivos da negativa.

6.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um objeto JSON com resumo_normalizado (status negado), motivos da negativa, justificativa_clinica e dados do paciente/procedimentos. Este objeto contém informações necessárias para a elaboração de uma apelação técnica.

# 2. Objetivo
Produzir uma minuta de apelação técnica para reconsideração da autorização negada, utilizando as informações fornecidas.

# 3. Regras que você deve seguir para gerar sua resposta
- Sintetizar os motivos da negativa utilizando a terminologia fornecida pela resposta (ex.: "ausência de cobertura contratual", "informação insuficiente"), sem emitir juízo de valor.
- Na Fundamentação Técnica, relacionar a justificativa_clinica a critérios gerais de necessidade médica (ex.: falha terapêutica prévia, guideline clínico genérico, risco-benefício, evidência clínica usual), sem citar normas proprietárias ou fontes específicas.
- No Pedido, listar explicitamente os procedimentos por TUSS e descrição, solicitando reconsideração da autorização. Se algum dado estiver ausente, escrever "não informado" na seção do markdown correspondente.
- Em Anexos Sugeridos, propor documentos pertinentes ao caso (laudo médico atualizado, exames comprobatórios, evolução clínica, formulários específicos), mantendo foco na completude documental para conformidade.
- Preencher resumo_apelacao com id_pedido, status_atual="negado" e itens_chave com até 3 bullets objetivos (ex.: "justificativa clínica alinhada à necessidade médica", "documentos adicionais sugeridos"). Não criar chaves além das previstas em expected_output.
6.3 Configurações do Agente

6.3.1 Condições de Ativação

Este agente é acionado somente se a seguinte condição for atendida:

6.3.2 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado condicionalmente após a conclusão do agente anterior (RF 4), apenas se a condição de ativação for atendida.
  • Tipo do input: Este agente deve ser apto a receber como input um objeto JSON com resumo_normalizado, motivos da negativa, justificativa_clinica e dados do paciente/procedimentos.
  • 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é 9.000 caracteres.

6.3.3 Especificação do Output

  • Formato de output: O output deve ser um objeto JSON contendo a minuta de apelação em Markdown e um resumo da apelação.
  • Exemplo de Estrutura de Output: 
     {"apelacao_markdown":"# Carta de Recurso\n\n## Identificação\n- Pedido: ...\n- Paciente: ...\n- Prestador: ...\n\n## Resumo da Negativa\n- Motivos alegados: ...\n\n## Fundamentação Técnica\n- Indicação clínica: ...\n- Diretrizes/boas práticas (genéricas): ...\n\n## Pedido\n- Reconsideração da autorização para os procedimentos: ...\n\n## Anexos Sugeridos\n- ...","resumo_apelacao":{"id_pedido":"string","status_atual":"negado","itens_chave":["string"]}}
  • Número de caracteres esperado: O JSON final terá um tamanho aproximado de 3.000 caracteres.

6.3.4 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

6.3.5 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

6.3.6 Memória

  • Visibilidade das Instruções (Prompt): As instruções não são visíveis para agentes subsequentes.
  • Visibilidade da Resposta: A resposta (JSON da apelação) é o entregável final e não é passada para outros agentes internos.

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

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

Posts Relacionados

© 2025 prototipe.ai. Todos os direitos reservados.