Agente de IA para Gestão de Recursos de Apoio Diagnóstico

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

Como criar um agente de IA que otimiza o uso de recursos de apoio diagnóstico, como agendamento de exames e manutenção de equipamentos.

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 "Gestão de Recursos de Apoio Diagnóstico", uma solução de automação projetada para otimizar o uso de recursos de apoio diagnóstico, como agendamento de exames e manutenção de equipamentos. 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 é implementar algoritmos de otimização para garantir o agendamento eficiente dos recursos diagnósticos e criar um sistema de monitoramento para alertar sobre a necessidade de manutenção preventiva dos equipamentos, melhorando a eficiência operacional.

2. Contexto e Problema

Cenário Atual

As instituições de saúde enfrentam desafios significativos na gestão de seus recursos diagnósticos. Problemas comuns incluem:

  • Ineficiências no agendamento de exames que podem causar atrasos ou subutilização dos recursos diagnósticos.
  • Falta de manutenção preventiva em equipamentos que pode levar a falhas ou indisponibilidade.

Problemas Identificados

  • Agendamento Ineficiente: A falta de um sistema otimizado para agendamento resulta em subutilização dos equipamentos e longos tempos de espera para os pacientes.
  • Manutenção Deficiente: A ausência de um programa estruturado de manutenção preventiva aumenta o risco de falhas e paralisações inesperadas.

3. Impactos Esperados

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

  • Melhorar a eficiência do agendamento de exames, maximizando a utilização dos recursos diagnósticos.
  • Reduzir o tempo de inatividade dos equipamentos através de manutenção preventiva regular.
  • Aumentar a satisfação dos pacientes ao diminuir os tempos de espera para exames.
  • Minimizar riscos de falhas nos equipamentos críticos para o diagnóstico médico.

4. Visão Geral da Solução

O agente de IA para gestão de recursos de apoio diagnóstico otimiza o agendamento de exames e implementa um sistema de monitoramento para manutenção preventiva de equipamentos. 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 gestão eficiente de recursos diagnósticos.

A solução consiste em um fluxo de automação composto por 2 agentes de IA. O processo inicia com a otimização do agendamento de exames e termina com a geração de alertas e planos propositivos para manutenção dos equipamentos.

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

Agentes Função Principal
Agente de Otimização de Agendamento de Exames (RF 1) Gerar uma grade de agendamento que maximize a utilização de recursos diagnósticos.
Agente de Monitoramento de Manutenção de Equipamentos (RF 2) Gerar alertas e planos de manutenção preventiva para equipamentos.

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.

6. Requisitos Funcionais

RF 1. Agente de Otimização de Agendamento de Exames

1.1 Tarefa do Agente

Gerar uma grade de agendamento factível e priorizada que maximize a utilização de recursos diagnósticos sem violar restrições operacionais, clínicas e de equipe.

1.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo dados estruturados sobre recursos diagnósticos, exames solicitados e disponibilidade de equipe.

# 2. Objetivo
Gerar uma grade de agendamento que maximize a utilização de recursos diagnósticos.

# 3. Regras que você deve seguir para gerar sua resposta
- Trate como hard constraints: (1) nenhum equipamento ou técnico alocado em sobreposição de horários; (2) respeitar janelas_disponiveis e indisponibilidades; (3) cumprir requisitos de modalidade e nível de habilidade do técnico; (4) inserir tempos de setup e limpeza entre exames do mesmo equipamento; (5) aplicar buffer_min entre slots quando indicado por politicas.buffer_min; (6) não ultrapassar carga_max_diaria_min e pausas_min por técnico.
- Priorize conforme politicas.regras_prioridade. Em empates, aplique desempates na ordem definida (mais_antigo, menor_deslocamento).
- Cumprimento de SLA: classifique cada solicitação e posicione em janela que atenda SLA correspondente; se impossível, marque violacao_SLA e mova para nao_alocados com motivo 'fora_SLA'.
- Overbooking: somente se overbooking_permitido=true e limitado a taxa_overbooking_max_porcent por equipamento por período; nunca para exames com contraste ou que exijam sedação.
- Agrupamento operacional: quando possível, agrupe exames de mesma modalidade sequencialmente em um equipamento para reduzir tempos de setup; não force agrupamento se causar violação de SLA.
- Restrições do paciente: aloque MRI para pacientes com claustrofobia em equipamentos abertos quando disponíveis; contraste requer técnico habilitado e janela extra de observação de 15 min.
- Turnos e pausas: insira pausas automáticas a cada 6 horas de trabalho por técnico e encerre alocação no fim do turno.
- Ajustes finos: utilize janelas preferidas do paciente apenas como soft constraint; minimize tempo ocioso do equipamento e tempo de espera do paciente, nesta ordem.
- Integridade do output: para cada slot, preencha buffers_aplicados; para cada nao_alocado, preencha motivo_code e detalhe objetivo; compute indicadores conforme definições e defina factibilidade em função de violacoes_SLA e nao_alocados (>0 e prioridade alta indica 'parcial' ou 'inviavel').
- Não crie novos campos além dos descritos; se um dado de entrada essencial estiver ausente, retorne agenda_gerada vazia, factibilidade='inviavel' e detalhe quais campos faltaram nas observacoes_normatizadas. 
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 dados estruturados 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 de um arquivo na interface da Prototipe AI, para acelerar o processo de validação.
  • Tipo do input: O input inicial para o fluxo é um conjunto de dados estruturados, incluindo informações sobre recursos diagnósticos, exames e disponibilidade de equipe.
  • Formatos Suportados: Esse agente deve ser capaz de receber dados nos formatos: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de dados estruturados com até 50.000 caracteres.

1.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON estruturado com a grade de agendamento, incluindo slots alocados e não alocados, além de indicadores de performance.
  • Exemplo de Estrutura de Output:
     {
      "agenda_gerada": [
        {
          "slot_id": "1",
          "solicitacao_id": "123",
          "equipamento_id": "MRI-01",
          "tecnico_id": "T-001",
          "inicio": "2025-12-16T08:00:00",
          "fim": "2025-12-16T08:45:00",
          "modalidade": "MRI",
          "prioridade": "urgente",
          "buffers_aplicados": { "setup_min": 5, "limpeza_min": 5 },
          "justificativas": ["optimizacao_recursos"]
        }
      ],
      "nao_alocados": [
        {
          "solicitacao_id": "124",
          "motivo_code": "sem_recurso_compativel",
          "detalhes": "Equipamento necessário indisponível"
        }
      ],
      "indicadores": {
        "utilizacao_porcent": 85,
        "tempo_medio_espera_min": 30,
        "conflitos_detectados": 0,
        "conflitos_resolvidos": 0,
        "violacoes_SLA": 1,
        "taxa_overbooking_porcent": 5
      },
      "factibilidade": "factivel",
      "observacoes_normatizadas": [
        { "code": "dados_incompletos", "descricao": "Informações de equipe incompletas" }
      ]
    } 
  • Número de caracteres esperado: O JSON final será denso, com um tamanho mínimo esperado de 5.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 Monitoramento de Manutenção de Equipamentos (RF 2).

RF 2. Agente de Monitoramento de Manutenção de Equipamentos

2.1 Tarefa do Agente

Gerar alertas e plano propositivo de manutenção preventiva e calibração para maximizar disponibilidade e reduzir risco de falha, respeitando janelas operacionais e criticidade clínica.

2.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo dados estruturados sobre equipamentos diagnósticos e suas necessidades de manutenção.

# 2. Objetivo
Gerar alertas e plano propositivo de manutenção preventiva para maximizar disponibilidade dos equipamentos.

# 3. Regras que você deve seguir para gerar sua resposta
- Cálculo de vencimento: derive dias_para_preventiva a partir de limites_fabricante (menor entre horas convertidas em dias via media_diaria_horas, ciclos e dias). Se dias_para_preventiva <= 0, classifique como 'preventiva_vencida'; se <= thresholds_severidade.critico_dias, severidade='alta'; se <= atencao_dias, severidade='media'; caso contrário, 'baixa'. Aplique mesma lógica para calibração.
- MTBF: calcule MTBF_atual com base em historico_falhas; se tempo desde a última falha > MTBF_atual*1.2, não gere alerta de risco; se < MTBF_atual*0.8, gere 'risco_falha' severidade proporcional à criticidade e frequência de falhas.
- Janela sugerida: proponha data_sugerida dentro de janelas_operacionais e fora de picos (use janela_preferencial de politicas). Se não houver janelas suficientes, retorne plano com 'justificativa: sem_janela_suficiente' e recomende redistribuição de exames.
- Consolidação: se politicas.consolidacao_por_local=true, agrupe intervenções em equipamentos do mesmo local dentro de antecipacao_max_dias para reduzir paradas múltiplas, sem ultrapassar limites de vencimento.
- Criticidade: priorize modalidades com maior criticidade e equipamentos marcados como 'alta'. Nunca proponha manutenção simultânea de todos os equipamentos de mesma modalidade e local.
- Estimativa de parada: use histórico de tempo_parada_min por tipo; se ausente, default preventiva=120, calibracao=60.
- Integridade: cada alerta deve ter motivo_code coerente com o limite violado; preencha janela_preferencial combinando janelas_operacionais com politicas.janela_preferencial; calcule indicadores conforme dados; classifique risco_indisponibilidade combinando severidade média ponderada pela criticidade e número de equipamentos substitutos (se único no local e severidade alta recorrente, risco='alto').
- Conflitos: se data_sugerida colidir com indisponibilidades conhecidas (quando informadas), ajuste dentro de antecipacao_max_dias; se inviável, marque alerta com observacao 'necessita_replanejamento_operacional'.
- Não crie novos campos além dos descritos; quando dados essenciais faltarem (limites_fabricante ausentes), marque severidade='media', motive com 'dados_incompletos' e inclua em observacoes_normatizadas os campos faltantes. 
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 dados estruturados sobre equipamentos diagnósticos e suas necessidades de manutenção.
  • Formatos Suportados: Esse agente deve ser capaz de receber dados nos formatos: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de dados estruturados com até 50.000 caracteres.

2.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON estruturado com alertas de manutenção e planos propositivos, incluindo detalhes de intervenções e indicadores de risco.
  • Exemplo de Estrutura de Output:
     {
      "alertas": [
        {
          "equipamento_id": "MRI-01",
          "tipo_alerta": "preventiva_programar",
          "severidade": "alta",
          "motivo_code": "limite_dias",
          "data_sugerida": "2025-12-20",
          "janela_preferencial": [
            { "inicio": "08:00", "fim": "12:00" }
          ],
          "tempo_parada_estimado_min": 120,
          "itens_recomendados": ["Calibração", "Limpeza"]
        }
      ],
      "plano_manutencao_proposto": [
        {
          "equipamento_id": "MRI-01",
          "intervencoes": [
            {
              "tipo": "preventiva",
              "data_sugerida": "2025-12-20",
              "janela_preferencial": [
                { "inicio": "08:00", "fim": "12:00" }
              ],
              "justificativas": ["optimizacao_recursos"]
            }
          ]
        }
      ],
      "indicadores": {
        "cobertura_preventiva_porcent": 90,
        "backlog_itens": 5,
        "risco_indisponibilidade": "medio",
        "MTBF_atual_dias": 30.5
      },
      "observacoes_normatizadas": [
        { "code": "dados_incompletos", "descricao": "Informações de limites de fabricante ausentes" }
      ]
    } 
  • Número de caracteres esperado: O JSON final será denso, com um tamanho mínimo esperado 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

  • 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 é o entregável final e não é passada para outros agentes internos.

2.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.

© 2025 prototipe.ai. Todos os direitos reservados.