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
- 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 deve ser visível para o Agente de Monitoramento de Manutenção de Equipamentos (RF 2).
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.