Version imprimable multipages. Cliquer ici pour imprimer.
Par Boris Delange | 14.10.2024
Dans cet article, nous allons :
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
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
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 :
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).
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 :
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.
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.
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.
Les points à retenir :
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.
>>> Testez LinkR ici
Par Boris Delange | 16.10.2024
Dans cet article, nous allons :
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 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.
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.
SELECT patient_id, age, sexe -- Sélection des colonnes patient_id (numéro du patient), age et sexe
FROM patients -- Depuis la table patients
WHERE age >= 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
SELECT stay_id, unite -- Sélection des colonnes stay_id (numéro du séjour), unite (le nom de l'unité, par exemple cardiologie)
FROM stays -- Depuis la table des séjours (stays)
WHERE los >= 1 -- Où la durée de séjour est supérieur ou égale à 1 jour
AND unite = '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
SELECT AVG(valeur_numerique) -- Sélection de la moyenne (AVG comme average) de la valeur de la biologie
FROM labo -- Depuis la table labo
WHERE lab_datetime >= adm_datetime -- Où le prélèvement est réalisé après l'admission dans le service...
AND lab_datetime <= adm_datetime + INTERVAL 24 HOUR -- ... et avant 24 heures après l'arrivée
AND concept IN ('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 :
Si l’on reprend le code pour les patients :
SELECT patient_id, age, sexe
FROM patients
WHERE age >= 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.
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 :
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.
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 !
Les points à retenir :