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
- 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 Engenharia de Atributos e Segmentação (RF 2).
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
- 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 Detecção de Padrões e Projeções de Demanda (RF 3).
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
- 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 Síntese de Insights e Plano de Ação (RF 4).
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.