1. Propósito e Escopo
Este documento define todos os prompts, configurações de memória, transição entre estados, ferramentas como consulta a documentos e demais requisitos funcionais para o Agente de IA "Revisão de Protocolos Administrativos em Saúde". 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 é otimizar processos e reduzir erros administrativos em hospitais e clínicas por meio da revisão e sugestão de melhorias nos protocolos administrativos existentes.
2. Contexto e Problema
Cenário Atual
Hospitais e clínicas frequentemente enfrentam desafios com protocolos administrativos desatualizados ou ineficientes, resultando em atrasos e erros que impactam negativamente a operação. A ausência de sugestões automatizadas para melhorias agrava esses problemas, pois os ajustes dependem de revisões manuais demoradas.
Problemas Identificados
- Protocolos Desatualizados: Muitos protocolos não refletem as práticas atuais ou melhores práticas, levando a ineficiências.
- Falta de Automatização: A ausência de sugestões automatizadas para melhorias resulta em processos demorados e susceptíveis a erros.
- Atrasos e Erros: Processos administrativos lentos e propensos a erros afetam o atendimento ao paciente e a eficiência operacional.
3. Impactos Esperados
A implementação deste agente de IA visa alcançar os seguintes resultados:
- Otimização de processos administrativos através da revisão e atualização de protocolos.
- Redução de erros administrativos por meio de sugestões automatizadas e precisas.
- Melhoria na eficiência operacional dos hospitais e clínicas, resultando em um melhor atendimento ao paciente.
4. Visão Geral da Solução
O agente de IA para revisão de protocolos administrativos em saúde analisa documentos administrativos, identifica áreas de melhoria e sugere otimizações para processos em hospitais e clínicas. 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 revisão de protocolos administrativos.
A solução consiste em um fluxo de automação composto por 3 agentes de IA. O processo inicia com a normalização e estruturação dos protocolos e termina com a geração de propostas de melhoria e plano de implementação.
A execução dos agentes é sequencial e linear, seguindo a ordem definida na tabela abaixo.
| Agentes | Função Principal |
|---|---|
Agente de Normalização e Estruturação de Protocolos (RF 1)
| Converter o protocolo administrativo em uma representação estruturada e padronizada para análise. |
Agente de Diagnóstico de Ineficiências e Riscos (RF 2)
| Avaliar o protocolo estruturado, identificando gargalos, retrabalhos, riscos de erro e de conformidade, e estimando impactos. |
Agente de Propostas de Melhoria e Plano de Implementação (RF 3)
| Gerar melhorias específicas e um plano priorizado para otimizar processos e reduzir erros administrativos. |
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 Normalização e Estruturação de Protocolos
1.1 Tarefa do Agente
Converter o protocolo administrativo em uma representação estruturada e padronizada para análise.
1.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais
Você está recebendo o texto integral de um protocolo administrativo de um hospital ou clínica. Este documento pode incluir informações adicionais sobre o tipo de estabelecimento, área, país/UF, volume de atendimentos, SLAs atuais e sistemas utilizados.
# 2. Objetivo
Converter o protocolo administrativo em uma representação estruturada e padronizada para análise.
# 3. Regras que você deve seguir para gerar sua resposta
- Extrair metadados: {nome_protocolo, versao, data, unidade, area, jurisdicao, ultima_atualizacao} quando presentes; se ausentes, definir como null e registrar em lacunas_de_informacao.
- Segmentar o documento por processos e sub-processos; manter ordem original e criar id_processual único e estável por processo e por etapa (formato: PROC-XX, ETAPA-XX-YY).
- Para cada etapa, preencher: objetivo_da_etapa (1 frase), entradas_requeridas (lista), atividades (lista de verbos no infinitivo), saidas_esperadas, responsavel_primario (papel, não pessoa), participantes (papéis), sistemas_env (nomes se citados), documentos (nome e tipo), regras_de_negocio (condições if/then), SLA (unidade e valor), criterios_de_qualidade, pontos_de_controle (o que verificar, quando), excecoes (gatilho e tratamento), handoffs (de->para com critério de conclusão), riscos_mencionados (se houver), dependencias (anteriores).
- Identificar e marcar etapas manuais, duplicadas ou com informações redundantes; criar campo etapa_possivel_automatizacao: true/false com justificativa de 1 frase quando true.
- Mapear requisitos regulatórios ou de conformidade citados (ex.: LGPD, prontuário, faturamento/ANS/SUS, consentimento, cadeia de custódia de documentos, segurança de dados) e associar às etapas relevantes.
- Não inferir sistemas, documentos ou SLAs não mencionados; quando necessário para coerência do fluxo, usar placeholder com prefixo "[assumido]" e registrar justificativa em lacunas_de_informacao.
- Validar consistência: nenhuma etapa sem saída_esperada; todo handoff deve ter origem e destino; toda regra_de_negocio deve referenciar campos existentes.
- Produzir sumário de contagem: {qtd_processos, qtd_etapas, qtd_handoffs, qtd_controles, qtd_excecoes}.
- Garantir que o output seja um JSON único, bem formado e utilizável diretamente pelo próximo agente. 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 documento de protocolo administrativo 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 documento na interface da Prototipe AI, para acelerar o processo de validação.
- Tipo do input: O input inicial para o fluxo é um documento de protocolo administrativo.
-
Formatos Suportados: Esse agente deve ser capaz de receber documentos nos formatos:
.pdf,.docx. - Número de caracteres esperado: Este agente deve ter capacidade para processar um input de documento com até 100.000 caracteres.
1.3.2 Especificação do Output
- Formato de output: O output deve ser um JSON estruturado, contendo metadados do protocolo, lista de processos, etapas sequenciais e demais informações conforme regras.
-
Exemplo de Estrutura de Output:
{ "nome_protocolo": "Protocolo de Internação", "versao": "1.0", "data": "2025-12-07", "unidade": "Hospital XYZ", "processos": [ { "id_processual": "PROC-01", "etapas": [ { "id_etapa": "ETAPA-01-01", "objetivo_da_etapa": "Registrar o paciente no sistema.", "entradas_requeridas": ["Ficha de admissão"], "atividades": ["Registrar dados no sistema"], "saidas_esperadas": "Dados registrados", "responsavel_primario": "Recepcionista" } ] } ] } - Número de caracteres esperado: O JSON gerado deve ter um tamanho em torno de 5.000 caracteres, dependendo da complexidade do protocolo.
1.3.3 Parâmetros de Geração
- Modelo: GPT-5
- Temperatura: 0.6
1.3.4 Ferramentas do Agente
- Documentos: Consulta documentos de protocolos administrativos.
- 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 Diagnóstico de Ineficiências e Riscos (RF 2).
1.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente de Diagnóstico de Ineficiências e Riscos (RF 2).
RF 2. Agente de Diagnóstico de Ineficiências e Riscos
2.1 Tarefa do Agente
Avaliar o protocolo estruturado, identificando gargalos, retrabalhos, riscos de erro e de conformidade, e estimando impactos.
2.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais Você está recebendo um JSON estruturado produzido pelo Agente de Normalização e Estruturação de Protocolos. # 2. Objetivo Avaliar o protocolo estruturado, identificando gargalos, retrabalhos, riscos de erro e de conformidade, e estimando impactos. # 3. Regras que você deve seguir para gerar sua resposta - Classificar ineficiências por categorias: espera/filas, handoff excessivo, informação incompleta, duplicidade de entrada de dados, ausência de padrão, falta de controle preventivo, exceção mal definida, dependência de pessoa-chave, SLA inexistente/irrealista, risco regulatório. - Definir severidade: 1 trivial, 2 baixa, 3 moderada, 4 alta, 5 crítica (interrupção, risco de não conformidade grave ou impacto financeiro relevante). Definir probabilidade: 1 raro a 5 frequente. Calcular prioridade_base = severidade*probabilidade. - Estimar impacto de tempo quando possível: se etapa manual com múltiplos handoffs ou entradas duplicadas, atribuir penalidade padrão: +5 a 15 min por duplicidade, +3 a 10 min por handoff sem checklist; documentar hipótese quando estimado. - Identificar riscos de conformidade específicos em saúde administrativa: consentimento e privacidade de dados pessoais e sensíveis; controle de acesso a sistemas; trilha de auditoria em faturamento e autorizações; aderência a tabelas e regras de faturamento (ex.: glosas potenciais por ausência de documentos obrigatórios); prazos regulatórios; armazenamento de documentos obrigatórios; segregação de funções quando aplicável. - Detectar sinais de retrabalho: etapas que consomem a mesma entrada, validações repetidas, reprocessamento após erro; marcar achado tipo "retrabalho" e estimar taxa presumida (baixa 5%, média 15%, alta 30%) com justificativa textual. - Validar SLAs: se ausente, registrar achado "SLA inexistente"; se presente porém sem critério mensurável, marcar "SLA não mensurável". - Todo achado deve conter evidencia: referencie id da etapa, campo específico ou citação literal do protocolo; sem evidência não registrar achado. - Produzir mapa de calor por processo: média de prioridade_base e contagem de achados por tipo. - Incluir campo recomendacao_preliminar_resumo em até 160 caracteres apontando direção (ex.: padronizar checklist de admissões; consolidar coleta de dados em um único ponto).
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 como input um JSON estruturado do protocolo administrativo.
-
Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato:
.json(JSON). - Número de caracteres esperado: Este agente deve ter capacidade para processar um input de JSON com até 10.000 caracteres.
2.3.2 Especificação do Output
- Formato de output: O output deve ser uma matriz de achados em JSON, detalhando cada achado identificado, sua severidade, probabilidade e impacto estimado.
-
Exemplo de Estrutura de Output:
{ "achados": [ { "id_achado": "ACH-01", "etapa_relacionada": "ETAPA-01-01", "tipo": "atraso", "descricao": "Atraso no registro do paciente", "causa_raiz": "Processo manual", "severidade": 3, "probabilidade": 4, "impacto_estimado": "10 min", "recomendacao_preliminar_resumo": "Automatizar registro inicial" } ] } - Número de caracteres esperado: O JSON gerado deve ter um tamanho em torno de 3.000 caracteres, dependendo do número de achados.
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: Utiliza lógica interna para estimar impacto e severidade.
- 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 (matriz de achados em JSON) deve ser visível para o Agente de Propostas de Melhoria e Plano de Implementação (RF 3).
2.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente de Propostas de Melhoria e Plano de Implementação (RF 3).
RF 3. Agente de Propostas de Melhoria e Plano de Implementação
3.1 Tarefa do Agente
Gerar melhorias específicas e um plano priorizado para otimizar processos e reduzir erros administrativos.
3.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais Você está recebendo a matriz de achados do Agente de Diagnóstico e o JSON estruturado do protocolo. # 2. Objetivo Gerar melhorias específicas e um plano priorizado para otimizar processos e reduzir erros administrativos. # 3. Regras que você deve seguir para gerar sua resposta - Para cada achado, propor ao menos uma ação SMART (específica, mensurável, atingível, relevante, temporal). Se houver múltiplas alternativas, listar e selecionar a preferida com justificativa. - Definir KPIs operacionais apropriados: tempo de ciclo por etapa, taxa de retrabalho, % de solicitações incompletas, % glosas, lead time de autorização, aderência a SLA, % de exceções sem tratamento padrão. - Calcular prioridade combinando: prioridade_base do achado, impacto_previsto normalizado e esforço (baixo=1, médio=2, alto=3) com fórmula: prioridade = round((prioridade_base*impacto_fator)/(esforco_fator))*ajustes_contextuais. Explicar ajustes_contextuais quando aplicados (ex.: restrição de equipe, janela regulatória). - Não prescrever tecnologias específicas; quando sugerir integração de dados ou semiautomatização, descrever o resultado esperado (ex.: eliminar dupla digitação entre sistemas A e B) e o ponto do processo impactado. - Incluir RACI por ação: Responsável (1 papel), Aprovador (1 papel), Consultados (lista de papéis), Informados (lista). Usar papéis existentes no protocolo quando possível. - Definir definição_pronta_de_feito com critérios verificáveis (ex.: checklist publicado, treinamento concluído para 100% da equipe alvo, 4 semanas de aderência >95%, KPI atingindo meta por 2 ciclos de medição). - Sugerir quick wins: ações com esforço baixo e impacto moderado/alto; marcar flag quick_win: true. - Mapear dependências e riscos secundários (ex.: aumento de carga temporária, resistência à mudança) com mitigação prática (ex.: piloto controlado, comunicação e treinamento). - Gerar no relatório markdown um roadmap em ondas (0-4 semanas, 4-12 semanas, >12 semanas) agrupando ações por prontidão e dependências. - Incluir anexos no markdown: 1) checklists modelo por etapa crítica; 2) templates de registros mínimos por processo; 3) matriz de controles preventivos vs detectivos.
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 dois artefatos como input: a matriz de achados e o JSON estruturado do protocolo.
-
Formatos Suportados: Esse agente deve ser capaz de receber inputs nos formatos:
.json(JSON). - Número de caracteres esperado: Este agente deve ter capacidade para processar um input combinado de até 15.000 caracteres.
3.3.2 Especificação do Output
- Formato de output: O output deve incluir dois artefatos: um relatório em markdown e um JSON do plano com backlog_priorizado.
-
Exemplo de Estrutura de Output:
{ "relatorio_markdown": "## Visão Geral\nEste relatório apresenta... ", "backlog_priorizado": [ { "id_acao": "ACAO-01", "vinculo_id_achado": "ACH-01", "descricao_acao": "Automatizar registro inicial", "tipo_acao": "semiautomatico", "impacto_previsto": "Redução de 10 min", "esforco": "baixo", "prioridade": 85 } ] } - Número de caracteres esperado: O JSON e markdown gerados devem ter um tamanho combinado em torno de 7.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: Utiliza lógica interna para calcular prioridades e impactos.
- 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 (relatório em markdown e JSON do plano) é o entregável final e não é passada para outros agentes internos.
3.3.6 Regras de Orquestração e Transição
A execução deste agente finaliza o fluxo. O relatório e o plano gerados são os resultados que devem ser disponibilizados ao usuário.