EveryQuery: Zero-Shot Clinical Prediction via Task-Conditioned Pretraining over Electronic Health Records

Each language version is independently generated for its own context, not a direct translation.

🏥 Le Problème : La Méthode "Devine et Compte"

Imaginez que vous essayez de prédire s'il va pleuvoir demain.
Les modèles médicaux actuels (appelés modèles autorégressifs) fonctionnent comme un météorologue un peu fou qui lance des milliers de fois un dé pour simuler le temps.

Il imagine 20 futurs différents pour un patient.
Il compte combien de fois il a plu dans ces 20 scénarios.
Si la pluie n'apparaît que 1 fois sur 20, il dit : "Il y a 5 % de chances".

Les défauts de cette méthode :

C'est lent : Faire 20 simulations pour chaque patient prend beaucoup de temps et d'ordinateurs.
C'est imprécis pour les événements rares : Si une maladie est très rare (comme un accident de voiture en 10 ans), il est possible que sur 20 simulations, elle n'apparaisse jamais. Le modèle dira alors "0 % de risque", même si le risque existe. C'est comme si le météorologue disait "il ne pleuvra jamais" juste parce qu'il n'a pas vu de pluie dans ses 20 lancers de dé.
On ne peut pas poser de questions précises : Vous ne pouvez pas dire au modèle "Quelle est la chance que ce patient ait un problème cardiaque ?". Vous devez d'abord faire toutes les simulations, puis trier les résultats. C'est comme devoir lire tout un livre pour trouver un mot précis.

💡 La Solution : EveryQuery, le "Détective Instantané"

Les auteurs proposent un nouveau modèle appelé EveryQuery. Au lieu de simuler le futur, ce modèle apprend à répondre directement à une question précise.

L'analogie du Détective :
Imaginez un détective très intelligent qui a lu tous les dossiers médicaux du monde.

L'ancien modèle (Autorégressif) : Le détective ferme les yeux, imagine 20 vies différentes pour le patient, et compte combien de fois le patient a eu une crise cardiaque dans ses rêves.
EveryQuery : Vous lui tendez une fiche avec la photo du patient et une question écrite : "Ce patient aura-t-il une crise cardiaque dans les 30 jours ?". Le détective regarde le dossier, réfléchit une seconde, et vous donne la réponse directe. Pas de rêves, pas de comptage, juste une réponse claire.

🚀 Comment ça marche ? (La Magie de l'Entraînement)

Pour apprendre à faire cela, les chercheurs ont entraîné le modèle avec une méthode spéciale :

Ils ont pris des millions de dossiers de patients.
À chaque fois, ils ont mélangé le dossier avec une question aléatoire (ex: "Aura-t-il une infection ?", "Aura-t-il une fracture ?").
Le modèle a appris à faire le lien direct entre le dossier et la réponse à la question spécifique.

C'est comme si on entraînait un étudiant non pas à écrire un roman entier, mais à répondre à n'importe quel questionnaire de type "Vrai/Faux" sur n'importe quel sujet, sans jamais avoir besoin de réécrire l'histoire.

🌟 Les Avantages Clés (En termes simples)

Rapidité Éclair (3000x plus rapide) :
- L'ancien modèle prend environ 6 secondes par patient pour faire ses 20 simulations.
- EveryQuery prend 20 millisecondes. C'est comme comparer un train à une fusée.
Meilleur pour les événements rares :
- Pour les maladies rares, l'ancien modèle rate souvent la cible (il dit 0 % alors qu'il y a un risque).
- EveryQuery, lui, regarde les signes avant-coureurs dans le dossier, même si la maladie est rare. Il ne dépend pas de la chance des simulations. C'est comme un détective qui trouve une piste même si le crime est très rare.
On peut lui poser n'importe quelle question (Promptabilité) :
- Vous pouvez lui demander : "Risque de diabète dans 30 jours ?" ou "Risque d'allergie aux pénicillines ?". Il change de "mode" instantanément pour répondre à cette question précise.

⚠️ La Limite : Le Langage de la Question

Il y a un petit bémol. Le modèle est très fort pour répondre à des questions simples comme : "Le patient aura-t-il le code médical X ?".

Mais il a du mal avec les questions complexes qui demandent de faire des choix multiples, comme : "Le patient sera-t-il réadmis à l'hôpital ?".
Pourquoi ? Parce que la réadmission peut arriver pour n'importe laquelle des 70 raisons possibles (infection, douleur, chute, etc.).

L'ancien modèle (qui imagine le futur) voit naturellement n'importe quelle raison.
EveryQuery doit poser 70 questions séparées et additionner les réponses, ce qui est moins efficace et fait perdre de la précision. C'est comme essayer de deviner si quelqu'un va gagner à la loterie en demandant "Va-t-il gagner le 1er prix ?" puis "le 2ème ?", etc., au lieu de simplement regarder le ticket gagnant.

🏁 Conclusion

EveryQuery est une révolution pour l'IA médicale car elle rend les prédictions :

Plus rapides (pas besoin de faire des milliers de simulations).
Plus précises (surtout pour les maladies rares).
Plus interactives (on pose la question, on a la réponse).

C'est un pas de géant vers un futur où les médecins pourront poser des questions instantanées à l'ordinateur pour aider les patients, plutôt que d'attendre des heures pour des statistiques floues. Le seul défi maintenant est d'apprendre à l'IA à comprendre des questions un peu plus complexes et combinées.

Each language version is independently generated for its own context, not a direct translation.

1. Problématique et Contexte

Les modèles de fondation (foundation models) pré-entraînés sur les dossiers médicaux électroniques (DME ou EHR) ont démontré un potentiel prometteur pour la prédiction clinique en générant des futurs patients synthétiques. Cependant, l'approche dominante actuelle repose sur des modèles autoregressifs (comme ETHOS ou CoMET) qui présentent trois limitations majeures :

Coût computationnel élevé : Pour obtenir une prédiction, ces modèles doivent échantillonner de nombreuses trajectoires futures (par exemple, 20 trajectoires par patient) et agréger les statistiques, ce qui est lent.
Bruit statistique et variance élevée : Les estimations pour les événements rares sont très bruitées car la probabilité d'observer un événement rare dans un nombre limité de trajectoires échantillonnées est faible, conduisant à des estimations quantifiées et souvent nulles.
Manque de "Promptability" (Interactivité) : Les utilisateurs ne peuvent pas conditionner directement les prédictions sur des questions cliniques spécifiques via un "prompt" structuré. Ils doivent soit redéfinir le pipeline d'inférence, soit créer des procédures d'agrégation personnalisées.

L'objectif de cet article est de concevoir un modèle de fondation pour les DME qui satisfasse simultanément trois propriétés : l'inférence zero-shot (sans fine-tuning spécifique), l'efficacité (une seule passe avant) et la promptabilité (conditionnement direct par une requête clinique).

2. Méthodologie : EveryQuery

Les auteurs proposent EveryQuery, un modèle de fondation qui remplace la génération autoregressive par un pré-entraînement conditionné par la tâche.

A. Formulation du Problème

Au lieu de prédire la prochaine séquence de tokens (approche générative), EveryQuery apprend à prédire directement la probabilité d'un événement futur $y$ étant donné l'historique du patient $x$ et une requête structurée $q$ .

Représentation : L'historique médical est tokenisé en une séquence de codes discrets $x$ (diagnostics, médicaments, procédures, etc.) selon le standard MEDS.
Requête ( $q$ ) : Une requête est définie comme un tuple $(c, \Delta t)$ , où $c$ est un code médical spécifique et $\Delta t$ est une fenêtre temporelle (fixée à 30 jours dans les expériences). La tâche est de déterminer si le code $c$ apparaît dans l'intervalle $[t_L, t_L + \Delta t]$ .

B. Architecture

Le modèle utilise une architecture Transformer bidirectionnel (basé sur ModernBERT) avec deux têtes de prédiction :

Prépendage de la requête : Le token de la requête $q$ est prépendé à la séquence de l'historique du patient $[q; x_1, ..., x_L]$ .
Mécanisme d'attention : Grâce à l'attention bidirectionnelle, le token de la requête peut "voir" tout l'historique du patient, et inversement. Cela permet au modèle de conditionner ses représentations internes sur la tâche spécifique demandée.
Têtes de sortie :
- Une tête prédit la probabilité que l'événement se produise ( $\hat{y}_{occurs}$ ).
- Une seconde tête prédit si la donnée est censurée ( $\hat{y}_{cens}$ ), c'est-à-dire si le dossier du patient ne couvre pas la fenêtre temporelle requise.

C. Pré-entraînement

Le modèle est pré-entraîné sur une distribution de paires (patient, requête) :

Échantillonnage : Les requêtes sont générées en tirant aléatoirement des codes parmi un vocabulaire de 10 000 codes (sur un total de 11 467).
Objectif de perte : Une fonction de perte multi-tâche combine la perte de censure (BCE) et la perte d'occurrence (BCE masquée pour ne considérer que les trajectoires non censurées).
Stratégie Zero-Shot : Le modèle apprend à répondre à n'importe quelle requête de l'espace d'entraînement sans nécessiter de fine-tuning ultérieur.

3. Résultats Expérimentaux

Les expériences ont été menées sur le jeu de données MIMIC-IV (v2.2) en comparant EveryQuery à un modèle autoregressif de référence (MEDS-EIC-AR).

A. Performance Zero-Shot

Sur 39 tâches de prédiction échantillonnées aléatoirement, EveryQuery surpasse le modèle autoregressif dans 82 % des cas.
L'amélioration moyenne de l'AUC (Area Under the Curve) est de +0,16 (IC 95% : [0,10, 0,22]).
Le modèle démontre une excellente généralisation aux codes "hors distribution" (OOD) : il surpasse la baseline sur 94 % des tâches utilisant des codes qui n'ont jamais été vus comme cibles de requêtes pendant le pré-entraînement.

B. Avantage pour les Événements Rares

C'est la découverte la plus significative :

La performance du modèle autoregressif se dégrade fortement pour les événements rares (corrélation positive forte entre la prévalence et l'AUC).
La performance d'EveryQuery est invariante à la prévalence.
Explication : Le modèle autoregressif doit "générer" l'événement rare dans ses trajectoires pour le détecter, ce qui est statistiquement improbable pour des événements rares. EveryQuery, en revanche, attend directement les signaux pertinents dans l'historique du patient liés au code demandé, indépendamment de la fréquence de l'événement dans la population.

C. Efficacité Computationnelle

EveryQuery est environ 3 000 fois plus rapide que la baseline autoregressive pour une tâche unique.
La baseline nécessite ~6 secondes par patient (pour 20 trajectoires), tandis qu'EveryQuery prend ~20 millisecondes (une seule passe avant).

D. Analyse des Représentations (Prompt Specificity)

Une analyse des embeddings (via UMAP et similarité cosinus) révèle que l'espace de représentation est organisé par la requête et non par le patient. Les embeddings pour une même requête sur différents patients sont plus similaires que les embeddings pour un même patient avec des requêtes différentes. Cela confirme que le modèle conditionne activement sa compréhension du patient sur la question posée.

E. Limites : Le cas de la Réadmission

Le modèle échoue sur la tâche de "réadmission à 30 jours". Cette tâche nécessite une logique disjonctive ("n'importe quelle admission parmi 70 codes possibles"). Comme le langage de requête actuel ne supporte qu'un seul code, l'agrégation naïve des prédictions (max ou indépendance conditionnelle) donne un AUC de 0,56 contre 0,64 pour le modèle autoregressif. Cela met en évidence une limite d'expressivité du langage de requête actuel.

4. Contributions Clés

Nouveau Paradigme : Introduction d'un modèle de fondation pour les DME basé sur le pré-entraînement conditionné par la tâche plutôt que sur la génération autoregressive.
Triple Avantage : Le modèle satisfait simultanément les trois critères désirables : inférence zero-shot, efficacité computationnelle (pas de rollouts de trajectoires) et promptabilité native.
Solution aux Événements Rares : Démonstration que le conditionnement direct résout le problème fondamental de la variance élevée et du bruit statistique des modèles génératifs pour les événements cliniques rares.
Généralisation Robuste : Preuve que le modèle généralise bien aux codes médicaux non vus comme cibles d'entraînement, grâce à la structure partagée des embeddings.

5. Signification et Perspectives

EveryQuery représente une avancée majeure pour l'application des modèles de fondation en clinique. En éliminant le besoin de générer des futurs synthétiques coûteux et bruités, il rend la prédiction clinique plus rapide, plus fiable (surtout pour les cas rares) et plus interactive.

Cependant, l'article reconnaît une compromis entre expressivité et efficacité. La limitation actuelle réside dans la capacité du langage de requête à exprimer des tâches complexes (comme les conditions disjonctives ou conjonctives). Les travaux futurs visent à enrichir ce langage de requête pour supporter des opérateurs logiques (ET, OU, NON) et des prédicats numériques, tout en conservant les avantages d'efficacité du modèle.

En résumé, EveryQuery propose une alternative supérieure aux approches génératives pour la plupart des tâches de prédiction clinique ciblées, ouvrant la voie à des systèmes d'aide à la décision clinique plus réactifs et précis.