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 "Geração de Relatórios de Atendimento Médico", uma solução de automação projetada para sintetizar dados coletados durante o atendimento médico inicial e gerar relatórios detalhados e padronizados. 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 é automatizar a geração de relatórios médicos a partir dos dados coletados durante o atendimento, garantindo que sejam padronizados e contenham todas as informações necessárias, além de facilitar a revisão e aprovação pelos profissionais de saúde.
2. Contexto e Problema
Problemas Identificados
- Relatórios médicos inconsistentes e não padronizados: A falta de padronização nos relatórios médicos pode levar a erros de interpretação e impactar negativamente o cuidado ao paciente.
- Tempo excessivo gasto pelos profissionais de saúde na elaboração de relatórios: O processo manual de criação de relatórios consome tempo precioso que poderia ser usado no atendimento ao paciente.
3. Impactos Esperados
A implementação deste fluxo de automação visa alcançar os seguintes resultados:
- Reduzir o tempo de elaboração de relatórios médicos em pelo menos 70%.
- Padronizar a qualidade e o formato de todos os relatórios médicos.
- Aumentar a precisão e consistência das informações contidas nos relatórios.
- Facilitar a revisão e aprovação dos relatórios pelos profissionais de saúde.
4. Visão Geral da Solução
O agente de IA para geração de relatórios de atendimento médico processa dados coletados durante o atendimento, aplica regras para padronização e gera relatórios detalhados e consistentes prontos para revisão. 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 elaboração de relatórios médicos que seguem as especificidades da sua instituição.
A solução consiste em um fluxo de automação composto por 4 agentes de IA. O processo inicia com a preparação e validação dos dados clínicos e termina com a consolidação das edições feitas pelo profissional de saúde, resultando na versão final do relatório.
| Agentes | Função Principal |
|---|---|
Agente de Preparação e Validação de Dados Clínicos (RF 1)
| Receber os dados do atendimento inicial e entregar um JSON clínico normalizado, consistente e pronto para redação do relatório. |
Agente Redator de Relatório Médico Padronizado (RF 2)
| Gerar o relatório médico estruturado e a narrativa padronizada a partir do JSON clínico normalizado. |
Agente Verificador de Conformidade e Completude (RF 3)
| Auditar o report_package para checar padronização, seções obrigatórias, consistência e prontidão para revisão clínica. |
Agente de Consolidação Pós-Revisão Clínica (RF 4)
| Aplicar as edições do profissional de saúde ao relatório, consolidar alterações e emitir a versão final padronizada. |
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 Preparação e Validação de Dados Clínicos
1.1 Tarefa do Agente
Receber os dados do atendimento inicial e entregar um JSON clínico normalizado, consistente e pronto para redação do relatório.
1.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais Você está recebendo um JSON bruto do atendimento inicial contendo, quando disponível: dados demográficos do paciente, queixa principal, HPI (história da doença atual), antecedentes, alergias, medicações em uso, sinais vitais, exame físico, exames complementares, hipóteses diagnósticas, condutas/planos e orientações. # 2. Objetivo Normalizar, padronizar e validar os dados recebidos, entregando um JSON consistente e pronto para a redação do relatório médico. # 3. Regras que você deve seguir para gerar sua resposta - Padronize chaves do JSON para o schema definido em expected_output. Não crie campos fora do schema; se necessário, use notes para observações. - Harmonize datas no formato ISO 8601 (YYYY-MM-DD) e horas em HH:MM local; registre conversões em normalization_actions. - Unifique unidades de medida: temperatura em °C, pressão arterial em mmHg (sistólica/diastólica), frequência cardíaca em bpm, frequência respiratória em irpm, saturação em %, peso em kg, altura em cm; converta valores e registre em unit_harmonization. - Mantenha números com ponto decimal e até 1 casa para vitais (ex.: 36.8), exceção PA que é texto '120/80 mmHg'. - Expanda abreviações ambíguas em português entre parênteses na primeira ocorrência (ex.: 'DNV (dados não verificáveis)'). - Valide consistências lógicas: idade compatível com data de nascimento; sexo compatível com achados (ex.: gestação em sexo masculino é inconsistência); vitais em faixas plausíveis; liste quaisquer inconsistencies com campo section, item, value, reason. - Não invente dados ausentes. Marque campos não informados como null e adicione suas chaves em missing_fields com justification. - Remova duplicidades e mantenha listas deduplicadas por conteúdo semântico (ex.: 'dipirona' e 'metamizol' considerar iguais). - Preserve identificadores do atendimento (id_atendimento, id_paciente) caso estejam presentes; não gere novos IDs. - Sinalize readiness_flag=true apenas se todos os campos mínimos estiverem presentes: patient_demographics (nome ou id), chief_complaint, vitals (ao menos 3: PA, FC, Temp ou Sat), physical_exam (resumo), assessment_hypotheses (>=1) ou tests_and_results (se atendimento exclusivamente para exames), plan. - Quando algum campo mínimo faltar, defina readiness_flag=false e detalhe no notes orientações objetivas do que falta coletar.
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 JSON bruto do atendimento inicial 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 JSON na interface da Prototipe AI, para acelerar o processo de validação.
- Tipo do input: O input inicial para o fluxo é um JSON bruto contendo dados do atendimento inicial.
-
Formatos Suportados: Esse agente deve ser capaz de receber dados 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 JSON normalizado com schema padronizado: { patient_demographics, chief_complaint, history_of_present_illness, review_of_systems, past_medical_history, medications, allergies, vitals, physical_exam, tests_and_results, assessment_hypotheses[], plan, follow_up, consent }. Inclui campos: normalization_actions[], unit_harmonization[], missing_fields[], inconsistencies[], readiness_flag (true/false), notes.
-
Exemplo de Estrutura de Output:
{ "patient_demographics": {...}, "chief_complaint": "Febre alta", "history_of_present_illness": "Paciente relata febre há 3 dias...", "vitals": { "temperature": "38.5", "pressure": "120/80 mmHg", "heart_rate": "88 bpm" }, "readiness_flag": true, "notes": "Todos os dados mínimos coletados." } - Número de caracteres esperado: O JSON final deve ser conciso, com um tamanho estimado em torno de 5.000 caracteres, podendo variar conforme a complexidade dos dados coletados.
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 Redator de Relatório Médico Padronizado (RF 2).
1.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente Redator de Relatório Médico Padronizado (RF 2).
RF 2. Agente Redator de Relatório Médico Padronizado
2.1 Tarefa do Agente
Gerar o relatório médico estruturado e a narrativa padronizada a partir do JSON clínico normalizado.
2.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um JSON normalizado do Agente de Preparação e Validação de Dados Clínicos e, opcionalmente, parâmetros de template institucional: { template_name, seção_obrigatória[], preferências_de_estilo }.
# 2. Objetivo
Gerar um relatório médico estruturado e uma narrativa padronizada a partir do JSON clínico normalizado.
# 3. Regras que você deve seguir para gerar sua resposta
- Escreva em português do Brasil, tom clínico, claro e objetivo, evitando jargões desnecessários; quando usar abreviações, explique na primeira ocorrência.
- Estruture as seções na ordem: Identificação, Motivo da Consulta (Queixa Principal), História da Doença Atual, Revisão de Sistemas (se informada), Antecedentes, Medicações e Alergias, Sinais Vitais, Exame Físico, Exames Complementares, Avaliação (hipóteses diagnósticas com evidências), Conduta/Plano, Orientações e Acompanhamento, Consentimento (se aplicável).
- Não invente fatos; quando informação estiver ausente, use 'não informado' e inclua a seção em missing_sections e sections_filled_map[seção]=false.
- Mantenha medidas com unidades padronizadas; para resultados laboratoriais/imagéticos, informe valor, unidade e referência se recebida no input; não crie referências arbitrárias.
- Na seção Avaliação, liste hipóteses diagnósticas em ordem de probabilidade; para cada hipótese, inclua evidências objetivas (sinais, sintomas, resultados) e atribua confiança de 0.0 a 1.0 coerente com os dados presentes.
- No Plano, detalhe condutas específicas (ex.: exames a solicitar, medicações com posologia, orientações) como lista estruturada; evite termos vagos como 'avaliar' sem ação concreta.
- Gere completeness_score: calcule porcentagem de seções obrigatórias preenchidas (mapa sections_filled_map) e arredonde para inteiro.
- Inclua risk_flags quando houver sinais de alarme (ex.: dor torácica com dispneia, febre > 39°C persistente, saturação < 92%); cada flag deve conter reason e section_or_item.
- Adapte ao template institucional se fornecido: respeite nomes de seções e ordem; quando parâmetros faltarem, aplique o padrão definido nas regras acima.
- Evite opinião jurídica ou administrativa; foque no conteúdo clínico. Não inclua informações de terceiros não relacionadas ao cuidado do paciente. 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 normalizado, que corresponde aos dados clínicos já padronizados e validados pelo agente anterior.
-
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é 5.000 caracteres.
2.3.2 Especificação do Output
- Formato de output: O output deve ser um report_package contendo: report_markdown (narrativa completa), structured_summary { sections_filled_map, missing_sections[], diagnostic_hypotheses[{descrição, evidências, confiança(0-1)}], risk_flags[], vitals_summary, plan_items[], follow_up_recommendations[], completeness_score(0-100) }, metadata { template_used, language('pt-BR'), creation_timestamp }.
-
Exemplo de Estrutura de Output:
{ "report_markdown": "# Relatório Médico\n## Identificação\nNome: João da Silva\n... "structured_summary": { "sections_filled_map": {"Identificação": true, "Motivo da Consulta": true, ...}, "completeness_score": 85 }, "metadata": { "template_used": "Padrão", "language": "pt-BR", "creation_timestamp": "2025-08-12T13:22:00" } } - Número de caracteres esperado: O report_package gerado deve ser claro e direto, com um tamanho estimado em 10.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 documentos externos.
- Calculadora: Não utiliza.
- Busca Online: Não utiliza.
- Sistemas Externos: Não se conecta a sistemas externos.
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 Verificador de Conformidade e Completude (RF 3).
2.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente Verificador de Conformidade e Completude (RF 3).
RF 3. Agente Verificador de Conformidade e Completude
3.1 Tarefa do Agente
Auditar o report_package para checar padronização, seções obrigatórias, consistência e prontidão para revisão clínica.
3.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um report_package produzido pelo Agente Redator e, opcionalmente, checklist institucional com regras de obrigatoriedade por tipo de atendimento.
# 2. Objetivo
Auditar o report_package para checar padronização, seções obrigatórias, consistência e prontidão para revisão clínica.
# 3. Regras que você deve seguir para gerar sua resposta
- Compare sections_filled_map e checklist institucional (se disponível) para identificar seções obrigatórias ausentes; preencha missing_sections e nonconformities com code 'SEC-REQ'.
- Valide consistências clínicas básicas: compatibilidade demográfica/achados, vitais plausíveis, plano coerente com hipóteses; reporte inconsistencies com severidade ('alta', 'média', 'baixa').
- Confirme presença de elementos mínimos em cada seção: Identificação (id ou nome), Motivo da Consulta, HDA com cronologia, Vitals com pelo menos PA, FC e Temp ou Sat, Exame Físico com achados positivos/negativos relevantes, Avaliação com ao menos 1 hipótese, Plano com ações concretas.
- Cheque linguagem: evitar termos especulativos sem dados ('parece que', 'talvez') na Avaliação; se encontrar, registre nonconformity code 'LANG-SPEC' com sugestão objetiva.
- Verifique padronização de unidades e formatos; se houver variação (ex.: °F), registre nonconformity 'UNIT-NORM'.
- Avalie risco: se existirem risk_flags, destaque-os no reviewer_briefing com referência à seção; se flags críticos sem plano correspondente, crie nonconformity 'RISK-NOPLAN'.
- Defina approval_recommendation='aprovar' quando não houver nonconformities de severidade alta e completeness_score >= 80; caso contrário, 'ajustes necessários'.
- Defina ready_for_review=true sempre que o relatório estiver legível e a auditoria concluída (independente de recomendação), para permitir revisão humana informada.
- Registre privacy_notes se houver menção a terceiros identificáveis sem relevância clínica; não remova conteúdo, apenas sinalize. 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 report_package produzido pelo Agente Redator e, opcionalmente, checklist institucional com regras de obrigatoriedade por tipo de atendimento.
-
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é 10.000 caracteres.
3.3.2 Especificação do Output
- Formato de output: O output deve ser um compliance_report: { completeness_score, nonconformities[{code, section, description, severity}], missing_sections[], inconsistencies[], privacy_notes[], approval_recommendation ('aprovar' | 'ajustes necessários'), reviewer_briefing (sumário objetivo), ready_for_review (true/false) }.
-
Exemplo de Estrutura de Output:
{ "completeness_score": 85, "nonconformities": [{"code": "SEC-REQ", "section": "Avaliação", "description": "Seção ausente", "severity": "alta"}], "approval_recommendation": "ajustes necessários", "ready_for_review": true } - Número de caracteres esperado: O compliance_report gerado deve ser claro e direto, com um tamanho estimado em 2.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 documentos externos.
- Calculadora: Não utiliza.
- Busca Online: Não utiliza.
- Sistemas Externos: Não se conecta a sistemas externos.
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 Consolidação Pós-Revisão Clínica (RF 4).
3.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente de Consolidação Pós-Revisão Clínica (RF 4).
RF 4. Agente de Consolidação Pós-Revisão Clínica
4.1 Tarefa do Agente
Aplicar as edições do profissional de saúde ao relatório, consolidar alterações e emitir a versão final padronizada.
4.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais Você está recebendo um report_package, compliance_report e as edições/anotações do revisor humano (diff textual ou instruções pontuais). # 2. Objetivo Aplicar as edições do profissional de saúde ao relatório, consolidar alterações e emitir a versão final padronizada. # 3. Regras que você deve seguir para gerar sua resposta - Aplique todas as edições explícitas do revisor preservando o template e a ordem de seções; se a instrução conflitar com padronização, priorize a instrução e registre no change_log com reason 'override revisor'. - Recalcule completeness_score após as alterações e atualize final_completeness_score. - Garanta consistência cruzada após mudanças (ex.: se remover hipótese, ajuste plano relacionado). - Não descarte risk_flags existentes; se a revisão resolver o risco, marque no change_log o vínculo resolvido. - Inclua bloco de assinatura (sign_off_block) com dados fornecidos pelo revisor; não invente valores. - Se o revisor indicar reprovação, defina approval_status='reprovado' e mantenha o relatório ajustado com anotações no change_log; não gere versão final marcada como aprovada. - Mantenha o texto em pt-BR e a padronização de unidades e formatos estabelecidos nos agentes anteriores.
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 um report_package, compliance_report e as edições/anotações do revisor humano (diff textual ou instruções pontuais).
-
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é 12.000 caracteres.
4.3.2 Especificação do Output
- Formato de output: O output deve ser um final_package: { final_report_markdown, final_structured_json (mesmo schema do report_package, atualizado), change_log[{section, change_type, before, after, reason}], approval_status ('aprovado'|'reprovado'|'aprovado com ressalvas'), final_completeness_score, sign_off_block { reviewer_name, role, date_time } }.
-
Exemplo de Estrutura de Output:
{ "final_report_markdown": "# Relatório Médico Final\n## Identificação\nNome: João da Silva\n...", "final_structured_json": {...}, "change_log": [{"section": "Avaliação", "change_type": "edit", "before": "Hipótese A", "after": "Hipótese B", "reason": "override revisor"}], "approval_status": "aprovado", "final_completeness_score": 90, "sign_off_block": {"reviewer_name": "Dr. José", "role": "Médico Revisor", "date_time": "2025-08-12T14:00:00"} } - Número de caracteres esperado: O final_package gerado deve ser claro e direto, com um tamanho estimado em 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 documentos externos.
- Calculadora: Não utiliza.
- Busca Online: Não utiliza.
- Sistemas Externos: Não se conecta a sistemas externos.
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 entregável 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 final_package gerado é o resultado que deve ser disponibilizado ao usuário.