Agente de IA para Geração de Relatórios de Exames de Imagem

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

Como criar um agente de IA que gera relatórios detalhados a partir de exames de imagem.

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 um agente de IA que gera relatórios detalhados a partir de exames de imagem, destacando áreas de interesse e possíveis diagnósticos. 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 de exames de imagem, integrando-se com sistemas de registros médicos eletrônicos e oferecendo opções de personalização para atender às necessidades específicas dos médicos e pacientes.

2. Contexto e Problema

Cenário Atual

No cenário atual, a geração de relatórios de exames de imagem é um processo manual, sujeito a erros humanos que podem impactar diagnósticos. Há uma demanda crescente por relatórios que sejam não apenas precisos, mas também detalhados e personalizados para cada paciente.


Problemas Identificados

  • Necessidade de rapidez e precisão: A geração manual de relatórios é lenta e propensa a erros.
  • Impacto de erros humanos: Erros na criação de relatórios podem resultar em diagnósticos incorretos.
  • Demanda por personalização: Médicos e pacientes esperam relatórios que atendam a necessidades específicas.

3. Impactos Esperados

A implementação deste agente de IA visa alcançar os seguintes resultados:

  • Acelerar a geração de relatórios de exames de imagem.
  • Aumentar a precisão dos relatórios, reduzindo a possibilidade de erros humanos.
  • Fornecer relatórios personalizados que atendam às necessidades dos médicos e pacientes.
  • Integrar-se com sistemas de registros médicos eletrônicos para um fluxo contínuo de informações.

4. Visão Geral da Solução

O agente de IA para geração de relatórios de exames de imagem analisa imagens médicas, gera relatórios detalhados automaticamente, destaca áreas de interesse e possíveis diagnósticos, e integra-se com sistemas de registros médicos eletrônicos. 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 que seguem as especificidades da sua empresa.

A solução consiste em um fluxo de automação composto por vários agentes de IA. O processo inicia com a obtenção de dados clínicos e metadados do exame e termina com a geração de um relatório final em markdown e JSON estruturado.

Agentes Função Principal
Agente de Execução de Chamada à API Realizar chamada à API do Sistema EMR para obter dados clínicos e metadados do exame.
Agente de Preparação de Contexto Clínico Normalizar e estruturar os metadados do exame e preferências médicas em um blueprint padronizado.
Agente de Análise de Imagens Médicas Analisar as imagens do exame e produzir achados estruturados, regiões de interesse e hipóteses diagnósticas.
Agente de Comparação com Exames Anteriores Comparar achados atuais com relatórios anteriores quando disponíveis e qualificar tendências.
Agente de Geração de Relatório Final Gerar o relatório final em markdown e JSON estruturado, destacando áreas de interesse e possíveis diagnósticos.

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 Execução de Chamada à API

1.1 Tarefa do Agente

Realizar chamada à API do Sistema EMR para obter dados clínicos e metadados do exame (paciente, indicação clínica, modalidade, preferências do solicitante e relatórios anteriores).

1.2 Prompt ou Instruções do Agente
 Este agente não precisa de instruções para LLM. Sua única função é executar a chamada à API com o payload recebido e retornar o corpo da resposta sem transformações. 
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 payload pronto para execução da chamada à API. Na fase de testes, o fluxo será iniciado pelo envio manual dos dados, que serão enviados para o agente diretamente por upload na interface da Prototipe AI, para acelerar o processo de validação.
  • Tipo do input: Payload pronto para execução da chamada: { endpoint, method, headers, auth_token, params: { patient_id, exam_id } }
  • Formatos Suportados: Este 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.

1.3.2 Especificação do Output

  • Formato de output: JSON com: { patient_demographics, clinical_indication, modality, body_part, contrast_info, exam_datetime, referring_physician_prefs, prior_reports: [ { exam_id, report_text, exam_datetime, modality, body_part } ] }
  • Número de caracteres esperado: O JSON gerado terá um tamanho aproximado de 3.000 caracteres.

1.3.3 Parâmetros de Geração

  • Modelo: Não se aplica.
  • Temperatura: Não se aplica.

1.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Executa chamadas à API do sistema EMR.

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 de Preparação de Contexto Clínico (RF 2).

RF 2. Agente de Preparação de Contexto Clínico

2.1 Tarefa do Agente

Normalizar e estruturar os metadados do exame e preferências médicas em um blueprint padronizado de laudo e parâmetros de personalização.

2.2 Prompt ou Instruções do Agente
 - Defina language com base em referring_physician_prefs.language; se ausente, use 'pt-BR'.
- Mapeie modality+body_part para um report_template_id padronizado (ex.: 'RX_TORAX', 'TC_CRANIO', 'RM_JOELHO').
- Construa sections com ordem explícita: Identificação, Técnica, Achados, Impressão Diagnóstica, Recomendações, Limitações, Resumo ao Paciente (se personalization.patient_friendly_summary=true).
- Gere clinical_questions alinhadas à indicação clínica. Ex.: dor torácica: consolidações, derrame pleural, cardiomegalia; TC crânio: hemorragia, desvio de linha média, sinais de hipertensão intracraniana.
- measurement_units por modalidade: RX/TC/RM em mm para medidas lineares; áreas em mm²; volumes em mL quando aplicável; densidade na TC em UH; sinal RM qualitativo (hipo/iso/hiperintenso); doppler em cm/s.
- Liste red_flags específicas do estudo (ex.: pneumotórax, hemorragia aguda, trombo, dissecção) para checagem explícita na análise.
- Configure personalization.level_of_detail: 'conciso'|'padrão'|'detalhado' conforme preferência do médico; ajuste granularidade das seções conforme este nível.
- Defina comparison_plan.prior_available=true se prior_reports tiver tamanho > 0 e inclua prior_refs com {exam_id, exam_datetime, modality, body_part}.
- Garanta que dados sensíveis do paciente fiquem apenas em Identificação; não repita nome/ID em outras seções. 
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: JSON do EMR: { patient_demographics, clinical_indication, modality, body_part, contrast_info, exam_datetime, referring_physician_prefs, prior_reports[] }
  • Formatos Suportados: Este 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.500 caracteres.

2.3.2 Especificação do Output

  • Formato de output: Blueprint estruturado: { language, report_template_id, sections: [id, title, required:boolean, order], clinical_questions:[{id, prompt, section_id}], measurement_units:{by_modality}, red_flags:[...], personalization:{ tone, level_of_detail, patient_friendly_summary:boolean }, comparison_plan:{prior_available:boolean, prior_refs:[...]} }
  • Número de caracteres esperado: O JSON gerado terá um tamanho aproximado de 4.000 caracteres.

2.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.7

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 utiliza.

2.3.5 Memória

  • Visibilidade das Instruções (Prompt): As instruções não são visíveis para agentes subsequentes.
  • Visibilidade da Resposta: A resposta gerada por este agente deve ser visível para o Agente de Análise de Imagens Médicas (RF 3).

2.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente de Análise de Imagens Médicas (RF 3).

RF 3. Agente de Análise de Imagens Médicas

3.1 Tarefa do Agente

Analisar as imagens do exame e produzir achados estruturados, regiões de interesse e hipóteses diagnósticas para revisão médica, seguindo o blueprint.

3.2 Prompt ou Instruções do Agente
 - Para cada clinical_question, produza 0..N areas_of_interest; quando presente, inclua: descrição anatômica clara, lateralidade, referência de série/slice ou vista; medidas com unidade do measurement_units adequado.
- Registre likelihood em escala contínua 0-1 para cada hipótese/finding; valores ≥0.8 = alta suspeição; 0.5–0.79 = intermediária; <0.5 = baixa.
- Classifique red_flags: para cada item do blueprint.red_flags, indique present boolean e evidência em linguagem objetiva (ex.: 'linha pleural visível com ausência de marcadores vasculares periféricos').
- Documente limitações e artefatos que impactem a confiança diagnóstica (ex.: motion, baixa resolução, campo de visão incompleto) e indique como afetam a interpretação.
- Evite declarações de diagnóstico definitivo; rotule hipóteses como 'sugerido' e marque sempre 'para revisão médica'.
- Para modalidades com contraste, descreva padrão de realce (ex.: homogêneo, periférico) quando aplicável.
- Vincule cada area_of_interest a uma seção do blueprint (findings_by_section) e a um clinical_question_id quando for resposta a uma pergunta.
- Não inclua dados pessoais do paciente fora da seção apropriada; use apenas referências de série/slice sem metadados sensíveis. 
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: Imagens médicas (DICOM/JPEG/PNG) e blueprint: { sections, clinical_questions, measurement_units, red_flags, personalization }
  • Formatos Suportados: Este agente deve ser capaz de receber inputs nos formatos DICOM, JPEG, PNG e JSON.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input combinado de até 10.000 caracteres e até 100 imagens.

3.3.2 Especificação do Output

  • Formato de output: JSON de achados: { areas_of_interest:[{id, description_anatomical, laterality, slice_or_series_ref, size:{value,unit}, density_or_signal, margins, enhancement, likelihood:0-1, related_question_id }], findings_by_section:{section_id:[finding_ids]}, red_flags_detected:[{flag, present:boolean, evidence}], image_quality:{artifacts:boolean, limitations:[...]}, suggestions:{differentials:[{label, likelihood}], follow_up:[{type, timeframe}]}, uncertainty_notes:[...] }
  • Número de caracteres esperado: O JSON gerado terá um tamanho aproximado de 5.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 utiliza.

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 Comparação com Exames Anteriores (RF 4).

RF 4. Agente de Comparação com Exames Anteriores

4.1 Tarefa do Agente

Comparar achados atuais com relatórios anteriores quando disponíveis e qualificar tendências.

4.2 Prompt ou Instruções do Agente
 - Defina comparability=false e rationale se modality ou body_part forem distintos de modo impeditivo; caso contrário, true.
- Classifique change usando critérios: 'novo' se sem menção prévia; 'resolvido' se presente antes e ausente agora; 'aumentou' se variação linear ≥2 mm ou ≥20% (quando disponível); 'reduziu' se variação ≤-2 mm ou ≤-20%; 'estável' caso contrário.
- Calcule time_interval_days entre exames usando exam_datetime; se ausente, deixe null e reduza confidence em 0.2.
- Vincule cada delta a um finding_ref do current_findings; inclua trecho de prior_reference_text relevante quando possível.
- Defina overall_trend pela maioria ponderada dos deltas (aumentou/piora e reduziu/melhora), ignorando itens 'estável'. 
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: current_findings JSON e prior_reports: [ { report_text, exam_datetime, modality, body_part } ]
  • Formatos Suportados: Este agente deve ser capaz de receber inputs nos formatos JSON.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 5.000 caracteres.

4.3.2 Especificação do Output

  • Formato de output: Comparativo estruturado: { comparability:boolean, rationale, deltas:[{ finding_ref, prior_reference_text, change:'aumentou'|'reduziu'|'estável'|'novo'|'resolvido', size_delta_mm: number|null, time_interval_days, confidence:0-1 }], overall_trend:'melhora'|'piora'|'estável' }
  • Número de caracteres esperado: O JSON gerado terá um tamanho aproximado de 4.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: Utiliza lógica interna para calcular intervalos de tempo e variações.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

4.3.5 Memória

  • Visibilidade das Instruções (Prompt): As instruções não são visíveis para agentes subsequentes.
  • Visibilidade da Resposta: A resposta gerada por este agente deve ser visível para o Agente de Geração de Relatório Final (RF 5).

4.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente de Geração de Relatório Final (RF 5).

RF 5. Agente de Geração de Relatório Final

5.1 Tarefa do Agente

Gerar o relatório final em markdown e JSON estruturado, destacando áreas de interesse e possíveis diagnósticos, com opções de personalização.

5.2 Prompt ou Instruções do Agente
 - Estruture o relatório seguindo sections do blueprint em ordem: Identificação (mínima, sem dados sensíveis além do necessário), Técnica, Achados, Comparação (se houver), Impressão Diagnóstica, Recomendações, Limitações e Resumo ao Paciente (se habilitado).
- Em highlighted_areas, inclua uma lista numerada com resumo objetivo, referência de série/slice e medida principal com unidade.
- Em suggested_diagnoses, liste no máximo 5 hipóteses ordenadas por likelihood; inclua racional baseado em achados e padrões descritos; rotule como 'para revisão médica'.
- Ajuste a extensão e detalhamento conforme personalization.level_of_detail. Se 'conciso', use frases curtas e foco nas conclusões; se 'detalhado', inclua descrições de padrões e medidas secundárias.
- Converta todas as medidas para as unidades definidas em measurement_units.
- Em limitations, traga image_quality e suas implicações na confiança.
- Se personalization.patient_friendly_summary=true, crie um parágrafo em linguagem acessível, sem termos técnicos e sem apresentar hipóteses não confirmadas como diagnósticos.
- Inclua no JSON campos sinalizadores: { for_medical_review:true, auto_generated:true, version:'v1' }. 
5.3 Configurações do Agente

5.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 4).
  • Tipo do input: Blueprint, current_findings, e quando aplicável, comparative_deltas.
  • Formatos Suportados: Este agente deve ser capaz de receber inputs nos formatos JSON.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 8.000 caracteres.

5.3.2 Especificação do Output

  • Formato de output: Relatório em markdown e JSON exportável: { markdown_report, fhir_like_json:{ sections,... }, highlighted_areas:[{id, summary, slice_ref}], suggested_diagnoses:[{label, likelihood, rationale}], recommendations:[...], limitations:[...], patient_friendly_summary?:string, personalization_applied:{...} }
  • Número de caracteres esperado: O JSON gerado terá um tamanho aproximado de 7.000 caracteres.

5.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

5.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Após a geração, o envio deste relatório ao sistema de registros médicos eletrônicos deve ser configurado manualmente na plataforma (Envio da Resposta do Agente). Este agente não executa essa integração diretamente.

5.3.5 Memória

  • Visibilidade das Instruções (Prompt): As instruções não são visíveis para agentes subsequentes.
  • Visibilidade da Resposta: A resposta (relatório final) é o entregável final e não é passada para outros agentes internos.

5.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 usuário.

© 2025 prototipe.ai. Todos os direitos reservados.