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

Este estudio evalúa modelos de lenguaje grandes de vanguardia para la traducción de documentación multimodal de fenotipos clínicos a algoritmos ejecutables en historias clínicas electrónicas, encontrando que, aunque interpretan eficazmente el texto estructurado, su rendimiento se degrada significativamente con entradas que solo contienen diagramas, identificando finalmente la calidad de la documentación, y no la capacidad del modelo, como el principal cuello de botella.

Lo esencial

Imagina que eres un chef maestro intentando recrear un plato famoso, pero no tienes la receta. En su lugar, tienes una pila desordenada de notas, algunas garabateadas en servilletas, otras dibujadas como caricaturas y algunas escritas en una mezcla confusa de idiomas. Tu objetivo es convertir estas notas desordenadas en un manual de instrucciones preciso, paso a paso, que una cocina robótica pueda seguir para cocinar el plato perfectamente.

Este artículo trata sobre probar a dos chefs de IA superinteligentes (llamados Modelos de Lenguaje Grande, o LLM) para ver si pueden realizar este trabajo para la investigación médica.

El Problema: La Receta "Perdida en la Traducción"

En la investigación médica, los científicos definen grupos específicos de pacientes (como "personas con diabetes tipo 2") utilizando reglas complejas. Estas reglas suelen estar escritas en documentos legibles para humanos que parecen una mezcla de historias, diagramas de flujo y tablas.

Para utilizar estas reglas en el sistema informático de un hospital, un experto humano debe traducirlas manualmente a un lenguaje informático (SQL). Esto es como traducir un poema a un código informático. Toma mucho tiempo, es muy tedioso y, si dos expertos diferentes lo hacen, podrían terminar con resultados ligeramente diferentes. Los investigadores querían ver si la IA podía realizar esta traducción automáticamente.

El Experimento: Probando a los Chefs de IA

Los investigadores seleccionaron dos de los modelos de IA más inteligentes disponibles (GPT o3 de OpenAI y Claude Opus 4.1 de Anthropic) y les dieron cinco "recetas" diferentes (definiciones médicas para afecciones como lesión renal, infartos y diabetes) de una biblioteca pública llamada PheKB.

Probaron a la IA de tres maneras diferentes, como dar al chef diferentes tipos de instrucciones:

1. El Paquete Completo: La IA recibió el documento completo (texto, gráficos y diagramas).
2. Solo la Historia: La IA recibió solo el texto escrito y las tablas, pero sin imágenes.
3. Solo las Imágenes: La IA recibió solo los diagramas y diagramas de flujo, sin palabras.

Los Resultados: Qué Funcionó y Qué No

1. La Trampa de "Solo Imágenes"
Cuando la IA intentó leer solo los diagramas (los diagramas de flujo), fracasó miserablemente. Era como pedirle a un chef que cocinara una comida compleja solo mirando un dibujo de una olla y un tenedor, sin texto que explicara los ingredientes o los niveles de calor. La IA pasó por alto detalles cruciales, se equivocó en los tiempos y produjo instrucciones que no funcionarían.

2. La "Historia" es el Rey
Cuando la IA recibió el texto escrito (incluso sin las imágenes), lo hizo muy bien. Resultó que las palabras escritas contenían casi toda la información necesaria. La IA podía entender la lógica y escribir el código informático con precisión.

3. La IA es un Gran Borrador, No un Editor Final
Ambos modelos de IA fueron sorprendentemente buenos entendiendo la imagen general y la lógica de las reglas. Sin embargo, cometieron tipos específicos de errores:

• Ingredientes Faltantes: A veces olvidaban incluir códigos médicos específicos (como un tipo específico de medicamento).
• Números Incorrectos: Podían equivocarse con un umbral (por ejemplo, decir "presión arterial superior a 140" cuando la regla era "superior a 150").
• Inventar Cosas: A veces, la IA inventaba reglas o condiciones que no estaban en el documento original en absoluto (una "alucinación").
• Confundir el Formato: Al mirar diagramas, a menudo no podían averiguar cómo convertir una flecha visual en un comando informático lógico de "si-entonces".

La Gran Conclusión

El artículo concluye que estos modelos de IA no están listos para reemplazar a los expertos humanos todavía. No pueden simplemente mirar un documento desordenado y escupir un programa informático perfecto y listo para usar.

Sin embargo, son excelentes generadores de borradores iniciales. Si les das texto claro y estructurado, pueden escribir un muy buen punto de partida para el código. Pero como pueden cometer errores sutiles pero peligrosos (como equivocarse con un número o pasar por alto una regla), un experto humano debe revisar siempre su trabajo.

La Lección Final:
El mayor problema no es que la IA no sea lo suficientemente inteligente; es que los documentos médicos no están escritos de una manera que sea fácil de leer para las computadoras. Si los médicos e investigadores estandarizaran sus notas para que fueran más claras y estructuradas (como escribir una receta en un formato estándar en lugar de garabatear en una servilleta), la IA sería mucho más útil. Hasta entonces, la IA es un asistente útil, pero el experto humano debe seguir siendo el jefe.

Resumen técnico

Resumen Técnico: Evaluación de Modelos de Lenguaje Grandes para Traducir Documentaciones de Fenotipos Multimodales en Algoritmos de Fenotipado Ejecutables para Historias Clínicas Electrónicas

Enunciado del Problema
La traducción de definiciones de fenotipos clínicos en consultas ejecutables a bases de datos de Historias Clínicas Electrónicas (HCE) es un cuello de botella crítico, aunque laborioso, en la investigación biomédica. Si bien los algoritmos de fenotipado son esenciales para identificar cohortes de pacientes a gran escala, generalmente se documentan en formatos de alto nivel y legibles por humanos (texto narrativo, tablas, diagramas de flujo, diagramas) en lugar de formas listas para la computación. Convertir estas especificaciones multimodales en lenguaje de consulta estructurado (SQL) adaptado a modelos de datos específicos (por ejemplo, OMOP CDM) requiere esfuerzo manual, experiencia en el dominio y validación iterativa. Este proceso introduce variabilidad interpretativa, limitando la portabilidad, la comparabilidad y la reutilización de cohortes entre instituciones. Aunque los Modelos de Lenguaje Grandes (LLM) han demostrado competencia en la generación de código y el razonamiento de múltiples pasos, no está claro si pueden convertir fielmente documentación de fenotipos multimodales del mundo real en SQL ejecutable conforme a estándares.

Metodología
Este estudio evaluó sistemáticamente la capacidad de dos LLM de vanguardia, OpenAI GPT o3 y Claude Opus 4.1, para traducir documentación de fenotipos en consultas SQL compatibles con OMOP.

• Conjunto de datos: Se seleccionaron cinco fenotipos clínicos establecidos de PheKB: Lesión Renal Aguda (AKI), Enfermedades Autoinmunes (ADs), Hipercolesterolemia Familiar (FH), Eventos Adversos Cardiovasculares Mayores (MACE) y Diabetes Mellitus Tipo 2 (T2DM). Estos se eligieron por sus diversos dominios clínicos y complejidades de documentación variables.
• Modalidades de entrada: Para aislar el impacto del formato de documentación, se probaron tres escenarios de entrada para cada fenotipo y modelo:
  1. Documento completo: Texto narrativo, tablas, diagramas y pseudocódigo.
  2. Solo texto: Texto narrativo y tablas (excluyendo diagramas y pseudocódigo).
  3. Solo diagramas: Diagramas visuales exclusivamente.
• Pipeline de prompting: Se empleó un pipeline de cadena de pensamiento de cuatro etapas:
  1. Extracción de un pseudocódigo estructurado a partir de la entrada.
  2. Verificación del pseudocódigo frente al documento fuente.
  3. Generación de SQL ejecutable basado en el pseudocódigo verificado.
  4. Revisión y corrección del SQL generado.
• Evaluación: Dos expertos en fenotipado clínico calificaron independientemente las consultas generadas en una escala de 0 a 4 a lo largo de siete dimensiones: precisión lógica/booleana, implementación de restricciones temporales, precisión del conjunto de valores, corrección del esquema OMOP, eficiencia de codificación, legibilidad humana y preparación para implementación local. El acuerdo entre evaluadores fue sustancial (kappa de Cohen > 0.79).
• Análisis de errores: Una revisión cualitativa categorizó los fallos en siete tipos distintos: errores de fidelidad lógica, incompletitud del conjunto de conceptos, errores de esquema/implementación, errores de umbrales/parámetros, alucinaciones, subespecificación/sobre-generalización y limitaciones en la interpretación de modalidades.

Resultados Clave

• Sensibilidad a la modalidad de entrada: La calidad del SQL generado fue altamente sensible a la representación de la entrada. Proporcionar solo diagramas resultó en una degradación dramática del rendimiento en todas las dimensiones de evaluación, particularmente en la precisión del conjunto de valores, las restricciones temporales y la precisión lógica. Por el contrario, la entrada solo en texto produjo un rendimiento que se aproximaba estrechamente al de la entrada de documento completo, lo que sugiere que la prosa narrativa captura la mayoría de la información necesaria para la generación de SQL.
• Rendimiento del modelo: Bajo las condiciones de documento completo y solo texto, Claude Opus 4.1 generalmente logró puntuaciones mejores o comparables en cinco de las siete dimensiones, mientras que OpenAI o3 superó en precisión lógica/booleana y preparación para implementación local. En escenarios de solo diagramas, las brechas de rendimiento se estrecharon, aunque OpenAI o3 mantuvo una ventaja en precisión lógica.
• Varianza específica del fenotipo: El fenotipo de Enfermedad Autoinmune (ADs) obtuvo las calificaciones más altas en ambos modelos. Esto se atribuyó a su estilo de documentación, que utilizaba pseudocódigo explícito y bien organizado, en contraste con la documentación menos estructurada de otros fenotipos.
• Categorías de errores: El análisis identificó siete modos de fallo. Los errores de fidelidad lógica (por ejemplo, malinterpretar diagnósticos únicos como suficientes para una condición que requiere eventos repetidos) y la incompletitud del conjunto de conceptos (omisión de IDs de conceptos requeridos) fueron de los más consecuentes. También se observaron alucinaciones, donde los modelos introdujeron conceptos clínicos o umbrales no respaldados. Las limitaciones en la interpretación de modalidades fueron más prominentes en las entradas de solo diagramas, donde los modelos fallaron al traducir criterios de exclusión visuales en lógica SQL.

Significado y Afirmaciones
El artículo posiciona a los LLM no como implementadores autónomos de fenotipos clínicos, sino como "generadores de borradores iniciales" capaces, cuya utilidad está estrictamente condicionada por la calidad de la documentación de entrada. El estudio afirma que:

1. La documentación es el cuello de botella principal: La fidelidad de las consultas de fenotipado generadas por LLM depende más de la estandarización y estructura de la documentación de entrada que de las capacidades inherentes de los modelos. El lenguaje natural estructurado es necesario y en gran medida suficiente para un rendimiento casi óptimo, mientras que los diagramas visuales por sí solos son insuficientes.
2. La supervisión experta es obligatoria: Debido a la diversidad y significancia clínica de los errores identificados (incluyendo alucinaciones e imprecisiones de umbrales), las consultas generadas por LLM aún no son aptas para implementación autónoma. La revisión obligatoria por expertos sigue siendo esencial, particularmente para restricciones temporales y precisión del conjunto de conceptos.
3. Camino hacia la escalabilidad: Estandarizar la documentación de fenotipos en formatos orientados a la implementación (como pseudocódigo explícito) ofrece una vía prometedora para mejorar la fidelidad de la traducción sin requerir avances adicionales en la arquitectura del modelo.
4. Paradigma colaborativo: Los hallazgos sugieren un flujo de trabajo colaborativo donde los LLM aceleran el borrado inicial de algoritmos de fenotipado, los cuales luego se refinan mediante una supervisión humana estructurada, potenciando potencialmente la portabilidad y reutilización de cohortes clínicas a través de redes de investigación.

Los autores reconocen limitaciones, incluida la evaluación de solo cinco fenotipos y dos modelos, la dependencia de puntuación experta en lugar de revisión de historiales estándar de oro para la precisión de la cohorte, y la falta de optimización sistemática de prompts. Se sugiere que el trabajo futuro se centre en la evaluación comparativa longitudinal, paneles de revisión más grandes y validación contra conjuntos de datos estándar de oro.