Agente de IA para Monitoramento de Sinais Vitais em Tempo Real

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

Como criar um agente de IA que analisa dados de sinais vitais de pacientes internados, identifica padrões anômalos e alerta a equipe médica.

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, ferramentas como chamadas a sistemas externos e demais requisitos funcionais para o Fluxo de Agentes "Monitoramento de Sinais Vitais em Tempo Real", uma solução de automação projetada para monitorar continuamente os sinais vitais de pacientes internados e alertar a equipe médica sobre qualquer anomalia detectada. 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 é analisar dados de sinais vitais em tempo real, identificar padrões anômalos e notificar a equipe médica para intervenções rápidas.

2. Contexto e Problema

Cenário Atual

O monitoramento contínuo dos sinais vitais dos pacientes é crucial para garantir a segurança e eficácia do tratamento. No entanto, a identificação manual de anomalias pode ser demorada e sujeita a erros, levando a atrasos na intervenção médica. Problemas específicos incluem:

  • Monitoramento contínuo e em tempo real dos sinais vitais dos pacientes para identificar rapidamente quaisquer anomalias.
  • Redução do tempo de resposta da equipe médica a situações críticas, garantindo intervenções mais rápidas e eficazes.
  • Integração dos dados de sinais vitais com o prontuário eletrônico para uma visão completa da saúde do paciente.

Atualmente, a equipe médica depende de sistemas de monitoramento que podem não detectar rapidamente todas as anomalias, especialmente em ambientes com alta carga de trabalho.


Problemas Identificados

  • Consumo de tempo: A análise manual dos sinais vitais consome tempo valioso da equipe médica, que poderia ser usado para atendimento direto ao paciente.
  • Risco de atraso: A demora na identificação de anomalias pode levar a um atraso na resposta médica, potencialmente agravando a condição do paciente.
  • Falta de integração: A ausência de integração com o prontuário eletrônico limita a visão holística da saúde do paciente.
  • Dependência de processos manuais: A análise manual está sujeita a erros humanos, resultando em detecção tardia de sinais críticos.
  • Risco de erros: A interpretação manual dos sinais vitais é propensa a erros, impactando a qualidade do cuidado ao paciente.

3. Impactos Esperados

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

  • Reduzir o tempo de resposta da equipe médica a situações críticas.
  • Melhorar a precisão na identificação de padrões anômalos nos sinais vitais.
  • Integrar dados de sinais vitais com o prontuário eletrônico para uma visão completa da saúde do paciente.
  • Aumentar a eficiência do monitoramento de pacientes, liberando a equipe médica para outras tarefas.
  • Reduzir a carga de trabalho da equipe médica, minimizando a necessidade de monitoramento manual contínuo.

4. Visão Geral da Solução

O agente de IA para monitoramento de sinais vitais em tempo real processa dados de dispositivos de monitoramento, aplica algoritmos de detecção de anomalias e alerta automaticamente a equipe médica sobre potenciais emergências. 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 no monitoramento de sinais vitais dos pacientes.

A solução consiste em um fluxo de automação composto por 4 agentes de IA. O processo inicia com a coleta de dados dos dispositivos de monitoramento e termina com o registro de anomalias no prontuário eletrônico.

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

Agentes Função Principal
Agente de Execução de Chamada à API - Ingestão de Sinais Vitais (RF 1) Realizar chamada à API para obter sinais vitais dos pacientes internados.
Agente Analítico de Detecção de Anomalias em Sinais Vitais (RF 2) Analisar os sinais vitais recebidos e identificar anomalias clínicas relevantes.
Agente de Execução de Chamada à API - Notificações de Alerta (RF 3) Enviar notificações automáticas à equipe assistencial sobre anomalias detectadas.
Agente de Execução de Chamada à API - Registro no Prontuário Eletrônico (RF 4) Registrar no prontuário eletrônico a ocorrência de anomalias e o resumo analítico.

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 a equipe médica 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 Execução de Chamada à API - Ingestão de Sinais Vitais

1.1 Tarefa do Agente

Realizar chamada à API do middleware de dispositivos de monitoramento para obter, em tempo quase real, batimentos cardíacos, pressão arterial, saturação de O2, frequência respiratória e temperatura de pacientes internados, padronizando o formato para os próximos agentes.

1.2 Prompt ou Instruções do Agente 
Este agente não requer instruções de LLM. Sua função é exclusivamente executar a chamada à API do sistema de dispositivos e retornar os dados conforme o expected_output.
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 de sinais vitais via API após a conexão com o middleware de dispositivos de monitoramento. Na fase de testes, os dados serão enviados diretamente por upload de um arquivo JSON na interface da Prototipe AI, para acelerar o processo de validação.
  • Tipo do input: O input inicial para o fluxo é um arquivo JSON contendo dados de sinais vitais padronizados.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs nos formatos: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 50.000 caracteres.

1.3.2 Especificação do Output

  • Formato de output: O output deve ser um arquivo JSON com os registros de sinais vitais padronizados para uso por agentes subsequentes.
  • Exemplo de Estrutura de Output: 
    { "records": [ { "patient_id": "string", "device_id": "string", "timestamp": "ISO-8601", "metrics": { "hr": {"value": 92, "unit": "bpm"}, "sbp": {"value": 118, "unit": "mmHg"}, "dbp": {"value": 76, "unit": "mmHg"}, "map": {"value": 90, "unit": "mmHg"}, "spo2": {"value": 96, "unit": "%"}, "rr": {"value": 18, "unit": "irpm"}, "temp": {"value": 36.8, "unit": "C"} }, "quality_flags": { "artifact": false, "sensor_off": false } } ] }
  • Número de caracteres esperado: O JSON gerado terá um tamanho aproximado de 2.000 caracteres por registro.

1.3.3 Parâmetros de Geração

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

1.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Conecta-se ao middleware de dispositivos de monitoramento para ingestão de dados.

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 Analítico de Detecção de Anomalias em Sinais Vitais (RF 2).

RF 2. Agente Analítico de Detecção de Anomalias em Sinais Vitais

2.1 Tarefa do Agente

Analisar o lote mais recente de sinais vitais por paciente, identificar anomalias clínicas relevantes, classificar severidade e decidir se um alerta deve ser emitido, incluindo recomendações de ação imediata e intervalo de reavaliação.

2.2 Prompt ou Instruções do Agente 
- Descarte de leituras inválidas: ignore qualquer leitura com quality_flags.artifact = true ou sensor_off = true. Se >50% das leituras no período avaliado forem inválidas, defina anomaly_detected = false, alert_required = false e recommended_actions = ["Verificar posicionamento do sensor"], recheck_interval_min = 2.
- Normalização de unidades: assuma unidades conforme expected_input; se unidade ausente, considere padrão (hr=bpm, sbp/dbp/map=mmHg, spo2=%, rr=irpm, temp=C).
- Limiar base para adultos (ajustáveis por custom_thresholds):
  • HR: critico >130 ou <40; alto 111-130 ou 40-49; moderado 100-110.
  • SBP: critico <90 ou >220; alto 90-100 ou 200-220; moderado 101-110 ou 160-199.
  • MAP: critico <60; alto 60-65; moderado 66-70.
  • SpO2: critico <90; alto 90-92; moderado 93-94. Se paciente_profile.diagnoses inclui DPOC e custom_thresholds.spo2_min existir, use esse valor como corte de alto em vez de 92.
  • RR: critico >30 ou <8; alto 25-30; moderado 21-24.
  • Temp: critico >=40.0 ou <35.0; alto 38.5-39.9; moderado 38.0-38.4.
- Tendência e persistência: classifique como anomalia apenas se o valor fora do limite persistir por >=2 minutos ou se a variação for abrupta (ex.: |ΔHR| >= 20 em 5 min; |ΔSBP| >= 40 em 5 min; |ΔSpO2| >= 4 pontos em 3 min), registrando trend.delta e window_min.
- Composição de severidade: para cada métrica fora do limite, atribua severity conforme maior entre limite atingido (critico>alto>moderado) e padrão de tendência. A severidade global é a maior severidade entre as métricas; se houver pelo menos duas métricas em alto simultaneamente, eleve global para critico.
- Escore de alerta precoce (simplificado):
  • Atribua pontos por métrica: 3 pontos (critico), 2 pontos (alto), 1 ponto (moderado), 0 normal. Some pontos das métricas disponíveis. Classifique risk: >=5 alto; 3-4 moderado; 0-2 baixo. Publique composite_early_warning_score.score e risk.
- Decisão de alerta: defina alert_required=true quando existir severidade global = critico ou risk=alto; ou quando risk=moderado por >=10 min. Caso contrário, alert_required=false e recommended_actions deve incluir "Aumentar frequência de monitoramento".
- Nível de escalonamento: immediato se (critico) ou (SpO2 < 90) ou (SBP < 90) ou (RR > 30); prioritario se risk=alto sem critérios de imediato; rotina se risk=moderado persistente.
- Supressão de duplicidade (cooldown): se recente_history.last_alerts contiver alerta do mesmo tipo nos últimos X minutos, onde X = cooldown_min do último alerta, então mantenha alert_required=false, mas atualize recommended_actions e recheck_interval_min conforme a severidade atual; defina cooldown_suggestion_min igual ao maior entre 10 e o intervalo recomendado.
- Recomendações iniciais baseadas em regra:
  • SpO2 < 90%: "Iniciar oxigenoterapia conforme protocolo"; recheck_interval_min=2.
  • SBP < 90 mmHg: "Avaliar volume/vasoativo conforme protocolo"; recheck_interval_min=5.
  • HR >130 bpm: "Avaliar dor, febre, hipovolemia, arritmia"; recheck_interval_min=5.
  • Temp >= 38.5 C: "Investigar foco infeccioso e antitérmico se indicado"; recheck_interval_min=10.
- Construção de notification_payload: preencha title com métrica e valor principal; body com resumo em até 200 caracteres incluindo duração e outras métricas relevantes; priority=high se escalonamento for imediato ou prioritário; inclua patient_id e contexto de unidade/leito se disponível.
- Construção de ehr_payload: registre lista de anomalias com valores/limiares, horários de início e duração, escore e recomendações; inclua tags ["monitoramento","alerta"].
- Se nenhum critério for atendido e valores normais: anomaly_detected=false, alert_required=false, recommended_actions=["Manter monitoramento"], recheck_interval_min=15.
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 bem-sucedida do agente anterior (RF 1).
  • Tipo do input: Este agente deve ser apto a receber como input um arquivo JSON contendo registros de sinais vitais padronizados.
  • 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é 6.000 caracteres por paciente.

2.3.2 Especificação do Output

  • Formato de output: O output deve ser um arquivo JSON contendo a análise das anomalias detectadas e recomendações de intervenção.
  • Exemplo de Estrutura de Output: 
    { "patient_id": "string", "anomaly_detected": true, "anomalies": [ { "metric": "hr|sbp|dbp|map|spo2|rr|temp", "value": 142, "unit": "bpm|mmHg|%|irpm|C", "threshold": { "type": "critico|alto|moderado", "operator": ">|<|<=|>=", "value": 130 }, "trend": { "delta": 20, "window_min": 5 }, "onset_time": "ISO-8601", "duration_min": 7, "severity": "critico|alto|moderado", "rationale": "Frequência cardíaca >130 bpm por 7 min com aumento de 20 bpm em 5 min." } ], "composite_early_warning_score": { "score": 6, "risk": "alto|moderado|baixo" }, "alert_required": true, "escalation_level": "imediato|prioritario|rotina", "recommended_actions": ["Acionar médico plantonista", "Administrar O2 se < 92% conforme protocolo"], "recheck_interval_min": 5, "cooldown_suggestion_min": 15, "notification_payload": { "title": "Alerta: Taquicardia (142 bpm)", "body": "Paciente 123: HR 142 bpm por 7 min; RR 24 irpm; SpO2 91%.", "priority": "high", "channels": ["pager","app"], "patient_id": "string", "context": { "unit": "UTI", "bed": "03" } }, "ehr_payload": { "patient_id": "string", "note_type": "observacao_monitoramento", "content": "Resumo de anomalias, horários, valores e intervenções recomendadas.", "tags": ["monitoramento","alerta"] } }
  • Número de caracteres esperado: O JSON gerado terá um tamanho aproximado de 3.000 caracteres por paciente.

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: Utiliza lógica interna para análise de dados e geração de recomendações.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

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 Execução de Chamada à API - Notificações de Alerta (RF 3).

RF 3. Agente de Execução de Chamada à API - Notificações de Alerta

3.1 Tarefa do Agente

Enviar notificações automáticas à equipe assistencial via sistemas de alerta (pager, app móvel, central) utilizando o payload preparado pelo agente analítico.

3.2 Prompt ou Instruções do Agente 
Este agente não requer instruções de LLM. Sua função é exclusivamente executar a chamada aos serviços de notificação com o payload recebido.
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 bem-sucedida do agente anterior (RF 2).
  • Tipo do input: Este agente deve ser apto a receber como input um payload de notificação preparado pelo agente analítico.
  • 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é 2.000 caracteres por notificação.

3.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON indicando o status de envio das notificações.
  • Exemplo de Estrutura de Output: 
    { "sent": true, "delivery": [ { "channel": "pager|app|email", "message_id": "string", "status": "queued|sent|failed", "timestamp": "ISO-8601" } ] }
  • Número de caracteres esperado: O JSON gerado terá um tamanho aproximado de 500 caracteres por notificação.

3.3.3 Parâmetros de Geração

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

3.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Conecta-se aos sistemas de notificação para envio de alertas.

3.3.5 Memória

  • Visibilidade das Instruções (Prompt): As instruções deste agente não são necessárias para agentes subsequentes.
  • Visibilidade da Resposta: A resposta gerada por este agente não é necessária para agentes subsequentes.

3.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 - Registro no Prontuário Eletrônico (RF 4).

RF 4. Agente de Execução de Chamada à API - Registro no Prontuário Eletrônico

4.1 Tarefa do Agente

Registrar no prontuário eletrônico (EHR) a ocorrência do evento de anomalia e o resumo analítico, garantindo rastreabilidade clínica.

4.2 Prompt ou Instruções do Agente 
Este agente não requer instruções de LLM. Sua função é exclusivamente executar a chamada ao EHR com o payload recebido.
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 bem-sucedida do agente anterior (RF 3).
  • Tipo do input: Este agente deve ser apto a receber como input um payload de registro de anomalia preparado pelo agente analítico.
  • 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é 2.000 caracteres por registro.

4.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON indicando o status de registro no EHR.
  • Exemplo de Estrutura de Output: 
    { "ehr_recorded": true, "ehr_note_id": "string", "timestamp": "ISO-8601" }
  • Número de caracteres esperado: O JSON gerado terá um tamanho aproximado de 200 caracteres por registro.

4.3.3 Parâmetros de Geração

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

4.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Conecta-se ao sistema de prontuário eletrônico para registro de eventos.

4.3.5 Memória

  • Visibilidade das Instruções (Prompt): As instruções deste agente não são necessárias para agentes subsequentes.
  • Visibilidade da Resposta: A resposta gerada por este agente não é necessária para agentes subsequentes.

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

A execução deste agente finaliza o fluxo de monitoramento e registro de anomalias.

Posts Relacionados

© 2025 prototipe.ai. Todos os direitos reservados.