Evaluating Large Language Models for Translating Multimodal Phenotype Documentations into Executable EHR Phenotyping Algorithms

Este estudo avalia modelos de linguagem de grande escala de ponta para traduzir documentação multimodal de fenótipos clínicos em algoritmos executáveis de prontuário eletrônico, constatando que, embora interpretem efetivamente textos estruturados, seu desempenho degrada-se significativamente com entradas apenas de diagramas, identificando finalmente a qualidade da documentação, e não a capacidade do modelo, como o principal gargalo.

O essencial

Imagine que você é um chef de cozinha mestre tentando recriar um prato famoso, mas não tem a receita. Em vez disso, você tem uma pilha bagunçada de anotações, algumas rabiscadas em guardanapos, outras desenhadas como cartoons e algumas escritas em uma mistura confusa de idiomas. Seu objetivo é transformar essas anotações desorganizadas em um manual de instruções preciso, passo a passo, que uma cozinha robótica possa seguir para cozinhar o prato perfeitamente.

Este artigo trata de testar dois chefs de IA superinteligentes (chamados Modelos de Linguagem de Grande Porte, ou LLMs) para ver se eles podem realizar esse trabalho para a pesquisa médica.

O Problema: A Receita "Perdida na Tradução"

Na pesquisa médica, os cientistas definem grupos específicos de pacientes (como "pessoas com Diabetes Tipo 2") usando regras complexas. Essas regras geralmente são escritas em documentos legíveis por humanos que parecem uma mistura de histórias, fluxogramas e tabelas.

Para usar essas regras no sistema computacional de um hospital, um especialista humano precisa traduzi-las manualmente para uma linguagem de computador (SQL). Isso é como traduzir um poema para código de computador. Leva muito tempo, é extremamente tedioso e, se dois especialistas diferentes fizerem isso, podem acabar com resultados ligeiramente diferentes. Os pesquisadores queriam ver se a IA poderia realizar essa tradução automaticamente.

O Experimento: Testando os Chefs de IA

Os pesquisadores selecionaram dois dos modelos de IA mais inteligentes disponíveis (o GPT o3 da OpenAI e o Claude Opus 4.1 da Anthropic) e forneceram a eles cinco "receitas" diferentes (definições médicas para condições como lesão renal, ataques cardíacos e diabetes) de uma biblioteca pública chamada PheKB.

Eles testaram a IA de três maneiras diferentes, como dar ao chef diferentes tipos de instruções:

1. O Pacote Completo: A IA recebeu o documento inteiro (texto, gráficos e diagramas).
2. Apenas a História: A IA recebeu apenas o texto escrito e as tabelas, mas nenhuma imagem.
3. Apenas as Imagens: A IA recebeu apenas os diagramas e fluxogramas, sem nenhuma palavra.

Os Resultados: O Que Funcionou e o Que Não Funcionou

1. A Armadilha "Apenas Imagens"
Quando a IA tentou ler apenas os diagramas (os fluxogramas), falhou miseravelmente. Era como pedir a um chef que cozinhasse uma refeição complexa apenas olhando para um desenho de uma panela e um garfo, sem nenhum texto explicando os ingredientes ou os níveis de calor. A IA perdeu detalhes cruciais, errou o tempo e produziu instruções que não funcionariam.

2. A "História" é o Rei
Quando a IA recebeu o texto escrito (mesmo sem as imagens), ela fez um trabalho muito bom. Acontece que as palavras escritas continham quase todas as informações necessárias. A IA conseguiu entender a lógica e escrever o código de computador com precisão.

3. A IA é um Excelente Rascunhista, Não um Editor Final
Ambos os modelos de IA foram surpreendentemente bons em entender o panorama geral e a lógica das regras. No entanto, cometeram tipos específicos de erros:

• Ingredientes Faltantes: Às vezes, esqueceram de incluir códigos médicos específicos (como um tipo específico de medicamento).
• Números Errados: Podiam errar um limite (por exemplo, dizendo "pressão arterial acima de 140" quando a regra era "acima de 150").
• Inventar Coisas: Às vezes, a IA inventava regras ou condições que não estavam no documento original de forma alguma (uma "alucinação").
• Confundir o Formato: Ao examinar diagramas, frequentemente não conseguiam descobrir como transformar uma seta visual em um comando lógico "se-então" de computador.

A Grande Conclusão

O artigo conclui que esses modelos de IA não estão prontos para substituir especialistas humanos ainda. Eles não podem simplesmente olhar para um documento bagunçado e cuspir um programa de computador perfeito e pronto para uso.

No entanto, eles são excelentes geradores de primeiro rascunho. Se você lhes der texto claro e estruturado, eles podem escrever um ponto de partida muito bom para o código. Mas, como podem cometer erros sutis, porém perigosos (como errar um número ou omitir uma regra), um especialista humano deve sempre verificar seu trabalho.

A Lição Final:
O maior problema não é que a IA não seja inteligente o suficiente; é que os documentos médicos não são escritos de uma maneira fácil para os computadores lerem. Se médicos e pesquisadores padronizassem suas anotações para serem mais claras e estruturadas (como escrever uma receita em um formato padrão em vez de rabiscar em um guardanapo), a IA se tornaria muito mais útil. Até lá, a IA é uma assistente útil, mas o especialista humano deve permanecer o chefe.

Resumo técnico

Resumo Técnico: Avaliação de Grandes Modelos de Linguagem para Traduzir Documentações Multimodais de Fenótipos em Algoritmos Executáveis de Fenotipagem de Prontuários Eletrônicos

Declaração do Problema
A tradução de definições de fenótipos clínicos em consultas executáveis a bancos de dados de Prontuários Eletrônicos (EHR) é um gargalo crítico, porém intensivo em mão de obra, na pesquisa biomédica. Embora os algoritmos de fenotipagem sejam essenciais para identificar coortes de pacientes em escala, eles são tipicamente documentados em formatos de alto nível e legíveis por humanos (texto narrativo, tabelas, fluxogramas, diagramas) em vez de formas prontas para computação. Converter essas especificações multimodais em linguagem de consulta estruturada (SQL) adaptada a modelos de dados específicos (por exemplo, OMOP CDM) exige esforço manual, expertise de domínio e validação iterativa. Esse processo introduz variabilidade interpretativa, limitando a portabilidade, a comparabilidade e a reutilização de coortes entre instituições. Embora os Grandes Modelos de Linguagem (LLMs) tenham demonstrado proficiência na geração de código e no raciocínio multi-etapa, permanece incerto se eles podem converter fielmente documentações de fenótipos multimodais do mundo real em SQL executável e conforme os padrões.

Metodologia
Este estudo avaliou sistematicamente a capacidade de dois LLMs de vanguarda — OpenAI GPT o3 e Claude Opus 4.1 — de traduzir documentações de fenótipos em consultas SQL compatíveis com o OMOP.

• Conjunto de Dados: Cinco fenótipos clínicos estabelecidos foram selecionados do PheKB: Lesão Renal Aguda (AKI), Doenças Autoimunes (ADs), Hipercolesterolemia Familiar (FH), Eventos Adversos Cardiovasculares Maiores (MACE) e Diabetes Mellitus Tipo 2 (T2DM). Estes foram escolhidos por seus diversos domínios clínicos e complexidades variadas de documentação.
• Modalidades de Entrada: Para isolar o impacto do formato de documentação, três cenários de entrada foram testados para cada fenótipo e modelo:
  1. Documento Completo: Texto narrativo, tabelas, diagramas e pseudocódigo.
  2. Apenas Texto: Texto narrativo e tabelas (excluindo diagramas e pseudocódigo).
  3. Apenas Diagrama: Diagramas visuais exclusivamente.
• Pipeline de Prompting: Um pipeline de cadeia de pensamento de quatro estágios foi empregado:
  1. Extração de um pseudocódigo estruturado a partir da entrada.
  2. Verificação do pseudocódigo contra o documento fonte.
  3. Geração de SQL executável com base no pseudocódigo verificado.
  4. Revisão e correção do SQL gerado.
• Avaliação: Dois especialistas em fenotipagem clínica classificaram independentemente as consultas geradas em uma escala de 0 a 4 em sete dimensões: precisão lógica/booleana, implementação de restrições temporais, precisão do conjunto de valores, correção do esquema OMOP, eficiência de codificação, legibilidade humana e prontidão para implantação local. A concordância entre avaliadores foi substancial (kappa de Cohen > 0,79).
• Análise de Erros: Uma revisão qualitativa categorizou as falhas em sete tipos distintos: erros de fidelidade lógica, incompletude do conjunto de conceitos, erros de esquema/implementação, erros de limite/parâmetro, alucinações, subespecificação/sobre-generalização e limitações de interpretação de modalidade.

Principais Resultados

• Sensibilidade à Modalidade de Entrada: A qualidade do SQL gerado foi altamente sensível à representação de entrada. Fornecer apenas diagramas resultou em uma degradação dramática no desempenho em todas as dimensões de avaliação, particularmente na precisão do conjunto de valores, restrições temporais e precisão lógica. Por outro lado, a entrada apenas em texto produziu desempenho aproximando-se estreitamente ao da entrada de documento completo, sugerindo que a prosa narrativa captura a maioria das informações necessárias para a geração de SQL.
• Desempenho do Modelo: Sob condições de documento completo e apenas texto, o Claude Opus 4.1 geralmente alcançou pontuações melhores ou comparáveis em cinco das sete dimensões, enquanto o OpenAI o3 superou em precisão lógica/booleana e prontidão para implantação local. Em cenários de apenas diagrama, as lacunas de desempenho estreitaram-se, embora o OpenAI o3 mantivesse uma vantagem na precisão lógica.
• Variância Específica do Fenótipo: O fenótipo de Doença Autoimune (ADs) produziu as classificações mais altas em ambos os modelos. Isso foi atribuído ao seu estilo de documentação, que utilizava pseudocódigo explícito e bem organizado, contrastando com a documentação menos estruturada de outros fenótipos.
• Categorias de Erros: A análise identificou sete modos de falha. Erros de fidelidade lógica (por exemplo, interpretar diagnósticos únicos como suficientes para uma condição que requer eventos repetidos) e incompletude do conjunto de conceitos (IDs de conceitos ausentes necessários) estavam entre os mais consequentes. Alucinações, onde os modelos introduziram conceitos clínicos ou limites sem suporte, também foram observadas. Limitações de interpretação de modalidade foram mais proeminentes em entradas apenas de diagrama, onde os modelos falharam em traduzir critérios de exclusão visuais em lógica SQL.

Significado e Alegações
O artigo posiciona os LLMs não como implementadores autônomos de fenótipos clínicos, mas como geradores de "primeiro rascunho" capazes, cuja utilidade é estritamente condicionada pela qualidade da documentação de entrada. O estudo alega que:

1. A Documentação é o Gargalo Primário: A fidelidade das consultas de fenotipagem geradas por LLMs depende mais da padronização e estrutura da documentação de entrada do que das capacidades inerentes dos modelos. Linguagem natural estruturada é necessária e largamente suficiente para desempenho quase ótimo, enquanto diagramas visuais isolados são insuficientes.
2. Supervisão Especializada é Obrigatória: Devido à diversidade e significância clínica dos erros identificados (incluindo alucinações e imprecisões de limites), as consultas geradas por LLMs ainda não são adequadas para implantação autônoma. A revisão obrigatória por especialistas permanece essencial, particularmente para restrições temporais e precisão do conjunto de conceitos.
3. Caminho para a Escalabilidade: Padronizar a documentação de fenótipos em formatos orientados à implementação (como pseudocódigo explícito) oferece um caminho promissor para melhorar a fidelidade de tradução sem exigir avanços adicionais na arquitetura do modelo.
4. Paradigma Colaborativo: As descobertas sugerem um fluxo de trabalho colaborativo onde os LLMs aceleram o rascunho inicial de algoritmos de fenotipagem, que são então refinados através de supervisão humana estruturada, potencialmente aprimorando a portabilidade e a reutilização de coortes clínicas entre redes de pesquisa.

Os autores reconhecem limitações, incluindo a avaliação de apenas cinco fenótipos e dois modelos, a dependência de pontuação de especialistas em vez de revisão de prontuários padrão-ouro para precisão da coorte, e a falta de otimização sistemática de prompts. Trabalhos futuros são sugeridos para focar em benchmarking longitudinal, painéis de revisão maiores e validação contra conjuntos de dados padrão-ouro.