Les vocabulaires OMOP

Ce que vous savez déjà

Dans la section Comprendre les entrepôts de données de santé, l’article Parler le même langage : les terminologies médicales a présenté les terminologies médicales en général : CIM-10, SNOMED CT, LOINC, ATC, RxNorm, leurs usages respectifs.

Si ces noms ne vous disent rien, relisez d’abord cet article : nous supposons ici que vous savez ce qu’est une terminologie standardisée et pourquoi elle est nécessaire.

L’article précédent, Le modèle OMOP CDM, a par ailleurs détaillé la dualité source/standard dans les tables d’événements (condition_concept_id vs condition_source_value vs condition_source_concept_id). Cet article expose le mécanisme qui rend cette dualité possible.

Le problème qu’OMOP résout

Chaque pays, chaque hôpital, chaque éditeur de logiciel utilise ses propres codes. OMOP doit donc faire deux choses :

1. Rassembler tous ces vocabulaires dans un dictionnaire unique, requêtable en SQL.
2. Aligner les codes locaux sur des concepts standards pour permettre la comparaison internationale.

Le résultat : un système où chaque code médical existe sous une forme unifiée, identifié par un concept_id, et où les liens entre codes (équivalences, hiérarchies, alignements) sont eux-mêmes des données interrogeables.

Trois niveaux à distinguer

C’est probablement le point le moins évident de tout le système OMOP, et celui qu’il vaut mieux poser avant d’aller plus loin. Quand on regarde une ligne d’événement clinique — par exemple un diagnostic dans CONDITION_OCCURRENCE — on ne voit pas deux représentations en parallèle (source et standard), comme on pourrait le croire au premier abord, mais trois niveaux distincts.

La distinction qui surprend le plus se joue entre les cas 1 et 2 (présentés ci-dessous) : être présent dans les OHDSI Vocabularies ne veut pas dire être standard. La CIM-10 est intégrée, chaque code a un concept_id officiel, mais ces concepts sont non standard — c’est SNOMED CT qui a été choisi comme vocabulaire standard pour les diagnostics. La CIM-10 sert donc à représenter le concept source, pas le concept standard.

Trois cas de figure typiques permettent de voir comment ces niveaux s’articulent en pratique. On les présente du plus simple au plus exigeant pour l’ETL.

Cas 1 — Le code source est déjà un concept standard

C’est la situation la plus simple : la source utilise directement le vocabulaire que OHDSI a désigné comme standard pour le domaine (LOINC pour la biologie, RxNorm pour les médicaments, SNOMED CT pour les diagnostics quand l’EHR le permet). L’ETL retrouve le concept dans CONCEPT et le pose à la fois en _source_concept_id et en _concept_id — les deux champs portent la même valeur, sans qu’aucun véritable alignement n’ait été nécessaire.

Cas 2 — Le code source est dans un vocabulaire OHDSI mais non standard

C’est le cas le plus fréquent dans les bases européennes : la source utilise un vocabulaire intégré dans les OHDSI Vocabularies — CIM-10, CIM-10-CM, CCAM, ATC, NABM… — mais qui n’est pas standard pour ce domaine. L’ETL retrouve le concept_id officiel correspondant au code, puis suit l’alignement déjà préparé dans CONCEPT_RELATIONSHIP pour atteindre le concept standard.

Cas 3 — Le code source n’est pas dans les OHDSI Vocabularies

C’est le cas le plus exigeant : le code source n’a aucun équivalent dans les vocabulaires que la communauté OHDSI maintient (nomenclature maison d’un établissement, code propriétaire d’un éditeur, libellé court d’un moniteur…). L’ETL a alors deux options.

Option A — Créer un concept custom (« 2-billionaires »). Quand le code mérite d’être tracé proprement, on lui attribue un concept_id au-delà de 2 000 000 000. OMOP réserve cette plage aux concepts locaux pour éviter tout conflit avec les identifiants officiels — d’où le surnom « 2B+ » ou « 2-billionaires ». Le concept est ajouté à un vocabulary_id dédié à l’établissement, et l’ETL doit lui-même tracer le Maps to vers le concept standard.

Option B — Laisser le concept source à 0. Quand le code source ne vaut pas la peine d’être tracé (libellé éphémère, donnée peu fiable, pas de besoin métier), l’ETL ne crée pas de concept custom. Le _source_value est conservé tel quel, mais _source_concept_id vaut 0 (« No matching concept »). Le concept standard, lui, peut toujours être renseigné si l’ETL arrive à interpréter le libellé.

Qui décide ce qui est standard ?

Cette désignation « standard / non standard » n’est pas une propriété intrinsèque d’un vocabulaire : c’est une décision prise par OHDSI, vocabulaire par vocabulaire, domaine par domaine. La CIM-10 et SNOMED CT sont toutes deux des nomenclatures matures et largement utilisées pour les diagnostics, mais c’est SNOMED CT qu’OHDSI a choisi comme standard. La CIM-10 reste donc dans les OHDSI Vocabularies, parfaitement intégrée, mais cantonnée au rôle de vocabulaire source.

Un concept représentant la signification de chaque événement clinique est désigné comme le Standard. (…) Seuls ces concepts standards sont utilisés pour enregistrer les données dans les champs du CDM qui se terminent par _CONCEPT_ID.

— Book of OHDSI, chapitre 5

Le Book of OHDSI précise les critères : le choix se fait « pour chaque domaine séparément, au niveau du vocabulaire », sur la base de la qualité des concepts, de la hiérarchie disponible et de l’objectif déclaré du vocabulaire. C’est le Vocabulary Working Group d’OHDSI qui maintient ces décisions, intègre les nouveaux vocabulaires et publie les mises à jour via ATHENA.

Standards et sources : qui fait quoi

Toutes les terminologies ne jouent pas le même rôle. OMOP désigne, pour chaque domaine, un vocabulaire standard et accepte les autres comme vocabulaires sources, à aligner sur le standard.

Les trois tables au cœur des vocabulaires

OMOP fait tenir tout son système de vocabulaires sur trois tables, qui se complètent :

• CONCEPT — le dictionnaire : un identifiant unique pour chaque code de chaque vocabulaire.
• CONCEPT_RELATIONSHIP — les liens entre concepts : équivalences, alignements, relations sémantiques.
• CONCEPT_ANCESTOR — les hiérarchies pré-calculées, pour interroger un concept et tous ses descendants.

Nous les détaillons dans cet ordre.

CONCEPT — le dictionnaire universel

CONCEPT est la table centrale du système. Chaque code médical de chaque vocabulaire intégré y figure comme une ligne unique, avec un identifiant interne stable : le concept_id.

Tous les vocabulaires cohabitent dans cette même table : une recherche WHERE concept_name LIKE '%diabetes%' peut renvoyer des résultats SNOMED CT, des codes CIM-10, des codes Read britanniques, ou des concepts d’autres vocabulaires nationaux.

CONCEPT_RELATIONSHIP — les liens entre concepts

Une fois le dictionnaire en place, il faut relier les concepts entre eux. C’est le rôle de CONCEPT_RELATIONSHIP. Chaque ligne définit une relation orientée :

concept_id_1 → [relationship_id] → concept_id_2

Quelques relations parmi les plus importantes :

Les concepts standards sont alignés sur eux-mêmes, les concepts non standards sur des concepts standards. La plupart des concepts non standards et tous les concepts standards portent cette relation vers un concept standard.

— Book of OHDSI, section 5.3.1

Concrètement, si vous avez un code source CIM-10 E11.9 (diabète sucré de type 2 sans complication) dans condition_source_value, son condition_source_concept_id pointera vers le concept OMOP 45561952 qui représente ce code. Ce concept est non standard, mais il a une relation Maps to vers le concept SNOMED CT standard 201826 — qui est ce qu’on retrouvera dans condition_concept_id.

CONCEPT_ANCESTOR — les hiérarchies pré-calculées

Les vocabulaires médicaux sont hiérarchiques : Diabète de type 2 est un enfant de Diabète, qui est un enfant de Maladie endocrinienne. Quand on veut tous les patients ayant un diabète quel qu’il soit, on ne veut pas lister tous les sous-types manuellement.

CONCEPT_ANCESTOR résout ce problème en stockant à l’avance toutes les paires ancêtre/descendant, à toutes les profondeurs de la hiérarchie.

Cela permet une requête comme :

SELECT *
FROM condition_occurrence c
WHERE c.condition_concept_id IN (
  SELECT descendant_concept_id
  FROM concept_ancestor
  WHERE ancestor_concept_id = 201820  -- Diabetes mellitus
)

Sans CONCEPT_ANCESTOR, il faudrait une jointure récursive sur CONCEPT_RELATIONSHIP — beaucoup plus lente et fragile.

DRUG_STRENGTH — la dose réelle des médicaments

Comme rappelé dans l’article précédent, DRUG_EXPOSURE ne stocke pas directement la dose reçue par le patient : la colonne quantity donne uniquement le nombre d’unités délivrées (comprimés, ampoules, millilitres…). Pour calculer la dose réelle, il faut joindre DRUG_EXPOSURE avec DRUG_STRENGTH, qui contient la concentration du principe actif pour chaque produit standard.

DRUG_STRENGTH distingue deux familles de formes galéniques via des colonnes différentes :

• Formes solides ou unitaires (comprimé, gélule, ampoule entière) : la quantité par unité est portée par amount_value et amount_unit_concept_id.
• Formes liquides ou de concentration (solution, perfusion, sirop, patch) : la concentration s’exprime comme un rapport numerator_value / denominator_value avec leurs unités respectives.

Le détail des formules de calcul de dose (par forme galénique, avec ou sans concentration) est dans la documentation officielle OMOP sur le calcul de dose. Pour la pratique, le tutoriel SQL de niveau avancé contient des exercices dédiés (dose totale d’un comprimé, débit d’une perfusion IV).

Les autres tables de vocabulaire

CONCEPT, CONCEPT_RELATIONSHIP, CONCEPT_ANCESTOR et DRUG_STRENGTH portent l’essentiel du système. Six tables auxiliaires complètent le dispositif. On les croise rarement dans les requêtes d’analyse, mais il est utile de savoir à quoi elles servent.

Concept_id = 0 — le « NULL » d’OMOP

Une convention déjà rencontrée dans l’article précédent : quand un code source n’a pas d’alignement disponible, son _concept_id est mis à 0.

CONCEPT.concept_id = 0 existe vraiment dans le dictionnaire ; il porte le nom “No matching concept”. C’est un choix de design pour éviter les NULL SQL classiques et fournir un signalement explicite.

Dans les vocabulaires standardisés, on ne distingue pas pourquoi une information est absente : retrait actif par le patient, valeur manquante, valeur non définie ou non standardisée, ou absence d’enregistrement d’alignement dans CONCEPT_RELATIONSHIP. Tout concept non aligné correspond, par défaut, à un alignement vers le concept standard concept_id = 0.

— Book of OHDSI, section 5.6.10 « Flavors of NULL »

En pratique :

• Comptez régulièrement les concept_id = 0 par table — c’est l’indicateur de qualité d’alignement le plus simple.
• Un code source peut être présent (source_value non vide) et son source_concept_id valide, tandis que le _concept_id standard vaut 0 si le concept source n’a pas encore d’alignement.

ATHENA — explorer les vocabulaires sans SQL

ATHENA est le dictionnaire centralisé des vocabulaires OMOP, accessible via une interface graphique. On y retrouve la même information que dans les tables CONCEPT, CONCEPT_RELATIONSHIP et CONCEPT_ANCESTOR d’une base OMOP, mais sans avoir à écrire une requête SQL à chaque fois qu’on cherche un concept : recherche par libellé, filtres par domaine, vocabulaire et statut standard, navigation dans les relations et les hiérarchies en quelques clics.

Avec un compte ATHENA (gratuit), on peut télécharger un bundle de vocabulaires prêt à être importé dans sa propre base OMOP — étape obligatoire pour que CONCEPT, CONCEPT_RELATIONSHIP et CONCEPT_ANCESTOR soient peuplés dans votre instance.

ATHENA est présenté plus en détail dans l’article sur l’écosystème d’outils OHDSI.

En pratique : les concept sets

Pour les analyses cliniques, on travaille rarement avec un seul concept à la fois. On construit des concept sets : des collections de concepts standards qui représentent ensemble une même notion clinique. Par exemple, un concept set « fréquence cardiaque » regroupera tous les codes LOINC sous lesquels cette mesure peut être enregistrée (variations selon le contexte de mesure, la méthode, la position du patient…), et un concept set « créatininémie » regroupera de même les différents codes LOINC du dosage de créatinine sanguine.

Un concept set typique combine plusieurs mécanismes :

1. Quelques concepts racines sélectionnés explicitement (par exemple le concept LOINC Heart rate).
2. L’inclusion des descendants via CONCEPT_ANCESTOR pour récupérer tous les sous-types — utile surtout pour les conditions et les médicaments, dont les hiérarchies sont les plus complètes.
3. L’exclusion sélective des descendants qu’on ne veut pas (par exemple, exclure une variante mesurée dans un contexte particulier).

C’est exactement ce que permet de construire ATLAS sans coder, ou ce qu’on écrit directement en SQL pour les exercices à venir. La documentation officielle d’ATLAS sur les concept sets détaille la marche à suivre, et l’INDICATE Data Dictionary propose 300+ exemples de concept sets cliniques prêts à l’emploi.

Pour aller plus loin

• L’explorateur interactif couvre aussi les tables de vocabulaire avec leurs colonnes et clés.
• Le chapitre 5 du Book of OHDSI est la référence officielle complète.
• ATHENA pour explorer concrètement les concepts et leurs relations.