Aligner ne suffit pas : les trois niveaux de dérivation de concepts

Le point de départ : fédérer suppose des données alignées

Je travaille dans INDICATE, un projet européen qui construit une infrastructure fédérée pour les données de réanimation. Dans un modèle fédéré, on ne déplace pas les données : c’est l’analyse qui voyage. Le code part vers chaque hôpital, s’exécute localement, et seuls des résultats agrégés reviennent. Les données patients ne quittent jamais leur établissement d’origine.

Illustrations tirées du cours INDICATE Data model training — Session 1 — Onboarding and data model.

Pour que cela fonctionne, il y a un prérequis incontournable : chaque centre doit exposer ses données dans le même format, alignées sur les mêmes concepts. Concrètement, chaque centre aligne ses concepts sources — ses codes locaux — vers des concepts cibles standards (SNOMED, LOINC, RxNorm…). Lorsqu’une étude est montée en fédéré, les scripts requêtent tous les centres en même temps : l’alignement doit donc être homogène d’un centre à l’autre, sans quoi les scripts ne fonctionnent pas, ou produisent des résultats biaisés.

C’est tout l’enjeu de l’interopérabilité, et c’est l’objet de notre Data Dictionary : harmoniser cet alignement sémantique entre centres, notamment grâce aux commentaires d’experts de chaque domaine, qui indiquent quel concept retenir, lequel exclure, et pourquoi.

C’est ainsi que j’ai présenté cet alignement, dans notre article Construire un ETL OMOP : l’alignement sémantique est l’essentiel du travail, et le chargement des données dans le modèle commun OMOP se réduit ensuite à un simple routage — une fois qu’on sait à quel concept cible correspond chaque concept source, il suffit d’envoyer chaque donnée dans la bonne table. C’est vrai pour une mesure de sodium. Ça devient faux dès que le concept cible n’existe pas tel quel dans les données sources.

Le vrai problème : la donnée brute

Les données d’un dossier patient informatisé sont saisies par des soignants, à travers un logiciel qui change d’un hôpital à l’autre — et donc une façon de le remplir qui change elle aussi. Elles arrivent dans l’entrepôt de données de santé via un processus d’ETL, souvent telles quelles — c’est-à-dire brutes. (Nos articles Les entrepôts de données de santé et Des données brutes aux données exploitables détaillent ces deux notions.)

Le concept cible peut alors se trouver dans trois situations :

1. il existe déjà, standardisé et fiable, dans les données ;
2. il n’existe pas comme tel, mais on peut le reconstruire à partir d’autres concepts déjà standards ;
3. il n’existe pas, et même les variables qui permettraient de le reconstruire n’ont pas de modélisation standard — la façon dont elles sont saisies dépend du logiciel et des habitudes de chaque équipe.

Ces trois situations appellent trois réponses différentes — trois voies vers un même concept cible. Ce ne sont pas des étages qu’on franchirait l’un après l’autre : selon le concept, on emprunte l’une ou l’autre, et certaines voies se composent. C’est ce que résume le schéma ci-dessous.

Niveau 1 — aucune dérivation

Le concept cible existe déjà dans les données, standardisé et fiable. Le seul travail est l’alignement : associer le code source (ou la variable locale) au bon concept standard. Aucune logique, aucun calcul.

C’est le cas idéal, celui qu’on imagine spontanément quand on parle d’interopérabilité. Une glycémie, une fréquence cardiaque mesurée, un code SNOMED de diagnostic déjà présent : on les fait pointer vers le concept standard correspondant, et c’est terminé.

La difficulté résiduelle à ce niveau est de choisir les bons codes parmi des centaines de candidats — un même « sodium » peut correspondre à des dizaines de codes LOINC selon le prélèvement, la méthode, l’unité. Toutefois, c’est une difficulté de sélection sémantique, pas de reconstruction.

Niveau 2 — dérivation interopérable

Le concept cible n’existe pas tel quel, mais on peut le reconstruire à partir d’autres concepts qui sont, eux, déjà standards. Comme ici les ingrédients sont standards, la recette de reconstruction est générique : elle s’écrit une fois et vaut pour tous les centres. D’où le nom : dérivation interopérable.

L’exemple type est la ventilation invasive. La prescription d’une ventilation invasive, prise seule, n’est pas fiable : une prescription peut perdurer parce qu’on aura oublié de l’arrêter, ou alors les paramètres du respirateur peuvent ne pas remonter dans le logiciel de réanimation pendant un temps, etc. On ne l’écarte pas pour autant : on la combine avec d’autres concepts, eux aussi mesurés en standard :

• une pression de plateau (code SNOMED 264907004 — OMOP concept 4139635) n’est mesurable que sur un patient intubé : sa présence fait fortement pencher vers une ventilation invasive ;
• une PEEP (code SNOMED 250854009 — OMOP concept 4353713) ne distingue pas une ventilation non invasive d’une ventilation invasive, mais élimine une simple oxygénothérapie ;
• le volume courant (code SNOMED 13621006 — OMOP concept 4029625), le mode ventilatoire, complètent le tableau.

Prise une à une, chacune de ces variables est faillible et insuffisante : aucune ne suffit à conclure seule. C’est leur combinaison, passée au tamis de règles expertes, qui produit en sortie un concept « Ventilation invasive » standardisé et fiable. Et cette règle est transposable : c’est le même raisonnement à Rennes, à Amsterdam ou à Séville.

Autre exemple, lui aussi de niveau 2 : l’insuffisance rénale aiguë selon les critères KDIGO. Elle se définit presque entièrement par une règle sur la créatinine (variation par rapport à une valeur de base) et la diurèse (mL/kg/h). Si ces deux variables sont alignées, on obtient le concept « insuffisance rénale aiguë » par un script purement interopérable — sans descendre au niveau de la dérivation locale. C’est important : tous les concepts ne demandent pas de travail local. Cela dit, la diurèse illustre bien que la frontière n’est pas tranchée : selon la façon dont elle est recueillie (cumul horaire, relevés ponctuels, poches…), l’aligner proprement peut, dans certains centres, redemander un script local en amont.

Niveau 3 — dérivation locale

Ici, le concept cible n’existe pas, et les variables qui permettraient de le reconstruire n’ont pas de modélisation standard — ou bien leur fiabilité dépend entièrement de la façon dont chaque équipe les saisit. Il faut alors un script propre à chaque centre. Ce niveau n’est pas standardisable, et c’est normal.

Reprenons le décubitus ventral. Le concept cible, lui, existe en standard, fiable — Prone body position (code SNOMED 1240000 — OMOP concept 4050473).

Le problème est en amont. Comment savoir qu’un patient était en décubitus ventral ? Dans mon centre, l’information se reconstruit à partir de trois variables :

• Position du patient, qui peut prendre les valeurs DV (décubitus ventral), DD (décubitus dorsal), DLG (décubitus latéral gauche), DLD (décubitus latéral droit), semi-assis ;
• Position de la tête, DD ou DV par exemple ;
• la prescription de mise en décubitus ventral (Placing subject in prone position, code SNOMED 431182000 — OMOP concept 4196006) — l’acte prescrit, à distinguer du fait d’être effectivement en décubitus ventral.

Cette prescription, prise seule, est peu fiable : l’acte peut avoir été réalisé sans être prescrit, ou la prescription peut ne pas avoir été décochée à l’arrêt, laissant une date de fin erronée. Et, en interrogeant la base de concepts, on constate qu’il n’existe pas de concept observable standard avec une liste de valeurs standardisées pour les deux premières. SNOMED a bien un observable « Body position » (concept 4287468), mais il n’est associé à aucune liste de valeurs du type { DV, DD, DLG, DLD, semi-assis } ; côté LOINC, la liste de réponses se limite à Assis / Couché / Debout. Pour la position de la tête, rien de standardisé avec ces valeurs. D’autant que ces valeurs varient d’un centre à l’autre, et plus encore d’un pays à l’autre.

Il faut donc un script local qui prend ces variables et applique des règles propres au centre : quel paramètre privilégier quand ils se contredisent, lequel considérer comme le plus fiable. En sortie, il produit le concept standard Prone body position. Et ce qui vaut pour mon centre ne vaudra pas pour un autre : un hôpital voisin, avec un autre logiciel et d’autres habitudes de saisie, écrira un script différent pour aboutir au même concept cible.

C’est pourquoi, à ce niveau, chaque équipe doit travailler en binôme : un data scientist et un professionnel de santé — l’utilisateur final qui renseigne réellement les données dans le logiciel. Lui seul sait comment l’information est saisie en pratique : ni le data scientist seul, ni le clinicien seul ne suffisent.

Les trois niveaux réunis : l’exemple de la dengue

Un cas qu’on m’a rapporté illustre bien que ces niveaux peuvent coexister, voire se composer, pour un même concept cible. Pour déterminer si un patient est atteint de la dengue, on s’appuie sur des critères diagnostiques. La classification OMS 2009 (Figure 1.4, p. 11) les organise sur deux axes : un axe de sévérité (dengue, avec ou sans signes d’alerte, vs dengue sévère) et un axe de certitude (dengue probable, clinique, vs dengue confirmée, au laboratoire). La dengue probable combine par exemple des éléments cliniques et biologiques :

À l’échelle d’un entrepôt de données de santé, réunir toutes ces informations n’est pas simple — et selon ce que contient déjà la base, on mobilise un, deux, ou les trois niveaux. C’est ce qui fait de la dengue l’exemple complet où l’on retrouve les trois cas de dérivation :

• parfois la dengue est déjà structurée en diagnostic dans l’entrepôt — un code source « dengue » saisi par le clinicien. Il suffit alors de l’aligner sur le concept standard Dengue (code SNOMED 38362002 — OMOP concept 440022) : c’est le niveau 1, aucune dérivation. Quand ce code existe et qu’on le juge fiable, inutile d’aller plus loin ;
• quand il n’est pas codé tel quel, on le reconstruit. Certains signes cliniques sont consignés en texte libre : il faut du TAL pour les extraire — typiquement, repérer les symptômes dans les comptes rendus médicaux — et produire des concepts structurés. C’est de la dérivation locale (le texte, sa langue, ses abréviations sont propres à chaque centre), le niveau 3 ;
• une fois ces signes et les résultats biologiques (PCR, NS1, sérologie IgM/IgG) disponibles comme concepts alignés, on peut écrire un script interopérable — le niveau 2 — qui applique les critères OMS sur ces concepts pour produire le concept cible « Dengue ». L’idée, en pseudo-code :

si (séjour/voyage en zone endémique) et fièvre
   et (≥ 2 parmi : nausées/vomissements, rash, douleurs,
                   test du tourniquet +, leucopénie, signe d'alerte) :
    dengue = "probable"
    si (PCR+ ou NS1+ ou sérologie IgM/IgG+) :
        dengue = "confirmée"
    si (choc ou saignement sévère ou atteinte d'organe sévère) :
        dengue = "sévère"
→ écrire le concept « Dengue » (avec son niveau de certitude / sévérité)

Et le TAL ne sert pas qu’à extraire des symptômes : parfois c’est le diagnostic de dengue lui-même qui est posé en toutes lettres dans un compte rendu. Le repérer relève toujours du niveau 3 (script local, propre à la langue et aux usages du centre), mais ce qu’il produit est directement le concept cible — on passe alors du niveau 3 au niveau 1, sans règle interopérable au milieu.

Selon le centre, on emprunte donc l’une ou l’autre de ces voies : un simple alignement si la dengue est déjà codée (niveau 1) ; une extraction du diagnostic depuis le texte (niveau 3) qui aboutit directement au concept (niveau 1) ; ou une remontée du niveau 3 (TAL local) vers le niveau 2 (règles interopérables) avant d’atteindre le concept cible, comme le résume la figure ci-dessous.

Le sepsis suit la même logique : le score SOFA se calcule par des règles interopérables (lactate, plaquettes, bilirubine, rapport PaO₂/FiO₂, support vasopresseur, Glasgow), mais la « suspicion d’infection » — l’association d’un prélèvement microbiologique et d’une antibiothérapie dans une fenêtre de temps — nécessite souvent des scripts locaux.

La règle : réfléchir concept par concept

Il n’y a pas de niveau « par défaut ». Le bon niveau se décide pour chaque concept cible, à partir d’une seule question :

Le concept cible existe-t-il, standardisé et fiable, dans les données sources ?

• Oui → niveau 1, aucune dérivation, simple alignement.
• Non, mais il est reconstructible à partir de concepts déjà standards → alors autant en faire un script interopérable, qui pourra être partagé à la communauté (niveau 2).
• Non, et les variables sources n’ont pas de modèle standard / leur fiabilité dépend des pratiques de saisie → niveau 3, dérivation locale, binôme data scientist + soignant.

Et les chemins se composent : parfois on va directement du local au concept cible (décubitus ventral), parfois du local vers l’interopérable puis vers la cible (dengue, sepsis), parfois on reste entièrement interopérable (insuffisance rénale aiguë).

Enfin, un réflexe à garder : dès qu’une dérivation est interopérable, autant la partager à la communauté. Un script qui ne dépend que de concepts standards fonctionnera ailleurs tel quel — le publier évite à chaque équipe de le réécrire et accélère leur travail d’alignement. Ce qui est local restera local ; mais tout ce qui peut être mutualisé devrait l’être.