Agente de IA para Análise de Dados de Admissão Hospitalar

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

Como criar um agente de IA que analisa dados coletados durante a admissão para identificar padrões e prever necessidades futuras de cuidados ou recursos.

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 "Análise de Dados de Admissão Hospitalar", uma solução de automação projetada para identificar padrões e prever necessidades futuras de cuidados ou recursos a partir de dados coletados durante a admissão 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 é utilizar técnicas de análise de dados para identificar padrões nos dados de admissão e gerar previsões sobre necessidades futuras de cuidados ou recursos, fornecendo insights acionáveis para a equipe hospitalar melhorar a gestão de recursos e planejamento de cuidados.

2. Contexto e Problema

Problemas Específicos

O processo atual de admissão hospitalar enfrenta dificuldades em identificar padrões nos dados de admissão que possam indicar necessidades futuras de cuidados, além de apresentar falta de previsões precisas sobre a demanda por recursos hospitalares.

  • Dificuldade em identificar padrões nos dados de admissão que possam indicar necessidades futuras de cuidados.
  • Falta de previsões precisas sobre a demanda por recursos hospitalares.

3. Impactos Esperados

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

  • Melhorar a precisão na identificação de padrões nos dados de admissão.
  • Aumentar a precisão das previsões sobre demandas futuras de cuidados e recursos.
  • Fornecer insights acionáveis para a equipe hospitalar melhorar a gestão de recursos e planejamento de cuidados.

4. Visão Geral da Solução

O agente de IA para análise de dados de admissão hospitalar processa dados coletados durante a admissão, aplica técnicas de análise para identificar padrões e gerar previsões, fornecendo insights acionáveis para a equipe hospitalar. 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 de recursos hospitalares.

A solução consiste em um fluxo de automação composto por 4 agentes de IA. O processo inicia com a validação e padronização dos dados de admissão e termina com a geração de um relatório de insights e plano de ação.

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

Agentes Função Principal
Agente de Validação e Padronização de Dados de Admissão (RF 1) Receber o dataset bruto de admissões e entregar um dataset padronizado e pronto para análise.
Agente de Engenharia de Atributos e Segmentação (RF 2) Enriquecer o dataset padronizado com atributos preditivos e segmentar pacientes/coortes operacionais relevantes.
Agente de Detecção de Padrões e Projeções de Demanda (RF 3) Identificar padrões temporais e de perfil nas admissões e gerar projeções de demanda por recursos.
Agente de Síntese de Insights e Plano de Ação (RF 4) Transformar padrões e projeções em insights acionáveis para gestão de recursos e planejamento de cuidados.

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 hospital receberá. Explore os links abaixo para entender melhor a solução em ação.

6. Requisitos Funcionais

RF 1. Agente de Validação e Padronização de Dados de Admissão

1.1 Tarefa do Agente

Receber o dataset bruto de admissões e entregar um dataset padronizado e pronto para análise, com checagens de qualidade e normalização de variáveis clínicas e operacionais.

1.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um dataset bruto de admissões hospitalares. Este dataset contém informações não padronizadas que precisam ser verificadas e normalizadas.

# 2. Objetivo
Processar o dataset para padronizar as informações, realizar checagens de qualidade e normalizar variáveis clínicas e operacionais.

# 3. Regras que você deve seguir para gerar sua resposta
- Exigir chaves mínimas: id_admissao (único), data_hora_chegada (ISO 8601), idade (0-120), sexo (M/F/Outro/NA). Se ausentes, marcar linha como invalida e reportar em data_quality_report.regras_quebradas.
- Converter datas para ISO 8601 (UTC ou incluir timezone explícito se fornecido); criar campos derivados: data_chegada (AAAA-MM-DD), hora_chegada (HH:MM), semana_iso, mes (1-12), ano.
- Normalizar categorias para conjuntos controlados: sexo ∈ {M,F,Outro,NA}; via_admissao ∈ {ambulancia, encaminhamento, demanda_espontanea, transferencia, NA}; prioridade_triagem ∈ {vermelho, laranja, amarelo, verde, azul, NA}. Registrar mapeamentos em dicionarios_normalizacao e sinalizar categorias desconhecidas como 'NA'.
- Validar ranges: idade (0-120); se fora, definir idade=NA e registrar em imputacoes_realizadas com motivo 'idade_out_of_range'.
- Deduplicar por id_admissao; se houver duplicatas, manter o registro com data_hora_chegada mais recente e reportar contagem em duplicidades_removidas.
- Harmonizar CID-10: manter cid10 em maiúsculas sem pontos; criar cid10_grupo com o primeiro caractere (A-Z) e um grupo clínico amplo; se cid10 ausente mas diagnostico_inicial presente, manter cid10=NA e preencher diagnostico_inicial_normalizado (minúsculas, sem acentos).
- Derivar tempos operacionais (em minutos): tempo_ate_triagem = data_hora_triagem - data_hora_chegada; tempo_ate_internacao = data_hora_internacao - data_hora_chegada; se negativo, definir como NA e registrar regra quebrada 'tempo_negativo'.
- Tratar PII: remover/anonimizar campos de identificação direta (nome, documento, telefone, email) se presentes; manter apenas ids pseudonimizados.
- Produzir dataset_padronizado com esquema declarado e consistente; qualquer coluna extra manter como 'extra_*'. 
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 dataset de admissões hospitalares 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 dataset na interface da Prototipe AI, para acelerar o processo de validação.
  • Tipo do input: O input inicial para o fluxo é um dataset de admissões hospitalares, que deve ser processado para padronização e análise.
  • Formatos Suportados: Esse agente deve ser capaz de receber datasets nos formatos: .csv, .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 150.000 caracteres.

1.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON com o dataset padronizado e um relatório de qualidade dos dados.
  • Exemplo de Estrutura de Output:
     {
      "dataset_padronizado": "dados em CSV ou JSON lines",
      "data_quality_report": {
        "linhas_totais": 1000,
        "linhas_validas": 950,
        "percent_missing_por_coluna": {
          "idade": 0.02,
          "sexo": 0.01
        },
        "duplicidades_removidas": 5,
        "regras_quebradas": ["idade_out_of_range", "tempo_negativo"],
        "imputacoes_realizadas": ["idade_out_of_range"]
      },
      "dicionarios_normalizacao": {
        "sexo_map": {"M": "Masculino", "F": "Feminino"},
        "via_admissao_map": {"ambulancia": "Ambulância", "encaminhamento": "Encaminhamento"}
      },
      "campos_derivados_definicao": "Definições dos campos derivados"
    } 
  • Número de caracteres esperado: O JSON final deve ter 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 Engenharia de Atributos e Segmentação (RF 2).

RF 2. Agente de Engenharia de Atributos e Segmentação

2.1 Tarefa do Agente

Enriquecer o dataset padronizado com atributos preditivos e segmentar pacientes/coortes operacionais relevantes para análise de demanda.

2.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um dataset padronizado de admissões hospitalares. Este dataset foi processado para garantir qualidade e consistência.

# 2. Objetivo
Enriquecer o dataset com atributos preditivos e segmentar pacientes/coortes operacionais relevantes para análise de demanda.

# 3. Regras que você deve seguir para gerar sua resposta
- Criar faixas de idade: idade_bin ∈ {0-1,2-17,18-39,40-59,60-74,75+} com base em idade; se idade=NA, idade_bin='NA'.
- Codificar prioridade_triagem_ordinal: vermelho=5, laranja=4, amarelo=3, verde=2, azul=1, NA=0.
- Derivar sazonalidade: dow (0-6), is_weekend (0/1), hora_chegada_bin (0-5 madrugada, 6-11 manhã, 12-17 tarde, 18-23 noite), mes, semana_iso.
- Agrupar CID-10 em macrogrupos: infecciosas(A-B), neoplasias(C-D), sangue(D50-D89), endócrino(E), mental(F), nervoso(G), olho(H00-H59), ouvido(H60-H95), circulatório(I), respiratório(J), digestivo(K), pele(L), músculo-esquelético(M), geniturinário(N), gravidez(O), perinatal(P), congênitas(Q), sintomas(R), lesões(S-T), causas externas(V-Y), fatores Z; armazenar em cid10_macrogrupo; se NA, cid10_macrogrupo='NA'.
- Extrair carga de comorbidades: comorb_count (contar itens delimitados por vírgula/; ou termos conhecidos), indicador_comorb_alta (1 se comorb_count>=2, senão 0).
- Criar indicadores de recursos potenciais: necessidade_uti_proxy = 1 se prioridade_triagem_ordinal>=4 ou cid10_macrogrupo ∈ {circulatório, respiratório, lesões} e idade>=60; horas_enfermagem_proxy = 6 se prioridade>=4, 4 se 3, 2 se <=2; leito_previsto = 1 se tempo_ate_internacao não NA e <= 240 min; caso contrário 0.
- Definir segmentos_coortes com critérios estáveis: 
  - 'Idosos Alta Complexidade': idade>=75 OU (idade>=60 e prioridade>=4)
  - 'Emergência Circulatória/Respiratória': cid10_macrogrupo ∈ {circulatório, respiratório} e prioridade>=4
  - 'Baixa Complexidade': prioridade<=2 e leito_previsto=0
  - 'Trauma/Lesões': cid10_macrogrupo='lesões'
  Para cada segmento, calcular tamanho e proporcao sobre o total válido.
- Garantir dicionario_features com definição clara de cada variável nova, incluindo tipo (numerico, categórico, binário) e regra de cálculo.
- Preservar somente colunas necessárias para previsão e padrões; mover demais para extra_*. 
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 dataset padronizado de admissões hospitalares.
  • 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é 100.000 caracteres.

2.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON com o dataset enriquecido e segmentado, além de um dicionário de features.
  • Exemplo de Estrutura de Output:
     {
      "dataset_features": "dados em JSON lines",
      "dicionario_features": [
        {"nome": "idade_bin", "tipo": "categórico", "definicao": "Faixa etária do paciente"},
        {"nome": "necessidade_uti_proxy", "tipo": "binário", "definicao": "Indicador de necessidade de UTI"}
      ],
      "segmentos_coortes": [
        {"nome": "Idosos Alta Complexidade", "criterio_logico": "idade>=75 OU (idade>=60 e prioridade>=4)", "tamanho": 150, "proporcao": 0.15}
      ]
    } 
  • Número de caracteres esperado: O JSON final deve ter um tamanho estimado em torno de 8.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.
  • Calculadora: Não utiliza.
  • 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 Detecção de Padrões e Projeções de Demanda (RF 3).

RF 3. Agente de Detecção de Padrões e Projeções de Demanda

3.1 Tarefa do Agente

Identificar padrões temporais e de perfil nas admissões e gerar projeções de demanda por recursos (leitos, UTI, horas de enfermagem) em horizontes de curto prazo.

3.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um dataset enriquecido e segmentado de admissões hospitalares.

# 2. Objetivo
Identificar padrões temporais e de perfil nas admissões e gerar projeções de demanda por recursos em horizontes de curto prazo.

# 3. Regras que você deve seguir para gerar sua resposta
- Agregar por data_chegada (diário):
  admissões = contagem de id_admissao;
  leitos_previstos = soma de leito_previsto;
  uti_previstos = soma de necessidade_uti_proxy;
  horas_enfermagem_previstas = soma de horas_enfermagem_proxy.
- Calcular tendências: media_movel_7d, media_movel_14d, taxa_crescimento_7d = (mm7d_dia - mm7d_7dias_atras)/mm7d_7dias_atras; marcar como NA se denominador<=0.
- Detectar anomalias: flag_anomalia=1 se admissões_dia > (mm7d + 2*dp7d) ou < (mm7d - 2*dp7d) quando janelas disponíveis; registrar em padroes_identificados com tipo='anomalia'.
- Sazonalidade: identificar picos por dia da semana e hora_chegada_bin; incluir padrões se diferença relativa >15% vs média.
- Projeções: extrapolar curto prazo usando última media_movel (7d para 7 dias, 14d para 14/30 dias) ajustada por taxa_crescimento_7d quando positiva/negativa; limitar variação diária a ±20% para estabilidade; gerar por recurso aplicando as taxas observadas (ex.: proporção uti_previstos/admissões média das últimas 4 semanas).
- Bandas de confiança: definir central=projeção; inferior=central*(1 - cv_ultimas_4_semanas); superior=central*(1 + cv_ultimas_4_semanas), onde cv = desvio-padrão/média, truncado entre 0.05 e 0.35.
- Backtest simples: reservar últimos 14 dias como validação se houver histórico>=60 dias; comparar projeções ingênuas (mm7d) com observados e calcular MAPE e bias; registrar metricas_backtest. Se histórico insuficiente, registrar motivo em metricas_backtest.periodo_avaliado='insuficiente'.
- Produzir previsões agregadas gerais e por segmentos_coortes (aplicando a mesma metodologia a cada segmento com pelo menos 2 admissões/dia em média; caso contrário, marcar como 'volume_baixo'). 
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 dataset enriquecido e segmentado de admissões hospitalares.
  • 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é 100.000 caracteres.

3.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON com padrões identificados, projeções de demanda e métricas de backtest.
  • Exemplo de Estrutura de Output:
     {
      "padroes_identificados": [
        {"tipo": "anomalia", "descricao": "Pico de admissões", "metrica_associada": "admissões_dia", "intensidade": "alta"}
      ],
      "previsoes_demanda": {
        "horizontes": [7, 14, 30],
        "por_recurso": {"leitos": [10, 20, 30], "uti": [5, 10, 15], "horas_enfermagem": [50, 100, 150]}
      },
      "bandas_confianca": {"inferior": [9, 18, 27], "central": [10, 20, 30], "superior": [11, 22, 33]},
      "metricas_backtest": {"horizonte": 14, "mape": 0.1, "bias": 0.05, "periodo_avaliado": "últimos 14 dias"}
    } 
  • Número de caracteres esperado: O JSON final deve ter um tamanho estimado em torno de 8.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.
  • 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 Síntese de Insights e Plano de Ação (RF 4).

RF 4. Agente de Síntese de Insights e Plano de Ação

4.1 Tarefa do Agente

Transformar padrões e projeções em insights acionáveis para gestão de recursos e planejamento de cuidados.

4.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo padrões identificados e projeções de demanda de admissões hospitalares.

# 2. Objetivo
Transformar padrões e projeções em insights acionáveis para gestão de recursos e planejamento de cuidados.

# 3. Regras que você deve seguir para gerar sua resposta
- Elaborar sumario_executivo com 3-6 achados de maior impacto, usando números absolutos e variações percentuais vs média das últimas 4 semanas.
- Traduzir projeções em capacidade necessária: 
  - leitos_adicionais = max(0, pico_prev_leitos - capacidade_leitos_atual) se capacidade for fornecida; caso não fornecida, reportar apenas demanda prevista.
  - horas_enfermagem_adicionais = pico_prev_horas - baseline_horas (se disponível) ou apresentar intervalo com bandas_de_confianca.
  - necessidade_uti (casos) por dia e pico de 7/14/30 dias.
- Priorizar recomendações com matriz impacto x urgência: prioridade ∈ {alta, média, baixa}; definir prioridade='alta' quando horizonte<=7 dias e aumento previsto>15%.
- Definir alertas_automaticos com condições claras, por exemplo: 'se admissões_diarias > banda_superior então acionar alerta "Acionamento de Plano de Contingência"'.
- Para cada recomendação, incluir quantificação e premissas explícitas (ex.: coeficientes de horas_enfermagem_proxy utilizados, segmento alvo). Evitar verbos vagos; incluir responsável sugerido (owner) e prazo.
- Apresentar limitações: se metricas_backtest.mapE>25% ou histórico_insuficiente, anexar aviso de baixa confiabilidade e sugerir coleta de mais dados (campos específicos que mais faltaram, conforme data_quality_report quando disponível).
- Garantir que o relatório seja autoexplicativo, com glossário curto dos principais termos (até 8 entradas) em anexos_tecnicos. 
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 padrões identificados e projeções de demanda de admissões hospitalares.
  • 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é 50.000 caracteres.

4.3.2 Especificação do Output

  • Formato de output: O output deve ser um relatório estruturado em JSON com insights acionáveis e plano de ação.
  • Exemplo de Estrutura de Output:
     {
      "sumario_executivo": "Resumo dos principais achados e projeções de demanda",
      "principais_riscos": [
        {"risco": "Superlotação de UTI", "horizonte": 7, "probabilidade": "alta", "impacto": "crítico", "indicador_disparo": "uti_previstos > capacidade"}
      ],
      "recomendacoes_operacionais": [
        {"acao": "Aumentar equipe de enfermagem", "recurso_afetado": "horas_enfermagem", "horizonte": 14, "quantificacao": "+20%", "premissas": "Baseado em pico de demanda previsto", "prioridade": "alta"}
      ],
      "alertas_automaticos": [
        {"condicao": "admissões_diarias > banda_superior", "limiar": "Acionamento de Plano de Contingência", "mensagem": "Alerta de superlotação iminente"}
      ],
      "kpis_sugeridos": [
        {"kpi": "Taxa de Ocupação de Leitos", "formula": "(leitos_ocupados / leitos_totais) * 100", "frequencia": "diária", "owner": "Diretor de Operações"}
      ],
      "anexos_tecnicos": {"metodologia_resumo": "Descrição das metodologias utilizadas para projeção", "metricas_backtest": "Detalhes das métricas de backtest"}
    } 
  • Número de caracteres esperado: O JSON final deve ter um tamanho estimado em torno de 10.000 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

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

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

A execução deste agente finaliza o fluxo. O relatório gerado é o resultado que deve ser disponibilizado ao hospital.

© 2025 prototipe.ai. Todos os direitos reservados.