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

Cette étude évalue les grands modèles de langage de pointe pour la traduction de la documentation multimodale des phénotypes cliniques en algorithmes exécutables de dossier médical électronique, constatant que, bien qu'ils interprètent efficacement les textes structurés, leurs performances se dégradent considérablement avec des entrées exclusivement diagrammatiques, identifiant ainsi la qualité de la documentation plutôt que les capacités du modèle comme le principal goulot d'étranglement.

L'essentiel

Imaginez que vous êtes un chef étoilé tentant de recréer un plat célèbre, mais sans la recette. À la place, vous possédez une pile désordonnée de notes, certaines griffonnées sur des serviettes, d'autres dessinées sous forme de bandes dessinées, et certaines écrites dans un mélange confus de langues. Votre objectif est de transformer ces notes brouillonnes en un manuel d'instructions précis et étape par étape qu'une cuisine robotisée peut suivre pour cuisiner le plat parfaitement.

Ce document porte sur le test de deux chefs IA ultra-intelligents (appelés modèles de langage de grande taille, ou LLM) pour voir s'ils peuvent accomplir cette tâche pour la recherche médicale.

Le Problème : La Recette « Perdue en Traduction »

Dans la recherche médicale, les scientifiques définissent des groupes spécifiques de patients (comme « les personnes atteintes de diabète de type 2 ») à l'aide de règles complexes. Ces règles sont généralement écrites dans des documents lisibles par l'homme qui ressemblent à un mélange d'histoires, de diagrammes de flux et de tableaux.

Pour utiliser ces règles dans le système informatique d'un hôpital, un expert humain doit les traduire manuellement dans un langage informatique (SQL). C'est comme traduire un poème en code informatique. Cela prend beaucoup de temps, est très fastidieux, et si deux experts différents le font, ils pourraient aboutir à des résultats légèrement différents. Les chercheurs voulaient voir si l'IA pouvait effectuer cette traduction automatiquement.

L'Expérience : Tester les Chefs IA

Les chercheurs ont sélectionné deux des modèles d'IA les plus intelligents disponibles (GPT o3 d'OpenAI et Claude Opus 4.1 d'Anthropic) et leur ont donné cinq « recettes » différentes (définitions médicales pour des affections telles que les lésions rénales, les crises cardiaques et le diabète) issues d'une bibliothèque publique appelée PheKB.

Ils ont testé l'IA de trois manières différentes, comme donner au chef différents types d'instructions :

1. Le Pack Complet : L'IA a reçu le document entier (texte, graphiques et diagrammes).
2. Juste l'Histoire : L'IA n'a reçu que le texte écrit et les tableaux, mais aucune image.
3. Juste les Images : L'IA n'a reçu que les diagrammes et les organigrammes, sans aucun mot.

Les Résultats : Ce Qui a Fonctionné et Ce Qui N'a Pas Fonctionné

1. Le Piège du « Uniquement Images »
Lorsque l'IA a tenté de lire uniquement les diagrammes (les organigrammes), elle a échoué lamentablement. C'était comme demander à un chef de cuisiner un repas complexe en regardant uniquement un dessin d'une casserole et d'une fourchette, sans aucun texte expliquant les ingrédients ou les niveaux de chaleur. L'IA a manqué des détails cruciaux, s'est trompée sur le timing et a produit des instructions qui ne fonctionneraient pas.

2. L'« Histoire » est Roi
Lorsque l'IA a reçu le texte écrit (même sans les images), elle a très bien travaillé. Il s'est avéré que les mots écrits contenaient presque toutes les informations nécessaires. L'IA pouvait comprendre la logique et écrire le code informatique avec précision.

3. L'IA est un Excellent Brouilleur, Pas un Rédacteur Final
Les deux modèles d'IA étaient étonnamment bons pour comprendre la vue d'ensemble et la logique des règles. Cependant, ils ont commis des types spécifiques d'erreurs :

• Ingrédients Manquants : Ils ont parfois oublié d'inclure des codes médicaux spécifiques (comme un type particulier de médicament).
• Chiffres Incorrects : Ils pouvaient se tromper sur un seuil (par exemple, dire « tension artérielle supérieure à 140 » alors que la règle était « supérieure à 150 »).
• Invention de Choses : Parfois, l'IA inventait des règles ou des conditions qui n'étaient pas du tout dans le document original (une « hallucination »).
• Confusion du Format : En regardant les diagrammes, ils ne parvenaient souvent pas à déterminer comment transformer une flèche visuelle en une commande informatique logique du type « si-alors ».

La Grande Conclusion

Le document conclut que ces modèles d'IA ne sont pas encore prêts à remplacer les experts humains. Ils ne peuvent pas simplement regarder un document brouillon et cracher un programme informatique parfait et prêt à l'emploi.

Cependant, ce sont d'excellents générateurs de premier jet. Si vous leur donnez un texte clair et structuré, ils peuvent écrire un très bon point de départ pour le code. Mais parce qu'ils peuvent commettre des erreurs subtiles mais dangereuses (comme se tromper sur un chiffre ou manquer une règle), un expert humain doit toujours vérifier leur travail.

La Leçon Finale :
Le plus grand problème n'est pas que l'IA n'est pas assez intelligente ; c'est que les documents médicaux ne sont pas écrits d'une manière facile à lire pour les ordinateurs. Si les médecins et les chercheurs standardisaient leurs notes pour les rendre plus claires et plus structurées (comme écrire une recette dans un format standard plutôt que de griffonner sur une serviette), l'IA deviendrait beaucoup plus utile. En attendant, l'IA est une assistante utile, mais l'expert humain doit rester le patron.

Résumé technique

Résumé Technique : Évaluation des Grands Modèles de Langage pour la Traduction de Documentations Multimodales de Phénotypes en Algorithmes d'Extraction de Phénotypes Exécutables dans les Dossiers de Santé Électroniques

Énoncé du Problème
La traduction des définitions de phénotypes cliniques en requêtes exécutables de base de données de Dossiers de Santé Électroniques (DSE) constitue un goulot d'étranglement critique, bien que laborieux, dans la recherche biomédicale. Bien que les algorithmes d'extraction de phénotypes soient essentiels pour identifier des cohortes de patients à grande échelle, ils sont généralement documentés sous des formats haut niveau, lisibles par l'humain (texte narratif, tableaux, organigrammes, diagrammes) plutôt que sous des formes prêtes au calcul. La conversion de ces spécifications multimodales en langage de requête structuré (SQL) adapté à des modèles de données spécifiques (par exemple, OMOP CDM) nécessite un effort manuel, une expertise du domaine et une validation itérative. Ce processus introduit une variabilité interprétative, limitant la portabilité, la comparabilité et la réutilisation des cohortes entre les institutions. Bien que les Grands Modèles de Langage (LLM) aient démontré leur compétence dans la génération de code et le raisonnement multi-étapes, il reste à déterminer s'ils peuvent convertir fidèlement des documentations de phénotypes multimodales réelles en SQL exécutable conforme aux normes.

Méthodologie
Cette étude a évalué systématiquement la capacité de deux LLM de pointe — OpenAI GPT o3 et Claude Opus 4.1 — à traduire des documentations de phénotypes en requêtes SQL conformes à OMOP.

• Jeu de données : Cinq phénotypes cliniques établis ont été sélectionnés à partir de PheKB : l'Insuffisance Rénale Aiguë (AKI), les Maladies Auto-immunes (ADs), l'Hypercholestérolémie Familiale (FH), les Événements Cardiovasculaires Majeurs Adverses (MACE) et le Diabète de Type 2 (T2DM). Ils ont été choisis pour la diversité de leurs domaines cliniques et la variabilité de la complexité de leur documentation.
• Modalités d'entrée : Pour isoler l'impact du format de documentation, trois scénarios d'entrée ont été testés pour chaque phénotype et modèle :
  1. Document complet : Texte narratif, tableaux, diagrammes et pseudo-code.
  2. Texte uniquement : Texte narratif et tableaux (excluant les diagrammes et le pseudo-code).
  3. Diagramme uniquement : Diagrammes visuels exclusivement.
• Pipeline de prompting : Une chaîne de pensée à quatre étapes a été employée :
  1. Extraction d'un pseudo-algorithme structuré à partir de l'entrée.
  2. Vérification du pseudo-algorithme par rapport au document source.
  3. Génération de SQL exécutable basée sur le pseudo-algorithme vérifié.
  4. Examen et correction du SQL généré.
• Évaluation : Deux experts en extraction de phénotypes cliniques ont noté indépendamment les requêtes générées sur une échelle de 0 à 4 selon sept dimensions : précision logique/booléenne, mise en œuvre des contraintes temporelles, précision des ensembles de valeurs, correction du schéma OMOP, efficacité du codage, lisibilité humaine et préparation au déploiement local. L'accord inter-évaluateurs était substantiel (kappa de Cohen > 0,79).
• Analyse des erreurs : Un examen qualitatif a catégorisé les échecs en sept types distincts : erreurs de fidélité logique, incomplétude des ensembles de concepts, erreurs de schéma/d'implémentation, erreurs de seuil/de paramètre, hallucinations, sous-spécification/sur-généralisation et limitations d'interprétation des modalités.

Résultats Clés

• Sensibilité à la modalité d'entrée : La qualité du SQL généré était hautement sensible à la représentation de l'entrée. La fourniture de diagrammes uniquement a entraîné une dégradation dramatique des performances dans toutes les dimensions d'évaluation, en particulier en ce qui concerne la précision des ensembles de valeurs, les contraintes temporelles et la précision logique. À l'inverse, l'entrée sous forme de texte uniquement a produit des performances proches de celles de l'entrée avec document complet, suggérant que la prose narrative capture la majorité des informations nécessaires à la génération de SQL.
• Performance des modèles : Dans les conditions de document complet et de texte uniquement, Claude Opus 4.1 a généralement obtenu de meilleurs scores ou des scores comparables dans cinq des sept dimensions, tandis qu'OpenAI o3 a surpassé les autres en précision logique/booléenne et en préparation au déploiement local. Dans les scénarios de diagramme uniquement, les écarts de performance se sont réduits, bien qu'OpenAI o3 ait maintenu un avantage en précision logique.
• Variance spécifique au phénotype : Le phénotype des Maladies Auto-immunes (ADs) a obtenu les notes les plus élevées pour les deux modèles. Cela a été attribué à son style de documentation, qui utilisait un pseudo-code explicite et bien organisé, contrastant avec la documentation moins structurée des autres phénotypes.
• Catégories d'erreurs : L'analyse a identifié sept modes d'échec. Les erreurs de fidélité logique (par exemple, interpréter un diagnostic unique comme suffisant pour une condition nécessitant des événements répétés) et l'incomplétude des ensembles de concepts (absence d'identifiants de concepts requis) figuraient parmi les plus conséquents. Des hallucinations, où les modèles introduisaient des concepts cliniques ou des seuils non étayés, ont également été observées. Les limitations d'interprétation des modalités étaient les plus prononcées dans les entrées de type diagramme uniquement, où les modèles ont échoué à traduire les critères d'exclusion visuels en logique SQL.

Signification et Revendications
L'article positionne les LLM non pas comme des implémenteurs autonomes de phénotypes cliniques, mais comme des « générateurs de premier brouillon » capables, dont l'utilité est strictement conditionnée par la qualité de la documentation d'entrée. L'étude revendique que :

1. La documentation est le goulot d'étranglement principal : La fidélité des requêtes d'extraction de phénotypes générées par les LLM dépend davantage de la normalisation et de la structure de la documentation d'entrée que des capacités inhérentes des modèles. Un langage naturel structuré est nécessaire et largement suffisant pour des performances quasi optimales, alors que les diagrammes visuels seuls sont insuffisants.
2. La supervision experte est obligatoire : En raison de la diversité et de l'importance clinique des erreurs identifiées (incluant les hallucinations et les imprécisions de seuil), les requêtes générées par les LLM ne sont pas encore adaptées à un déploiement autonome. Un examen expert obligatoire reste essentiel, en particulier pour les contraintes temporelles et la précision des ensembles de concepts.
3. Voie vers l'évolutivité : La normalisation de la documentation de phénotypes en formats orientés implémentation (tels que le pseudo-code explicite) offre une voie prometteuse pour améliorer la fidélité de la traduction sans nécessiter de nouvelles avancées dans l'architecture des modèles.
4. Paradigme collaboratif : Les résultats suggèrent un flux de travail collaboratif où les LLM accélèrent la rédaction initiale des algorithmes d'extraction de phénotypes, lesquels sont ensuite affinés par une supervision humaine structurée, améliorant potentiellement la portabilité et la réutilisation des cohortes cliniques à travers les réseaux de recherche.

Les auteurs reconnaissent les limites, notamment l'évaluation de seulement cinq phénotypes et deux modèles, la dépendance à un scoring d'experts plutôt qu'à une revue de dossiers standard d'or pour la précision des cohortes, et l'absence d'optimisation systématique des invites. Des travaux futurs sont suggérés pour se concentrer sur le suivi longitudinal, des panels d'examen plus larges et la validation par rapport à des jeux de données standard d'or.