Introduction

Au cours des années 2000, les hôpitaux et établissements de santé ont accumulé une quantité massive de données cliniques, principalement grâce à l’informatisation des systèmes d’information. Ces données sont collectées à l’origine pour gérer les soins, la facturation ou les démarches administratives. Elles sont également une opportunité pour répondre à d’autres usages : recherche, évaluation de la qualité des soins, gestion hospitalière, santé publique, etc.

Pour exploiter ce potentiel, les hôpitaux se sont dotés d’entrepôts de données [@doutreligne_entrepots_2022; @lamer_development_2023]. Pourtant, ces entrepôts ne sont qu’une pièce du puzzle, et la réutilisation efficace des données peut s’appuyer sur un enchaînement d’outils et de structures : data lake, entrepôt, datamarts, feature store… chacun ayant un rôle bien précis dans un pipeline de réutilisation des données.

Dans cet article, je vous propose une vue d’ensemble de ce pipeline. Il s’appuie sur des expériences concrètes de terrain dans le secteur de la santé, mais aussi sur des pratiques inspirées d’autres domaines plus avancés en matière de gestion de données, comme le e-commerce, les plateformes de streamings, ou les services numériques. Ces secteurs ont depuis longtemps adopté des architectures de données modulaires et performantes, et il est temps que la santé s’en inspire. L’objectif : mieux comprendre comment organiser ses données pour faciliter l’analyse, produire des résultats reproductibles, et valoriser enfin toute la richesse des données de santé.

Le Système d’Information : un potentiel… difficile à exploiter

Les données brutes générées par les hôpitaux sont dispersées dans une multitude de logiciels — dossier patient, laboratoire, imagerie, pharmacie, etc. Chaque outil utilise ses propres formats, ses propres identifiants pour les patients ou les séjours, et repose sur des technologies souvent hétérogènes. Résultat : croiser ces informations est un exercice complexe.

À cela s’ajoute une autre contrainte : les bases de données des logiciels métiers ne sont généralement pas accessibles en écriture ni en lecture libre, pour éviter de perturber leur bon fonctionnement. Ce sont des bases transactionnelles, conçues pour être précises, fiables et optimisées pour les tâches quotidiennes — pas pour l’analyse.

Et pourtant, ces bases regorgent d’informations utiles : chaque donnée est soigneusement enregistrée en ligne, accompagnée de nombreuses métadonnées (auteur de la saisie, date, appareil utilisé…).

Le Data Lake : un socle souple pour explorer ses données

Premier maillon (optionnel) du pipeline de réutilisation des données, le data lake est un espace de stockage centralisé, extensible et très souple. Il permet d’ingérer et de conserver les données brutes provenant de multiples sources — même très hétérogènes — dans leur format d’origine, sans transformation préalable, et sans avoir à se poser immédiatement la question du modèle de données. Ces données peuvent être structurées (comme des tables), semi-structurées (JSON, XML), ou non structurées (textes libres, images, signaux physiologiques, etc.).

D’un point de vue technique, on y retrouve des bases relationnelles classiques (PostgreSQL, Oracle), mais aussi des technologies issues du big data : stockage distribué (Hadoop, Apache Hudi), traitements massifs (Apache Spark, MapReduce, etc.).

Contrairement à l’entrepôt de données, le data lake ne force pas la structuration immédiate. Cette flexibilité est précieuse : elle permet aux data scientists de manipuler librement les données, de tester des hypothèses, d’adapter les extractions à des besoins très spécifiques — sans devoir redéfinir l’ensemble du pipeline à chaque fois.

Sans data lake, il faut finaliser le processus ETL (extraction, transformation, chargement) avant de pouvoir analyser quoi que ce soit. Et si, en cours de route, on s’aperçoit qu’il manque une donnée, il faut tout reprendre : adapter le modèle, reconfigurer l’ETL, recharger les données… Ce cycle peut ralentir considérablement la recherche.

The Data Warehouse

Parmi tous les composants du pipeline, l’entrepôt de données est sans doute le plus connu. Il joue le rôle de référentiel central, capable d’agréger les données issues de plusieurs logiciels cliniques ou administratifs, qu’elles soient historiques ou récentes, à un niveau de détail très fin.

Contrairement au data lake, qui stocke les données telles quelles, l’entrepôt impose une normalisation stricte : nommage homogène des tables et des champs, identifiants cohérents entre sources, modèle relationnel stable. Tout cela repose sur un processus bien rôdé : l’ETL (Extract-Transform-Load), qui consiste à extraire les données pertinentes du système d’information (ou d’autres sources), les nettoyer, les transformer, et les charger dans un modèle unifié.

Durant cette étape, on écarte volontairement certaines métadonnées techniques (logs d’utilisation, réglages logiciels, etc.). On corrige aussi les incohérences (valeurs aberrantes, doublons…), et surtout, on harmonise les identifiants pour pouvoir relier les données entre elles, même si elles viennent de logiciels différents.

L’entrepôt repose en général sur des bases relationnelles classiques (PostgreSQL, Oracle, SQL Server…), mais certaines architectures explorent aussi des solutions NoSQL (MongoDB, Cassandra…), utiles pour manipuler des données semi-structurées à grande échelle.

Côté outils, l’ETL peut être développé en R, Python ou Java, orchestré avec des planificateurs comme Apache Airflow, ou bien conçu via des interfaces graphiques comme Talend ou Pentaho, sans besoin de coder.

Pour favoriser l’interopérabilité entre établissements, plusieurs initiatives ont vu le jour autour de modèles de données communs (CDM). C’est le cas du modèle OMOP, porté par la communauté internationale OHDSI, qui propose une nomenclature partagée et une cartographie des terminologies locales vers des vocabulaires standardisés.

Les Datamarts : transformer les données en informations prêtes à l’emploi

Même si l’entrepôt centralise les données de manière structurée, il reste souvent trop complexe pour répondre directement à des questions spécifiques. C’est là qu’interviennent les datamarts : des sous-ensembles de l’entrepôt, organisés autour de cas d’usage précis (recherche clinique, suivi qualité, épidémiologie, etc.).

Le datamart permet d’extraire et de transformer les données brutes en variables exploitables, appelées features ou indicateurs. Par exemple, au lieu de conserver toutes les valeurs de potassium d’un patient, le datamart indiquera s’il a présenté une hypokaliémie pendant son séjour.

Ces transformations s’appuient sur des règles métier ou des algorithmes : seuils, combinaisons de diagnostics, tendances temporelles… L’objectif est de fournir des données immédiatement utiles pour répondre à une question donnée, dans un format déjà partiellement agrégé.

Certains datamarts sont organisés sous forme de cubes OLAP (Online Analytical Processing), qui permettent de naviguer dans les données selon plusieurs axes : temps, services hospitaliers, pathologies, etc. Ces structures facilitent les analyses multidimensionnelles, très prisées en épidémiologie ou en gestion hospitalière.

Enfin, les datamarts sont généralement hébergés sur des bases relationnelles classiques (PostgreSQL, Oracle…), mais peuvent aussi s’appuyer sur des technologies orientées analyse comme Apache Kylin.

Le Feature Store : l’outil des data scientists

Le feature store est la dernière brique du pipeline, et c’est aussi la plus orientée science des données. Son rôle ? Mettre à disposition des variables prêtes à l’analyse, dans un format simple, propre et reproductible.

Alors que les datamarts restent souvent organisés en lignes (1 ligne par événement ou par patient-séjour), le feature store pivote les données pour les présenter sous forme colonnes : 1 variable = 1 colonne, comme dans un fichier d’analyse statistique ou de machine learning.

Ce format simplifie énormément la vie des analystes : plus besoin de faire des jointures complexes, de pivoter les tables ou de retraiter les données. On accède directement à des jeux de données “flat”, souvent comparables à des questionnaires, où chaque ligne correspond à une unité d’analyse (patient, séjour, etc.).

Autre intérêt majeur : le feature store trace l’origine des variables. Il conserve les métadonnées de chaque feature (comment elle a été calculée, à partir de quelles données, selon quelle version d’un algorithme…), ce qui garantit la reproductibilité des analyses.

Enfin, il peut accueillir des features issues de règles métier (comme les datamarts), mais aussi des features issues de modèles de machine learning (par exemple : probabilité de réadmission, score de risque…).

Conclusion : un pipeline modulable pour une exploitation efficace des données

Ce tour d’horizon avait pour but de clarifier les rôles et les articulations entre les différentes briques d’un pipeline de réutilisation des données : data lake, entrepôt de données, datamarts et feature store. Chacune apporte une réponse à des besoins spécifiques — du stockage brut jusqu’à l’analyse fine.

L’entrepôt reste une base incontournable : il consolide les données selon un modèle commun, assurant cohérence et pérennité. Mais c’est l’ajout de datamarts, pour structurer les informations selon des objectifs métiers, et de feature stores, pour les rendre immédiatement exploitables en analyse, qui donne toute sa puissance au pipeline. De son côté, le data lake permet d’amorcer les travaux plus tôt, sans attendre que le pipeline complet soit en place.

Sans data lake, chaque ajout de donnée ou modification de besoin oblige à reprendre le processus ETL et le modèle de données. C’est lourd, chronophage, et peu compatible avec une recherche agile.

Bien sûr, la composition de ce pipeline n’est pas figée. Son architecture et la présence de chacun des composants dépendent du contexte : volume de données, complexité des sources, nombre de features, types de projets, ressources humaines disponibles, et surtout besoins en reproductibilité. L’enjeu est d’adapter intelligemment le pipeline aux objectifs de chaque structure.

Consultez la page À propos pour plus d’informations sur le projet.

Barrières et difficultés

Caractéristiques (Features)

Une caractéristique (feature) est une valeur unique associée à un nom, comme 25 minutes pour la durée d’hypotension en dessous de 65 mmHg (Table 1).

Dans une caractéristique, la dimension temporelle est implicite : elle n’est plus formalisée par une date précise dans l’enregistrement. Elle peut parfois apparaître dans le nom de la variable — par exemple, la valeur maximale de créatinine à J0, c’est à dire au premier jour de l’hospitalisation (max_creat_j0) — ou être intégrée directement dans la valeur de la caractéristique elle-même, pour exprimer un délai ou une durée — par exemple, la durée du séjour (duree_sejour).

Une caractéristique dépend fortement du contexte de l’étude. Par exemple, pour la créatinine, J0 fait référence au premier jour de l’hospitalisation considérée dans le protocole d’analyse. De même, une variable décrivant la présence d’antécédents médicaux dépendra étroitement de la définition retenue dans l’étude : celle-ci peut s’appuyer sur la présence d’un diagnostic codé, la réalisation d’un acte médical spécifique, ou encore la délivrance d’un médicament donné. Ces événements doivent être recherchés sur une période d’observation définie (par exemple les 12 mois précédents l’inclusion), en fonction des objectifs de l’étude et des antécédents jugés pertinents pour la pathologie étudiée.

Extraction de caractéristiques (feature extraction)

L’extraction de caractéristiques (feature extraction) est le processus qui consiste à transformer des données brutes en variables pertinentes et exploitables pour répondre à une question précise, ou alimenter un modèle d’analyse. Cette étape mobilise à la fois la connaissance du domaine (dans notre cas, la santé) et des méthodes pour résumer, combiner ou dériver des informations utiles à partir des données disponibles.

L’hypotension au bloc opératoire

A partir des données enregistrées au bloc opératoire (fréquence cardiaque, pression artérielle, saturation en oxygène), il est possible de dériver des événements indésirables peropératoires tels que la survenue d’une bradycardie, d’une tachycardie, d’une hypotension, d’une hypertension ou encore d’une désaturation (Figure 1). Ces événements sont essentiels pour la recherche car les médicaments utilisés pour l’anesthésie, en particulier les hypnotiques, modifient les paramètres physiologiques du patient. L’hypotension peropératoire, par exemple, est associée à une augmentation de la mortalité post-opératoire et à la survenue de complications rénales [@wijnberge_association_2021].

En l’état, les données représentées dans la (Figure 1) ne sont pas directement exploitables. Il s’agit en effet de mesures dépendantes du temps, avec une valeur par enregistrement, et dont les instants de recueil diffèrent d’un patient à l’autre. Pour analyser l’hypotension, il est préférable de calculer des indicateurs dérivés, tels que la durée passée sous un seuil donné — par exemple 65 mmHg — comme illustré dans la (Figure 2). Cette opération nécessite la mise en place d’un algorithme permettant de comptabiliser le temps cumulé sous la valeur seuil, en tenant compte notamment de la gestion des données manquantes (lorsque l’intervalle entre deux mesures est anormalement long) et de la fréquence d’échantillonnage [@lamer_methodology_2016].

Ainsi, des données initialement organisées ligne par ligne, avec une mesure par ligne et un nombre de mesures variable selon la durée de prise en charge au bloc opératoire, sont transformées en un format où chaque colonne correspond à une caractéristique spécifique (Figure 3).

Opérations usuelles pour l’extraction de caractéristiques

Les principales opérations utilisées lors de l’extraction de caractéristiques sont les suivantes :

• Sélection de modalités : repérer les événements pertinents dans une base à partir de codes ou de terminologies standardisées. Exemple : identification des diagnostics CIM-10 de catatonie (F06.1 et F20.2) [@mastellari_exploring_2024] ; sélection des délivrances d’antidépresseurs par les codes ATC N06A [@lamer_prolonged_2024].

• Filtres temporels : restreindre l’analyse à une période donnée. Exemple : calcul des délivrances de médicaments par semaine [@lamer_prolonged_2024] ; définir une fenêtre de 90 jours avant une hospitalisation pour quantifier les expositions médicamenteuses.

• Lien entre plusieurs bases : associer des informations issues de sources différentes afin de reconstruire une trajectoire ou contextualiser un événement. Exemple : relier les données d’administration de médicaments avec le passage d’un patient au bloc opératoire.

• Fonctions de résumé : elles permettent de dériver des caractéristiques synthétiques à partir des données brutes. On distingue :

  • les opérations d’agrégation, qui condensent une série de valeurs en un indicateur unique (moyenne, médiane, minimum, maximum, écart-type) ;

  • les opérations de comptage, qui quantifient la fréquence ou l’ampleur d’un événement (nombre d’occurrences, nombre d’individus concernés) ;

  • les opérations de dérivation, qui produisent de nouvelles variables à partir de relations entre mesures (par exemple, calcul d’une différence ou d’une durée entre deux événements) [@lamer_prolonged_2024].

Pour calculer une caractéristique, ces opérations peuvent s’enchaîner (Figure 4). On peut par exemple commencer par associer deux bases de données afin de disposer à la fois de mesures ponctuelles (par exemple, les résultats de biologie) et de périodes (comme les séjours dans différentes unités de soins). On sélectionne ensuite les paramètres biologiques et les unités pertinentes, puis on applique un filtre temporel pour restreindre l’analyse à une période donnée. Enfin, une fonction de résumé permet de calculer un indicateur synthétique, par exemple la valeur maximale d’un biomarqueur au cours d’un séjour en unité de réanimation.

Une proposition de méthode

Nous proposons de découper le processus en deux étapes : la définition de tracks (ou pistes), qui consiste à transformer les données brutes en segments temporels ou signaux d’intérêt, et l’agrégation des tracks (track aggregation), qui permet de résumer ces segments par des valeurs exploitables (Figure 5). Les features obtenues sont alors des variables unidimensionnelles et indépendantes du temps, compatibles avec une unité statistique unique (patient, séjour, acte, etc.).

Lors de cette transformation, la structure des données change : on passe de nombreuses lignes réparties sur plusieurs tables à un tableau synthétique où chaque ligne représente l’unité statistique, et chaque colonne une caractéristique extraite. Cette standardisation permet de gérer la complexité initiale des données de santé, souvent hétérogènes, multidimensionnelles et dépendantes du temps. Par exemple, dans une étude sur les interactions médicamenteuses, des administrations de plusieurs médicaments sont combinées pour détecter une exposition concomitante, qui est ensuite agrégée pour produire un indicateur binaire ou une durée.

Cas d’usage complet

Nous souhaitons mesurer le nombre de médicaments appartenant à la liste de Laroche [laroche_potentially_2007] dans les 90 jours qui précédent l’hospitalisation (Figure 6).

Tout d’abord, les enregistrements bruts des données administratives (dates d’admission et de sortie d’hospitalisation) ont été transformés en un nouveau type d’enregistrement correspondant à la survenue d’une hospitalisation (étape 1). Ensuite, cette piste a été transformée pour obtenir une seconde piste représentant les 90 jours précédant l’hospitalisation (90_days) (étape 2).

Les administrations de médicaments figurant dans la liste de Laroche ont été identifiées, et les périodes d’administration du médicament A et du médicament B ont été calculées à partir des dates d’administration et de la durée de traitement, aux étapes 3 et 4, respectivement. Des pistes similaires ont été calculées pour l’ensemble des médicaments de la liste de Laroche, mais, pour des raisons de clarté de la figure, nous avons choisi d’illustrer uniquement les deux premiers médicaments.

Après ces quatre étapes, des comparaisons entre pistes ont été réalisées successivement. Cela a permis de comparer les pistes d’administration du médicament A et du médicament B à la piste 90_days, aux étapes 5 et 6, respectivement. Les résultats ont ensuite été réunis dans une piste commune afin d’obtenir les pistes d’administration des éléments de la liste de Laroche au cours de la période 90_days (étape 7).

Enfin, le nombre d’éléments distincts a été comptabilisé pour obtenir la caractéristique finale, à savoir le nombre de médicaments de la liste de Laroche administrés au cours des 90 jours précédant l’hospitalisation.

Enjeux et bonnes pratiques de l’extraction de caractéristiques

L’extraction de caractéristiques est une étape cruciale dans les projets de data science en santé. Bien qu’elle permette souvent de disposer des variables nécessaires pour directement à la question d’analyse posée, ce processus reste méthodologiquement complexe.

Dans de nombreux cas, les caractéristiques sont extraites à partir de bases de données médicales figées, contenant des épisodes de soins passés et un grand nombre d’enregistrements. Cela implique que tous les scénarios d’analyse doivent être anticipés, afin d’éviter des modifications manuelles fastidieuses ou sources d’erreur en aval.

La manière dont les caractéristiques sont extraites peut influencer significativement les résultats (voir notamment les travaux de Pasma à ce sujet [@pasma_artifact_2020]). Le choix des variables, des fenêtres temporelles, ou encore des méthodes de calcul, peut introduire des biais ou masquer des signaux pertinents.

Ce processus illustre bien la démarche pluridisciplinaire propre à la data science en santé : il mobilise des compétences en santé (pour comprendre les parcours de soins et sélectionner les bonnes données), en informatique (pour automatiser et fiabiliser l’extraction), et en statistique (pour interpréter les résultats avec rigueur).

Enfin, pour aller plus loin, il peut être pertinent d’intégrer un feature store pour centraliser le stockage des caractéristiques, et un feature catalogue pour documenter leur définition, leur version, et leur utilisation dans différents projets ou publications.

A voir

Pipeline de réutilisation des données

Synthèse