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