1. Propósito e Escopo
Este documento define todos os prompts e detalhes de requisitos para um requisitos para o Fluxo de Agentes "Validação de Documentos de Alta", uma solução de automação projetada para garantir que todas as informações críticas nos documentos de alta estejam corretas e completas, antes da liberação do paciente. 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 é transformar o input de documentos de alta em um processo validado e seguro, garantindo precisão e integridade, reduzindo drasticamente o risco de omissões ou erros que possam impactar o cuidado contínuo do paciente.
2. Contexto e Problema
Cenário Atual
Em muitos hospitais e clínicas, os documentos de alta são frequentemente preenchidos manualmente, o que pode levar a erros e omissões. Problemas comuns incluem:
- Informações incorretas ou incompletas nos documentos de alta.
- Possível impacto negativo no cuidado contínuo do paciente devido a dados ausentes.
A falta de um processo automatizado de verificação pode resultar em atrasos e riscos para o paciente, além de aumentar a carga de trabalho da equipe médica.
Problemas Identificados
- Erros Manuais: A digitação manual de informações pode levar a erros que passam despercebidos.
- Documentação Incompleta: Campos críticos podem ser deixados em branco, impactando o cuidado do paciente.
- Atrasos na Liberação: Verificações manuais atrasam o processo de alta, afetando a fluidez do atendimento.
3. Impactos Esperados
A implementação deste fluxo de automação visa alcançar os seguintes resultados:
- Reduzir erros de documentação em pelo menos 90%.
- Aumentar a precisão das informações de alta.
- Acelerar o processo de liberação do paciente, garantindo que todos os dados estejam corretos e completos.
- Melhorar a continuidade do cuidado, proporcionando dados precisos e completos para o seguimento do paciente.
4. Visão Geral da Solução
O agente de IA para validação de documentos de alta verifica a precisão e integridade dos documentos, garantindo que todas as informações críticas estejam corretas e completas antes da liberação do paciente. 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 validação dos documentos de alta.
A solução consiste em um fluxo de automação composto por 3 agentes de IA. O processo inicia com a extração de dados dos documentos de alta e termina com a comunicação de alertas à equipe de saúde.
A execução dos agentes é sequencial e linear, seguindo a ordem definida na tabela abaixo.
| Agentes | Função Principal |
|---|---|
Agente de Extração Estruturada de Dados de Alta (RF 1)
| Converter o documento de alta em um JSON padronizado com todos os campos clínicos e administrativos necessários para validação. |
Agente de Validação de Integridade e Precisão de Alta (RF 2)
| Aplicar regras de negócio clínicas e administrativas para checar completude, consistência e correção do JSON extraído do documento de alta. |
Agente de Síntese de Alertas e Comunicação para Equipe (RF 3)
| Transformar o resultado da validação em um resumo acionável, priorizado por severidade, destacando correções necessárias antes da liberação do paciente. |
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 Extração Estruturada de Dados de Alta
1.1 Tarefa do Agente
Converter o documento de alta (PDF ou texto) em um JSON padronizado com todos os campos clínicos e administrativos necessários para validação.
1.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais Você está recebendo um documento de alta, que pode ser um PDF, uma imagem legível ou texto estruturado/não estruturado. Este documento contém informações clínicas e administrativas essenciais para a liberação do paciente. # 2. Objetivo Converter o documento de alta em um JSON padronizado que contenha todos os campos necessários para a validação subsequente, garantindo que as informações estejam estruturadas de forma adequada para o agente de validação. # 3. Regras que você deve seguir para gerar sua resposta - Extraia informações nas seguintes seções: identificação do paciente, dados administrativos do atendimento, diagnósticos (principal e secundários) com CID-10, procedimentos (com código TUSS quando explícito), profissional responsável (nome e CRM com UF), prescrições de alta, alergias, orientações (cuidados, sinais de alarme, restrições), informações de retorno/seguimento, exames pendentes, dispositivos/órteses/próteses, assinaturas e carimbo. - Normalizações obrigatórias: 1) Datas: formato ISO 8601 (YYYY-MM-DD) e data-hora como YYYY-MM-DDThh:mm:ssZ; se horário ausente, preencher hh:mm:ss como 00:00:00Z. 2) Telefone: formato E.164 (ex.: +5511999999999) se número completo estiver disponível; caso contrário, manter vazio. 3) CRM: padronizar como "CRM-UF-#####"; quando o número ou UF não constarem, preencher campos vazios mantendo a chave. 4) Unidades de dose: converter para mg, g, mcg, mL ou UI quando possível por leitura explícita; se não for possível, manter unidade textual original na chave unidade. 5) Frequência: padronizar padrões comuns (ex.: 8/8h, 12/12h, 1x/dia, 2x/dia); se texto livre, preservar texto livre em frequencia. - Extração estruturada de prescrições: cada item deve conter obrigatoriamente chaves medicamento, dose.quantidade, dose.unidade, via, frequencia, duracao.quantidade, duracao.unidade; se algum subcampo não for encontrado no documento, manter a chave com valor vazio ou 0 conforme o tipo. - CID-10: quando houver código entre parênteses ou ao lado da descrição, capturar e colocar em diagnósticos.principal.cid10 ou no array de secundários; se múltiplos, separar em principal e secundários conforme rótulos do documento; na ausência de rótulos, considerar o primeiro como principal. - Assinaturas: detectar menções a assinatura/carimbo do médico e do paciente/responsável; definir flags assinatura_presente e carimbo_presente como true/false; capturar data/hora se constarem junto à assinatura. - Orientações de alta: separar frases imperativas ou listas sob subtítulos típicos (ex.: Orientações, Cuidados, Sinais de Alarme, Restrições); popular arrays correspondentes; retorno deve conter data, local e especialidade quando explicitado; se constar "retorno em 7 dias", calcular a data adicionando 7 dias à data de alta quando a data de alta estiver presente; se data de alta ausente, manter apenas quantidade textual em observacoes na seção orientacoes. - Exames pendentes: capturar nome do exame, data de coleta quando mencionada, responsável indicado e prazo previsto se existir. - Dispositivos: capturar presença de cateteres, drenos, sondas; indicar se foram retirados ou mantidos e cuidados associados. - Campos obrigatórios devem sempre existir no JSON, mesmo que vazios, para padronização do agente seguinte. - Não inferir informações clínicas não presentes no documento; quando ambíguas, priorizar literalidade do texto e deixar campos vazios mantendo a chave. - Eliminar duplicidades óbvias (mesmo medicamento com mesma posologia repetido); manter apenas uma ocorrência consolidada.
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 alta 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 alta, que após ser processado, resulta em um JSON que é o output direto deste agente.
-
Formatos Suportados: Esse agente deve ser capaz de receber documentos nos formatos:
.pdf,.jpg,.png,.txt. - 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 no formato JSON contendo todos os campos clínicos e administrativos necessários para validação.
-
Exemplo de Estrutura de Output:
{ "paciente": {"nome": "", "id_interno": "", "data_nascimento": "YYYY-MM-DD", "sexo": "M|F|Outro|Ignorado", "contato": {"telefone_e164": "", "email": ""}, "responsavel": {"nome": "", "parentesco": ""}}, "atendimento": {"unidade": "", "leito": "", "convenio": "", "data_hora_alta": "YYYY-MM-DDThh:mm:ssZ"}, "diagnosticos": {"principal": {"descricao": "", "cid10": ""}, "secundarios": [{"descricao": "", "cid10": ""}]}, "procedimentos": [{"descricao": "", "codigo_tuss": "", "data": "YYYY-MM-DD"}], "profissionais": {"medico_responsavel": {"nome": "", "crm": "CRM-UF-#####"}}, "prescricoes_na_alta": [{"medicamento": "", "dose": {"quantidade": "", "unidade": "mg|g|mcg|mL|UI"}, "via": "VO|IV|IM|SC|NASAL|TOP|OUTRA", "frequencia": "ex.: 8/8h|1x/dia", "duracao": {"quantidade": 0, "unidade": "dias|semanas"}, "indicacao": "", "observacoes": ""}], "alergias": [{"substancia": "", "gravidade": "leve|moderada|grave"}], "orientacoes": {"cuidados": [""], "sinais_alarme": [""], "restricoes": [""], "retorno": {"data": "YYYY-MM-DD", "local": "", "especialidade": "", "agendado": true}}, "exames_pendentes": [{"nome": "", "coleta_data": "YYYY-MM-DD", "responsavel": "", "prazo_previsto": "YYYY-MM-DD"}], "dispositivos": [{"tipo": "", "status": "retirado|mantido", "cuidados": ""}], "assinaturas": {"medico": {"assinatura_presente": true, "carimbo_presente": true, "data_hora": "YYYY-MM-DDThh:mm:ssZ"}, "paciente_ou_responsavel": {"assinatura_presente": true, "data_hora": "YYYY-MM-DDThh:mm:ssZ"}} } - Número de caracteres esperado: O JSON gerado deve ser claro e estruturado, com um tamanho estimado em 3.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 Validação de Integridade e Precisão de Alta (RF 2).
1.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente de Validação de Integridade e Precisão de Alta (RF 2).
RF 2. Agente de Validação de Integridade e Precisão de Alta
2.1 Tarefa do Agente
Aplicar regras de negócio clínicas e administrativas para checar completude, consistência e correção do JSON extraído do documento de alta.
2.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um JSON padronizado produzido pelo Agente de Extração Estruturada de Dados de Alta. Este JSON contém todas as informações clínicas e administrativas extraídas do documento de alta.
# 2. Objetivo
Aplicar regras de validação para garantir que o JSON está completo, consistente e correto, identificando quaisquer omissões ou erros que possam impactar a liberação do paciente.
# 3. Regras que você deve seguir para gerar sua resposta
- Matriz de obrigatoriedade mínima (bloqueia alta se ausente):
1) atendimento.data_hora_alta
2) paciente.nome
3) profissionais.medico_responsavel.nome e profissionais.medico_responsavel.crm
4) diagnosticos.principal.descricao
5) Prescrições na alta: se houver medicamentos mencionados no texto, cada item deve ter medicamento, dose.quantidade, dose.unidade, via, frequencia, duracao.quantidade, duracao.unidade
6) orientacoes.cuidados (pelo menos 1), orientacoes.sinais_alarme (pelo menos 1)
7) orientacoes.retorno.agendado explicitado (true/false). Se true, exigir data ou janela de tempo. Se apenas janela (ex.: 7 dias), aceitar sem data calculada e marcar prazos_followup_validados=false.
- Validações de formato/conteúdo:
1) CRM: regex aceitável ^CRM-[A-Z]{2}-[0-9]{3,6}$; se não casar, registrar INT-CRM-001 (severidade média, não bloqueante) e recomendar correção de UF/numeração.
2) CID-10: regex aceitável ^[A-Z][0-9]{2}([A-Z0-9])(\.[A-Z0-9]{1,4})?$; se descrição presente sem código, registrar INT-CID-001 (severidade baixa, sugerir inclusão do código).
3) Datas: verificar que atendimento.data_hora_alta não é futura em mais de 24h do momento atual; se for, INT-DATA-002 (severidade alta, potencial erro de data).
4) Telefone: se presente e não for E.164, INT-TEL-001 (baixa).
- Consistências clínicas mínimas em prescrições:
1) Toda prescrição deve ter dose.quantidade numérica > 0 e unidade não vazia; se faltar, VAL-RX-001 (alta, bloqueante para o item).
2) Via deve estar dentre valores padronizados; se fora, normalizar para OUTRA e sinalizar VAL-RX-002 (média).
3) Frequência não pode ser vazia; padrões reconhecidos: "x/dia", "y/yh"; se texto livre sem periodicidade explícita, VAL-RX-003 (média).
4) Duração.quantidade > 0 e unidade presente; se faltante, VAL-RX-004 (média).
- Alergias x prescrições:
1) Se alergias[].substancia coincide textualmente com algum medicamento prescrito, sinalizar ALERTA-ALERGIA-001 (crítica, bloqueante) e listar o par conflito.
- Orientações obrigatórias:
1) Sinais de alarme deve conter ao menos um evento clínico (ex.: febre, dor intensa, sangramento). Se vazio, VAL-ORI-001 (média).
2) Se orientacoes.retorno.agendado = true e não houver data nem local/especialidade, VAL-RET-001 (média); se agendado=false e não há instrução clara de como proceder, VAL-RET-002 (baixa).
- Exames pendentes:
1) Se existir exames_pendentes, cada item deve ter pelo menos nome e responsável; se responsável vazio, VAL-EXA-001 (média).
- Assinaturas:
1) assinaturas.medico.assinatura_presente e assinaturas.medico.carimbo_presente devem ser true; se qualquer um for false, ASS-001 (alta, bloqueante).
2) assinaturas.paciente_ou_responsavel.assinatura_presente = true; se false, ASS-002 (média, não bloqueante em casos permitidos, mas recomendar coleta).
- Abreviações proibidas/restritas:
1) Se lista institucional for fornecida em input, varrer prescrições e orientações; cada ocorrência gera ABB-001 (baixa) com sugestão de termo por extenso.
- Cálculo de completude:
1) percentual_campos_preenchidos = (n_campos_obrigatorios_preenchidos / n_campos_obrigatorios_total) * 100 arredondado ao inteiro mais próximo.
- Determinação de severidade_global e status_integridade:
1) Se existir qualquer regra com bloqueia_alta=true ou alerta crítico, status_integridade = "reprovado" e severidade_global >= "alta".
2) Se não há bloqueantes, mas há violações médias/baixas, status_integridade = "aprovado_com_alertas"; caso contrário, "aprovado".
- Não inventar dados ausentes; quando a checagem depender de informação que não veio no input, marcar como "não aplicável" e não penalizar.
- Saída deve listar cada regra violada com: codigo, descricao, campo (dot notation), valor_encontrado, severidade, bloqueia_alta, recomendacao. 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 padronizado produzido pelo Agente de Extração Estruturada de Dados de Alta.
-
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 até 3.000 caracteres.
2.3.2 Especificação do Output
- Formato de output: O output deve ser um arquivo no formato JSON contendo a verificação completa, o status de integridade e detalhes de qualquer regra violada.
-
Exemplo de Estrutura de Output:
{ "verificacao_completa": true, "status_integridade": "aprovado|aprovado_com_alertas|reprovado", "percentual_campos_preenchidos": 0, "regras_violadas": [ {"codigo": "INT-001", "descricao": "Campo obrigatório ausente: data_hora_alta", "campo": "atendimento.data_hora_alta", "valor_encontrado": "", "severidade": "alta", "bloqueia_alta": true, "recomendacao": "Informar data e hora da alta."} ], "inconsistencias": [""], "omissoes": [""], "alertas_criticos": [""], "severidade_global": "baixa|media|alta|critica", "prazos_followup_validados": true } - Número de caracteres esperado: O JSON gerado deve ser claro e direto, com um tamanho estimado em 2.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 (JSON da validação) deve ser visível para o Agente de Síntese de Alertas e Comunicação para Equipe (RF 3).
2.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente de Síntese de Alertas e Comunicação para Equipe (RF 3).
RF 3. Agente de Síntese de Alertas e Comunicação para Equipe
3.1 Tarefa do Agente
Transformar o resultado da validação em um resumo acionável, priorizado por severidade, destacando correções necessárias antes da liberação do paciente.
3.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais Você está recebendo a saída do Agente de Validação de Integridade e Precisão de Alta, que contém o status de integridade do documento de alta e detalhes de qualquer regra violada. # 2. Objetivo Transformar o resultado da validação em um resumo acionável, priorizado por severidade, destacando correções necessárias antes da liberação do paciente. # 3. Regras que você deve seguir para gerar sua resposta - Definir alerta_necessario=true quando status_integridade = "reprovado" ou quando existir pelo menos uma regra com severidade "critica". - Construir resumo_priorizado ordenando regras_violadas por severidade (critica > alta > media > baixa) e, em empate, por código. - Preencher bloqueios_para_liberacao somente com as regras que tenham bloqueia_alta=true. - Gerar checklist_pre_liberacao contendo no mínimo: data/hora da alta confirmada; assinatura e carimbo do médico; diagnóstico principal com CID-10; posologia completa das prescrições; sinais de alarme presentes; retorno/seguimento definido; responsáveis por exames pendentes atribuídos. - mensagem_curta_para_time: criar uma frase de até 240 caracteres destacando quantidade de bloqueios e itens de atenção, ex.: "2 bloqueios (assinatura, data da alta) e 3 alertas (posologia, retorno, CID-10)." - Se nenhuma violação for encontrada, checklist_pre_liberacao deve ser uma lista de confirmação (ex.: "Documento revisado e completo"), e alerta_necessario=false.
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 a saída do Agente de Validação de Integridade e Precisão de Alta.
-
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 até 2.000 caracteres.
3.3.2 Especificação do Output
- Formato de output: O output deve ser um arquivo no formato JSON contendo um resumo priorizado das violações, bloqueios para liberação e um checklist pré-liberação.
-
Exemplo de Estrutura de Output:
{ "alerta_necessario": false, "resumo_priorizado": [ {"severidade": "critica|alta|media|baixa", "mensagem": "", "campo": "", "codigo_regra": "", "acao_recomendada": ""} ], "bloqueios_para_liberacao": [ {"codigo_regra": "", "descricao": "", "campo": ""} ], "checklist_pre_liberacao": ["Confirmar data/hora da alta", "Coletar assinatura do médico", "Incluir sinais de alarme nas orientações"], "mensagem_curta_para_time": "" } - Número de caracteres esperado: O JSON gerado deve ser claro e direto, com um tamanho estimado em 1.500 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 (JSON com resumo e alertas) é 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 resumo gerado é o resultado que deve ser disponibilizado ao usuário.