Are LLMs Ready to Assist Physicians? PhysAssistBench for Interactive Doctor-Patient-EHR Assistance

Cet article introduit PhysAssistBench, un nouveau benchmark construit à partir de cas réels issus de MIMIC-IV qui évalue la capacité des grands modèles de langage à coordonner les connaissances cliniques, la communication avec le patient et l'utilisation d'outils de DME dans des scénarios interactifs médecin-patient, révélant que les modèles actuels restent peu fiables pour une telle assistance médicale intégrée malgré des améliorations isolées de leurs capacités individuelles.

L'essentiel

L'idée générale : Le test du « Super-Stagiaire »

Imaginez un hôpital où les médecins sont débordés. Ils veulent embaucher un « Super-Stagiaire » (une IA) pour les aider. Ce stagiaire doit faire trois choses à la fois :

1. Lire le dossier du patient (Dossiers Médicaux Électroniques ou DME) instantanément.
2. Parler au patient pour obtenir toute l'histoire.
3. Écouter le Docteur, qui est occupé et parle souvent en abrégé.

L'article soutient que, bien que l'IA soit excellente pour passer des examens médicaux (comme un étudiant qui mémorise un manuel), nous ne savons pas réellement si elle peut gérer le travail désordonné et réel d'un assistant de médecin. Pour le savoir, les auteurs ont construit un nouveau test très difficile appelé PhysAssistBench.

Le problème : Le « Manuel » vs « La Vie Réelle »

Considérez les tests actuels de l'IA comme un examen de conduite où vous devez seulement garer une voiture dans un parking vide avec des cônes parfaits. L'IA réussit haut la main.

Mais la vraie vie n'est pas un parking vide. C'est l'heure de pointe.

• Le Docteur : Au lieu de dire : « Veuillez vérifier la tension artérielle », le docteur pourrait simplement dire : « Comment est la pression ? » ou même juste « Pression ? » (C'est ce qu'on appelle une requête implicite).
• Le Patient : Au lieu de dire : « J'ai de l'hypertension », le patient pourrait dire : « Ma tête ressemble à un ballon et mes chaussettes laissent des marques profondes sur mes chevilles » (C'est une communication ambiguë).
• Le Système : L'ordinateur de l'hôpital exige que vous cliquiez sur des boutons spécifiques dans un ordre précis pour obtenir les données.

L'article affirme que les modèles d'IA actuels échouent lorsqu'ils mélangent ces trois éléments. Ils se perdent dans le trafic.

La solution : Un hôpital « Jeu Vidéo »

Pour tester l'IA correctement, les chercheurs ont construit une simulation réaliste utilisant de vraies données de patients anonymisées provenant d'une base de données appelée MIMIC-IV.

Ils n'ont pas seulement écrit des questions ; ils ont créé un environnement de jeu vidéo avec trois personnages :

1. Le Docteur Occupé : Une IA qui pose des questions courtes et vagues basées sur de vrais cas médicaux.
2. Le « Patient Agentique » : Un personnage informatique qui agit comme un véritable humain. Il possède un dossier médical, mais il a aussi une personnalité. Il peut oublier de mentionner un symptôme ou le décrire en argot. Il répond aux questions en se basant uniquement sur son historique médical réel, et non sur des histoires inventées.
3. L'Ordinateur de l'Hôpital : Un système strict qui ne donne des données que si vous les demandez en utilisant les bonnes « clés » numériques (outils).

L'IA testée doit jouer le rôle de l'Assistant. Elle doit écouter le Docteur, comprendre ce qu'il veut réellement dire, poser les bonnes questions au Patient, vérifier les faits sur l'Ordinateur, puis donner une réponse claire au Docteur.

Le Test : Quatre tours de chaos

Le test consiste en 324 « scénarios » différents (comme différents cas de patients). Chaque scénario comporte quatre tours :

• Tour 1 : Le Docteur demande un fait spécifique (ex : « Quel est le dernier test sanguin ? »).
• Tour 2 : Le Docteur demande plus d'infos, mais utilise des abréviations (ex : « Et les médocs ? »).
• Tour 3 : Le Docteur demande une recommandation basée sur tout ce qui a été dit jusqu'ici (ex : « Étant donné tout cela, que faisons-nous ? »).
• Tour 4 : Le Docteur demande à l'IA de rédiger une nouvelle prescription ou de mettre à jour le dossier.

L'IA doit réussir les quatre tours pour valider l'ensemble du scénario. Si elle commet une seule erreur lors d'un tour, toute la session est un échec.

Qu'en est-il ? Le « Super-Stagiaire » trébuche

Les chercheurs ont testé 14 des modèles d'IA les plus intelligents disponibles (incluant des noms célèbres comme GPT-5, Claude et Gemini).

Les Résultats :

• La Bonne Nouvelle : L'IA est excellente pour les tâches simples. Si le Docteur demande : « Quelle est la tension artérielle ? » et que l'IA se contente de la chercher, elle réussit plus de 80 % du temps.
• La Mauvaise Nouvelle : Quand le test devient complexe, l'IA a beaucoup de mal.
  • Le Problème du « Langage Abrégé » : Lorsque le Docteur utilise un langage vague (comme « Vérifie les médocs »), l'IA se confond souvent sur quels médicaments ou sur ce qu'elle doit vérifier.
  • Le Problème du « Patient » : Lorsque l'IA doit parler au « Patient » pour obtenir les informations manquantes, ses performances chutent considérablement. Elle est bien meilleure pour lire un fichier informatique que pour avoir une conversation.
  • Le Problème du « Tout ou Rien » : Même les meilleurs modèles n'ont réussi que 8 % à 23 % des scénarios complets de 4 tours parfaitement. Cela signifie que dans un véritable hôpital, l'IA ferait probablement une erreur dans une conversation multi-étapes plus souvent qu'elle ne réussirait.

La Conclusion

L'article conclut que l'IA n'est pas encore prête à être un « copilote » fiable pour les médecins dans un véritable hôpital.

L'Analogie :
Imaginez que vous apprenez à un robot à être un chef cuisinier.

• Les anciens tests : Vous demandiez au robot : « Peux-tu couper un oignon ? ». Il réussissait.
• Ce Nouveau Test : Vous mettez le robot dans une cuisine animée. Le Chef de cuisine hurle : « Répare la soupe ! ». Le robot doit goûter la soupe, demander au client ce qu'il veut, vérifier le garde-manger pour les ingrédients, et ensuite cuisiner la soupe.
• Le Résultat : Le robot continue de brûler la soupe ou d'oublier de demander au client. Il sait couper des oignons, mais il ne sait pas gérer une cuisine.

Les auteurs affirment que le plus grand obstacle n'est pas que l'IA manque de connaissances médicales ; c'est qu'elle ne peut pas coordonner l'écoute, la parole et l'utilisation d'outils en même temps sans s'embrouiller. Ils ont rendu ce test public afin que d'autres chercheurs puissent tenter de résoudre ces problèmes spécifiques.

Résumé technique

Résumé Technique : PHYSASSISTBENCH

Énoncé du Problème

Les évaluations actuelles des modèles de langage de grande taille (LLM) dans le domaine de la santé évaluent principalement des capacités isolées : la récupération de connaissances médicales, l'interaction avec les systèmes de dossiers de santé électroniques (DSE), ou la communication avec le patient. Cependant, le déploiement le plus plausible à court terme pour les LLM médicaux n'est pas celui de médecins autonomes, mais celui d'assistants opérant sous supervision humaine. Ce rôle nécessite la coordination simultanée de trois modalités distinctes au sein d'une seule interaction :

1. Requêtes implicites du médecin : Les cliniciens émettent souvent des requêtes elliptiques, dépendantes du contexte ou multi-tours (par exemple, « Étant donné tout cela, changer le médicament ? » plutôt que des instructions pleinement spécifiées).
2. Informations ambiguës du patient : Les patients fournissent des descriptions de symptômes familières, incomplètes et cliniquement imprécises.
3. Utilisation précise des outils DSE : Le système doit exécuter des appels d'outils exacts basés sur la norme FHIR pour récupérer ou mettre à jour des dossiers structurés.

Les benchmarks existants ne parviennent pas à capturer ce cadre intégré. Ils traitent généralement ces rôles de manière isolée (par exemple, Q&A statique ou utilisation d'outils à un seul tour) et n'évaluent pas la capacité du modèle à coordonner les connaissances, la communication et les actions système à travers des scénarios cliniques évolutifs et multi-tours.

Méthodologie

Benchmark PHYSASSISTBENCH

Les auteurs introduisent PHYSASSISTBENCH, un benchmark conçu pour évaluer les LLM en tant qu'assistants de médecins dans un environnement interactif médecin-patient-DSE.

• Source de données : Construit à partir de dossiers de patients réels et dé-identifiés provenant de MIMIC-IV.
• Échelle : 324 sessions multi-tours (1 296 tours au total), évaluées en anglais et en chinois.
• Structure : Chaque session simule une rencontre clinique unique comprenant quatre tours (Tour 0 – Tour 3).
  • Tour 0 : Toujours une recherche d'information (IL - Information Lookup) pour ancrer la session dans des données concrètes.
  • Tours 1–3 : Progressent à travers des tâches de collecte de données (DG), de raisonnement clinique (CR), ou d'écriture/mise à jour (WU).
• Types de tâches :
  • Recherche d'information (IL) : Récupération d'un fait unique via le DSE.
  • Collecte de données (DG) : Collecte d'informations provenant de plusieurs sources (DSE + Entretien avec le patient).
  • Raisonnement clinique (CR) : Synthèse des découvertes pour former des recommandations.
  • Écriture/Mise à jour (WU) : Exécution d'opérations d'écriture FHIR (ex: prescriptions).
• Sous-types d'implicité : Le benchmark teste spécifiquement la capacité du modèle à gérer des requêtes sous-spécifiées via trois mécanismes linguistiques :
  • Anaphore nominale (NA) : Pronoms se référant à des entités antérieures.
  • Ellipse de prédicat (PE) : Omission de verbes ou d'arguments (ex : « La créatinine ? » au lieu de « Quel est le taux de créatinine ? »).
  • Anaphore d'événement abstrait (AE) : Références à un contexte accumulé (ex : « Étant donné tout cela... »).
• Métriques d'évaluation :
  • Score de grille (Rubric Score) : Notation par tour basée sur l'exactitude factuelle, l'interprétation clinique et l'absence d'hallucinations.
  • Pass@Turn : Fraction de tours passant un seuil.
  • Pass@Session : Fraction de sessions où tous les tours passent le seuil (une métrique plus stricte reflétant la dépendance multi-tour de la pratique clinique).

Pipeline d'Environnement Patient Agentique

Pour générer des scénarios évolutifs et cliniquement fondés à partir de dossiers MIMIC-IV statiques, les auteurs ont développé un pipeline de données synthétiques multi-agents :

1. Pré-filtrage des patients : Des vérifications hors ligne garantissent que les dossiers contiennent des preuves suffisantes (ex : tendances spécifiques de laboratoire ou paires de médicaments) pour soutenir le scénario cible avant l'implication du LLM.
2. Planification de session : Un agent construit un arc clinique cohérent de quatre tours, faisant correspondre les données statiques à un récit impliquant des outils FHIR spécifiques et des questions d'entretien avec le patient.
3. Génération par niveau de tour : Un système multi-agents (agents Utilisateur, Planificateur, Patient, Réponse, Vérificateur) génère le dialogue.
   • Agent Patient : Simule un patient ayant des profils spécifiques de littératie en santé et d'observance, répondant strictement sur la base des preuves du DSE sous-jacent (pas d'hallucinations contrefactuelles).
   • Exécution d'outils : De vraies requêtes FHIR sont exécutées contre les données MIMIC-IV pour garantir l'ancrage factuel.
   • Portes de qualité : Une validation en trois étapes (Plan, Observation, Réponse) filtre les hallucinations, les erreurs structurelles et le contenu dangereux.

Contributions Clés

1. Formulation de l'assistance interactive : L'article définit l'assistance médicale comme un problème de coordination entre la connaissance clinique, la communication avec le patient et les systèmes DSE, un cadre négligé par les évaluations actuelles de rôles isolés.
2. Pipeline agentique évolutif : Une nouvelle méthode pour transformer des dossiers DSE statiques en « patients agentiques » interactifs et ancrés dans les dossiers, permettant des scénarios multi-tours sans compromettre la facticité clinique.
3. Publication de PHYSASSISTBENCH : Un benchmark révisé manuellement et validé par des médecins comprenant 324 sessions et 1 296 tours, démontrant que les LLM de pointe actuels ne sont pas encore des assistants médicaux fiables.

Résultats Expérimentaux

Les auteurs ont évalué 14 LLM de pointe (5 à source fermée, 9 à poids ouverts) sur PHYSASSISTBENCH.

• Performance Globale : Même les modèles les plus puissants (ex : GLM-5, Claude-Opus-4.7, GPT-5.4-high) présentent des limitations significatives. Le meilleur modèle (GLM-5) a atteint un Score de Grille Moyen (mRS) d'environ 69,4 % (anglais), mais le Pass@Session (cohérence stricte) n'était que de 21,3 % à un seuil de 0,60 et de 6,5 % à 0,75.
• Le goulot d'étranglement de la coordination : La performance chute considérablement lorsque les tâches nécessitent l'intégration de multiples sources.
  • La Recherche d'information est robuste (~82,6 %).
  • La Collecte de données et le Raisonnement clinique sont des points faibles constants (~47,5 % et ~54,9 % respectivement), indiquant que la composition multi-outils et le raisonnement sont plus difficiles que la simple récupération ponctuelle.
• Impact des requêtes implicites : Les modèles souffrent d'une pénalité mesurable lorsque les requêtes sont implicites.
  • L'Anaphore d'événement abstrait (AE) a causé la plus forte baisse de performance (moyenne de -5,3 % par rapport aux requêtes explicites).
  • Les plus petits modèles (ex : Qwen3.5-27B) ont montré une fragilité extrême à l'implicite (jusqu'à -9,8 % de baisse), tandis que les modèles plus forts restaient plus stables.
• Écart de communication avec le patient : Tous les modèles ont nettement moins bien performé sur les tours d'entretien avec le patient par rapport aux tours basés uniquement sur le DSE (baisse moyenne de 26,4 points). Cela suggère que la gestion d'un input patient ambigu et familier est un goulot d'étranglement de capacité distinct, indépendant de la capacité générale du modèle.
• Biais linguistique : Les modèles non-chinois ont été étonnamment plus performants sur les sessions en chinois (jusqu'à +11,4 % Pass@Session), ce qui est attribué à des « priors de sécurité conditionnés par la langue » où les données d'entraînement en anglais suppriment les appels d'outils DSE en raison des clauses de non-responsabilité de sécurité.

Signification et Revendications

L'article affirme que une assistance clinique fiable nécessite la coordination entre les connaissances, la communication et les systèmes, et non des gains isolés dans l'un d'entre eux.

• État actuel : Les LLM de pointe ne sont pas encore des assistants médicaux fiables. Ils peinent à résoudre l'intention implicite, à gérer l'ambiguïté du patient et à intégrer les preuves de diverses sources dans un flux de travail unique.
• Paradigme d'évaluation : Les auteurs soutiennent que les benchmarks actuels se concentrant sur le Q&A statique ou l'utilisation d'outils à un seul tour sont insuffisants. La dimension « interaction » — spécifiquement la capacité à maintenir le contexte, à résoudre les ellipses et à coordonner les outils sur plusieurs tours — est le goulot d'étranglement clé pour le déploiement clinique des LLM.
• Direction future : Le benchmark sert de ressource pour tester la résistance du raisonnement multi-tours et de l'utilisation d'outils structurés, soulignant que les progrès futurs doivent se concentrer sur la coordination agentique plutôt que sur la simple expansion des connaissances médicales paramétriques.

Les auteurs déclarent explicitement que le benchmark est destiné à la recherche et à l'évaluation uniquement et n'est pas destiné au déploiement clinique ou à la prise de décision autonome. Ils reconnaissent les limites en matière de couverture des scénarios (se concentrant sur quatre flux de travail cliniques spécifiques) et la dépendance aux données MIMIC-IV, qui peuvent ne pas se généraliser à tous les systèmes de santé.