El problema
Los datos clínicos tienen mucho valor predictivo, pero no viajan bien entre hospitales.
Una historia clínica electrónica no es una tabla limpia. Es una secuencia larga de visitas, diagnósticos, pruebas, fármacos, resultados, unidades, tiempos, huecos y códigos.
Los modelos específicos para EHR pueden aprender muy bien dentro del entorno donde se entrenan, pero suelen depender de vocabularios y prácticas de codificación locales.
Cuando el modelo se lleva a otro sistema sanitario, aparecen códigos nuevos, equivalencias incompletas y pérdidas de información. El trabajo plantea una pregunta directa: ¿y si convertimos esos códigos en texto comprensible para un LLM general?
Por qué es difícil
Cada centro codifica distinto
Los mismos conceptos clínicos pueden aparecer con códigos, catálogos y granularidad diferentes.
La historia clínica es longitudinal
No basta con una foto fija: importan visitas, eventos recientes, valores de laboratorio y trayectoria del paciente.
Los datos sanitarios son sensibles
Entrenar modelos específicos con datos de muchos hospitales es difícil por privacidad, permisos y gobernanza.
La eficiencia también cuenta
Los LLM generales pueden ser portables, pero procesar historias largas consume mucha memoria y tiempo.
La idea principal
El enfoque es sorprendentemente sencillo: tomar los códigos de la historia clínica, reemplazarlos por descripciones en lenguaje natural y generar un embedding del paciente con un modelo de lenguaje.
Ese embedding no decide por sí solo. Después se entrena un clasificador simple, como una regresión logística, para cada tarea clínica.
La ventaja es que el modelo no necesita haber visto todos los códigos durante su entrenamiento. Si aparece un código nuevo pero tiene una descripción textual, el LLM puede representarlo.
La historia clínica deja de ser solo una colección de códigos locales y pasa a ser texto clínico reutilizable por modelos generales.
Una forma sencilla de verlo
Es como traducir varios dialectos hospitalarios a un idioma común antes de pedirle a la IA que aprenda patrones.
Cómo se resolvió
Los autores no proponen una arquitectura clínica compleja, sino una comparación sistemática entre embeddings de LLM y modelos EHR específicos.
Convertir códigos en texto
Cada evento clínico se expresa como una descripción textual, con valores y unidades cuando están disponibles.
Generar embeddings
Usan modelos de embedding basados en LLM, especialmente Qwen3-Embedding-8B, para convertir la historia en un vector numérico.
Entrenar clasificadores simples
Sobre esos vectores entrenan regresiones logísticas, aislando la calidad de la representación del paciente.
Comparar con modelos fuertes
El estudio compara contra CLMBR-T-Base, un modelo EHR especializado, modelos biomédicos tipo BERT y baselines basados en conteos.
Validar fuera del entorno inicial
Además de EHRSHOT, prueban generalización en UK Biobank, donde la cobertura de vocabulario se vuelve un punto crítico.
Embedding
Representación numérica que resume una historia clínica para que otro modelo pueda usarla.
EHRSHOT
Benchmark con 15 tareas clínicas para evaluar predicción sobre historias clínicas longitudinales.
UK Biobank
Cohorte externa usada para comprobar si la representación generaliza fuera del sistema inicial.
Few-shot
Evaluación con pocos ejemplos etiquetados, útil cuando un hospital no dispone de grandes datasets locales para cada tarea.
El experimento
En EHRSHOT trabajaron con 6.739 pacientes adultos, 921.499 visitas y más de 41,6 millones de eventos clínicos entre 1990 y 2023.
Las 15 tareas cubren resultados operativos, predicción de resultados de laboratorio, asignación de nuevos diagnósticos y hallazgos en radiografía de tórax.
Para validación externa usaron UK Biobank, con 387.464 pacientes procesados, unos 19,5 millones de visitas y más de 72 millones de eventos.
La comparación principal fue entre Qwen3-Embedding-8B y CLMBR-T-Base. También analizaron variantes más pequeñas, modelos biomédicos tipo BERT, baselines de conteo, distintos formatos de serialización y ventanas temporales.
Qué se descubrió
En EHRSHOT, Qwen3-Embedding-8B igualó el rendimiento macro-AUROC de CLMBR-T-Base: ambos alcanzaron 0,769. La diferencia importante es que CLMBR-T-Base es específico de EHR y mucho más eficiente, mientras que el LLM general aporta portabilidad.
En UK Biobank, Qwen3-Embedding-8B obtuvo un rendimiento medio algo superior: 0,751 frente a 0,736 de CLMBR-T-Base. Los autores atribuyen parte de esa mejora a una mayor cobertura de vocabulario.
Ese punto es clave: al aplicar CLMBR-T-Base a UK Biobank, solo el 16% de los códigos podía mapearse a su vocabulario. Al trabajar con descripciones en lenguaje natural, el LLM puede incorporar códigos que el modelo específico no conoce.
El trabajo también muestra límites claros. CLMBR-T-Base codificó EHRSHOT en unos minutos, mientras que Qwen3-Embedding-8B necesitó más de 20 horas. La portabilidad tiene un coste.
Otra lección práctica es que una serialización simple, como una lista de códigos recientes en texto, funcionó mejor de lo que cabría esperar. Añadir formatos más elaborados no siempre mejoró el resultado.
- Los LLM embeddings pueden igualar a modelos EHR específicos en algunas tareas.
- La ventaja de los LLM aparece especialmente cuando cambia el vocabulario entre sistemas.
- Los modelos específicos siguen siendo mucho más eficientes.
- Los valores de laboratorio y los eventos recientes aportan señales muy relevantes.
Portabilidad
El texto permite representar códigos nuevos sin reentrenar todo el modelo sobre datos privados de cada hospital.
Coste
El rendimiento comparable llega con una carga computacional mucho mayor que la de un modelo EHR especializado.
Complementariedad
Combinar embeddings de LLM y de modelo EHR específico mejoró el rendimiento, señal de que capturan información distinta.
La conclusión no es que un LLM sustituya a los modelos clínicos especializados, sino que puede hacerlos más transportables y complementarios.
Por qué importa
Este trabajo encaja con tus líneas de laboratorio, decision support y datos clínicos porque toca una barrera real: mover modelos entre sistemas sin perder significado.
En laboratorios clínicos y plataformas de reglas, los códigos, unidades, rangos y nombres de pruebas cambian entre centros. Una capa textual o semántica puede ayudar a construir herramientas más reutilizables.
También conecta con optimización: no siempre se optimiza solo la métrica predictiva. Hay que equilibrar rendimiento, coste computacional, privacidad, portabilidad y facilidad de implantación.
La lectura práctica es muy clara: para que una IA clínica sea útil fuera del entorno donde nació, necesita representar el dato de forma comprensible y transferible.
Aplicaciones reales
Laboratorio clínico
Transformar códigos y nombres de pruebas en descripciones normalizadas para mejorar reutilización entre centros.
Modelos multicentro
Reducir dependencia de vocabularios cerrados cuando se validan modelos en hospitales distintos.
Decision support
Crear representaciones de pacientes que puedan alimentar reglas, alertas o predicciones clínicas.
Gobernanza del dato
Separar representación, predicción y despliegue para auditar mejor qué información entra en el modelo.
Qué podemos aprender
Una IA clínica no solo necesita buenos algoritmos. Necesita una forma robusta de traducir datos locales a representaciones que puedan entenderse, compararse y reutilizarse entre sistemas.
Preguntas frecuentes
Este comentario es una publicación propia
No. Es una explicación divulgativa de un trabajo de Stefan Hegselmann, Georg von Arnim, Tillmann Rheude, Noel Kronenberg, David Sontag, Gerhard Hindricks, Roland Eils y Benjamin Wild.
El trabajo usa el LLM para generar diagnósticos en texto libre
No. El enfoque principal usa embeddings de LLM como representación numérica de la historia clínica y después entrena clasificadores simples.
El LLM es claramente mejor que un modelo EHR específico
No de forma general. En EHRSHOT iguala el rendimiento medio; en UK Biobank mejora algo. La ventaja principal es la portabilidad, no una superioridad absoluta.
Cuál es la principal limitación práctica
El coste computacional. El modelo general es más flexible, pero mucho más lento y pesado que el modelo EHR especializado.
Trabajo comentado
Publicación original y recursos
Hegselmann, S.; von Arnim, G.; Rheude, T.; Kronenberg, N.; Sontag, D.; Hindricks, G.; Eils, R.; Wild, B. Large language models are powerful electronic health record encoders. npj Digital Medicine 9, 530 (2026). https://doi.org/10.1038/s41746-026-02915-9.