Version imprimable multipages. Cliquer ici pour imprimer.
Par Boris Delange | 15.10.2024
Dans cet article, nous allons :
Une base de données (BDD) est comme un grand tableur Excel, où chaque feuille représente une table.
Tout l’enjeu d’une base de données est :
Comment feriez-vous pour stocker dans un tableur Excel les données de biologie et les données démographiques de 5 patients ?
Mettons que l’on ait besoin de stocker le taux d’hémoglobine, les plaquettes et les leucocytes.
Le premier réflexe qui vient à l’esprit est de créer une colonne par paramètre de biologie.
Nous ajoutons une colonne date_biologie pour connaître la date de réalisation du prélèvement biologique.
| patient_id | age | sexe | date_admission | date_sortie | date_biologie | hémoglobine | plaquettes | leucocytes |
|---|---|---|---|---|---|---|---|---|
| 1 | 45 | M | 2024-10-01 | 2024-10-10 | 2024-10-03 | 13.5 | / | / |
| 1 | 45 | M | 2024-10-01 | 2024-10-10 | 2024-10-04 | / | 150,000 | 7,200 |
| 2 | 60 | F | 2024-09-25 | 2024-10-05 | 2024-09-26 | 12.8 | 180,000 | 8,000 |
| 3 | 38 | F | 2024-10-05 | 2024-10-12 | 2024-10-07 | 14.0 | 220,000 | / |
| 3 | 38 | F | 2024-10-05 | 2024-10-12 | 2024-10-08 | / | / | 6,500 |
| 4 | 52 | M | 2024-09-20 | 2024-09-30 | 2024-09-21 | 11.5 | 140,000 | 9,500 |
| 5 | 29 | F | 2024-10-08 | 2024-10-15 | 2024-10-09 | 13.2 | 170,000 | 7,800 |
| 5 | 29 | F | 2024-10-16 | 2024-10-20 | 2024-10-16 | 14.2 | / | / |
Comment lire ce tableau ?
Le patient 1 a un seul séjour (une seule date_admission) et deux dosages biologiques à deux dates différentes durant ce même séjour (deux valeurs pour date_biologie).
Le patient 5 a deux séjours (deux valeurs pour date_admission), avec une biologie prélevée par séjour (deux valeurs différentes de date_biologie).
Nous pouvons remarquer deux choses :
Si l’on revient à nos trois principes de conception (éviter les redondances, moins de cases vides et flexibilité), il semblerait que l’on puisse faire mieux.
Pourquoi ne pas créer une table (ou une feuille Excel pour continuer avec l’analogie) pour les patients ?
| patient_id | age | sexe |
|---|---|---|
| 1 | 45 | M |
| 2 | 60 | F |
| 3 | 38 | F |
| 4 | 52 | M |
| 5 | 29 | F |
On gagne ainsi de la place avec 3 lignes en moins.
Pourquoi ne pas avoir intégré les séjours dans cette table ?
Si on avait intégré les séjours dans cette table (avec les colonnes date_admission et date_sortie), nous aurions certes eu une seule ligne pour les patients 1 à 4, mais deux lignes pour le patient 5, qui a deux séjours différents.
Toujours dans une logique de diminuer le nombre de lignes, on préférera créer une table pour les séjours.
| patient_id | admission_id | date_admission | date_sortie |
|---|---|---|---|
| 1 | 1 | 2024-10-01 | 2024-10-10 |
| 2 | 2 | 2024-09-25 | 2024-10-05 |
| 3 | 3 | 2024-10-05 | 2024-10-12 |
| 4 | 4 | 2024-09-20 | 2024-09-30 |
| 5 | 5 | 2024-10-08 | 2024-10-15 |
| 5 | 6 | 2024-10-16 | 2024-10-20 |
Pour finir, nous allons créer une table pour stocker les données de biologie.
| patient_id | admission_id | date_biologie | hémoglobine | plaquettes | leucocytes |
|---|---|---|---|---|---|
| 1 | 1 | 2024-10-03 | 13.5 | / | / |
| 1 | 1 | 2024-10-04 | / | 150,000 | 7,200 |
| 2 | 2 | 2024-09-26 | 12.8 | 180,000 | 8,000 |
| 3 | 3 | 2024-10-07 | 14.0 | 220,000 | / |
| 3 | 3 | 2024-10-07 | / | / | 6,500 |
| 4 | 4 | 2024-09-21 | 11.5 | 140,000 | 9,500 |
| 5 | 5 | 2024-10-09 | 13.2 | 170,000 | 7,800 |
| 5 | 6 | 2024-10-16 | 14.2 | / | / |
OK, mais ici nous avons encore des cases vides, nous pourrions optimiser.
La solution est de créer une colonne pour le nom du paramètre biologique, et une colonne pour sa valeur. Ainsi, plus de case vide !
| patient_id | admission_id | date_biologie | paramètre | valeur |
|---|---|---|---|---|
| 1 | 1 | 2024-10-03 | hémoglobine | 13.5 |
| 1 | 1 | 2024-10-04 | plaquettes | 150,000 |
| 1 | 1 | 2024-10-04 | leucocytes | 7,200 |
| 2 | 2 | 2024-09-26 | hémoglobine | 12.8 |
| 2 | 2 | 2024-09-26 | plaquettes | 180,000 |
| 2 | 2 | 2024-09-26 | leucocytes | 8,000 |
| 3 | 3 | 2024-10-07 | hémoglobine | 14.0 |
| 3 | 3 | 2024-10-07 | plaquettes | 220,000 |
| 3 | 3 | 2024-10-07 | leucocytes | 6,500 |
| 4 | 4 | 2024-09-21 | hémoglobine | 11.5 |
| 4 | 4 | 2024-09-21 | plaquettes | 140,000 |
| 4 | 4 | 2024-09-21 | leucocytes | 9,500 |
| 5 | 5 | 2024-10-09 | hémoglobine | 13.2 |
| 5 | 5 | 2024-10-09 | plaquettes | 170,000 |
| 5 | 5 | 2024-10-09 | leucocytes | 7,800 |
| 5 | 6 | 2024-10-16 | hémoglobine | 14.2 |
Nous venons de créer une base de données !
Alors certes, cela peut paraître moins lisible au premier abord, mais quand on a des millions de données, il est nécessaire d’optimiser leur stockage.
Et vous le verrez si vous faites un peu de programmation, cette manière d’organiser les données est finalement bien plus lisible qu’un fichier Excel à 50, 100 colonnes…
Les données sont maintenant éparpillées sur plusieurs tables.
Comment les fusionner de nouveau ?
Si l’on veut fusionner plusieurs tables, on fera ce que l’on appelle une jointure.
Par exemple, si on fait une jointure entre les tables patients et séjours, en faisant une correspondance sur la colonne patient_id, nous obtiendrons cette table :
| patient_id | age | sexe | admission_id | date_admission | date_sortie |
|---|---|---|---|---|---|
| 1 | 45 | M | 1 | 2024-10-01 | 2024-10-10 |
| 2 | 60 | F | 2 | 2024-09-25 | 2024-10-05 |
| 3 | 38 | F | 3 | 2024-10-05 | 2024-10-12 |
| 4 | 52 | M | 4 | 2024-09-20 | 2024-09-30 |
| 5 | 29 | F | 5 | 2024-10-08 | 2024-10-15 |
| 5 | 29 | F | 6 | 2024-10-16 | 2024-10-20 |
On pourra joindre les données de la table biologie de la même façon, et obtenir le tableau du début de l’article.
Il existe un langage de programmation qui permet spécifiquement de requêter les bases de données.
Ce langage se nomme SQL, pour Structured Query Language.
C’est un langage assez simple et facile d’accès.
Il se compose de quelques mots clefs qui permettent d’obtenir les données que l’on veut, dont (non exhaustif) :
Par exemple :
SELECT patient_id, age, sexe
FROM patients
WHERE age > 45
On sélectionne les colonnes patient_id, age, sexe de la table patients où la valeur de la colonne age est supérieur à la valeur 45.
On a le résultat suivant :
| patient_id | age | sexe |
|---|---|---|
| 2 | 60 | F |
| 4 | 52 | M |
Ce que l’on appelle un schéma de base de données est la structure des tables qui composent une base de données.
Il spécifie :
Par exemple, OMOP est un schéma de BDD spécialisée dans les données de santé.
Le schéma de données du modèle OMOP
Cette base est assez complexe, ce qui est nécessaire pour englober toutes les données de santé.
De même que nous l’avons fait plus haut, vous pouvez retrouver la table person qui correspond aux patients et la table visit_detail qui correspond aux séjours.
Les points à retenir :
Pour aller plus loin :
Exécutez du SQL directement dans votre navigateur grâce à DuckDB-Wasm. Données : MIMIC-IV OMOP Demo (licence).
Le modèle OMOP CDM organise les données de santé autour de tables standardisées. Pour explorer la structure complète, consultez le schéma OMOP v5.4.
Année 2135. Vous êtes data scientist spécialisé en données massives de santé, et référent OMOP de votre hôpital. Toutes les données des patients sont désormais informatisées et stockées dans des bases fédérées au format OMOP CDM, le standard international qui a unifié les systèmes de santé du monde entier.
Ce matin, une demande urgente arrive sur votre terminal : retrouver le dossier d'un patient. Seule information disponible : le patient est né en 2054.
À vous de jouer.
La table PERSON contient les informations démographiques de chaque patient. C’est le point de départ pour retrouver notre patient né en 2054.
Commencez par explorer la structure de la table person. Affichez les 5 premières lignes pour découvrir les colonnes disponibles.
Combien de patients sont enregistrés dans la base de votre hôpital ? Cela vous donnera une idée de l’ampleur de la recherche.
Vous savez que le patient recherché est né en 2054. Trouvez son person_id en filtrant sur l’année de naissance (year_of_birth).
Patient identifié : 8789342.
Pour comprendre son parcours médical, vous devez maintenant explorer son historique d'hospitalisations.
Quand a-t-il été hospitalisé ? Combien de fois ? Et quelle a été la durée de chaque séjour ?
La table VISIT_OCCURRENCE enregistre chaque hospitalisation d’un patient. Une hospitalisation peut contenir plusieurs séjours hospitaliers (dans la table visit_detail).
Affichez les 5 premières hospitalisations de la table visit_occurrence.
Combien y a-t-il d’hospitalisations au total dans la base ?
Combien d’hospitalisations a effectué notre patient (person_id = 8789342) ?
Calculez la durée en jours de chaque hospitalisation de notre patient, triées par date de début. Affichez l’identifiant de l’hospitalisation, les dates de début et fin, et créez une colonne duree_hospit pour la durée calculée.
date_fin - date_debut AS duree_hospit)
Hospitalisation identifiée : 6687131 (25 jours).
Cette hospitalisation a duré 25 jours. Que s'est-il passé pendant ce séjour ? Dans quels services le patient est-il passé ?
La table VISIT_DETAIL contient les détails granulaires d’une hospitalisation : passages aux urgences, transferts entre unités, séjours dans différentes unités hospitalières…
Affichez les 5 premières lignes de la table visit_detail pour découvrir sa structure.
Combien de séjours hospitaliers (lignes dans visit_detail) sont liés à l’hospitalisation visit_occurrence_id = 6687131 ?
Affichez tous les séjours de cette hospitalisation, triés par date de début. Sélectionnez visit_detail_id, visit_detail_start_date, visit_detail_end_date et care_site_id.
Calculez la durée de chaque séjour pour cette hospitalisation. Ajoutez une colonne duree_sejour (en jours) à la requête précédente.
En repartant de la requête précédente, récupérez le nom des unités (care_site_name) en joignant visit_detail avec la table care_site.
Intéressons-nous maintenant aux décès.
La table DEATH enregistre les décès des patients. Elle contient une ligne par patient décédé, avec la date et éventuellement la cause du décès. Explorons cette table pour comprendre la mortalité dans notre cohorte, et regardons si le patient que l'on suit est décédé.
Affichez toutes les colonnes de la table death pour découvrir sa structure.
Combien de patients sont décédés dans cette base ?
Vérifiez si notre patient 8789342 est décédé en faisant une jointure LEFT JOIN entre person et death. Affichez le person_id et la death_date (qui sera NULL si le patient est vivant).
Notre patient 8789342 est vivant.
La table OBSERVATION_PERIOD définit la période pendant laquelle un patient est suivi dans le système de santé. Elle est calculée à partir des dates min et max des hospitalisations du patient. Cette information est essentielle pour les études longitudinales.
Affichez les 5 premières lignes de la table observation_period.
Calculez la durée de suivi en jours pour notre patient 8789342. Affichez le person_id, les dates de début et fin, et créez une colonne duree_suivi.
Bien joué, vous avez exploré toutes les informations concernant le patient et ses séjours !
Maintenant voyons en détail la table CONCEPT, centrale dans le modèle OMOP. Cette table contient toutes les terminologies standardisées (SNOMED, LOINC, RxNorm...). C'est la clé pour comprendre les codes utilisés dans les autres tables.
Affichez les 5 premiers concepts de la table concept.
Recherchez le concept dont le concept_id est 8532.
Affichez le nom du genre (concept_name) pour notre patient 8789342. Joignez person et concept sur gender_concept_id.
Félicitations ! Vous avez exploré les tables fondamentales du modèle OMOP.
Il est temps de mettre en pratique toutes vos connaissances en combinant plusieurs tables dans une seule requête. C'est le vrai travail d'un data scientist en santé : croiser les informations pour obtenir une vue complète des données patient.
Créez une vue complète des séjours de l’hospitalisation 6687131 en combinant visit_detail, person, concept, care_site et death.
Affichez :
person_idvisit_occurrence_idvisit_detail_idvisit_detail_start_datetimevisit_detail_end_datetimecare_site_name : le nom du servicebirth_datetimegender_concept_name : le nom du genreage : l'âge au moment du séjourdeath_datetime : la date de décès (si applicable)Vous maîtrisez les bases du modèle OMOP. Ce niveau explore les tables cliniques : diagnostics, mesures, observations, procédures et dispositifs médicaux.
Bienvenue dans le niveau intermédiaire ! Nous allons explorer les tables cliniques du modèle OMOP.
Commençons par la table CONDITION_OCCURRENCE, qui contient les diagnostics posés. Dans OMOP, chaque diagnostic est encodé via un condition_concept_id standardisé.
La table CONDITION_OCCURRENCE stocke les diagnostics. Chaque ligne = un diagnostic posé pour un patient à une date donnée.
Découvrez la structure de la table condition_occurrence en affichant les 5 premières lignes.
Combien de diagnostics ont été posés pour notre patient 8789342 ?
Affichez les diagnostics du patient avec leur nom lisible. Joignez la table concept pour traduire les condition_concept_id.
Un même diagnostic peut apparaître plusieurs fois (à chaque hospitalisation). Listez les diagnostics uniques du patient avec leur nombre d’occurrences.
Nous avons maintenant une connaissance plus précise du patient, après avoir vu ses antécédents médicaux.
Explorons maintenant la table MEASUREMENT, qui contient les résultats quantitatifs : paramètres vitaux, examens biologiques, scores cliniques. C'est souvent la table la plus volumineuse d'une base OMOP.
La table MEASUREMENT stocke les mesures avec leur valeur numérique, leur unité et leurs bornes de référence.
Découvrez la structure de la table measurement en affichant les 5 premières lignes.
Combien de mesures ont été enregistrées pour notre patient 8789342 ?
Quels types de mesures sont les plus fréquents pour ce patient ? Affichez le nom de chaque type de mesure et son nombre d’occurrences.
nb_mesures (ex: COUNT(*) AS nb_mesures)Analysez l’évolution de la fréquence cardiaque (Heart rate, concept_id = 3027018) du patient. Affichez la date, la valeur et l’unité.
Calculez les statistiques de la fréquence cardiaque : valeur minimale, maximale et moyenne.
Explorons maintenant les observations cliniques. La table OBSERVATION capture les observations médicales : échelles de douleur, résultats d'examen clinique...
La table OBSERVATION contient des informations diverses : antécédents, habitudes, évaluations qualitatives.
Découvrez la structure de la table observation en affichant les 5 premières lignes.
Quels types d’observations sont enregistrés pour ce patient ? Affichez le nom et le nombre d’occurrences de chaque type.
Le patient a reçu différents modes d’oxygénation (concept_id = 4036936). Affichez la date et le mode d’administration stocké dans value_as_string.
Note : ce concept n’apparaît pas dans l’exercice précédent car il n’est pas disponible dans notre table concept réduite (licence SNOMED). Les données existent néanmoins dans observation.
Voyons maintenant les actes médicaux réalisés. La table PROCEDURE_OCCURRENCE contient les procédures : interventions chirurgicales, examens d'imagerie, gestes techniques...
La table PROCEDURE_OCCURRENCE enregistre tous les actes médicaux réalisés sur le patient.
Découvrez la structure de la table procedure_occurrence en affichant les 5 premières lignes.
Listez les procédures réalisées pour notre patient avec leur nom et leur nombre d’occurrences.
Affichez la chronologie des procédures du patient : date, nom de la procédure, triées par date. Utilisez DISTINCT pour éviter les doublons.
Terminons avec les dispositifs médicaux. La table DEVICE_EXPOSURE enregistre les dispositifs utilisés : sondes, cathéters, prothèses, pompes...
La table DEVICE_EXPOSURE contient les dispositifs médicaux utilisés pour le patient.
Découvrez la structure de la table device_exposure en affichant les 5 premières lignes.
Quels dispositifs ont été utilisés pour ce patient ? Affichez le nom du dispositif et le nombre d’utilisations.
Synthèse finale : Combinez vos connaissances pour créer une vue complète du patient. Vous allez croiser les données de plusieurs tables cliniques pour obtenir un résumé médical complet.
Repartez de la requête de synthèse du niveau Facile (fournie ci-dessous) et enrichissez-la en ajoutant pour chaque séjour :
hr_min : la fréquence cardiaque minimale (measurement_concept_id = 3027018)septic_shock : 1 si le patient a eu un choc septique durant le séjour (condition_concept_id = 10420211), 0 sinonSELECT
vd.person_id,
vd.visit_occurrence_id,
vd.visit_detail_id,
vd.visit_detail_start_datetime,
vd.visit_detail_end_datetime,
cs.care_site_name,
p.birth_datetime,
c.concept_name AS gender_concept_name,
DATE_PART('year', vd.visit_detail_start_datetime::TIMESTAMP) - p.year_of_birth AS age,
d.death_datetime
FROM visit_detail vd
LEFT JOIN person p ON vd.person_id = p.person_id
LEFT JOIN concept c ON p.gender_concept_id = c.concept_id
LEFT JOIN care_site cs ON vd.care_site_id = cs.care_site_id
LEFT JOIN death d ON vd.person_id = d.person_id
WHERE vd.visit_occurrence_id = 6687131
ORDER BY vd.visit_detail_start_datetime;
Source : OHDSI Common Data Model v5.4
Cliquez sur une table pour voir sa documentation complète.
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
person_id |
On suppose que chaque personne avec un identifiant unique différent est en fait une personne différente et que les données de deux personnes différentes ne doivent pas être combinées. | Toute liaison de personnes nécessaire pour identifier de manière unique les Personnes doit être effectuée avant l'écriture de cette table. Cet identifiant peut être l'id original des données source s'il s'agit d'un entier, sinon il peut être un numéro auto-généré. | integer | Oui | PK | - | - | - |
gender_concept_id |
Ce champ est destiné à capturer le sexe biologique à la naissance de la Personne. Ce champ ne doit pas être utilisé pour étudier les questions d'identité de genre. | Utilisez la valeur de genre présente dans les données en supposant qu'il s'agit du sexe biologique à la naissance. Si les données source capturent l'identité de genre, elle doit être stockée dans la table OBSERVATION. | integer | Oui | - | FK | CONCEPT | Gender |
year_of_birth |
Calculez l'âge en utilisant year_of_birth. | Pour les sources de données avec date de naissance, l'année doit être extraite. Si aucune année de naissance n'est disponible, supprimez les données de la personne de l'instance CDM. | integer | Oui | - | - | - | - |
month_of_birth |
- | Pour les sources de données qui fournissent la date de naissance précise, le mois doit être extrait et stocké dans ce champ. | integer | Non | - | - | - | - |
day_of_birth |
- | Pour les sources de données qui fournissent la date de naissance précise, le jour doit être extrait et stocké dans ce champ. | integer | Non | - | - | - | - |
birth_datetime |
Ce champ n'est pas requis mais fortement recommandé. | Pour les sources de données qui fournissent la date et l'heure précises de naissance, cette valeur doit être stockée dans ce champ. | datetime | Non | - | - | - | - |
race_concept_id |
Ce champ capture l'origine ethnique de la personne. | N'utilisez ce champ que si vous avez des informations sur l'origine ethnique disponibles dans les données source. Les origines mixtes ne sont actuellement pas supportées. Si une personne a plus d'une origine enregistrée, mettez Concept_Id 0. | integer | Oui | - | FK | CONCEPT | Race |
ethnicity_concept_id |
Ce champ capture l'Ethnicité telle que définie par l'OMB : "Hispanic" ou "Not Hispanic". | Ce champ ne doit être utilisé que pour les sources de données basées aux États-Unis. Ne pas déduire l'ethnicité de la race. | integer | Oui | - | FK | CONCEPT | Ethnicity |
location_id |
Ce champ représente la dernière localisation connue de la personne. | Mettez le location_id de la table LOCATION représentant l'information de localisation la plus précise pour la personne. | integer | Non | - | FK | LOCATION | - |
provider_id |
Ce champ représente le dernier médecin traitant connu (médecin généraliste). | Mettez le provider_id de la table PROVIDER du dernier médecin traitant connu. | integer | Non | - | FK | PROVIDER | - |
care_site_id |
Ce champ représente l'établissement de soins où le prestataire fournit habituellement des soins. | - | integer | Non | - | FK | CARE_SITE | - |
person_source_value |
Utilisez ce champ pour faire le lien avec les personnes dans les données source. | Ce champ permet de stocker la valeur de la personne telle qu'elle apparaît dans la source. Non requis mais fortement recommandé. | varchar(50) | Non | - | - | - | - |
gender_source_value |
Ce champ est utilisé pour stocker le sexe biologique de la personne à partir des données source. | Mettez le sexe biologique tel qu'il apparaît dans les données source. | varchar(50) | Non | - | - | - | - |
gender_source_concept_id |
En raison du petit nombre d'options, ce champ tend à être zéro. | Si les données source codent le sexe biologique dans un vocabulaire supporté par OMOP, stockez le concept_id ici. | integer | Non | - | FK | CONCEPT | - |
race_source_value |
Ce champ est utilisé pour stocker l'origine ethnique de la personne à partir des données source. | Mettez l'origine ethnique telle qu'elle apparaît dans les données source. | varchar(50) | Non | - | - | - | - |
race_source_concept_id |
En raison du petit nombre d'options, ce champ tend à être zéro. | Si les données source codent l'origine ethnique dans un vocabulaire supporté par OMOP, stockez le concept_id ici. | integer | Non | - | FK | CONCEPT | - |
ethnicity_source_value |
Ce champ est utilisé pour stocker l'ethnicité de la personne à partir des données source. | Mettez l'ethnicité telle qu'elle apparaît dans les données source. | varchar(50) | Non | - | - | - | - |
ethnicity_source_concept_id |
En raison du petit nombre d'options, ce champ tend à être zéro. | Si les données source codent l'ethnicité dans un vocabulaire supporté par OMOP, stockez le concept_id ici. | integer | Non | - | FK | CONCEPT | - |
Cette table sert de gestion centrale de l'identité pour toutes les Personnes dans la base de données. Elle contient des enregistrements qui identifient de manière unique chaque personne ou patient, ainsi que quelques informations démographiques.
Tous les enregistrements de cette table sont des Personnes indépendantes.
Toutes les Personnes d'une base de données doivent avoir un enregistrement dans cette table, sauf si elles échouent aux exigences de qualité des données spécifiées dans l'ETL. Les Personnes sans Événements doivent quand même avoir un enregistrement. Si plus d'une source de données contribue aux Événements de la base de données, les Personnes doivent être réconciliées, si possible, entre les sources pour créer un seul enregistrement par Personne. Le contenu de BIRTH_DATETIME doit être équivalent au contenu de BIRTH_DAY, BIRTH_MONTH et BIRTH_YEAR.
Pour les conventions détaillées, consultez le dépôt THEMIS.
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
observation_period_id |
Identifie chaque période d'observation distincte par personne. | Attribuez un ID unique à chaque période discrète par personne. | integer | Oui | PK | - | - | - |
person_id |
Lien vers la personne concernée par la période d'observation. | Doit correspondre à une entrée valide dans la table PERSON. | integer | Oui | - | FK | PERSON | - |
observation_period_start_date |
Détermine le début de la période. | Souvent déduit comme la date de l'événement le plus ancien ; dans les données d'assurance, représente le début de l'affiliation. | date | Oui | - | - | - | - |
observation_period_end_date |
Détermine la fin de la période quand tous les événements sont capturés. | Souvent déduit comme la date de l'événement le plus récent ; dans les données d'assurance, représente la fin de l'affiliation. | date | Oui | - | - | - | - |
period_type_concept_id |
Indique la source de provenance (affiliation, DPI, autre). | Sélectionnez le concept représentant la méthode de détermination ; domaine Type Concept standard. | integer | Oui | - | FK | CONCEPT | Type Concept |
La table OBSERVATION_PERIOD définit les périodes de temps pendant lesquelles les événements cliniques sont censés être enregistrés pour une personne. Elle établit la période où les événements indiquent des occurrences réelles, et leur absence suggère une non-occurrence.
Chaque personne peut avoir plusieurs enregistrements OBSERVATION_PERIOD non chevauchants. Les événements peuvent exister en dehors de ces périodes mais ne peuvent pas être présumés absents. Les calculs d'incidence et de prévalence ne doivent utiliser que les périodes d'observation actives. Lors de la définition des cohortes, les événements en dehors de ces périodes peuvent informer les critères d'inclusion, bien que l'exhaustivité ne soit pas garantie. Les périodes courtes (jours uniques) peuvent fausser les calculs de taux, donc l'application d'exigences minimales de temps d'observation est recommandée.
Chaque personne nécessite au moins un OBSERVATION_PERIOD représentant les intervalles avec une capture élevée d'événements cliniques. Ceux-ci peuvent dériver des périodes d'affiliation (données d'assurance) ou nécessiter une inférence (systèmes DPI). Le début reflète typiquement l'événement clinique le plus ancien, et la fin reflète soit l'événement le plus récent, soit la date de coupure de la base de données. Les périodes à événement unique sont valides. Les périodes chevauchantes ou adjacentes doivent être fusionnées en une seule.
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
person_id |
Identifiant unique liant à la personne décédée. | Lien vers la table PERSON. | integer | Oui | PK | FK | PERSON | - |
death_date |
Date de décès de la personne. | Si la date précise n'est pas connue, estimez la date. | date | Oui | - | - | - | - |
death_datetime |
Date et heure de décès de la personne. | Si aucune heure n'est donnée, définir à minuit (00:00:00). | datetime | Non | - | - | - | - |
death_type_concept_id |
Provenance de l'enregistrement de décès. | Utilisez ce champ pour identifier la provenance de l'enregistrement de décès (par ex. DPI, certificat de décès, données d'assurance). | integer | Oui | - | FK | CONCEPT | Type Concept |
cause_concept_id |
Concept standard représentant la cause du décès. | Mappez la cause du décès vers un Concept Standard dans le domaine Condition si disponible. | integer | Non | - | FK | CONCEPT | Condition |
cause_source_value |
Code source pour la cause du décès. | Stockez la valeur source originale. | varchar(50) | Non | - | - | - | - |
cause_source_concept_id |
Concept représentant la cause source du décès. | Si les données source codent la cause du décès dans un vocabulaire supporté par OMOP, stockez le concept_id ici. | integer | Non | - | FK | CONCEPT | - |
La table DEATH contient l'événement clinique du décès d'une personne. Chaque personne peut avoir au maximum un enregistrement dans cette table. La cause du décès peut être capturée si disponible.
Les personnes vivantes ne doivent pas avoir d'enregistrement dans cette table. Chaque personne ne peut avoir qu'un seul enregistrement de décès. Si plusieurs enregistrements de décès existent dans les données source, choisissez le plus fiable en fonction de l'évaluation de la qualité des données.
Si les informations de décès proviennent de plusieurs sources (par ex. DPI et données d'assurance), réconciliez-les pour créer un seul enregistrement de décès. Le death_type_concept_id doit refléter la source la plus fiable. La cause du décès doit être mappée vers un Concept Standard dans le domaine Condition quand c'est possible.
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
visit_occurrence_id |
Identifiant unique pour chaque interaction. | Créé en attribuant un ID distinct à chaque rencontre patient-système de santé. | integer | Oui | PK | - | - | - |
person_id |
Identifie le patient. | Lien vers la table PERSON. | integer | Oui | - | FK | PERSON | - |
visit_concept_id |
Concept standard du domaine Visit représentant le type de rencontre. | Remplissez ce champ en fonction du type de visite effectuée. | integer | Oui | - | FK | CONCEPT | Visit |
visit_start_date |
Date d'admission pour les hospitalisations ; date d'interaction patient-prestataire pour les autres. | Si cette information n'est pas disponible, l'enregistrement doit être supprimé. | date | Oui | - | - | - | - |
visit_start_datetime |
Heure de début de la visite. | Si aucune heure n'est donnée pour la date de début d'une visite, définir à minuit (00:00:00). | datetime | Non | - | - | - | - |
visit_end_date |
Date de sortie pour les hospitalisations ; identique à la date de début pour les visites du même jour. | Les dates de fin de visite sont obligatoires. | date | Oui | - | - | - | - |
visit_end_datetime |
Heure de fin de la visite. | Défaut à minuit si non disponible. | datetime | Non | - | - | - | - |
visit_type_concept_id |
Indique la provenance (DPI vs. données d'assurance). | Remplissez ce champ en fonction de la provenance de l'enregistrement de visite. | integer | Oui | - | FK | CONCEPT | Type Concept |
provider_id |
Prestataire unique associé. | S'il y a plusieurs prestataires associés à une visite, vous devrez choisir lequel mettre ici. | integer | Non | - | FK | PROVIDER | - |
care_site_id |
Localisation de l'établissement de santé. | Lien vers la table CARE_SITE. | integer | Non | - | FK | CARE_SITE | - |
visit_source_value |
Valeur source verbatim indiquant le type de visite. | Stockez le code source original. | varchar(50) | Non | - | - | - | - |
visit_source_concept_id |
Concept de codage du système source si supporté par OMOP. | Mappez vers le concept si la source utilise un vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
admitted_from_concept_id |
Concept standard du domaine Visit indiquant l'origine de l'admission. | Si une personne a été admise depuis son domicile ou s'est auto-référée, définir à 0. | integer | Non | - | FK | CONCEPT | Visit |
admitted_from_source_value |
Valeur source verbatim pour l'origine de l'admission. | Stockez la valeur source originale. | varchar(50) | Non | - | - | - | - |
discharged_to_concept_id |
Concept de destination de sortie. | On suppose qu'une personne sort vers son domicile donc il n'y a pas de concept_id standard pour 'domicile'. Utilisez concept_id = 0. | integer | Non | - | FK | CONCEPT | Visit |
discharged_to_source_value |
Valeur source verbatim pour la destination de sortie. | Stockez la valeur source originale. | varchar(50) | Non | - | - | - | - |
preceding_visit_occurrence_id |
Lien vers la visite immédiatement précédente pour la même personne. | Utilisez pour chaîner les visites chronologiquement. | integer | Non | - | FK | VISIT_OCCURRENCE | - |
La table VISIT_OCCURRENCE contient des événements représentant les périodes où les personnes interagissent avec le système de santé. Ces rencontres sont configurées par des circonstances spécifiques incluant la localisation du patient (institutionnelle vs. à distance), la disponibilité du prestataire et la durée du séjour.
Les types de visites sont organisés hiérarchiquement en utilisant des concepts standardisés du domaine Visit. Les configurations de visites courantes incluent : Visite hospitalière (admission à l'hôpital avec séjour au lit dépassant un jour), Visite aux urgences (soins d'urgence le même jour), Visite ambulatoire (soins ambulatoires le même jour sans lit), Visite à domicile (le prestataire fournit le service au domicile du patient), Visite de télésanté (interaction patient-prestataire à distance), Visites en pharmacie/laboratoire (visites spécialisées le même jour), Visite de gestion de cas (interaction administrative sans prestataires). La durée de la visite, ou 'durée de séjour', est définie comme VISIT_END_DATE - VISIT_START_DATE.
Les concepts de visite dérivent des systèmes de codage de santé (CPT, Place of Service). Lorsqu'ils ne sont pas disponibles, les visites doivent être inférées par des hypothèses ETL définies. Les visites peuvent être adjacentes mais ne peuvent pas se chevaucher sur des dates non-limites. Les visites multi-jours ne peuvent pas partager de jours sauf aux points de début/fin.
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
visit_detail_id |
Identifiant unique pour chaque enregistrement de détail de visite. | Généré lors de l'ETL. | integer | Oui | PK | - | - | - |
person_id |
Identifie le patient. | Lien vers la table PERSON. | integer | Oui | - | FK | PERSON | - |
visit_detail_concept_id |
Concept standard pour le type de détail de visite. | Doit être un descendant du VISIT_CONCEPT_ID de la visite parente. | integer | Oui | - | FK | CONCEPT | Visit |
visit_detail_start_date |
Date de début du détail de visite. | Champ obligatoire. | date | Oui | - | - | - | - |
visit_detail_start_datetime |
Date et heure de début du détail de visite. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
visit_detail_end_date |
Date de fin du détail de visite. | Champ obligatoire. | date | Oui | - | - | - | - |
visit_detail_end_datetime |
Date et heure de fin du détail de visite. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
visit_detail_type_concept_id |
Provenance de l'enregistrement de détail de visite. | Indique d'où proviennent les données. | integer | Oui | - | FK | CONCEPT | Type Concept |
provider_id |
Professionnel de santé associé au détail de visite. | Lien vers la table PROVIDER. | integer | Non | - | FK | PROVIDER | - |
care_site_id |
Établissement de soins où le détail de visite a eu lieu. | Lien vers la table CARE_SITE. | integer | Non | - | FK | CARE_SITE | - |
visit_detail_source_value |
Valeur source pour le type de détail de visite. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
visit_detail_source_concept_id |
Concept source pour le type de détail de visite. | Mapper vers un concept si la source utilise le vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
admitted_from_concept_id |
Concept indiquant l'origine de l'admission. | Utiliser 0 pour le domicile ou l'auto-référence. | integer | Non | - | FK | CONCEPT | Visit |
admitted_from_source_value |
Valeur source pour l'origine de l'admission. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
discharged_to_concept_id |
Concept de destination de sortie. | Utiliser 0 pour un retour à domicile. | integer | Non | - | FK | CONCEPT | Visit |
discharged_to_source_value |
Valeur source pour la destination de sortie. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
preceding_visit_detail_id |
Lien vers le détail de visite immédiatement précédent. | Utiliser pour chaîner les détails de visite chronologiquement. | integer | Non | - | FK | VISIT_DETAIL | - |
parent_visit_detail_id |
Lien vers un détail de visite parent pour les hiérarchies imbriquées. | Utiliser pour les hiérarchies de visites à plusieurs niveaux. | integer | Non | - | FK | VISIT_DETAIL | - |
visit_occurrence_id |
Lien vers la visite parente. | Lien obligatoire vers la table VISIT_OCCURRENCE. | integer | Oui | - | FK | VISIT_OCCURRENCE | - |
La table VISIT_DETAIL représente les détails granulaires des enregistrements VISIT_OCCURRENCE parents. Elle maintient une relation 1:n où chaque VISIT_OCCURRENCE peut avoir zéro ou plusieurs enregistrements VISIT_DETAIL associés. Les exemples incluent les transferts d'unité pendant les séjours hospitaliers ou les lignes de facturation individuelles dans les demandes de remboursement.
Les enregistrements VISIT_DETAIL doivent avoir leur VISIT_OCCURRENCE_ID associé spécifié. Chaque VISIT_DETAIL_CONCEPT_ID doit être un descendant du VISIT_CONCEPT_ID de la visite parente, maintenant une cohérence hiérarchique au sein de la structure du domaine des visites.
Le remplissage de VISIT_DETAIL est optionnel mais recommandé lorsque les données sources nécessitent une logique d'agrégation pour créer des enregistrements VISIT_OCCURRENCE unifiés. Dans les systèmes de dossiers médicaux électroniques, plusieurs interactions avec des professionnels de santé peuvent être consolidées en une seule visite en utilisant VISIT_DETAIL pour préserver les informations granulaires des rencontres.
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
condition_occurrence_id |
Identifiant unique pour chaque occurrence de condition. | Généré lors de l'ETL. | integer | Oui | PK | - | - | - |
person_id |
Identifie le patient. | Lien vers la table PERSON. | integer | Oui | - | FK | PERSON | - |
condition_concept_id |
Concept standard représentant la condition. | Mapper le code source vers un Concept Standard du domaine Condition. | integer | Oui | - | FK | CONCEPT | Condition |
condition_start_date |
Date à laquelle la condition a été diagnostiquée ou a commencé. | Champ obligatoire. | date | Oui | - | - | - | - |
condition_start_datetime |
Date et heure auxquelles la condition a été diagnostiquée ou a commencé. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
condition_end_date |
Date à laquelle la condition s'est résolue. | Souvent indisponible ; utiliser CONDITION_ERA pour les périodes dérivées. | date | Non | - | - | - | - |
condition_end_datetime |
Date et heure auxquelles la condition s'est résolue. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
condition_type_concept_id |
Provenance de l'enregistrement de condition. | Indique d'où proviennent les données (DME, remboursements, etc.). | integer | Oui | - | FK | CONCEPT | Type Concept |
condition_status_concept_id |
Statut de la condition (préliminaire, final, etc.). | Utiliser les concepts du domaine Condition Status. | integer | Non | - | FK | CONCEPT | Condition Status |
stop_reason |
Raison pour laquelle la condition n'est plus enregistrée. | Souvent indisponible. | varchar(20) | Non | - | - | - | - |
provider_id |
Professionnel de santé ayant diagnostiqué la condition. | Lien vers la table PROVIDER. | integer | Non | - | FK | PROVIDER | - |
visit_occurrence_id |
Visite au cours de laquelle la condition a été diagnostiquée. | Lien vers la table VISIT_OCCURRENCE. | integer | Non | - | FK | VISIT_OCCURRENCE | - |
visit_detail_id |
Détail de visite au cours duquel la condition a été diagnostiquée. | Lien vers la table VISIT_DETAIL. | integer | Non | - | FK | VISIT_DETAIL | - |
condition_source_value |
Code source pour la condition. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
condition_source_concept_id |
Concept source pour la condition. | Mapper vers un concept si la source utilise le vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
condition_status_source_value |
Valeur source pour le statut de la condition. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
Cette table documente les événements cliniques indiquant une maladie ou une condition médicale. Les enregistrements capturent les diagnostics, signes ou symptômes soit observés par les professionnels de santé, soit rapportés par les patients.
Les conditions sont organisées dans un système hiérarchique au sein du domaine Condition. Enregistrer toutes les conditions sources sans appliquer de filtres analytiques. Les diagnostics d'exclusion doivent être exclus. Les antécédents familiaux et les événements médicaux passés appartiennent à la table OBSERVATION.
Tous les codes sources mappant vers des concepts standard du domaine Condition doivent être enregistrés dans cette table. Les conditions en double au sein d'une même rencontre nécessitent une logique ETL pour déterminer s'il faut les consolider ou maintenir des enregistrements séparés.
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
drug_exposure_id |
Identifiant unique pour chaque enregistrement d'exposition médicamenteuse. | Généré lors de l'ETL. | integer | Oui | PK | - | - | - |
person_id |
Personne recevant le médicament. | Lien vers la table PERSON. | integer | Oui | - | FK | PERSON | - |
drug_concept_id |
Concept standard du médicament (mappé depuis la source). | Doit mapper vers le domaine Drug. | integer | Oui | - | FK | CONCEPT | Drug |
drug_exposure_start_date |
Date de début de prescription, de délivrance ou d'administration. | Champ obligatoire. | date | Oui | - | - | - | - |
drug_exposure_start_datetime |
Date et heure de début de l'exposition médicamenteuse. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
drug_exposure_end_date |
Date de fin de l'exposition médicamenteuse. | Déduite de la date de début et de la durée si non disponible. | date | Oui | - | - | - | - |
drug_exposure_end_datetime |
Date et heure de fin de l'exposition médicamenteuse. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
verbatim_end_date |
Date de fin telle qu'elle apparaît dans les données sources. | Stocker la date de fin d'origine si disponible. | date | Non | - | - | - | - |
drug_type_concept_id |
Provenance (prescrit, dispensé, administré). | Domaine Type Concept. | integer | Oui | - | FK | CONCEPT | Type Concept |
stop_reason |
Raison de l'arrêt du médicament. | Souvent indisponible. | varchar(20) | Non | - | - | - | - |
refills |
Renouvellements prévus au moment de la prescription. | Stocker comme entier. | integer | Non | - | - | - | - |
quantity |
Quantité totale dispensée. | Conversion d'unité vers la table DRUG_STRENGTH requise. | float | Non | - | - | - | - |
days_supply |
Jours d'approvisionnement tels qu'enregistrés. | Exclure les valeurs négatives ou erronément élevées. | integer | Non | - | - | - | - |
sig |
Instructions verbatim du prescripteur pour le médicament. | Stocker comme texte. | text | Non | - | - | - | - |
route_concept_id |
Voie d'administration. | Domaine Route. | integer | Non | - | FK | CONCEPT | Route |
lot_number |
Identifiant du lot de fabrication. | Stocker si disponible. | varchar(50) | Non | - | - | - | - |
provider_id |
Prescripteur ou professionnel administrant. | Lien vers la table PROVIDER. | integer | Non | - | FK | PROVIDER | - |
visit_occurrence_id |
Visite associée. | Lien vers la table VISIT_OCCURRENCE. | integer | Non | - | FK | VISIT_OCCURRENCE | - |
visit_detail_id |
Détail de visite associé (ex. séjour en réanimation). | Lien vers la table VISIT_DETAIL. | integer | Non | - | FK | VISIT_DETAIL | - |
drug_source_value |
Code source (NDC, Gemscript). | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
drug_source_concept_id |
Concept source (non standard). | Mapper vers un concept si la source utilise le vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
route_source_value |
Voie verbatim des données sources. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
dose_unit_source_value |
Unité de dose verbatim. | Champ déprécié. | varchar(50) | Non | - | - | - | - |
La table DRUG_EXPOSURE capture les enregistrements documentant l'exposition d'une personne à un médicament ou une substance biochimique introduite dans le corps. Les médicaments comprennent les médicaments sur ordonnance et en vente libre, les vaccins et les thérapies biologiques.
Les enregistrements de cette table indiquent l'exposition aux médicaments. La table documente les prescriptions rédigées, les prescriptions dispensées et les médicaments administrés par les professionnels de santé, le DRUG_TYPE_CONCEPT_ID différenciant ces types.
Les informations sur la quantité et la dose arrivent dans des formats variés ; l'ETL doit capturer autant de détails que possible. Les enregistrements multiples le même jour pour des médicaments identiques ne doivent pas être dédupliqués sans preuve solide de vraie duplication. Une attention particulière est requise pour les renouvellements de prescription.
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
procedure_occurrence_id |
Identifiant unique pour chaque occurrence de procédure. | Généré lors de l'ETL. | integer | Oui | PK | - | - | - |
person_id |
Identifie le patient. | Lien vers la table PERSON. | integer | Oui | - | FK | PERSON | - |
procedure_concept_id |
Concept standard représentant la procédure. | Mapper le code source vers un Concept Standard du domaine Procedure. | integer | Oui | - | FK | CONCEPT | Procedure |
procedure_date |
Date à laquelle la procédure a été réalisée. | Champ obligatoire. | date | Oui | - | - | - | - |
procedure_datetime |
Date et heure de la procédure. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
procedure_end_date |
Date de fin de la procédure. | Optionnel ; pour les procédures sur plusieurs jours. | date | Non | - | - | - | - |
procedure_end_datetime |
Date et heure de fin de la procédure. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
procedure_type_concept_id |
Provenance de l'enregistrement de procédure. | Domaine Type Concept. | integer | Oui | - | FK | CONCEPT | Type Concept |
modifier_concept_id |
Modificateur de procédure (ex. bilatéral, latéralité). | Stocker si disponible. | integer | Non | - | FK | CONCEPT | - |
quantity |
Nombre de fois que la procédure a été réalisée. | Stocker comme entier. | integer | Non | - | - | - | - |
provider_id |
Professionnel de santé ayant réalisé la procédure. | Lien vers la table PROVIDER. | integer | Non | - | FK | PROVIDER | - |
visit_occurrence_id |
Visite au cours de laquelle la procédure a été réalisée. | Lien vers la table VISIT_OCCURRENCE. | integer | Non | - | FK | VISIT_OCCURRENCE | - |
visit_detail_id |
Détail de visite au cours duquel la procédure a été réalisée. | Lien vers la table VISIT_DETAIL. | integer | Non | - | FK | VISIT_DETAIL | - |
procedure_source_value |
Code source pour la procédure. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
procedure_source_concept_id |
Concept source pour la procédure. | Mapper vers un concept si la source utilise le vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
modifier_source_value |
Valeur source pour le modificateur. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
La table PROCEDURE_OCCURRENCE contient les enregistrements des activités ou processus prescrits par, ou réalisés par, un professionnel de santé sur le patient à des fins diagnostiques ou thérapeutiques.
Les examens de laboratoire sont distincts des procédures. Les mesures représentent des résultats observés avec des quantités et unités attendues, tandis que les procédures sont des actions. La phlébotomie, bien que techniquement une procédure, est rarement capturée séparément car elle est généralement associée aux examens de laboratoire.
Lors du traitement des enregistrements en double, l'ETL doit déterminer s'il faut les consolider en un seul enregistrement ou les maintenir séparément. Les codes sources mappés vers des Concepts Standard du domaine Procedure doivent être enregistrés dans cette table.
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
device_exposure_id |
Identifiant unique pour chaque enregistrement d'exposition à un dispositif. | Généré lors de l'ETL. | integer | Oui | PK | - | - | - |
person_id |
Identifie le patient. | Lien vers la table PERSON. | integer | Oui | - | FK | PERSON | - |
device_concept_id |
Concept standard représentant le dispositif. | Mapper vers le domaine Device. | integer | Oui | - | FK | CONCEPT | Device |
device_exposure_start_date |
Date de début de l'exposition au dispositif. | Champ obligatoire. | date | Oui | - | - | - | - |
device_exposure_start_datetime |
Date et heure de début de l'exposition au dispositif. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
device_exposure_end_date |
Date de fin de l'exposition au dispositif. | Optionnel. | date | Non | - | - | - | - |
device_exposure_end_datetime |
Date et heure de fin de l'exposition au dispositif. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
device_type_concept_id |
Provenance de l'enregistrement du dispositif. | Domaine Type Concept. | integer | Oui | - | FK | CONCEPT | Type Concept |
unique_device_id |
Identifiant unique du dispositif (UDI). | Stocker si disponible. | varchar(255) | Non | - | - | - | - |
production_id |
Identifiant de production du fabricant. | Stocker si disponible. | varchar(255) | Non | - | - | - | - |
quantity |
Nombre de dispositifs utilisés. | Stocker comme entier. | integer | Non | - | - | - | - |
provider_id |
Professionnel de santé ayant posé ou utilisé le dispositif. | Lien vers la table PROVIDER. | integer | Non | - | FK | PROVIDER | - |
visit_occurrence_id |
Visite au cours de laquelle le dispositif a été utilisé. | Lien vers la table VISIT_OCCURRENCE. | integer | Non | - | FK | VISIT_OCCURRENCE | - |
visit_detail_id |
Détail de visite au cours duquel le dispositif a été utilisé. | Lien vers la table VISIT_DETAIL. | integer | Non | - | FK | VISIT_DETAIL | - |
device_source_value |
Code source pour le dispositif. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
device_source_concept_id |
Concept source pour le dispositif. | Mapper vers un concept si la source utilise le vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
unit_concept_id |
Unité de mesure pour le dispositif. | Domaine Unit. | integer | Non | - | FK | CONCEPT | Unit |
unit_source_value |
Valeur source pour l'unité. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
unit_source_concept_id |
Concept source pour l'unité. | Mapper vers un concept si la source utilise le vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
Le domaine Device capture les informations concernant l'exposition d'une personne à un objet physique étranger ou un instrument utilisé à des fins diagnostiques ou thérapeutiques. Cela inclut les objets implantables comme les pacemakers et les stents, les équipements et fournitures médicaux, les instruments utilisés dans les procédures médicales et les matériaux utilisés dans les soins cliniques.
La distinction entre les dispositifs ou fournitures et les procédures est parfois floue, mais les premiers sont des objets physiques tandis que les secondes sont des actions, souvent pour appliquer un dispositif ou une fourniture.
Les codes sources et les champs de texte source qui mappent vers des Concepts Standard du domaine Device doivent être enregistrés dans cette table.
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
measurement_id |
Identifiant unique pour chaque enregistrement de mesure. | Généré lors de l'ETL. | integer | Oui | PK | - | - | - |
person_id |
Identifie le patient. | Lien vers la table PERSON. | integer | Oui | - | FK | PERSON | - |
measurement_concept_id |
Concept standard représentant la mesure. | Mapper vers le domaine Measurement. | integer | Oui | - | FK | CONCEPT | Measurement |
measurement_date |
Date de la mesure. | Champ obligatoire. | date | Oui | - | - | - | - |
measurement_datetime |
Date et heure de la mesure. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
measurement_time |
Heure de la mesure (déprécié). | Utiliser measurement_datetime à la place. | varchar(10) | Non | - | - | - | - |
measurement_type_concept_id |
Provenance de l'enregistrement de mesure. | Domaine Type Concept. | integer | Oui | - | FK | CONCEPT | Type Concept |
operator_concept_id |
Opérateur pour la valeur (=, <, >, etc.). | Domaine Meas Value Operator. | integer | Non | - | FK | CONCEPT | Meas Value Operator |
value_as_number |
Résultat numérique de la mesure. | Stocker la valeur numérique. | float | Non | - | - | - | - |
value_as_concept_id |
Résultat catégoriel de la mesure. | Domaine Meas Value. | integer | Non | - | FK | CONCEPT | Meas Value |
unit_concept_id |
Unité de la mesure. | Domaine Unit. | integer | Non | - | FK | CONCEPT | Unit |
range_low |
Borne inférieure de la plage normale. | Stocker si disponible. | float | Non | - | - | - | - |
range_high |
Borne supérieure de la plage normale. | Stocker si disponible. | float | Non | - | - | - | - |
provider_id |
Professionnel de santé ayant prescrit ou réalisé la mesure. | Lien vers la table PROVIDER. | integer | Non | - | FK | PROVIDER | - |
visit_occurrence_id |
Visite au cours de laquelle la mesure a été effectuée. | Lien vers la table VISIT_OCCURRENCE. | integer | Non | - | FK | VISIT_OCCURRENCE | - |
visit_detail_id |
Détail de visite au cours duquel la mesure a été effectuée. | Lien vers la table VISIT_DETAIL. | integer | Non | - | FK | VISIT_DETAIL | - |
measurement_source_value |
Code source pour la mesure. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
measurement_source_concept_id |
Concept source pour la mesure. | Mapper vers un concept si la source utilise le vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
unit_source_value |
Valeur source pour l'unité. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
unit_source_concept_id |
Concept source pour l'unité. | Mapper vers un concept si la source utilise le vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
value_source_value |
Valeur source pour le résultat. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
measurement_event_id |
Lien vers un autre événement clinique. | Stocker si disponible. | integer | Non | - | - | - | - |
meas_event_field_concept_id |
Concept identifiant le type d'événement lié. | Mapper vers un concept. | integer | Non | - | FK | CONCEPT | - |
La table MEASUREMENT enregistre des valeurs structurées (numériques ou catégorielles) obtenues par un examen ou des tests systématiques et standardisés d'une personne ou de son échantillon. Cela inclut les examens de laboratoire, les signes vitaux et les résultats quantitatifs de pathologie.
Les mesures sont principalement des examens de laboratoire avec quelques exceptions, comme la pression artérielle ou les tests fonctionnels. Les résultats sont donnés sous forme de combinaison valeur et unité. Lors de l'investigation des mesures, recherchez les operator_concept_ids (<, >, etc.).
Seules les valeurs sources mappant vers des concepts du domaine Measurement appartiennent à cette table. Bien que les mesures aient toujours des résultats, les champs VALUE_AS_NUMBER et VALUE_AS_CONCEPT_ID sont optionnels car les données sources manquent souvent d'informations sur les résultats.
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
observation_id |
Identifiant unique pour chaque enregistrement d'observation. | Généré lors de l'ETL. | integer | Oui | PK | - | - | - |
person_id |
Identifie le patient. | Lien vers la table PERSON. | integer | Oui | - | FK | PERSON | - |
observation_concept_id |
Concept standard représentant l'observation. | Mapper vers le domaine Observation. | integer | Oui | - | FK | CONCEPT | - |
observation_date |
Date de l'observation. | Champ obligatoire. | date | Oui | - | - | - | - |
observation_datetime |
Date et heure de l'observation. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
observation_type_concept_id |
Provenance de l'enregistrement d'observation. | Domaine Type Concept. | integer | Oui | - | FK | CONCEPT | Type Concept |
value_as_number |
Valeur numérique de l'observation. | Stocker si applicable. | float | Non | - | - | - | - |
value_as_string |
Valeur textuelle de l'observation. | Stocker si applicable. | varchar(60) | Non | - | - | - | - |
value_as_concept_id |
Valeur catégorielle de l'observation. | Mapper vers un concept. | integer | Non | - | FK | CONCEPT | - |
qualifier_concept_id |
Qualificateur pour l'observation. | Stocker si applicable. | integer | Non | - | FK | CONCEPT | - |
unit_concept_id |
Unité de l'observation. | Domaine Unit. | integer | Non | - | FK | CONCEPT | Unit |
provider_id |
Professionnel de santé ayant effectué l'observation. | Lien vers la table PROVIDER. | integer | Non | - | FK | PROVIDER | - |
visit_occurrence_id |
Visite au cours de laquelle l'observation a été effectuée. | Lien vers la table VISIT_OCCURRENCE. | integer | Non | - | FK | VISIT_OCCURRENCE | - |
visit_detail_id |
Détail de visite au cours duquel l'observation a été effectuée. | Lien vers la table VISIT_DETAIL. | integer | Non | - | FK | VISIT_DETAIL | - |
observation_source_value |
Code source pour l'observation. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
observation_source_concept_id |
Concept source pour l'observation. | Mapper vers un concept si la source utilise le vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
unit_source_value |
Valeur source pour l'unité. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
qualifier_source_value |
Valeur source pour le qualificateur. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
value_source_value |
Valeur source pour le résultat. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
observation_event_id |
Lien vers un autre événement clinique. | Stocker si disponible. | integer | Non | - | - | - | - |
obs_event_field_concept_id |
Concept identifiant le type d'événement lié. | Mapper vers un concept. | integer | Non | - | FK | CONCEPT | - |
La table OBSERVATION capture les faits cliniques sur une personne obtenus par examen, interrogatoire ou procédures. Elle enregistre les données qui ne peuvent pas être représentées ailleurs, comme les faits sociaux, les choix de mode de vie et les antécédents médicaux.
Les observations diffèrent des mesures car elles ne nécessitent pas de tests standardisés pour générer des faits cliniques. La table enregistre généralement quand les observations ont été obtenues. Les exemples incluent les antécédents médicaux, les antécédents familiaux, les besoins de traitement, les circonstances sociales et les schémas d'utilisation des soins de santé.
Les enregistrements mappant vers des domaines autres que Condition, Procedure, Drug, Specimen, Measurement ou Device appartiennent ici. Les observations fonctionnent comme des paires attribut-valeur avec le Concept d'Observation comme attribut et les faits cliniques comme valeurs. Les valeurs peuvent être des Concepts, numériques ou textuelles.
La table NOTE capture les notes cliniques et de texte libre documentant les soins du patient. Ces notes sont écrites par les professionnels de santé et contiennent des informations narratives sur les visites, les diagnostics, les traitements et les observations qui ne peuvent pas être facilement structurées.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
note_id | Identifiant unique de la note. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
person_id | Référence au patient associé à la note. | Lien vers PERSON.person_id. | INTEGER | Oui | FK | PERSON | ||
note_date | Date à laquelle la note a été écrite. | Date de création de la note. | DATE | Oui | ||||
note_datetime | Date et heure de la note. | Si non disponible, dérivé de note_date. | DATETIME | Non | ||||
note_type_concept_id | Type de note (provenance des données). | Concept du vocabulaire Note Type. | INTEGER | Oui | FK | CONCEPT | Type Concept | |
note_class_concept_id | Catégorie de la note (ex: note de sortie, compte-rendu opératoire). | Concepts du domaine Note Class. | INTEGER | Oui | FK | CONCEPT | ||
note_title | Titre optionnel de la note. | Texte libre pour le titre. | VARCHAR(250) | Non | ||||
note_text | Contenu texte de la note. | Texte libre avec le contenu complet de la note. | TEXT | Oui | ||||
encoding_concept_id | Encodage du texte (ex: UTF-8). | Concept représentant l'encodage caractère. | INTEGER | Oui | FK | CONCEPT | ||
language_concept_id | Langue de la note. | Concept du vocabulaire Language. | INTEGER | Oui | FK | CONCEPT | ||
provider_id | Professionnel ayant rédigé la note. | Lien vers PROVIDER.provider_id. | INTEGER | Non | FK | PROVIDER | ||
visit_occurrence_id | Visite associée à la note. | Lien vers VISIT_OCCURRENCE.visit_occurrence_id. | INTEGER | Non | FK | VISIT_OCCURRENCE | ||
visit_detail_id | Détail de visite associé à la note. | Lien vers VISIT_DETAIL.visit_detail_id. | INTEGER | Non | FK | VISIT_DETAIL | ||
note_source_value | Valeur source pour le type de note. | Code ou texte original du système source. | VARCHAR(50) | Non | ||||
note_event_id | ID de l'événement clinique lié à la note. | Référence polymorphe vers un événement clinique. | BIGINT | Non | ||||
note_event_field_concept_id | Concept identifiant la table de l'événement. | Permet d'identifier la table source de note_event_id. | INTEGER | Non | FK | CONCEPT |
La table NOTE contient les enregistrements de texte libre générés lors des interactions cliniques. Elle est essentielle pour capturer les informations narratives qui ne peuvent pas être codées dans les tables structurées. Les notes peuvent être analysées par des outils de NLP pour extraire des concepts (voir NOTE_NLP).
Le champ note_class_concept_id permet de catégoriser les notes (lettre de sortie, compte-rendu d'imagerie, etc.). L'encodage et la langue doivent être spécifiés pour permettre le traitement NLP ultérieur. Les champs note_event_id et note_event_field_concept_id permettent de lier la note à un événement clinique spécifique.
La table NOTE_NLP stocke les résultats de l'analyse NLP (Natural Language Processing) appliquée aux notes cliniques. Elle capture les termes et concepts médicaux extraits automatiquement du texte libre, permettant de transformer les données non structurées en informations codifiées exploitables.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
note_nlp_id | Identifiant unique de l'extraction NLP. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
note_id | Référence à la note source analysée. | Lien vers NOTE.note_id. | INTEGER | Oui | FK | NOTE | ||
section_concept_id | Section de la note où le terme a été trouvé. | Concept identifiant la section (ex: antécédents, traitement). | INTEGER | Non | FK | CONCEPT | ||
snippet | Fragment de texte contenant le terme extrait. | Contexte textuel autour du terme identifié. | VARCHAR(250) | Non | ||||
offset | Position du début du terme dans la note. | Index de caractère du début de l'extraction. | VARCHAR(50) | Non | ||||
lexical_variant | Forme exacte du terme trouvé dans le texte. | Texte tel qu'il apparaît dans la note source. | VARCHAR(250) | Oui | ||||
note_nlp_concept_id | Concept standard mappé au terme extrait. | Concept OMOP correspondant au terme NLP. | INTEGER | Non | FK | CONCEPT | ||
note_nlp_source_concept_id | Concept source du terme avant mapping. | Concept non-standard du vocabulaire source NLP. | INTEGER | Non | FK | CONCEPT | ||
nlp_system | Nom du système NLP utilisé. | Identifiant de l'outil NLP (ex: cTAKES, MetaMap). | VARCHAR(250) | Non | ||||
nlp_date | Date d'exécution de l'analyse NLP. | Date à laquelle le NLP a été appliqué. | DATE | Oui | ||||
nlp_datetime | Date et heure de l'analyse NLP. | Horodatage complet de l'extraction. | DATETIME | Non | ||||
term_exists | Indicateur si le terme est présent ou absent. | Y pour présent, N pour absence explicite. | VARCHAR(1) | Non | ||||
term_temporal | Contexte temporel du terme (passé, présent, futur). | Indique si le terme réfère à un état actuel ou historique. | VARCHAR(50) | Non | ||||
term_modifiers | Modificateurs contextuels du terme. | Informations sur la négation, l'incertitude, etc. | VARCHAR(2000) | Non |
NOTE_NLP stocke les résultats des pipelines de traitement automatique du langage naturel. Chaque enregistrement représente un concept médical extrait d'une note clinique, avec son contexte (snippet), sa position dans le texte, et le mapping vers les vocabulaires standards OMOP.
Les champs term_exists et term_temporal sont essentiels pour l'interprétation : un terme peut être mentionné comme absent ("pas de diabète") ou historique ("antécédent de pneumonie"). Le nlp_system doit documenter l'outil utilisé pour permettre la reproductibilité et l'évaluation de la qualité des extractions.
La table EPISODE représente des séquences d'événements cliniques liés à un même contexte médical, typiquement un épisode de soins pour une condition spécifique comme un cancer ou une grossesse. Elle permet de regrouper les événements associés à une maladie ou un traitement particulier.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
episode_id | Identifiant unique de l'épisode. | Clé primaire générée automatiquement. | BIGINT | Oui | PK | |||
person_id | Référence au patient concerné. | Lien vers PERSON.person_id. | BIGINT | Oui | FK | PERSON | ||
episode_concept_id | Concept définissant le type d'épisode. | Concept du domaine Episode (ex: Treatment Episode, Disease Episode). | INTEGER | Oui | FK | CONCEPT | Episode | |
episode_start_date | Date de début de l'épisode. | Premier événement de l'épisode. | DATE | Oui | ||||
episode_start_datetime | Date et heure de début. | Si non disponible, dérivé de episode_start_date. | DATETIME | Non | ||||
episode_end_date | Date de fin de l'épisode. | Dernier événement ou résolution de l'épisode. | DATE | Non | ||||
episode_end_datetime | Date et heure de fin. | Si non disponible, dérivé de episode_end_date. | DATETIME | Non | ||||
episode_parent_id | Référence à un épisode parent. | Permet de créer des hiérarchies d'épisodes. | BIGINT | Non | FK | EPISODE | ||
episode_number | Numéro séquentiel de l'épisode. | Pour numéroter les épisodes récurrents (ex: 2ème ligne de chimiothérapie). | INTEGER | Non | ||||
episode_object_concept_id | Concept décrivant l'objet de l'épisode. | Le diagnostic ou traitement concerné (ex: cancer du sein). | INTEGER | Oui | FK | CONCEPT | ||
episode_type_concept_id | Type de provenance des données. | Concept indiquant la source de l'épisode. | INTEGER | Oui | FK | CONCEPT | Type Concept | |
episode_source_value | Valeur source de l'épisode. | Code ou identifiant du système source. | VARCHAR(50) | Non | ||||
episode_source_concept_id | Concept source de l'épisode. | Concept non-standard avant mapping. | INTEGER | Non | FK | CONCEPT |
EPISODE est particulièrement utile pour l'oncologie où l'on suit des épisodes de maladie et de traitement. Un patient peut avoir plusieurs épisodes pour différents cancers ou différentes lignes de traitement. Les épisodes peuvent être hiérarchisés via episode_parent_id.
episode_concept_id définit la nature de l'épisode (Disease Episode pour une maladie, Treatment Episode pour un traitement). episode_object_concept_id spécifie de quoi il s'agit (ex: le type de cancer). Les événements individuels sont liés via la table EPISODE_EVENT.
La table EPISODE_EVENT lie les épisodes aux événements cliniques individuels qui les composent. Elle permet d'associer des diagnostics, procédures, médicaments et autres événements cliniques à un épisode de soins spécifique.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
episode_id | Référence à l'épisode. | Lien vers EPISODE.episode_id. | BIGINT | Oui | FK | EPISODE | ||
event_id | ID de l'événement clinique associé. | Référence polymorphe vers l'événement (condition, drug_exposure, etc.). | BIGINT | Oui | ||||
episode_event_field_concept_id | Concept identifiant la table source de l'événement. | Permet de savoir quelle table contient l'événement référencé. | INTEGER | Oui | FK | CONCEPT |
EPISODE_EVENT est une table de liaison qui associe les événements cliniques (conditions, procédures, médicaments) à leurs épisodes respectifs. Par exemple, pour un épisode de cancer, on peut lier le diagnostic initial, les différentes chimiothérapies, et les bilans de surveillance.
Le champ episode_event_field_concept_id indique de quelle table provient event_id. Les concepts utilisés correspondent aux identifiants de champs CDM (ex: concept pour condition_occurrence_id, drug_exposure_id, etc.). Un même événement peut être associé à plusieurs épisodes si cliniquement pertinent.
La table SPECIMEN contient les informations sur les prélèvements biologiques collectés chez les patients. Elle documente les échantillons tels que le sang, l'urine, les biopsies tissulaires et autres spécimens utilisés pour les analyses de laboratoire ou les examens anatomopathologiques.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
specimen_id | Identifiant unique du prélèvement. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
person_id | Référence au patient prélevé. | Lien vers PERSON.person_id. | INTEGER | Oui | FK | PERSON | ||
specimen_concept_id | Type de prélèvement (sang, urine, biopsie, etc.). | Concept du domaine Specimen. | INTEGER | Oui | FK | CONCEPT | Specimen | |
specimen_type_concept_id | Provenance des données du spécimen. | Concept indiquant la source de l'information. | INTEGER | Oui | FK | CONCEPT | Type Concept | |
specimen_date | Date du prélèvement. | Date à laquelle l'échantillon a été collecté. | DATE | Oui | ||||
specimen_datetime | Date et heure du prélèvement. | Si non disponible, dérivé de specimen_date. | DATETIME | Non | ||||
quantity | Quantité de spécimen prélevé. | Volume ou masse selon l'unité. | FLOAT | Non | ||||
unit_concept_id | Unité de mesure de la quantité. | Concept d'unité (mL, g, etc.). | INTEGER | Non | FK | CONCEPT | Unit | |
anatomic_site_concept_id | Site anatomique du prélèvement. | Localisation du prélèvement sur le corps. | INTEGER | Non | FK | CONCEPT | Spec Anatomic Site | |
disease_status_concept_id | Statut pathologique du spécimen. | État du tissu (normal, tumoral, etc.). | INTEGER | Non | FK | CONCEPT | ||
specimen_source_id | Identifiant source du spécimen. | Numéro de tube ou d'échantillon du laboratoire. | VARCHAR(50) | Non | ||||
specimen_source_value | Valeur source du type de spécimen. | Code ou texte original du système source. | VARCHAR(50) | Non | ||||
unit_source_value | Valeur source de l'unité. | Texte de l'unité dans le système source. | VARCHAR(50) | Non | ||||
anatomic_site_source_value | Valeur source du site anatomique. | Texte de localisation du système source. | VARCHAR(50) | Non | ||||
disease_status_source_value | Valeur source du statut pathologique. | Texte original du statut dans le système source. | VARCHAR(50) | Non |
SPECIMEN documente les prélèvements biologiques indépendamment des analyses effectuées. Les résultats d'analyses sur ces spécimens sont dans MEASUREMENT. Cette table est particulièrement importante pour les biobanques et la recherche où la traçabilité des échantillons est essentielle.
Un même spécimen physique peut générer plusieurs enregistrements MEASUREMENT si plusieurs analyses sont effectuées. Le champ anatomic_site_concept_id utilise les concepts SNOMED pour la localisation. Le disease_status_concept_id est utile en oncologie pour distinguer les tissus sains des tissus tumoraux.
La table FACT_RELATIONSHIP permet de créer des relations entre les enregistrements de différentes tables cliniques. Elle établit des liens sémantiques entre les faits, comme la relation entre un diagnostic et un médicament prescrit pour ce diagnostic, ou entre une mesure et sa procédure associée.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
domain_concept_id_1 | Domaine du premier fait. | Concept identifiant le domaine (Condition, Drug, etc.). | INTEGER | Oui | FK | CONCEPT | Metadata | |
fact_id_1 | ID du premier fait dans sa table d'origine. | Référence vers l'enregistrement de domain_concept_id_1. | INTEGER | Oui | ||||
domain_concept_id_2 | Domaine du second fait. | Concept identifiant le domaine du second fait. | INTEGER | Oui | FK | CONCEPT | Metadata | |
fact_id_2 | ID du second fait dans sa table d'origine. | Référence vers l'enregistrement de domain_concept_id_2. | INTEGER | Oui | ||||
relationship_concept_id | Type de relation entre les deux faits. | Concept décrivant la nature de la relation. | INTEGER | Oui | FK | CONCEPT | Relationship |
FACT_RELATIONSHIP permet d'exprimer des relations complexes entre événements cliniques. Par exemple : "ce médicament a été prescrit pour cette condition", "cette mesure a été effectuée lors de cette procédure", ou "ces deux observations sont liées". Les relations peuvent être bidirectionnelles.
Les domain_concept_id utilisent les concepts de domaine (Drug, Condition, Measurement, etc.). Pour les relations symétriques, il faut créer deux enregistrements (A vers B et B vers A). Les relationship_concept_id définissent la sémantique de la relation (ex: "Has associated procedure", "Caused by").
La table LOCATION contient les adresses géographiques et informations de localisation. Elle peut représenter des adresses de patients, de prestataires de soins ou d'établissements de santé. Les données sont généralisées pour protéger la vie privée des patients.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
location_id | Identifiant unique de la localisation. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
address_1 | Première ligne d'adresse. | Numéro et nom de rue. | VARCHAR(50) | Non | ||||
address_2 | Deuxième ligne d'adresse. | Complément d'adresse (appartement, bâtiment, etc.). | VARCHAR(50) | Non | ||||
city | Ville. | Nom de la ville. | VARCHAR(50) | Non | ||||
state | État, région ou département. | Code ou nom de la subdivision administrative. | VARCHAR(2) | Non | ||||
zip | Code postal. | Code postal de l'adresse. | VARCHAR(9) | Non | ||||
county | Comté ou canton. | Subdivision administrative locale. | VARCHAR(20) | Non | ||||
location_source_value | Valeur source de la localisation. | Représentation originale dans le système source. | VARCHAR(50) | Non | ||||
country_concept_id | Concept du pays. | Concept géographique pour le pays. | INTEGER | Non | FK | CONCEPT | Geography | |
country_source_value | Valeur source du pays. | Nom ou code du pays dans le système source. | VARCHAR(80) | Non | ||||
latitude | Latitude géographique. | Coordonnée latitude (décimal). | FLOAT | Non | ||||
longitude | Longitude géographique. | Coordonnée longitude (décimal). | FLOAT | Non |
LOCATION stocke les adresses de manière générique, utilisables pour les patients (via PERSON.location_id), les prestataires (via PROVIDER) et les établissements (via CARE_SITE). Les coordonnées géographiques peuvent être utilisées pour des analyses spatiales.
Pour la protection de la vie privée, les adresses des patients doivent être généralisées (ex: code postal uniquement, pas d'adresse complète). Les coordonnées latitude/longitude peuvent être décalées ou arrondies. Les localisations des établissements peuvent être plus précises.
La table CARE_SITE identifie les lieux physiques où les soins sont dispensés. Cela inclut les hôpitaux, cliniques, cabinets médicaux, services hospitaliers, et autres établissements ou unités de soins où les patients reçoivent des traitements.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
care_site_id | Identifiant unique du site de soins. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
care_site_name | Nom du site de soins. | Nom de l'établissement ou du service. | VARCHAR(255) | Non | ||||
place_of_service_concept_id | Type d'établissement. | Concept décrivant le type de lieu (hôpital, clinique, etc.). | INTEGER | Non | FK | CONCEPT | Place of Service | |
location_id | Référence à l'adresse du site. | Lien vers LOCATION.location_id. | INTEGER | Non | FK | LOCATION | ||
care_site_source_value | Valeur source du site de soins. | Identifiant ou code dans le système source. | VARCHAR(50) | Non | ||||
place_of_service_source_value | Valeur source du type d'établissement. | Code original du type de lieu dans le système source. | VARCHAR(50) | Non |
CARE_SITE représente la hiérarchie des établissements de soins. Un hôpital peut avoir plusieurs sites de soins (urgences, réanimation, cardiologie). Les visites et événements cliniques peuvent être rattachés à un care_site pour analyser les variations de pratique entre établissements.
La granularité du care_site dépend des données sources et des besoins analytiques. On peut représenter l'hôpital entier ou descendre au niveau du service. Le place_of_service_concept_id utilise les concepts CMS Place of Service ou équivalents européens.
La table PROVIDER contient les informations sur les professionnels de santé qui dispensent les soins. Cela inclut les médecins, infirmiers, pharmaciens et autres praticiens impliqués dans la prise en charge des patients.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
provider_id | Identifiant unique du prestataire. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
provider_name | Nom du prestataire. | Nom complet ou pseudonyme. | VARCHAR(255) | Non | ||||
npi | National Provider Identifier (USA). | Identifiant national du professionnel. | VARCHAR(20) | Non | ||||
dea | Drug Enforcement Administration ID (USA). | Identifiant pour la prescription de substances contrôlées. | VARCHAR(20) | Non | ||||
specialty_concept_id | Spécialité médicale. | Concept décrivant la spécialité (cardiologie, chirurgie, etc.). | INTEGER | Non | FK | CONCEPT | Provider | |
care_site_id | Site de soins principal du prestataire. | Lien vers CARE_SITE.care_site_id. | INTEGER | Non | FK | CARE_SITE | ||
year_of_birth | Année de naissance du prestataire. | Utilisé pour l'analyse démographique des praticiens. | INTEGER | Non | ||||
gender_concept_id | Genre du prestataire. | Concept de genre (masculin, féminin, etc.). | INTEGER | Non | FK | CONCEPT | Gender | |
provider_source_value | Valeur source du prestataire. | Identifiant dans le système source. | VARCHAR(50) | Non | ||||
specialty_source_value | Valeur source de la spécialité. | Code ou texte de spécialité du système source. | VARCHAR(50) | Non | ||||
specialty_source_concept_id | Concept source de la spécialité. | Concept non-standard de la spécialité. | INTEGER | Non | FK | CONCEPT | ||
gender_source_value | Valeur source du genre. | Code de genre du système source. | VARCHAR(50) | Non | ||||
gender_source_concept_id | Concept source du genre. | Concept non-standard du genre. | INTEGER | Non | FK | CONCEPT |
PROVIDER permet d'analyser les patterns de prescription et de soins par professionnel ou spécialité. Les événements cliniques peuvent référencer le provider_id pour identifier qui a réalisé l'acte ou prescrit le traitement. La spécialité est importante pour les études de variation des pratiques.
Le NPI et DEA sont des identifiants américains ; utiliser les identifiants nationaux équivalents pour d'autres pays (RPPS en France par exemple). Le provider_name peut être pseudonymisé pour la protection des données. Un même prestataire peut intervenir dans plusieurs care_sites.
La table COST capture les informations de coûts associés aux événements cliniques. Elle permet de stocker les coûts des médicaments, procédures, visites et autres services de santé pour les analyses médico-économiques.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
cost_id | Identifiant unique du coût. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
cost_event_id | ID de l'événement associé au coût. | Référence polymorphe vers l'événement (drug_exposure_id, procedure_id, etc.). | INTEGER | Oui | ||||
cost_domain_id | Domaine de l'événement associé. | Nom du domaine (Drug, Procedure, Visit, etc.). | VARCHAR(20) | Oui | ||||
cost_type_concept_id | Type de coût. | Concept indiquant la nature du coût (facturé, remboursé, etc.). | INTEGER | Oui | FK | CONCEPT | Type Concept | |
currency_concept_id | Devise du coût. | Concept de devise (EUR, USD, etc.). | INTEGER | Non | FK | CONCEPT | Currency | |
total_charge | Montant total facturé. | Coût brut avant remboursement. | FLOAT | Non | ||||
total_cost | Coût total réel. | Coût effectif pour l'établissement. | FLOAT | Non | ||||
total_paid | Montant total payé. | Somme des paiements (assurance + patient). | FLOAT | Non | ||||
paid_by_payer | Montant payé par l'assurance. | Part remboursée par l'organisme payeur. | FLOAT | Non | ||||
paid_by_patient | Montant payé par le patient. | Reste à charge pour le patient. | FLOAT | Non | ||||
paid_patient_copay | Copaiement du patient. | Ticket modérateur ou forfait. | FLOAT | Non | ||||
paid_patient_coinsurance | Co-assurance du patient. | Pourcentage à la charge du patient. | FLOAT | Non | ||||
paid_patient_deductible | Franchise du patient. | Montant de la franchise appliquée. | FLOAT | Non | ||||
paid_by_primary | Payé par l'assurance primaire. | Remboursement de l'assurance principale. | FLOAT | Non | ||||
paid_ingredient_cost | Coût des ingrédients. | Pour les médicaments, coût des principes actifs. | FLOAT | Non | ||||
paid_dispensing_fee | Frais de dispensation. | Honoraires de dispensation pharmaceutique. | FLOAT | Non | ||||
payer_plan_period_id | Période de couverture associée. | Lien vers PAYER_PLAN_PERIOD.payer_plan_period_id. | INTEGER | Non | FK | PAYER_PLAN_PERIOD | ||
amount_allowed | Montant autorisé. | Montant maximum accepté par l'assurance. | FLOAT | Non | ||||
revenue_code_concept_id | Code de recette. | Concept du code de facturation. | INTEGER | Non | FK | CONCEPT | Revenue Code | |
revenue_code_source_value | Code de recette source. | Code original du système de facturation. | VARCHAR(50) | Non | ||||
drg_concept_id | DRG (Diagnosis Related Group). | Concept du groupe homogène de malades. | INTEGER | Non | FK | CONCEPT | DRG | |
drg_source_value | DRG source. | Code GHM/GHS original (France) ou DRG (USA). | VARCHAR(3) | Non |
COST permet les analyses de coût-efficacité et les études médico-économiques. Chaque coût est lié à un événement clinique spécifique via cost_event_id et cost_domain_id. Les différents champs permettent de distinguer les différentes composantes du financement des soins.
Les montants sont en unité monétaire définie par currency_concept_id. Pour la France, utiliser les codes GHM/GHS pour drg_source_value. Les champs de paiement détaillés dépendent de la structure du système de santé local. Tous les montants sont optionnels selon les données disponibles.
La table PAYER_PLAN_PERIOD capture les périodes de couverture d'assurance santé des patients. Elle documente les différents régimes d'assurance et les dates pendant lesquelles le patient était couvert par chaque plan.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
payer_plan_period_id | Identifiant unique de la période. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
person_id | Référence au patient. | Lien vers PERSON.person_id. | INTEGER | Oui | FK | PERSON | ||
payer_plan_period_start_date | Date de début de la couverture. | Premier jour de la période de couverture. | DATE | Oui | ||||
payer_plan_period_end_date | Date de fin de la couverture. | Dernier jour de la période de couverture. | DATE | Oui | ||||
payer_concept_id | Concept de l'organisme payeur. | Concept identifiant le type d'assureur. | INTEGER | Non | FK | CONCEPT | Payer | |
payer_source_value | Valeur source de l'organisme payeur. | Code ou nom de l'assureur dans le système source. | VARCHAR(50) | Non | ||||
payer_source_concept_id | Concept source du payeur. | Concept non-standard de l'assureur. | INTEGER | Non | FK | CONCEPT | ||
plan_concept_id | Concept du type de plan. | Concept identifiant le type de couverture. | INTEGER | Non | FK | CONCEPT | Plan | |
plan_source_value | Valeur source du plan. | Code ou nom du plan dans le système source. | VARCHAR(50) | Non | ||||
plan_source_concept_id | Concept source du plan. | Concept non-standard du plan. | INTEGER | Non | FK | CONCEPT | ||
sponsor_concept_id | Concept du sponsor. | Employeur ou organisme finançant la couverture. | INTEGER | Non | FK | CONCEPT | Sponsor | |
sponsor_source_value | Valeur source du sponsor. | Nom ou code du sponsor dans le système source. | VARCHAR(50) | Non | ||||
sponsor_source_concept_id | Concept source du sponsor. | Concept non-standard du sponsor. | INTEGER | Non | FK | CONCEPT | ||
family_source_value | Identifiant familial. | Numéro de contrat familial ou groupe. | VARCHAR(50) | Non | ||||
stop_reason_concept_id | Raison de fin de couverture. | Concept expliquant pourquoi la couverture a pris fin. | INTEGER | Non | FK | CONCEPT | ||
stop_reason_source_value | Valeur source de la raison de fin. | Code ou texte de fin dans le système source. | VARCHAR(50) | Non | ||||
stop_reason_source_concept_id | Concept source de la raison de fin. | Concept non-standard de la raison de fin. | INTEGER | Non | FK | CONCEPT |
PAYER_PLAN_PERIOD permet de suivre l'historique de couverture d'assurance des patients. Un patient peut avoir plusieurs périodes consécutives ou simultanées (assurance primaire et complémentaire). Cette information est cruciale pour les analyses d'accès aux soins et de suivi de population.
En France, distinguer l'assurance maladie obligatoire (AMO) des complémentaires (AMC). Créer des périodes séparées pour chaque changement de couverture. Les périodes ne doivent pas se chevaucher pour un même type de couverture. Les dates doivent être précises au jour près.
La table CONCEPT est le cœur du système de vocabulaires OMOP. Elle contient tous les concepts standardisés utilisés pour représenter les données cliniques. Chaque concept a un identifiant unique et appartient à un vocabulaire et un domaine spécifiques.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
concept_id | Identifiant unique du concept. | Clé primaire, attribuée par OHDSI. | INTEGER | Oui | PK | |||
concept_name | Nom descriptif du concept. | Libellé lisible du concept. | VARCHAR(255) | Oui | ||||
domain_id | Domaine du concept. | Domaine auquel appartient le concept (Condition, Drug, etc.). | VARCHAR(20) | Oui | FK | DOMAIN | ||
vocabulary_id | Vocabulaire source du concept. | Identifiant du vocabulaire (SNOMED, RxNorm, LOINC, etc.). | VARCHAR(20) | Oui | FK | VOCABULARY | ||
concept_class_id | Classe du concept. | Classification au sein du vocabulaire (Clinical Finding, Ingredient, etc.). | VARCHAR(20) | Oui | FK | CONCEPT_CLASS | ||
standard_concept | Indicateur de concept standard. | S = Standard, C = Classification, NULL = Non-standard. | VARCHAR(1) | Non | ||||
concept_code | Code original du concept. | Code dans le vocabulaire source (ex: code CIM-10, code SNOMED). | VARCHAR(50) | Oui | ||||
valid_start_date | Date de début de validité. | Date à partir de laquelle le concept est utilisable. | DATE | Oui | ||||
valid_end_date | Date de fin de validité. | Date jusqu'à laquelle le concept est valide. | DATE | Oui | ||||
invalid_reason | Raison d'invalidation. | U = Upgraded, D = Deleted, NULL = Valide. | VARCHAR(1) | Non |
CONCEPT est la table de référence pour tous les codes utilisés dans le CDM. Les concepts standards (standard_concept = 'S') sont ceux vers lesquels toutes les données doivent être mappées. Les concepts non-standards servent de source pour le mapping. Utiliser CONCEPT_RELATIONSHIP pour trouver les mappings.
Cette table est fournie par OHDSI et ne doit pas être modifiée. Lors de l'ETL, mapper les codes sources vers les concept_id standards. Toujours vérifier que le concept est valide (valid_end_date dans le futur, invalid_reason NULL) avant de l'utiliser.
La table VOCABULARY liste tous les vocabulaires médicaux disponibles dans le CDM OMOP. Elle contient les métadonnées des terminologies comme SNOMED CT, ICD-10, LOINC, RxNorm, et les vocabulaires personnalisés.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
vocabulary_id | Identifiant unique du vocabulaire. | Code court du vocabulaire (ex: SNOMED, ICD10CM). | VARCHAR(20) | Oui | PK | |||
vocabulary_name | Nom complet du vocabulaire. | Nom descriptif de la terminologie. | VARCHAR(255) | Oui | ||||
vocabulary_reference | Référence externe. | URL ou citation de la source officielle. | VARCHAR(255) | Non | ||||
vocabulary_version | Version du vocabulaire. | Numéro ou date de version utilisée. | VARCHAR(255) | Non | ||||
vocabulary_concept_id | Concept représentant le vocabulaire. | Lien vers CONCEPT.concept_id pour ce vocabulaire. | INTEGER | Oui | FK | CONCEPT |
VOCABULARY permet de connaître les terminologies disponibles et leurs versions. Les vocabulaires les plus utilisés sont : SNOMED (conditions, procédures), RxNorm/RxNorm Extension (médicaments), LOINC (mesures de laboratoire), ICD10CM/ICD10 (classifications diagnostiques).
Cette table est fournie par OHDSI via Athena. La version du vocabulaire est importante pour la reproductibilité des analyses. Les vocabulaires personnalisés peuvent être ajoutés avec un vocabulary_id commençant par un numéro élevé (>2000000000).
La table DOMAIN définit les domaines sémantiques du CDM OMOP. Chaque domaine correspond à une catégorie de données cliniques et détermine dans quelle table les concepts doivent être stockés.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
domain_id | Identifiant unique du domaine. | Code du domaine (ex: Condition, Drug, Measurement). | VARCHAR(20) | Oui | PK | |||
domain_name | Nom du domaine. | Nom descriptif du domaine. | VARCHAR(255) | Oui | ||||
domain_concept_id | Concept représentant le domaine. | Lien vers CONCEPT.concept_id. | INTEGER | Oui | FK | CONCEPT |
Les principaux domaines sont : Condition (diagnostics), Drug (médicaments), Procedure (actes), Measurement (mesures/analyses), Observation (observations), Device (dispositifs), Specimen (prélèvements). Le domaine d'un concept détermine la table de destination lors de l'ETL.
Cette table est fournie par OHDSI. Lors de l'ETL, vérifier le domain_id du concept pour savoir dans quelle table insérer l'enregistrement. Un même code source peut mapper vers des concepts de domaines différents selon le contexte.
La table CONCEPT_CLASS définit les classes de concepts au sein des vocabulaires. Elle permet de catégoriser les concepts selon leur niveau de granularité ou leur type au sein d'un vocabulaire donné.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
concept_class_id | Identifiant de la classe. | Code de la classe (ex: Clinical Finding, Ingredient). | VARCHAR(20) | Oui | PK | |||
concept_class_name | Nom de la classe. | Nom descriptif de la classe de concept. | VARCHAR(255) | Oui | ||||
concept_class_concept_id | Concept représentant la classe. | Lien vers CONCEPT.concept_id. | INTEGER | Oui | FK | CONCEPT |
Les classes varient selon le vocabulaire. Pour SNOMED : Clinical Finding, Procedure, etc. Pour RxNorm : Ingredient, Clinical Drug, Branded Drug, etc. Pour LOINC : Lab Test, Clinical Observation, etc. La classe aide à filtrer les concepts lors des recherches.
Table fournie par OHDSI. Utile pour comprendre la hiérarchie des concepts dans un vocabulaire. Par exemple, dans RxNorm, les Ingredients sont les principes actifs, les Clinical Drugs combinent ingrédient + dosage + forme.
La table CONCEPT_SYNONYM stocke les noms alternatifs et synonymes pour les concepts. Elle permet de rechercher des concepts en utilisant différentes dénominations dans plusieurs langues.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
concept_id | Concept concerné. | Lien vers CONCEPT.concept_id. | INTEGER | Oui | FK | CONCEPT | ||
concept_synonym_name | Synonyme du concept. | Nom alternatif ou traduction du concept. | VARCHAR(1000) | Oui | ||||
language_concept_id | Langue du synonyme. | Concept identifiant la langue du synonyme. | INTEGER | Oui | FK | CONCEPT | Language |
CONCEPT_SYNONYM est utile pour la recherche de concepts en texte libre. Un concept peut avoir plusieurs synonymes, y compris dans différentes langues. Par exemple, "Myocardial infarction" peut avoir comme synonymes "Heart attack", "MI", "Infarctus du myocarde".
Table fournie par OHDSI. Peut être enrichie avec des traductions locales. Le language_concept_id utilise les concepts de langue ISO (ex: 4180186 pour l'anglais, 4182503 pour le français). Utile pour construire des interfaces de recherche multilingues.
La table CONCEPT_RELATIONSHIP définit les relations entre concepts. Elle est essentielle pour le mapping des codes sources vers les concepts standards et pour naviguer dans les hiérarchies de vocabulaires.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
concept_id_1 | Premier concept de la relation. | Concept source de la relation. | INTEGER | Oui | FK | CONCEPT | ||
concept_id_2 | Second concept de la relation. | Concept cible de la relation. | INTEGER | Oui | FK | CONCEPT | ||
relationship_id | Type de relation. | Identifiant de la relation (Maps to, Is a, etc.). | VARCHAR(20) | Oui | FK | RELATIONSHIP | ||
valid_start_date | Date de début de validité. | Date à partir de laquelle la relation est valide. | DATE | Oui | ||||
valid_end_date | Date de fin de validité. | Date jusqu'à laquelle la relation est valide. | DATE | Oui | ||||
invalid_reason | Raison d'invalidation. | NULL si valide, D = Deleted, U = Updated. | VARCHAR(1) | Non |
Relations clés : "Maps to" (mapping vers concept standard), "Is a" (hiérarchie parent-enfant), "Has ingredient" (composition des médicaments). Pour le mapping ETL, rechercher les relations "Maps to" depuis les concepts source vers les concepts standards.
Lors du mapping, utiliser la requête : SELECT concept_id_2 FROM concept_relationship WHERE concept_id_1 = [source_concept_id] AND relationship_id = 'Maps to' AND invalid_reason IS NULL. Les relations sont directionnelles ; la relation inverse existe souvent avec un relationship_id inverse.
La table RELATIONSHIP liste tous les types de relations possibles entre concepts. Chaque type de relation a une relation inverse correspondante, permettant la navigation bidirectionnelle dans le graphe de concepts.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
relationship_id | Identifiant de la relation. | Code de la relation (ex: Maps to, Is a). | VARCHAR(20) | Oui | PK | |||
relationship_name | Nom de la relation. | Description lisible de la relation. | VARCHAR(255) | Oui | ||||
is_hierarchical | Relation hiérarchique. | 1 si relation parent-enfant, 0 sinon. | VARCHAR(1) | Oui | ||||
defines_ancestry | Définit l'ascendance. | 1 si utilisée pour calculer CONCEPT_ANCESTOR. | VARCHAR(1) | Oui | ||||
reverse_relationship_id | Relation inverse. | ID de la relation inverse (ex: Mapped from). | VARCHAR(20) | Oui | FK | RELATIONSHIP | ||
relationship_concept_id | Concept représentant la relation. | Lien vers CONCEPT.concept_id. | INTEGER | Oui | FK | CONCEPT |
Relations principales : "Maps to" / "Mapped from" (mapping), "Is a" / "Subsumes" (hiérarchie), "Has ingredient" / "Ingredient of" (composition). Les relations hiérarchiques (is_hierarchical = 1) sont utilisées pour naviguer dans les arbres de concepts.
Table fournie par OHDSI. Les relations avec defines_ancestry = 1 sont utilisées pour calculer la table CONCEPT_ANCESTOR. Toujours utiliser la relation appropriée selon le sens de navigation souhaité.
La table CONCEPT_ANCESTOR contient la fermeture transitive des hiérarchies de concepts. Elle permet de trouver rapidement tous les ancêtres ou descendants d'un concept sans parcourir récursivement les relations.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
ancestor_concept_id | Concept ancêtre (parent). | Concept plus général dans la hiérarchie. | INTEGER | Oui | FK | CONCEPT | ||
descendant_concept_id | Concept descendant (enfant). | Concept plus spécifique dans la hiérarchie. | INTEGER | Oui | FK | CONCEPT | ||
min_levels_of_separation | Distance minimale. | Nombre minimum de niveaux entre ancêtre et descendant. | INTEGER | Oui | ||||
max_levels_of_separation | Distance maximale. | Nombre maximum de niveaux entre ancêtre et descendant. | INTEGER | Oui |
CONCEPT_ANCESTOR est essentiel pour les requêtes inclusives. Par exemple, pour trouver tous les patients avec un "diabète", la requête inclut automatiquement "diabète de type 1", "diabète de type 2", etc. Chaque concept est aussi son propre ancêtre (min_levels = 0).
Table calculée par OHDSI à partir des relations hiérarchiques. Exemple de requête pour trouver tous les descendants : SELECT descendant_concept_id FROM concept_ancestor WHERE ancestor_concept_id = [parent_id]. Utiliser min_levels_of_separation = 0 pour inclure le concept lui-même.
La table SOURCE_TO_CONCEPT_MAP permet de stocker les mappings personnalisés entre les codes sources locaux et les concepts OMOP standards. Elle est utilisée lors de l'ETL pour convertir les terminologies locales.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
source_code | Code source local. | Valeur du code dans le système source. | VARCHAR(50) | Oui | ||||
source_concept_id | Concept source (si existant). | Concept OMOP non-standard correspondant au code source. | INTEGER | Oui | FK | CONCEPT | ||
source_vocabulary_id | Vocabulaire source. | Identifiant du vocabulaire local ou standard source. | VARCHAR(20) | Oui | FK | VOCABULARY | ||
source_code_description | Description du code source. | Libellé explicatif du code source. | VARCHAR(255) | Non | ||||
target_concept_id | Concept cible standard. | Concept OMOP standard vers lequel mapper. | INTEGER | Oui | FK | CONCEPT | ||
target_vocabulary_id | Vocabulaire cible. | Vocabulaire du concept cible (ex: SNOMED, RxNorm). | VARCHAR(20) | Oui | FK | VOCABULARY | ||
valid_start_date | Date de début de validité. | Date à partir de laquelle le mapping est valide. | DATE | Oui | ||||
valid_end_date | Date de fin de validité. | Date jusqu'à laquelle le mapping est valide. | DATE | Oui | ||||
invalid_reason | Raison d'invalidation. | NULL si valide, sinon raison de l'invalidation. | VARCHAR(1) | Non |
SOURCE_TO_CONCEPT_MAP est la table de travail pour l'ETL. Elle stocke les correspondances entre vos codes locaux (codes maison, codes établissement) et les concepts standards OMOP. C'est un complément à CONCEPT_RELATIONSHIP pour les vocabulaires non-standards.
Créer un vocabulary_id personnalisé pour votre source (ex: "HOPITAL_LOCAL"). Remplir cette table avant l'ETL avec tous les mappings nécessaires. Un même source_code peut mapper vers plusieurs target_concept_id si nécessaire. Documenter les mappings manuels pour la reproductibilité.
La table DRUG_STRENGTH contient les informations de dosage des médicaments. Elle détaille la quantité de principe actif par unité de forme pharmaceutique et permet le calcul des doses quotidiennes.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
drug_concept_id | Concept du médicament. | Lien vers CONCEPT.concept_id (domaine Drug). | INTEGER | Oui | FK | CONCEPT | Drug | |
ingredient_concept_id | Concept de l'ingrédient actif. | Principe actif du médicament. | INTEGER | Oui | FK | CONCEPT | Drug | |
amount_value | Quantité d'ingrédient. | Quantité par unité (ex: 500 pour 500mg/comprimé). | FLOAT | Non | ||||
amount_unit_concept_id | Unité de la quantité. | Concept d'unité (mg, g, UI, etc.). | INTEGER | Non | FK | CONCEPT | Unit | |
numerator_value | Numérateur de concentration. | Pour les solutions : quantité dans le numérateur. | FLOAT | Non | ||||
numerator_unit_concept_id | Unité du numérateur. | Unité de mesure du numérateur. | INTEGER | Non | FK | CONCEPT | Unit | |
denominator_value | Dénominateur de concentration. | Pour les solutions : volume ou quantité du dénominateur. | FLOAT | Non | ||||
denominator_unit_concept_id | Unité du dénominateur. | Unité de mesure du dénominateur (mL, L, etc.). | INTEGER | Non | FK | CONCEPT | Unit | |
box_size | Taille du conditionnement. | Nombre d'unités dans la boîte. | INTEGER | Non | ||||
valid_start_date | Date de début de validité. | Date de début de commercialisation. | DATE | Oui | ||||
valid_end_date | Date de fin de validité. | Date de fin (31-Dec-2099 si toujours valide). | DATE | Oui | ||||
invalid_reason | Raison d'invalidation. | NULL si valide, D ou U sinon. | VARCHAR(1) | Non |
DRUG_STRENGTH permet de calculer les doses administrées. Pour les formes solides, utiliser amount_value/amount_unit. Pour les liquides, utiliser le ratio numerator/denominator. Un médicament multi-ingrédient a plusieurs lignes, une par ingrédient.
Table fournie par OHDSI pour les vocabulaires RxNorm et RxNorm Extension. Utile pour standardiser les calculs de dose et pour les études de pharmacoépidémiologie. La formule DDD (Defined Daily Dose) peut être calculée à partir de ces données.
La table CONDITION_ERA contient des périodes continues pendant lesquelles un patient avait une condition. Elle agrège les enregistrements CONDITION_OCCURRENCE consécutifs ou proches pour former des épisodes de maladie.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
condition_era_id | Identifiant unique de l'ère de condition. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
person_id | Référence au patient. | Lien vers PERSON.person_id. | INTEGER | Oui | FK | PERSON | ||
condition_concept_id | Concept de la condition. | Concept standard de la condition (niveau ingrédient pour les maladies). | INTEGER | Oui | FK | CONCEPT | Condition | |
condition_era_start_date | Date de début de l'ère. | Premier jour de la période de condition. | DATE | Oui | ||||
condition_era_end_date | Date de fin de l'ère. | Dernier jour de la période de condition. | DATE | Oui | ||||
condition_occurrence_count | Nombre d'occurrences agrégées. | Nombre de CONDITION_OCCURRENCE dans cette ère. | INTEGER | Non |
CONDITION_ERA simplifie l'analyse des durées de maladie. Les conditions proches dans le temps (gap <= 30 jours par défaut) sont fusionnées en une seule ère. Utile pour identifier les patients avec une condition chronique ou les récidives.
Table dérivée, générée par un script ETL à partir de CONDITION_OCCURRENCE. L'algorithme standard utilise un gap de 30 jours pour fusionner les occurrences consécutives. Le condition_concept_id est standardisé au niveau le plus spécifique disponible.
La table DRUG_ERA représente des périodes d'exposition continue à un principe actif (ingrédient). Elle agrège les DRUG_EXPOSURE pour créer des périodes de traitement cohérentes, en tenant compte des renouvellements d'ordonnance.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
drug_era_id | Identifiant unique de l'ère médicamenteuse. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
person_id | Référence au patient. | Lien vers PERSON.person_id. | INTEGER | Oui | FK | PERSON | ||
drug_concept_id | Concept du principe actif. | Concept de l'ingrédient (pas du médicament commercial). | INTEGER | Oui | FK | CONCEPT | Drug | |
drug_era_start_date | Date de début de l'ère. | Premier jour d'exposition au médicament. | DATE | Oui | ||||
drug_era_end_date | Date de fin de l'ère. | Dernier jour d'exposition (incluant la durée de la dernière prescription). | DATE | Oui | ||||
drug_exposure_count | Nombre d'expositions agrégées. | Nombre de DRUG_EXPOSURE dans cette ère. | INTEGER | Non | ||||
gap_days | Jours de gap cumulés. | Total des jours sans traitement au sein de l'ère. | INTEGER | Non |
DRUG_ERA représente l'exposition au niveau de l'ingrédient actif. Ainsi, des prescriptions d'Amoxicilline 500mg et d'Augmentin (amoxicilline + acide clavulanique) génèrent des ères distinctes pour chaque ingrédient. Utile pour les études de pharmacoépidémiologie.
Table dérivée à partir de DRUG_EXPOSURE. L'algorithme utilise un gap de 30 jours par défaut pour fusionner les expositions. Les drug_concept_id sont remontés au niveau ingrédient via les relations RxNorm. Le gap_days mesure la compliance du patient.
La table DOSE_ERA représente des périodes d'exposition à une dose spécifique d'un médicament. Elle permet de suivre les changements de posologie au cours du temps pour un même traitement.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
dose_era_id | Identifiant unique de l'ère de dose. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
person_id | Référence au patient. | Lien vers PERSON.person_id. | INTEGER | Oui | FK | PERSON | ||
drug_concept_id | Concept du principe actif. | Concept de l'ingrédient. | INTEGER | Oui | FK | CONCEPT | Drug | |
unit_concept_id | Unité de la dose. | Concept d'unité (mg, g, UI, etc.). | INTEGER | Oui | FK | CONCEPT | Unit | |
dose_value | Valeur de la dose quotidienne. | Dose journalière pendant cette période. | FLOAT | Oui | ||||
dose_era_start_date | Date de début de l'ère de dose. | Premier jour à cette dose. | DATE | Oui | ||||
dose_era_end_date | Date de fin de l'ère de dose. | Dernier jour à cette dose. | DATE | Oui |
DOSE_ERA capture les changements de posologie. Un patient sous metformine passant de 500mg/jour à 1000mg/jour aura deux ères de dose distinctes. Utile pour les études de titration et d'efficacité dose-dépendante.
Table dérivée à partir de DRUG_EXPOSURE et DRUG_STRENGTH. La dose_value représente la dose quotidienne standardisée. Une nouvelle ère est créée à chaque changement de posologie. Moins fréquemment implémentée que DRUG_ERA.
La table COHORT stocke les résultats des définitions de cohortes. Une cohorte est un ensemble de patients partageant des critères communs (exposition, condition, etc.) pendant une période définie.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
cohort_definition_id | Référence à la définition de cohorte. | Lien vers COHORT_DEFINITION.cohort_definition_id. | INTEGER | Oui | FK | COHORT_DEFINITION | ||
subject_id | Identifiant du sujet (patient). | Généralement person_id du patient. | INTEGER | Oui | ||||
cohort_start_date | Date d'entrée dans la cohorte. | Premier jour où le patient remplit les critères. | DATE | Oui | ||||
cohort_end_date | Date de sortie de la cohorte. | Dernier jour où le patient remplit les critères. | DATE | Oui |
COHORT est une table de résultats utilisée par les outils OHDSI comme ATLAS pour stocker les populations d'étude. Un patient peut appartenir à plusieurs cohortes et peut avoir plusieurs périodes dans une même cohorte (entrées/sorties multiples).
Table générée par les outils d'analyse, pas par l'ETL initial. Les cohortes sont définies via COHORT_DEFINITION et instanciées dans cette table. Le subject_id est généralement le person_id mais peut représenter d'autres entités selon le cas d'usage.
La table COHORT_DEFINITION stocke les définitions formelles des cohortes. Elle contient les métadonnées et la logique utilisée pour identifier les patients appartenant à chaque cohorte.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
cohort_definition_id | Identifiant unique de la définition. | Clé primaire de la définition de cohorte. | INTEGER | Oui | PK | |||
cohort_definition_name | Nom de la cohorte. | Nom descriptif de la population étudiée. | VARCHAR(255) | Oui | ||||
cohort_definition_description | Description de la cohorte. | Explication détaillée des critères d'inclusion/exclusion. | TEXT | Non | ||||
definition_type_concept_id | Type de définition. | Concept indiquant le type de définition. | INTEGER | Oui | FK | CONCEPT | ||
cohort_definition_syntax | Syntaxe de la définition. | Code ou requête définissant la cohorte (JSON ATLAS ou SQL). | TEXT | Non | ||||
subject_concept_id | Type de sujet. | Concept indiquant ce que représente le sujet (généralement Person). | INTEGER | Oui | FK | CONCEPT | ||
cohort_initiation_date | Date de création de la cohorte. | Date à laquelle la cohorte a été définie. | DATE | Non |
COHORT_DEFINITION décrit formellement comment une cohorte est construite. Les définitions peuvent être créées via ATLAS (interface graphique) et exportées en JSON, ou écrites directement en SQL. La reproductibilité des études repose sur ces définitions.
Table générée par les outils d'analyse. Le cohort_definition_syntax contient généralement du JSON ATLAS ou du SQL OHDSI. Documenter précisément les critères d'inclusion/exclusion dans cohort_definition_description pour la transparence scientifique.
La table CDM_SOURCE contient les métadonnées sur la source des données et l'instance CDM. Elle documente l'origine des données, la version du CDM utilisée, et les dates de couverture des données.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
cdm_source_name | Nom de la source CDM. | Nom identifiant cette instance de données. | VARCHAR(255) | Oui | ||||
cdm_source_abbreviation | Abréviation de la source. | Code court pour la source (ex: APHP, CHRU). | VARCHAR(25) | Oui | ||||
cdm_holder | Organisation responsable. | Nom de l'organisation gérant les données. | VARCHAR(255) | Oui | ||||
source_description | Description de la source. | Description détaillée de l'origine des données. | TEXT | Non | ||||
source_documentation_reference | Référence documentation. | URL ou citation vers la documentation source. | VARCHAR(255) | Non | ||||
cdm_etl_reference | Référence ETL. | Documentation du processus ETL utilisé. | VARCHAR(255) | Non | ||||
source_release_date | Date de publication des données source. | Date de l'extraction des données source. | DATE | Oui | ||||
cdm_release_date | Date de création du CDM. | Date à laquelle cette version du CDM a été créée. | DATE | Oui | ||||
cdm_version | Version du CDM. | Version OMOP CDM utilisée (ex: v5.4). | VARCHAR(10) | Non | ||||
cdm_version_concept_id | Concept de la version CDM. | Concept représentant la version du CDM. | INTEGER | Oui | FK | CONCEPT | ||
vocabulary_version | Version des vocabulaires. | Version des vocabulaires OHDSI utilisée. | VARCHAR(20) | Oui |
CDM_SOURCE est essentielle pour la traçabilité et la reproductibilité. Elle permet de savoir quelles données sont présentes, d'où elles viennent, et avec quelle version des outils elles ont été traitées. Cette table ne contient généralement qu'une seule ligne.
Remplir cette table à chaque nouveau chargement de données. Documenter la version des vocabulaires OHDSI (Athena) utilisée. Le cdm_etl_reference devrait pointer vers le code ETL ou sa documentation pour la reproductibilité.
La table METADATA stocke des métadonnées structurées sous forme clé-valeur. Elle permet de documenter des informations supplémentaires sur les données CDM qui ne sont pas capturées dans CDM_SOURCE.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
metadata_id | Identifiant unique de la métadonnée. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
metadata_concept_id | Concept de la métadonnée. | Concept identifiant le type de métadonnée. | INTEGER | Oui | FK | CONCEPT | ||
metadata_type_concept_id | Type de métadonnée. | Concept indiquant la nature de la métadonnée. | INTEGER | Oui | FK | CONCEPT | ||
name | Nom de la métadonnée. | Clé identifiant la métadonnée. | VARCHAR(250) | Oui | ||||
value_as_string | Valeur textuelle. | Valeur de la métadonnée en texte. | VARCHAR(250) | Non | ||||
value_as_concept_id | Valeur comme concept. | Valeur de la métadonnée comme concept OMOP. | INTEGER | Non | FK | CONCEPT | ||
value_as_number | Valeur numérique. | Valeur de la métadonnée en nombre. | FLOAT | Non | ||||
metadata_date | Date de la métadonnée. | Date associée à cette métadonnée. | DATE | Non | ||||
metadata_datetime | Date et heure de la métadonnée. | Horodatage de la métadonnée. | DATETIME | Non |
METADATA offre une flexibilité pour stocker des informations additionnelles non prévues par le schéma CDM standard. Par exemple : paramètres de configuration de l'ETL, statistiques sur les données, informations de qualité, ou métadonnées spécifiques au site.
Utiliser des concepts standards pour metadata_concept_id quand ils existent. Pour les métadonnées personnalisées, créer des concepts locaux. Cette table peut être utilisée pour stocker des informations d'audit, de traçabilité ou de configuration.
La base de données MIMIC, pour Medical Information Mart for Intensive Care, est une base de données nord-américaine contenant des données de plus de 50 000 patients admis en réanimation. Il s’agit de l’une des bases de données de réanimation les plus utilisées, du fait de son accès gratuit.
Malgré des données d’une qualité imparfaite, elle constitue un bon socle pour apprendre à manipuler les données issues d’entrepôts de données de santé (EDS).
Elle existe en plusieurs versions, dont la plus récente est la MIMIC-IV.
La base de données MIMIC comporte pour les versions III et IV des bases tests, qui contiennent les données anonymisées de 100 patients et qui sont accessibles publiquement.
Vous pouvez télécharger les données ici :
Pour accéder aux bases de données complètes, il est nécessaire de valider quelques étapes.
Rendez-vous sur la page de la base MIMIC-III.
Vous verrez cet encadré tout en bas de la page :
Vous devez donc commencer par vous inscrire sur le site physionet.org.
Vous devrez faire une demande d’accès à Physionet, en renseignant quelques informations et en donnant les coordonnées d’un superviseur ou d’un collègue, à qui un mail sera envoyé.
Vous devrez ensuite compléter le CITI Course, il s’agit d’une formation nécessaire afin d’accéder aux données hébergées sur le site Physionet. Les différentes étapes sont détaillées ici.
Vous pourrez ensuite télécharger le certificat une fois le CITI Course terminé, vous pourrez le le déposer ici pour validation par l’équipe de Physionet.
Il ne vous restera plus qu’à signer le data use agreement.