Le modèle OMOP CDM

Ce que vous savez déjà

Les articles précédents de cette section ont posé le pourquoi d’OMOP (le projet initial, sa communauté, l’idée d’un format commun). Cet article ouvre le comment : à quoi ressemble concrètement le modèle lorsqu’on examine sa structure.

Pour suivre, il suffit de garder en tête quelques notions vues dans la section Comprendre les entrepôts de données de santé :

• Une base de données relationnelle est une collection de tables reliées entre elles par des clés — des colonnes partagées dont la valeur identifie un même objet d’une table à l’autre (par exemple person_id, qui apparaît dans toutes les tables d’événements pour rattacher chaque ligne à un patient unique de la table PERSON). C’est exactement la logique décrite dans l’article Comment sont organisées les données de santé ?.
• Les données de santé sont structurées au format long : une ligne par événement, des colonnes pour qualifier cet événement.
• Les codes médicaux (CIM-10, SNOMED CT, LOINC…) sont conservés sous une forme standardisée pour permettre la comparabilité entre bases.

OMOP CDM applique ces principes de manière rigoureuse : un schéma relationnel précisément spécifié, identique d’une institution à l’autre. C’est ce schéma que nous détaillons à partir d’ici.

Une brève histoire des versions

Le Common Data Model n’est pas figé : il évolue par versions, publiées par OHDSI sur GitHub. Connaître l’historique aide à comprendre la version qu’on utilise — et celles qu’on évite.

Les grandes catégories de tables

Le CDM v5.4 organise sa quarantaine de tables en six grandes catégories. Toutes ne sont pas utilisées dans toutes les bases : la plupart des entrepôts hospitaliers se concentrent sur les données cliniques et le système de santé.

Trois conventions fondamentales

Avant de plonger dans les tables une à une, trois principes structurent tout le modèle. Les comprendre vous fera gagner beaucoup de temps en pratique.

1. Modèle centré patient

Chaque enregistrement, dans toutes les tables d’événements, est associé à un identifiant patient (person_id) et à au moins une date. C’est la garantie que toute analyse peut produire une vue longitudinale de la santé d’un patient.

Les domaines sont modélisés dans un schéma relationnel centré patient, où chaque enregistrement comporte au minimum l’identité de la personne et une date.

— Book of OHDSI, section 4.1 Design Principles

2. Dualité source / standard

C’est probablement la convention OMOP la plus importante à comprendre. Pour chaque événement clinique, le modèle conserve deux représentations en parallèle :

• Le code source original tel qu’il existe dans le système hospitalier (par exemple un code CIM-10 pour un diagnostic).
• Le concept standardisé OMOP vers lequel ce code source a été mappé (par exemple le concept SNOMED CT équivalent).

Concrètement, chaque table d’événements suit le même patron de colonnes :

- <event>_concept_id        : identifiant du concept standard OMOP
- <event>_source_value      : code/libellé source tel quel
- <event>_source_concept_id : concept OMOP correspondant au code source

Pourquoi cette double représentation ? Parce qu’elle permet à la fois la comparabilité internationale (via le concept standard) et la traçabilité (en conservant le code source original, on peut toujours vérifier la donnée à la source).

3. Le type_concept_id : d’où vient cet enregistrement ?

Beaucoup de tables incluent une colonne <event>_type_concept_id. Attention au piège : ce n’est pas une catégorisation de l’événement lui-même, mais une indication de sa provenance.

Par exemple, pour un médicament dans DRUG_EXPOSURE, le drug_type_concept_id indique si la donnée vient d’une prescription, d’une dispensation ou d’une administration — pas la nature du médicament.

C’est utile pour la qualité : on peut vouloir restreindre une analyse aux médicaments effectivement dispensés ou administrés, pas seulement prescrits.

Ces trois conventions en tête, abordons maintenant les principales tables du modèle. Nous les regroupons en deux familles : d’abord celles qui décrivent le patient et son parcours dans le système de soins, puis celles qui décrivent les événements cliniques observés au fil de ce parcours.

Le patient et son parcours

PERSON — la table des patients

Tout commence par PERSON. C’est la table de démographie : une ligne par patient unique dans la base.

Notez la nuance entre year_of_birth (obligatoire) et month_of_birth/day_of_birth (optionnels). Le modèle accepte qu’une date de naissance soit partiellement connue — c’est fréquent dans les bases de remboursement.

VISIT_OCCURRENCE — les contacts avec le système de santé

Chaque contact du patient avec le système de soins (hospitalisation, consultation externe, urgence…) génère une ligne dans VISIT_OCCURRENCE.

VISIT_DETAIL — les séjours par unité dans une hospitalisation

Lors d’une hospitalisation, un patient peut transiter par plusieurs services : urgences à l’arrivée, réanimation, puis service de médecine pour la suite. VISIT_DETAIL capture ces étapes intermédiaires, chaque ligne pointant vers la visit_occurrence_id du séjour parent — on garde ainsi une vue d’ensemble tout en pouvant analyser chaque passage en unité.

Les événements cliniques

MEASUREMENT — les valeurs quantifiables

MEASUREMENT contient tout ce qui se mesure avec une valeur — chiffre, intervalle, résultat catégoriel codé.

OBSERVATION — les faits cliniques sans valeur numérique

OBSERVATION accueille les événements cliniques qui ne trouvent leur place dans aucune autre table de domaine : statut tabagique, profession, motif de consultation, antécédents familiaux, score qualitatif, exposition environnementale… Quand un concept n’appartient pas aux domaines Condition, Drug, Procedure ou Measurement, c’est ici qu’il atterrit.

Une question fréquente : où va telle ou telle donnée — MEASUREMENT ou OBSERVATION ? La règle officielle est que le domaine du concept détermine la table : un concept de domaine Measurement va dans MEASUREMENT, un concept de domaine Observation dans OBSERVATION. ATHENA donne le domaine de chaque concept.

CONDITION_OCCURRENCE — les diagnostics

Chaque diagnostic posé pour un patient devient une ligne dans CONDITION_OCCURRENCE. Une admission peut générer plusieurs lignes (un diagnostic principal + plusieurs comorbidités).

PROCEDURE_OCCURRENCE — les actes médicaux

PROCEDURE_OCCURRENCE documente tout ce qu’on fait au patient, par opposition à ce qu’on observe chez lui (CONDITION_OCCURRENCE) ou ce qu’on lui donne (DRUG_EXPOSURE).

DEVICE_EXPOSURE — les dispositifs médicaux

DEVICE_EXPOSURE stocke ce qu’on applique au patient quand il s’agit d’un objet physique — par opposition à un médicament (DRUG_EXPOSURE) ou à un geste (PROCEDURE_OCCURRENCE). La frontière avec PROCEDURE_OCCURRENCE peut être floue : la pose d’un stent est une procédure, mais le stent lui-même est un dispositif. Les deux tables coexistent souvent pour le même épisode de soin.

NOTE — les comptes-rendus en texte libre

NOTE accueille les données non structurées : ce que les autres tables ne capturent pas parce que c’est de la rédaction libre. C’est la matière première du TAL (NLP en anglais), dont les résultats remontent ensuite dans une table dédiée NOTE_NLP.

DRUG_EXPOSURE — les médicaments

DRUG_EXPOSURE regroupe toutes les expositions médicamenteuses : prescriptions, dispensations, administrations à l’hôpital. Le drug_type_concept_id permet de distinguer ces provenances.

Calculer la dose réellement reçue

Une particularité d’OMOP : la dose de médicament prise par le patient n’est pas stockée directement dans DRUG_EXPOSURE. La colonne quantity donne seulement le nombre d’unités délivrées (comprimés, ampoules, millilitres…). Pour passer du nombre d’unités à la dose réelle en milligrammes, il faut joindre DRUG_EXPOSURE avec la table DRUG_STRENGTH, qui contient la concentration du principe actif pour chaque produit standard.

Pour aller plus loin

Cet article a couvert les tables centrales pour la pratique clinique. Les autres tables (PROVIDER, CARE_SITE, LOCATION, COST, SPECIMEN, EPISODE, NOTE_NLP…) suivent les mêmes principes.

• L’explorateur interactif du schéma OMOP v5.4 donne le détail colonne par colonne de toutes les tables.
• Le chapitre 4 du Book of OHDSI est la documentation officielle complète.
• Les conventions précises (formats de date, contraintes, valeurs autorisées) sont décrites dans Themis, le référentiel officiel des conventions ETL d’OHDSI.