Data Architecture

Entrepôts de données de santé : un seul concept juridique pour deux réalités

Mariuca De Hillerin

Nous vous parlions dans notre tout premier post du Modern Data Management. Bienvenue dans sa suite logique ! Nous explorons ici toutes les subtilités liées au concept d’entrepôt de données de santé qui fait fureur en ce moment dans la HealthTech – on le voit et on l’entend partout.

Architectures de données vs. logiciels de recherche clinique

Force est de constater que l’on voit surtout passer l’expression “entrepôt de données” pour parler d’une architecture de données. Parfois, nous l’employons nous-mêmes faute de temps… (Ce mea culpa aura raison de nous). Or, c’est sans équivoque un abus de langage, puisque ces deux notions sont différentes et méritent d’être mises en contraste.

Techniquement, en effet, une architecture de données peut contenir zéro, un ou plusieurs entrepôts de données (data warehouses). Tout comme une bibliothèque contient plusieurs étagères. Ces data warehouse sont simplement des “contenants” qui permettent de stocker la donnée. On peut avoir des entrepôts de données contenant une donnée “brute”, d’autres contenant une donnée parfaitement harmonisée, d’autres contenant les mêmes données mais dans d’autres formats ou pour d’autres usages (on ne "range" pas les données de la même façon pour la recherche clinique, pour le pilotage ou encore pour le soin !)

Illustration Entrepôt de données de santé

Une architecture de données peut contenir plusieurs entrepôts de données.

Cette confusion entre “data warehouse en santé” et architecture de données de santé introduit de fait un biais de compréhension qui nous fâche (un peu). Allons-y pour le message clé de ce blogpost.

Parler d’entrepôt de données de santé sous-entend une manière de gérer la donnée selon le concept d’ETL (extract-transform-load), selon laquelle on importerait, transformerait et chargerait les données une fois pour toutes et pour tous les usages… Conception archi fausse (sans mauvais jeu de mots). L’écosystème data s’est rendu compte ces dernières années que cela ne correspondait souvent pas à la réalité du terrain, et c’est particulièrement vrai en santé où les usages des données peuvent être très différents, par exemple entre le soin et la recherche clinique.
Illustration Entrepôt de données de santé

Le changement de paradigme “extract-load+transform” : au coeur de l’archi data moderne

Enfin, juridiquement, tel que défini par la CNIL, un entrepôt de données désigne “une base de données comportant des données de santé qui permettra de réaliser ultérieurement plusieurs traitements” (recherche ou évaluation en santé, production d’indicateurs, pilotage stratégique de l’activité). Cette définition concerne donc à la fois des data warehouses et des architectures de données complètes telles que nous venons de les décrire…

Ceci explique donc cela. Il y a un fossé entre les architectures de données modernes et les nombreuses “solutions d’entrepôts de données de santé” disponibles sur le marché, qui sont en fait des logiciels de recherche clinique techniquement adossés à un data warehouse. Si vous avez tout suivi, vous comprendrez que ces solutions correspondent donc en quelque sorte à l’un des blocs d’une architecture de données mais n’en possèdent ni le caractère modulaire, ni les caractéristiques transparentes et collaboratives, ni l’immense potentiel d’usages.

Illustration Entrepôt de données de santé

Un logiciel de recherche clinique adossé à un data warehouse n’est pas une architecture de données moderne.

Lire un autre article

Icône de professionnel de santé

La donnée de santé : un cadre juridique à sa mesure

Icône de professionnel de santé

Les enjeux du cohorting en recherche clinique...

Icône de professionnel de santé

Ce que les modèles de langes comprennent du monde