Agente de IA para Geração de Relatórios de Atendimento Médico

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

Como criar um agente de IA que sintetiza dados coletados durante o atendimento médico inicial para gerar relatórios detalhados e padronizados.

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

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

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

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.

© 2025 prototipe.ai. Todos os direitos reservados.