Une série d’articles expliquant tout l’environnement de la recherche en santé numérique
1.1 - Qu'est-ce qu'un entrepôt de données de santé ?
Par Boris Delange | 14.10.2024
Dans cet article, nous allons :
Expliquer ce que sont le système d'information hospitalier (SIH) et un entrepôt de données de santé (EDS)
Expliquer les concepts d'ETL et d'interopérabilité
Détailler les flux de données intégrés dans les EDS
Vous donner les clefs pour pouvoir accéder à ces données en pratique
Informatisation des hôpitaux
Depuis quelques années déjà, la majorité des services hospitaliers est passée des pancartes et des prescriptions papiers à des logiciels de soins.
L’ensemble de ces logiciels s’appelle le système d’information hospitalier, ou SIH.
Il existe de nombreux logiciels pour chaque hôpital : un logiciel pour l’imagerie, un pour la prescription de chimiothérapie, un autre pour la réanimation etc.
Toutes les données utilisées et produites par les logiciels sont stockées dans des bases de données.
Donc en soi, toute donnée que vous voyez apparaître à l’écran est techniquement récupérable, il “suffirait” de copier ces données pour les utiliser dans le cadre de la recherche.
Cours "Données de santé", faculté de médecine de Rennes, 2024
Entrepôts de données de santé
Un entrepôt de données de santé (EDS) est un espace de stockage où sont copiées les données issues du soin, pour être utilisées en recherche.
La grande majorité des CHU sont pourvus d’EDS, avec des niveaux de maturité plus ou moins avancés.
En effet, il ne suffit pas de copier ces données, elles doivent être transformées et calquées sur un modèle de données pour être utilisées en recherche.
Tout ce processus est appelé l’ETL, pour Extract, Transform and Load.
Cours "Données de santé", faculté de médecine de Rennes, 2024
ETL et interopérabilité
Comme on l’a vu, les logiciels médicaux sont nombreux et créés par différents éditeurs.
Chaque logiciel stocke ses données sur une base de données avec un schéma différent, défini par l’éditeur.
Il faut imaginer ça comme un tableur Excel avec des noms de colonnes différents pour chaque logiciel.
Vous imaginez bien qu’il est ainsi difficile de fusionner ces données (on ne peut pas fusionner deux fichiers Excel contenant des noms de colonnes différents).
L’interopérabilité est définie par la capacité de matériels, de logiciels ou de protocoles différents à fonctionner ensemble et à partager des informations.
Il s’agit de la capacité des logiciels médicaux à pouvoir échanger des données.
Les logiciels médicaux pour la grande majorité ne sont pas interopérables, ce qui empêche de fusionner les données pour les utiliser en recherche.
C’est là qu’intervient le travail d’ETL.
Cours "Données de santé", faculté de médecine de Rennes, 2024
L’ETL se compose de trois étapes :
Extract : les données des logiciels médicaux sont copiées sur des serveurs de données servant au traitement de ces données brutes.
A ce stade, les données sont au format de l’éditeur de chaque logiciel, donc non interopérables entre-elles.
Transform : c’est l’étape cruciale et la plus complexe, qui permet de transformer toutes ces données en un format unique,
qui permettra de “fusionner” ces données.
Il faut imaginer cela comme des tableurs qui auront au terme de cette transformation les mêmes colonnes pour chaque logiciel,
permettant d’obtenir un seul tableur.
Load : une fois ces données transformées, elles alimentent les serveurs de données servant à la recherche.
Ce processus d’ETL est réalisé à intervalles réguliers, par exemple une fois par semaine, lorsque les serveurs alloués au soin
sont moins sollicités (la nuit ou le week-end).
Flux de données
On appelle flux de données l’intégration d’une source de données à l’EDS.
Par exemple, les données de biologie constituent un flux, puisque l’on réalise l’ETL depuis la base de données du logiciel qui gère ces données de biologie.
On peut citer les flux suivants :
Données démographiques : les patients avec leur âge, leur sexe et leurs séjours hospitaliers
Données biologiques
Données de pancarte : les paramètres vitaux relevés chez les patients, par exemple la pression artérielle, la fréquence cardiaque etc
Données de prescription : les médicaments reçus par les patients
etc
Comme on l’a vu, la majorité des CHU en France sont équipés d’EDS, avec un degré de maturité différent.
Ce degré de maturité dépend des flux de données disponibles.
En effet, le travail d’ETL permettant d’obtenir ces flux de données intégrés à l’EDS de façon régulière est un travail colossal.
Une fois un flux de données créé, les données de ce flux sont intégrées au fur et à mesure à l’EDS, par exemple une fois par semaine.
Le travail ne s’arrête pas là : il faut assurer la qualité continue de ce flux.
Il est fréquent que tout le processus d’ETL d’un flux soit mis à défaut par une mise à jour d’un logiciel.
Les équipes de l’ETL ont des outils qui permettent de s’assurer que les données sont correctement intégrées à l’EDS.
Si ce n’est pas le cas, ils reçoivent une alerte, leur permettant de corriger le problème.
Schémas de BDD
Si vous n’avez pas les idées claires sur qu’est une base de données (BDD) et un schéma de BDD, vous pouvez lire cet article.
Nous avons vu que l’EDS est une grande base de données qui permet d’avoir au même endroit et au même format les données de santé
issues des différents logiciels.
Il existe plusieurs schémas de BDD concernant les données de santé.
Parmi ceux-ci, nous pouvons citer le modèle OMOP (pour Observational Medical Outcomes Partnership), qui est un schéma de BDD (ou modèle de données) commun, dans le sens où il s’adapte à plusieurs sources de données de santé (différents hôpitaux de différents pays, les données de la médecine libérale etc).
Il est largement utilisé dans de nombreux pays.
C’est ce modèle que nous utilisons dans LinkR.
Et en pratique ?
En pratique, ces EDS sont déployés dans la majorité des CHU et quelques centres hospitaliers périphériques.
Vous pouvez vous rapprocher des équipes en charge de l’EDS de votre hôpital pour demander un accès aux données.
Vous serez accompagnés dans la rédaction d’un protocole de recherche et les différentes démarches juridiques vous seront expliquées.
Un obstacle fréquemment évoqué est la nécessité de maîtriser des compétences en programmation pour exploiter ces données.
En effet, des langages comme R, Python et SQL sont souvent requis pour analyser ces données.
C’est pourquoi nous avons créé LinkR, qui permet de manipuler ces données sans connaissance en programmation, et qui permet de travailler plus facilement de façon collaborative sur des projets entre cliniciens et data scientists.
Dans le prochain article, nous verrons les avantages des EDS par rapport au recueil de données manuel.
Conclusion
Les points à retenir :
Le système d'information hospitalier (SIH) est l'ensemble des logiciels servant pour le soin
Les entrepôts de données de santé (EDS) concentrent les données des patients pour un usage secondaire, pour la recherche
Le processus d'ETL permet de transformer les données du SIH, non interopérables, en données interopérables et prêtes à être utilisées pour la recherche au sein des EDS
Le modèle de données OMOP est un schéma de base de données utilisement à l'échelle mondiale, c'est celui qui a été choisi pour fonctionner avec notre logiciel LinkR
LinkR est une plateforme de data science qui a été créée pour faciliter l'accessibilité des données d'EDS.
Cette application permet notamment aux professionnels de santé, sans connaissance en programmation, de manipuler ces données.
Décrire les limites du recueil de données : beaucoup de temps humain et des données de mauvaise qualité
Décrire les avantages de travailler avec les entrepôts de données de santé (EDS) : un gain de temps, des études avec de plus grands effectifs et des données de meilleure qualité
Décrire les freins à l'utilisation des données des EDS
Donner des pistes pour surmonter ces freins
Limites du recueil de données
On entend par recueil de données le fait d’extraire des données pour les utiliser dans le cadre d’une étude.
Généralement, on utilise le système d’information hospitalier (les logiciels servant pour le soin) pour afficher les données, que l’on recopie sur un tableur Excel.
Les variables nécessaires à l’étude sont définies en amont permettant de créer le tableur Excel avec une colonne correspondant à chaque variable.
Si l’on prend l’exemple d’une étude visant à prédire la mortalité d’un patient à partir de paramètres à son admission en réanimation, nous aurions un tableur Excel ressemblant à ceci :
patient_id
age
sexe
date_admission
créatininémie
pression art systolique
bilirubinémie
diurèse
1
45
M
2024-10-01
1.2
120
0.8
1500
2
60
F
2024-09-25
1.0
135
1.1
1800
3
38
F
2024-10-05
0.9
110
0.7
1600
4
52
M
2024-09-20
1.4
140
1.3
1400
5
29
F
2024-10-08
1.1
125
0.9
1700
La créatininémie, la pression artérielle systolique, la bilirubinémie et la diurèse seront les valeurs à l’admission.
Première problématique
Le temps passé pour recueillir les données des patients est directement proportionnel au nombre de patients et au nombre de paramètres.
Si on estime par exemple à 15 minutes le temps pour recueillir 10 paramètres chez un patient, et 45 minutes pour 50 paramètres (on imagine que ce n’est pas totalement linéaire, le temps d’accéder au dossier, de se l’approprier, avant de recueillir les données), on peut estimer le temps passé comme ceci :
Si on a une étude avec 200 patients et 50 paramètres (soit 10000 cases à remplir à la main), on voit que l’on est déjà à 150 heures.
De fait, étant donné les moyens humains nécessaires pour obtenir de telles données, ces études dépassent rarement 200 patients.
Deuxième problématique
Ces données recueillies peuvent être de mauvaise qualité.
Certaines données sont simples à recueillir, l’âge du patient, son sexe, sa date d’admission… Il y a peu de risques de se tromper lors du recueil de ces données (quoiqu’au bout du 150ème patient, cela peut arriver).
Le problème réside surtout dans les données où un choix doit être fait au moment du recueil.
Nous avons volontairement été flous sur la définition des variables à l’admission. Nous avons indiqué “la créatininémie, la pression artérielle systolique, la bilirubinémie et la diurèse seront les valeurs à l’admission”.
Les questions que l'on se pose durant le recueil :
Si je n'ai qu'une valeur de créatininémie à l'admission, c'est assez simple, je prends la valeur disponible.
Si je n'ai pas de valeur, jusqu'à combien de temps je peux remonter pour avoir une valeur ?
Si j'ai plusieurs valeurs, je prends le maximum ? La dernière valeur ? La moyenne ?
Si nous n’avons pas clairement défini les variables, ces choix seront laissés à la discrétion de la personne faisant le recueil, et donc pourront varier d’une personne à l’autre.
Pour modifier une valeur entrée dans le tableur, il faudra retourner la chercher dans le dossier du patient, donc ce temps est à multiplier par le nombre de patients…
Et si par malheur j’ai oublié de recueillir un paramètre, je vais de la même façon devoir retourner dans chaque dossier, un par un…
Donc du fait de ces choix faits au moment du recueil et du risque d’erreur lors du recueil, ces données pourront être de mauvaise qualité.
D'où l'importance de bien définir les variables à recueillir.
Nous publierons prochainement un article là-dessus.
Avantages des EDS
Premier avantage
Le temps passé à extraire les données depuis l'EDS n'est plus proportionnel au nombre de patients mais uniquement au nombre de paramètres.
Nous reprenons le graphique précédent et comparons le temps passé entre le recueil de données manuel et l’extraction des données avec l’EDS.
Sur cette figure, la ligne rouge en pointillés est le temps passé à extraire les données avec l’EDS.
On voit donc que très rapidement, à partir de 50 patients pour 10 paramètres et 75 patients pour 50 paramètres, il devient plus rentable de travailler avec l’EDS.
On peut ainsi imaginer travailler avec des bases de plusieurs centaires de milliers de patients, ce qui est évidemment impossible avec le recueil manuel.
Deuxième avantage
L'extraction des données fonctionnant avec des scripts à partir des données brutes, une simple modification des scripts permet de générer de nouveau les données finales.
Ce qui est génial !
Les EDS sont des grandes bases de données qui contiennent les données brutes des patients (leurs données biologiques, les prescriptions etc).
Les scripts sont des suites d’instructions permettant d’obtenir les données finales (le tableau du premier paragraphe) à partir des données brutes (les données de l’EDS, avec une ligne par donnée).
Pour obtenir le tableau présenté au début de cet article, le script ressemblerait à ceci :
-- 1) Sélection des patients
-- On met ici le code pour sélectionner les patients selon nos critères d'inclusion et pour récupérer leur âge et leur sexe.
SELECTpatient_id,age,sexe-- Sélection des colonnes patient_id (numéro du patient), age et sexe
FROMpatients-- Depuis la table patients
WHEREage>=18-- Avec âge supérieur ou égal à 18 ans
-- 2) Récupération des séjours
-- On récupère les séjours et on les ajoute la date d'admission à nos données
SELECTstay_id,unite-- Sélection des colonnes stay_id (numéro du séjour), unite (le nom de l'unité, par exemple cardiologie)
FROMstays-- Depuis la table des séjours (stays)
WHERElos>=1-- Où la durée de séjour est supérieur ou égale à 1 jour
ANDunite='Cardiologie'-- Et où l'unité est la cardiologie
-- 3) Récupération de la biologie
-- On récupère la moyenne des données de biologie dans les 24 heures suivant l'admission dans le service
SELECTAVG(valeur_numerique)-- Sélection de la moyenne (AVG comme average) de la valeur de la biologie
FROMlabo-- Depuis la table labo
WHERElab_datetime>=adm_datetime-- Où le prélèvement est réalisé après l'admission dans le service...
ANDlab_datetime<=adm_datetime+INTERVAL24HOUR-- ... et avant 24 heures après l'arrivée
ANDconceptIN('creatininemie','pression_art_sys','bilirubinemie')-- Et où le nom de la biologie est dans cette liste
Euh attends... C'est du code ça ? Je n'y comprends rien !
Le SQL est un langage qui sert à requêter les bases de données.
C’est un langage assez pragmatique, si on comprend les quelques mots clefs, il suffit de lire le code pour comprendre ce que l’on obtient.
Les mots-clefs sont les suivants :
SELECT : vous choisissez les colonnes que vous voulez garder
FROM : de quelle table seront extraites les données ?
WHERE : quels filtres appliquer sur les données ?
Si l’on reprend le code pour les patients :
SELECTpatient_id,age,sexeFROMpatientsWHEREage>=18
On sélectionne les colonnes patient_id, age et sexe de la table des patients qui sont âgés de plus de 18 ans.
On obtiendra donc :
patient_id
age
sexe
1
45
M
2
60
F
3
38
F
4
52
M
5
29
F
Et ainsi de suite pour le reste du code, pour obtenir le tableau final.
patient_id
age
sexe
date_admission
créatininémie
pression art systolique
bilirubinémie
1
45
M
2024-10-01
1.2
120
0.8
2
60
F
2024-09-25
1.0
135
1.1
3
38
F
2024-10-05
0.9
110
0.7
4
52
M
2024-09-20
1.4
140
1.3
5
29
F
2024-10-08
1.1
125
0.9
Cool... Mais concrètement, en quoi c'est "génial" ?
Ce qui est génial est que ce code peut être appliqué pour obtenir une infinité de patients.
Souvenez-vous des pointillés rouges, le temps est proportionnel au nombre de paramètres à extraire et non au nombre de patients.
Plus on voudra extraire de paramètres, plus ce script sera complexe et plus on passera de temps à l’écrire.
Mais par contre, que l’on ait 100 patients ou 100 000 patients à extraire, ce script sera le même !
J'en profite pour combattre une idée reçue.
On pense souvent que ces bases de données prennent un espace monstrueux.
En fait non, les méthodes actuelles de stockage de données sont optimisées, et vous pouvez stocker facilement une base de 50 000 patients sur votre ordinateur.
En fait, c'est le cas de la MIMIC-III, cette base contient les données de 50 000 patients, avec toutes les notes quotidiennes du personnel médical, avec un paramètre vital par minute, avec toutes les prescriptions etc.
Cette base de données occupe 3 Go seulement au format Parquet (plus optimisé que le CSV).
Et pas besoin de serveurs de calculs monstrueux pour travailler dessus, n'importe quel ordinateur portable est suffisant (hors cas particuliers tels que les algorithmes de machine learning qui peuvent être gourmands).
Deuxième aspect génial, c’est que si vous voulez ajouter une variable à votre tableau, il suffira de modifier le script et de le relancer, encore une fois quelque soit le nombre de patients.
Et troisième avantage, vous pourrez relancer vos scripts de façon itérative : si vous le relancez deux ans plus tard, vous aurez les données de patients de deux années supplémentaires.
Freins à l’utilisation des EDS
Vous devez à ce stade être convaincus de l’intérêt d’utiliser les EDS plutôt que le recueil manuel.
Mais alors, pourquoi ne fait-on pas toute la recherche médicale avec ces EDS ?
Il existe plusieurs freins qui limitent l'utilisation de ces EDS :
Le travail d'ETL pour intégrer les différents flux de données
La nécessité de connaissances en programmation
ETL et flux de données
Comme on l’a vu dans un précédent article, le travail d’ETL (le fait de transformer les données issues du soins pour être utilisées dans le cadre de la recherche, ou utilisation secondaire des données de santé) est un travail laborieux.
Ainsi, les EDS se construisent petit à petit en intégrant les différents flux de données progressivement.
Il est donc parfois nécessaire de recourir à une partie de recueil manuel si certaines données manquent dans l’EDS.
Connaissances en programmation
Nous l’avons vu avec les requêtes SQL ci-dessus, il est nécessaire d’avoir des connaissances en programmation pour tirer profit de ces EDS.
Cette suite d’article vous donne les clefs pour vous initier à la programmation.
Cela dit, et c’est là la raison de la naissance du projet LinkR, notre plateforme vous permet d’accéder à ces données sans connaissance en programmation.
Après une demande à l’équipe de votre EDS local, les données peuvent être mises à disposition sur LinkR, et vous pourrez y travailler de façon collaborative.
Une interface graphique vous permettra de créer des onglets pour afficher et analyser les données.
Une interface de programmation intégrée permettra au data scientist de vous aider dans la réalisation de certains scripts.
On insiste, le fait de ne RIEN connaître en programmation n'est pas un frein !
Conclusion
Les points à retenir :
Le recueil de données manuel est chronophage et aboutit à des données qui peuvent être de mauvaise qualité
Les EDS permettent d'obtenir des données de meilleures qualité, en plus grande quantité en moins de temps
Il existe quelques freins à l'utilisation des EDS, que LinkR permet en partie de surmonter
2 - Bases de données
Des ressources sur les principaux modèles de données et sur des bases de données accessibles en ligne
2.1 - Qu'est-ce qu'une base de données ?
Par Boris Delange | 15.10.2024
Dans cet article, nous allons :
Définir ce qu'est une base de données en partant d'une analogie avec Excel
Evoquer les principes de conception qui permettent de créer une base de données
Aborder les notions de tables, de jointures et de schémas
Aborder le SQL, ce langage de programmation qui permet de requêter les bases de données
Principes de conception
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 :
d’éviter les redondances des données, pour prendre moins d’espace
de contenir le moins de cases vides possibles, toujours pour occuper moins d’espace
d’être le plus flexible possible, pour pouvoir ajouter de nouvelles données que l’on n’avait pas prévues initialement
Structurer les données en tables
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 :
Il existe une redondance des données démographiques (âge, sexe, dates d'admission et de sortie)
Nous avons dû créer une ligne par date de prélèvement biologique, ce qui fait que nous avons des cases vides aux dates où certaines biologies n'ont pas été réalisées
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…
Jointures
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.
Requêter une base de données
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) :
SELECT : vous choisissez les colonnes que vous voulez garder
FROM : de quelle table seront extraites les données ?
WHERE : quels filtres appliquer sur les données ?
Par exemple :
SELECTpatient_id,age,sexeFROMpatientsWHEREage>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
Schémas de BDD
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 :
le nom des tables
le nom des colonnes de chaque table
le type de données de chaque colonne (si la colonne doit comprendre des données de type texte ou numérique par exemple)
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.
Conclusion
Les points à retenir :
Une base de données est un ensemble de tables avec un schéma particulier (noms des colonnes et type des données)
Les schémas des bases sont contruits selon des principes : éviter les redondances, optimiser l'espace et permettre la flexibilité
Les tables peuvent être liées entre-elles à l'aide de jointures
Le SQL est un langage de programmation permettant de requêter les bases de données
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.
Ctrl/Cmd + Entrée : Exécuter
Ctrl/Cmd + Shift + Entrée : Exécuter et valider
1PERSON
2VISIT_OCCURRENCE
3VISIT_DETAIL
4DEATH
5OBSERVATION_PERIOD
6CONCEPT
7SYNTHÈSE
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.
1Exercice 1.1 : Explorer la table PERSON
Commencez par explorer la structure de la table person. Affichez les 5 premières lignes pour découvrir les colonnes disponibles.
Exercice 1.1
Utilisez SELECT * FROM ... LIMIT 5
2Exercice 1.2 : Compter les patients
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.
Exercice 1.2
Utilisez COUNT(*)
3Exercice 1.3 : Trouver le patient
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).
Exercice 1.3
Filtrez avec WHERE sur l'année de naissance
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).
1Exercice 2.1 : Explorer les hospitalisations
Affichez les 5 premières hospitalisations de la table visit_occurrence.
Exercice 2.1
Utilisez SELECT * FROM ... LIMIT 5
2Exercice 2.2 : Compter les hospitalisations
Combien y a-t-il d’hospitalisations au total dans la base ?
Exercice 2.2
Utilisez COUNT(*)
3Exercice 2.3 : Hospitalisations par patient
Combien d’hospitalisations a effectué notre patient (person_id = 8789342) ?
Exercice 2.3
Filtrez avec WHERE sur person_id
4Exercice 2.4 : Durée des hospitalisations
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.
Exercice 2.4
Calculez la différence entre date de fin et date de début, et nommez la colonne avec AS (ex: 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…
1Exercice 3.1 : Explorer les détails
Affichez les 5 premières lignes de la table visit_detail pour découvrir sa structure.
Exercice 3.1
Utilisez SELECT * FROM ... LIMIT 5
2Exercice 3.2 : Détails de l'hospitalisation
Combien de séjours hospitaliers (lignes dans visit_detail) sont liés à l’hospitalisation visit_occurrence_id = 6687131 ?
Exercice 3.2
Utilisez COUNT(*) et filtrez sur visit_occurrence_id
3Exercice 3.3 : Parcours du patient
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.
Exercice 3.3
Filtrez sur l'hospitalisation et triez par date de début de séjour
4Exercice 3.4 : Durée des séjours
Calculez la durée de chaque séjour pour cette hospitalisation. Ajoutez une colonne duree_sejour (en jours) à la requête précédente.
Exercice 3.4
Calculez la différence entre date de fin et date de début du séjour
5Exercice 3.5 : Nom des unités
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.
Exercice 3.5
Faites une jointure avec care_site pour obtenir le nom de l'unité
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é.
1Exercice 4.1 : Explorer la structure de DEATH
Affichez toutes les colonnes de la table death pour découvrir sa structure.
Exercice 4.1
Utilisez SELECT * FROM ...
2Exercice 4.2 : Compter les décès
Combien de patients sont décédés dans cette base ?
Exercice 4.2
Utilisez COUNT(*)
3Exercice 4.3 : Notre patient est-il décédé ?
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).
Exercice 4.3
Faites une jointure entre person et death sur person_id
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.
1Exercice 5.1 : Explorer les périodes d'observation
Affichez les 5 premières lignes de la table observation_period.
Exercice 5.1
Utilisez SELECT * FROM ... LIMIT 5
2Exercice 5.2 : Durée de suivi de notre patient
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.
Exercice 5.2
Filtrez sur person_id et calculez la différence entre les dates
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.
1Exercice 6.1 : Explorer les concepts
Affichez les 5 premiers concepts de la table concept.
Exercice 6.1
Utilisez SELECT * FROM ... LIMIT 5
2Exercice 6.2 : Trouver un concept
Recherchez le concept dont le concept_id est 8532.
Exercice 6.2
Filtrez avec WHERE sur concept_id
3Exercice 6.3 : Jointure patient-concept
Affichez le nom du genre (concept_name) pour notre patient 8789342. Joignez person et concept sur gender_concept_id.
Exercice 6.3
Joignez person avec concept sur gender_concept_id = 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.
1Exercice 7.1 : Synthèse - Vue complète des séjours
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_id
visit_occurrence_id
visit_detail_id
visit_detail_start_datetime
visit_detail_end_datetime
care_site_name : le nom du service
birth_datetime
gender_concept_name : le nom du genre
age : l'âge au moment du séjour
death_datetime : la date de décès (si applicable)
Exercice 7.1
Combinez visit_detail avec person, concept, care_site et death par des jointures
Niveau Intermédiaire : Données cliniques
Vous maîtrisez les bases du modèle OMOP. Ce niveau explore les tables cliniques : diagnostics, mesures, observations, procédures et dispositifs médicaux.
Ctrl/Cmd + Entrée : Exécuter
Ctrl/Cmd + Shift + Entrée : Exécuter et valider
1CONDITION
2MEASUREMENT
3OBSERVATION
4PROCEDURE
5DEVICE
6SYNTHÈSE
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.
1Exercice 1.1 : Explorer la table CONDITION_OCCURRENCE
Découvrez la structure de la table condition_occurrence en affichant les 5 premières lignes.
Exercice 1.1
Utilisez SELECT * FROM ... LIMIT 5
2Exercice 1.2 : Compter les diagnostics du patient
Combien de diagnostics ont été posés pour notre patient 8789342 ?
Exercice 1.2
Utilisez COUNT(*) et filtrez sur person_id
3Exercice 1.3 : Lister les diagnostics avec leur nom
Affichez les diagnostics du patient avec leur nom lisible. Joignez la table concept pour traduire les condition_concept_id.
Exercice 1.3
Joignez avec concept sur condition_concept_id = concept_id
4Exercice 1.4 : Diagnostics uniques du patient
Un même diagnostic peut apparaître plusieurs fois (à chaque hospitalisation). Listez les diagnostics uniques du patient avec leur nombre d’occurrences.
Exercice 1.4
Utilisez GROUP BY et COUNT(*), triez par ordre décroissant
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.
1Exercice 2.1 : Explorer la table MEASUREMENT
Découvrez la structure de la table measurement en affichant les 5 premières lignes.
Exercice 2.1
Utilisez SELECT * FROM ... LIMIT 5
2Exercice 2.2 : Compter les mesures du patient
Combien de mesures ont été enregistrées pour notre patient 8789342 ?
Exercice 2.2
Utilisez COUNT(*) et filtrez sur person_id
3Exercice 2.3 : Types de mesures les plus fréquents
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.
Exercice 2.3
Joignez avec concept, groupez et triez par count décroissant. Nommez la colonne du comptage nb_mesures (ex: COUNT(*) AS nb_mesures)
4Exercice 2.4 : Évolution de la fréquence cardiaque
Analysez l’évolution de la fréquence cardiaque (Heart rate, concept_id = 3027018) du patient. Affichez la date, la valeur et l’unité.
Exercice 2.4
Filtrez sur le concept_id de la fréquence cardiaque, triez par datetime
5Exercice 2.5 : Statistiques sur la fréquence cardiaque
Calculez les statistiques de la fréquence cardiaque : valeur minimale, maximale et moyenne.
Exercice 2.5
Utilisez MIN(), MAX(), AVG() sur value_as_number
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.
1Exercice 3.1 : Explorer la table OBSERVATION
Découvrez la structure de la table observation en affichant les 5 premières lignes.
Exercice 3.1
Utilisez SELECT * FROM ... LIMIT 5
2Exercice 3.2 : Types d'observations
Quels types d’observations sont enregistrés pour ce patient ? Affichez le nom et le nombre d’occurrences de chaque type.
Exercice 3.2
Joignez avec concept, groupez et triez par count
3Exercice 3.3 : Mode d'oxygénation
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.
Exercice 3.3
Filtrez sur observation_concept_id et affichez value_as_string
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.
1Exercice 4.1 : Explorer la table PROCEDURE_OCCURRENCE
Découvrez la structure de la table procedure_occurrence en affichant les 5 premières lignes.
Exercice 4.1
Utilisez SELECT * FROM ... LIMIT 5
2Exercice 4.2 : Procédures du patient
Listez les procédures réalisées pour notre patient avec leur nom et leur nombre d’occurrences.
Exercice 4.2
Joignez avec concept et groupez par concept_name
3Exercice 4.3 : Chronologie des procédures
Affichez la chronologie des procédures du patient : date, nom de la procédure, triées par date. Utilisez DISTINCT pour éviter les doublons.
Exercice 4.3
Utilisez DISTINCT, joignez avec concept, triez par datetime
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.
1Exercice 5.1 : Explorer la table DEVICE_EXPOSURE
Découvrez la structure de la table device_exposure en affichant les 5 premières lignes.
Exercice 5.1
Utilisez SELECT * FROM ... LIMIT 5
2Exercice 5.2 : Dispositifs utilisés
Quels dispositifs ont été utilisés pour ce patient ? Affichez le nom du dispositif et le nombre d’utilisations.
Exercice 5.2
Joignez avec concept et groupez par dispositif
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.
1Exercice 6.1 : Du format long au format large
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 sinon
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.
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.
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.
Guide utilisateur
Tous les enregistrements de cette table sont des Personnes indépendantes.
Conventions ETL
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.
OBSERVATION_PERIOD
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.
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.
Guide utilisateur
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.
Conventions ETL
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.
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.
Guide utilisateur
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.
Conventions ETL
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.
VISIT_OCCURRENCE
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é.
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.
Guide utilisateur
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.
Conventions ETL
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.
VISIT_DETAIL
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.
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.
Guide utilisateur
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.
Conventions ETL
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.
CONDITION_OCCURRENCE
Champ CDM
Guide utilisateur
Conventions ETL
Type
Requis
PK
FK
Table FK
Domaine FK
condition_occurrence_id
Identifiant unique pour chaque occurrence de condition.
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.
Guide utilisateur
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.
Conventions ETL
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.
DRUG_EXPOSURE
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.
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.
Guide utilisateur
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.
Conventions ETL
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.
PROCEDURE_OCCURRENCE
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.
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.
Guide utilisateur
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.
Conventions ETL
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.
DEVICE_EXPOSURE
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.
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.
Guide utilisateur
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.
Conventions ETL
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.
MEASUREMENT
Champ CDM
Guide utilisateur
Conventions ETL
Type
Requis
PK
FK
Table FK
Domaine FK
measurement_id
Identifiant unique pour chaque enregistrement de mesure.
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.
Guide utilisateur
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.).
Conventions ETL
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.
OBSERVATION
Champ CDM
Guide utilisateur
Conventions ETL
Type
Requis
PK
FK
Table FK
Domaine FK
observation_id
Identifiant unique pour chaque enregistrement d'observation.
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.
Guide utilisateur
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é.
Conventions ETL
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.
NOTE
Description de la table
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.
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).
Conventions ETL
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.
NOTE_NLP
Description de la table
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.
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
Guide Utilisateur
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.
Conventions ETL
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.
EPISODE
Description de la table
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.
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.
Conventions ETL
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.
EPISODE_EVENT
Description de la table
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.
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.
Conventions ETL
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.
SPECIMEN
Description de la table
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.
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.
Conventions ETL
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.
FACT_RELATIONSHIP
Description de la table
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.).
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.
Conventions ETL
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").
LOCATION
Description de la table
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.
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.
Conventions ETL
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.
CARE_SITE
Description de la table
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.).
Code original du type de lieu dans le système source.
VARCHAR(50)
Non
Guide Utilisateur
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.
Conventions ETL
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.
PROVIDER
Description de la table
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.).
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.
Conventions ETL
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.
COST
Description de la table
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.).
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.
Conventions ETL
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.
PAYER_PLAN_PERIOD
Description de la table
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.
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.
Conventions ETL
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.
CONCEPT
Description de la table
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.).
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
Guide Utilisateur
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.
Conventions ETL
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.
VOCABULARY
Description de la table
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.
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).
Conventions ETL
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).
DOMAIN
Description de la table
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).
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.
Conventions 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.
CONCEPT_CLASS
Description de la table
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).
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.
Conventions ETL
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.
CONCEPT_SYNONYM
Description de la table
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.
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".
Conventions ETL
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.
CONCEPT_RELATIONSHIP
Description de la table
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.
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.
Conventions ETL
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.
RELATIONSHIP
Description de la table
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.
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.
Conventions ETL
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é.
CONCEPT_ANCESTOR
Description de la table
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.
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
Guide Utilisateur
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).
Conventions ETL
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.
SOURCE_TO_CONCEPT_MAP
Description de la table
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.
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.
Conventions ETL
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é.
DRUG_STRENGTH
Description de la table
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.
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.
Conventions ETL
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.
CONDITION_ERA
Description de la table
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.
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.
Conventions ETL
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.
DRUG_ERA
Description de la table
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.
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
Guide Utilisateur
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.
Conventions ETL
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.
DOSE_ERA
Description de la table
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.
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.
Conventions ETL
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.
COHORT
Description de la table
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.
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).
Conventions ETL
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.
COHORT_DEFINITION
Description de la table
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.
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.
Conventions ETL
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.
CDM_SOURCE
Description de la table
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.
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.
Conventions ETL
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é.
METADATA
Description de la table
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.
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.
Conventions ETL
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.
2.4 - MIMIC
Description de la base
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.
Données test (publiques)
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 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.
Des cas concrets d’utilisation des données à partir des entrepôts de données de santé
3.1 - Tableau de bord de réanimation
Par Boris Delange | 01.08.2024
Vue d’ensemble
Ce tableau de bord permet d’obtenir une visualisation des indicateurs de qualité des services de réanimation.
Il a l’avantage de pouvoir être configué directement par les cliniciens, sans nécessité de connaissances préalables en programmation.
Il est organisé en plusieurs onglets :
Démographie : Cette section montre le nombre de patients admis sur la période choisie, ainsi que leurs informations démographiques (âge, sexe), le taux de mortalité, le nombre d’admissions, le taux de réadmission et les principaux diagnostics ICD-10 des séjours.
Ventilation : Cette section fournit des données sur la ventilation mécanique, y compris le nombre de patients sous ventilateurs, la durée de la ventilation, le taux d’échec d’extubation, le taux d’auto-extubation et les paramètres ventilatoires sélectionnés.
Sédation : Nous y retrouvons les médicaments utilisés pour la sédation, la durée totale de sédation, la consommation de neuroleptiques etc.
Dialyse : Cette section fournit des informations sur le nombre de patients dialysés, avec quel type de dialyse.
Installation
Pour installer ce projet, vous pouvez suivre le tutoriel “Mise en place” de la documentation.
Vous pouvez également suivre ces tutoriels, si vous souhaitez importer vos propres données :
Installer un projet : sélectionnez le laboratoire DOMASIA dans la ville de Rennes (France), vous verrez apparaître le projet “Tableau de bord d’indicateurs de qualité de réanimation” dans les projets.
Contributions
LinkR est un projet en cours de développement.
En cas de problème pour l’installation ou pour l’utilisation, ou si vous avez des suggestions pour améliorer l’application, merci de nous contacter à linkr-app@pm.me.
Prochaines étapes
Pour le moment, seule la partie “Démographie” est disponible, les autres sections en cours de développement.
Ce tableau de bord est configuré pour visualiser les données de réanimation. Une prochaine étape sera d’appliquer ce modèle de tableau de bords aux autres services hospitaliers et à la médecine libérale.
