En résumé
Les hôpitaux utilisent de nombreux logiciels pour le soin — prescriptions, biologie, imagerie, paramètres vitaux. Ces logiciels stockent leurs données dans des bases séparées, souvent incompatibles entre elles. Un entrepôt de données de santé (EDS) rassemble, transforme et structure ces données dans un espace unique, conçu pour la recherche.
Le système d’information hospitalier
Les hôpitaux utilisent des logiciels de soins pour gérer les prescriptions, les résultats biologiques, l’imagerie, les paramètres vitaux, les comptes rendus, etc. L’ensemble de ces logiciels s’appelle le système d’information hospitalier (SIH).
Il existe de nombreux logiciels au sein d’un même hôpital : un pour la biologie, un autre pour la pharmacie, un autre pour la réanimation, un autre encore pour l’imagerie…
Chaque logiciel stocke ses données dans sa propre base de données. Toute donnée qui apparaît à l’écran d’un logiciel de soin est donc, en théorie, récupérable. Mais en pratique, ces bases de données ne sont pas conçues pour être interrogées à des fins de recherche.
Des données dispersées
Un même patient peut avoir des données dans le logiciel de réanimation, le système de biologie, le logiciel de pharmacie, le système d’imagerie… Rassembler ces informations manuellement est un travail considérable.
Qu’est-ce qu’un entrepôt 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.
L’EDS ne remplace pas les logiciels de soins — il les complète. Les données continuent d’être produites dans le cadre du soin, mais une copie est régulièrement transférée vers l’entrepôt.
Une analogie simple
Imaginez que chaque logiciel de soin est un classeur dans un bureau différent. L’EDS, c’est la bibliothèque centrale qui rassemble une copie de tous les classeurs au même endroit, avec un système de classement unifié.
La grande majorité des CHU en France disposent d’un EDS, avec des niveaux de maturité variables. Certains intègrent une dizaine de flux de données, d’autres sont encore en construction. La CNIL propose une cartographie des entrepôts de données de santé en France.
L’ETL : transformer pour unifier
Le problème principal est que chaque logiciel stocke ses données dans un format différent. Les noms de colonnes, les unités, les identifiants ne sont pas les mêmes d’un logiciel à l’autre. On dit que ces systèmes ne sont pas interopérables.
Système d’information hospitalier
Biologie
patient_id, result_bio, val_num, date_prelvt
Pharmacie
pat_id, med_prescrit, posologie, voie_adm
Réanimation
id_patient, param_vital, horodatage, val
Imagerie
nip, examen, cr_texte, date_exam
Entrepôt de données
Format unique
patient_id, visit_id, concept_id,
datetime, numeric_value, unit,
…
Mêmes colonnes, mêmes codes, mêmes unités — quelle que soit la source.
Pour rendre ces données exploitables, il faut les transformer. Ce processus s’appelle l’ETL (Extract, Transform, Load) :
Extract
Les données sont copiées depuis les bases de données des logiciels de soins vers des serveurs intermédiaires. À ce stade, les données sont au format de chaque éditeur — non interopérables.
Transform
C'est l'étape cruciale. Les données sont transformées en un format unique : mêmes noms de colonnes, mêmes unités, mêmes identifiants. C'est ce qui permet de 'fusionner' des données de sources différentes.
Load
Les données transformées alimentent l'entrepôt de données, prêtes à être interrogées pour la recherche.
Ce processus est exécuté à intervalles réguliers — par exemple une fois par semaine, généralement la nuit ou le week-end, quand les serveurs de soin sont moins sollicités.
Un travail continu
L’ETL n’est pas un projet ponctuel. Chaque mise à jour d’un logiciel de soin peut casser un flux de données. Les équipes en charge de l’entrepôt doivent surveiller la qualité des données en continu et corriger les problèmes dès qu’ils apparaissent.
Les flux de données
On appelle flux de données l’intégration d’une source de données dans l’EDS. Chaque flux correspond à un type de données extrait d’un logiciel spécifique.
Données démographiques
Patients, âge, sexe, séjours hospitaliers…
Données biologiques
Résultats de laboratoire : NFS, ionogramme, CRP…
Paramètres vitaux
Fréquence cardiaque, pression artérielle, SpO2…
Prescriptions
Médicaments, posologies, voies d'administration…
Diagnostics codés
CIM-10 (Classification Internationale des Maladies), actes CCAM (Classification Commune des Actes Médicaux), PMSI (Programme de Médicalisation des Systèmes d'Information)…
Comptes rendus
Consultations, courriers, CR opératoires…
Le degré de maturité d’un EDS dépend du nombre de flux intégrés. Créer un flux fiable demande un travail considérable d’ingénierie. Mais une fois en place, les données sont mises à jour régulièrement et automatiquement.
Un modèle de données commun
Pour que les données soient réellement exploitables — et comparables entre hôpitaux — il faut qu’elles respectent un modèle de données commun.
Le modèle le plus utilisé est OMOP (Observational Medical Outcomes Partnership), développé par le réseau OHDSI. C’est un schéma de base de données conçu pour les données de santé, utilisé dans plus de 50 pays, représentant près d’un milliard de dossiers patients à travers le monde.
Mais pourquoi un modèle commun est-il nécessaire ? Sans lui, chaque hôpital organise ses données à sa façon. Le problème se pose à deux niveaux :
La structure : des schémas différents
D’un entrepôt à l’autre, les tables et les colonnes ne portent pas les mêmes noms pour stocker la même chose :
EDS Hôpital A
patient_id, birth_date
concept_code, numeric_value,
measurement_dt
EDS Hôpital B
person_id, ddn
code_concept, valeur,
date_mesure
La sémantique : des codes différents
Même quand la structure se ressemble, les codes utilisés pour désigner un même concept ne sont pas les mêmes :
Hôpital A
Fréquence cardiaque → code 13902
Libellé : « FC adulte »
Hôpital B
Fréquence cardiaque → code C90230
Libellé : « Fréquence cardiaque »
Un modèle comme OMOP résout ces deux problèmes : il impose des noms de colonnes identiques (interopérabilité structurelle) et des codes standardisés issus de vocabulaires internationaux comme SNOMED, LOINC ou ATC (interopérabilité sémantique).
Pourquoi OMOP ?
OMOP s’est imposé, aux côtés de FHIR, comme le standard de référence pour la recherche sur les entrepôts de données de santé. Il permet de comparer des données entre hôpitaux, entre pays, et de reproduire des études sur des bases différentes. Un script écrit pour un hôpital peut fonctionner sur un autre, sans modification. C’est le modèle le plus utilisé à l’heure actuelle — et celui que Linkr utilise par défaut.
Accéder aux données en pratique
Si votre hôpital dispose d’un EDS, vous pouvez vous rapprocher des équipes en charge pour demander un accès aux données. Ce processus implique généralement de :
Rédiger un protocole de recherche
Définir vos objectifs, votre population d'étude, les variables nécessaires — c'est l'objet des articles précédents.
Obtenir les autorisations réglementaires
RGPD (Règlement Général sur la Protection des Données), avis du comité d'éthique… Les équipes de l'EDS vous accompagnent dans ces démarches.
Accéder aux données
Une fois les autorisations obtenues, les données sont mises à disposition dans un environnement sécurisé.
Mais accéder aux données ne suffit pas : les données brutes d’un EDS contiennent des erreurs, des doublons, des valeurs manquantes. Avant toute analyse, un travail considérable de mise en qualité est nécessaire.
Un autre obstacle fréquemment évoqué est la nécessité de maîtriser des compétences en programmation (R, Python, SQL) pour exploiter ces données. C’est précisément pour lever cet obstacle que Linkr a été créé : permettre aux cliniciens de travailler sur les données de l’EDS sans connaissances en programmation, dans une interface adaptée.
C'est le sujet du prochain article
Dans le prochain article, nous verrons pourquoi la mise en qualité des données est un travail considérable — et pourquoi il en vaut la peine.
Ce qu’il faut retenir
- Le système d'information hospitalier (SIH) regroupe les logiciels utilisés pour le soin, chacun avec sa propre base de données.
- Un entrepôt de données de santé (EDS) rassemble et transforme ces données pour les rendre exploitables en recherche.
- Le processus d'ETL (Extract, Transform, Load) est au cœur de cette transformation — et nécessite un travail continu.
- Le modèle OMOP est le standard de données le plus utilisé, permettant la comparaison et la reproductibilité entre centres.