En résumé
Dans un projet, les données traversent trois espaces successifs. L’entrepôt contient les données brutes au format long (une ligne par événement), en lecture seule. Le pipeline les transforme au format large (une ligne par patient) sans jamais modifier la source. Le laboratoire accueille ces données prêtes à l’analyse : datasets, analyses statistiques et tableaux de bord.
Trois espaces, un sens de circulation
Un projet Linkr est organisé selon le chemin naturel des données : de la donnée brute de l’entrepôt jusqu’au résultat restitué. On distingue trois espaces, que l’on retrouve dans la navigation d’un projet.
1 · Entrepôt
Données brutes, format long
- Une ligne par événement clinique.
- Lecture seule — la source n’est jamais modifiée.
- On y explore les concepts, on construit des cohortes, on contrôle la qualité.
2 · Pipeline
Transformations, long → large
- Un graphe d’étapes qui prépare les données.
- Passe du format long au format large.
- Chaque étape produit un nouveau jeu de données.
3 · Laboratoire
Analyses, format large
- Une ligne par patient.
- Datasets, analyses intégrées, tableaux de bord.
- IDE Python / R pour le code sur-mesure.
Format long, format large : de quoi parle-t-on ?
Une base clinique (OMOP par exemple) est au format long : une ligne par événement — une mesure, un diagnostic, une prescription. C’est idéal pour stocker, mais pas pour analyser. Les cliniciens et statisticiens raisonnent au format large : une ligne par patient, une colonne par variable (âge, dernière créatinine, pression artérielle moyenne…). Tout l’enjeu du pipeline est de passer du long au large. Pour approfondir, voir la ressource Organisation des données.
L’entrepôt : explorer sans rien casser
L’entrepôt (data warehouse) est le point d’entrée des données cliniques. On y branche une ou plusieurs bases — une extraction OMOP, un jeu de démonstration, un export hospitalier. Ces bases sont toujours en lecture seule : Linkr ne réécrit jamais la donnée source.
À ce niveau, sans écrire de code, vous pouvez :
- Parcourir les concepts présents dans la base, par catégorie (diagnostics, médicaments, mesures…), avec leurs statistiques.
- Construire des cohortes en empilant des critères (âge, sexe, concepts, période, durée de séjour) dans une arborescence logique — Linkr génère le SQL correspondant.
- Contrôler la qualité des données : complétude, distributions, règles de validation.
Pour que ces outils sachent lire une base, il faut lui associer un schéma : un preset (OMOP CDM, MIMIC…) ou une définition sur-mesure, qui indique à Linkr quelle table contient les patients, les séjours, les mesures, etc. C’est le schéma qui rend l’entrepôt « intelligent » : il apprend à Linkr comment est structurée cette base précise.
Aligner le vocabulaire local sur des standards
Avant d’analyser, on a souvent besoin de traduire les codes propres à un établissement vers des vocabulaires standards (SNOMED, LOINC, RxNorm). Cette étape, l’alignement de concepts, a sa propre section : Alignement de concepts.
Le pipeline : préparer les données pour l’analyse
Entre l’entrepôt (format long) et le laboratoire (format large) s’intercale le pipeline : un enchaînement d’étapes qui transforment les données. Linkr suit ici le principe des outils de data preparation : la source n’est jamais modifiée, et chaque transformation produit un nouveau jeu de données en sortie. On garde ainsi la traçabilité de bout en bout — on peut toujours remonter à la donnée d’origine.
Un pipeline se représente comme un graphe : une base en entrée, une cohorte qui restreint la population, une ou plusieurs étapes de transformation, et un dataset en sortie.
Le pipeline visuel est en cours de finalisation
Le canvas graphique du pipeline existe déjà, mais son moteur d’exécution n’est pas encore entièrement branché. Aujourd’hui, le passage du format long au format large se fait concrètement dans l’IDE intégré (un script Python ou R sur le jeu de données) plutôt que par le graphe. C’est justement là que Linkr crée le lien entre les deux mondes : le clinicien prépare la cohorte avec les outils low-code, le data scientist écrit la transformation dans le même projet. Voir Votre premier projet.
Deux entrées vers un dataset
On n’est pas obligé de partir de l’entrepôt. Un dataset analytique peut naître de deux façons :
Depuis l’entrepôt
Base → cohorte → transformation → dataset. C’est le chemin complet, quand on part de données cliniques au format long.
Par import direct
Un fichier déjà au format large (CSV, Excel, Parquet) chargé directement dans le laboratoire, sans passer par l’entrepôt.
Le laboratoire : analyser et restituer
Le laboratoire est l’espace des données prêtes à l’analyse, au format large. C’est là que le travail devient visible : on décrit une population, on compare des groupes, on suit un indicateur.
Le laboratoire réunit trois briques :
- Les datasets — les jeux de données au format large (une ligne par patient), avec leurs colonnes et leurs statistiques descriptives.
- Les analyses intégrées — Table 1, Key Indicator, Plot Builder : des analyses prêtes à l’emploi, sans code.
- Les tableaux de bord — l’assemblage de widgets pour explorer et restituer. Voir la section Tableaux de bord.
Pour les besoins qui débordent des outils graphiques, l’IDE intégré (Python, R, SQL) permet d’écrire ses propres analyses directement sur le dataset.
Analyser avec des plugins
Les analyses et widgets intégrés couvrent les cas courants, mais pas tous. Un plugin est une brique d’analyse réutilisable que l’on branche là où on en a besoin dans le laboratoire :
- comme widget dans un tableau de bord,
- comme analyse sur un dataset.
Un plugin peut être un simple composant graphique configurable, ou embarquer du code Python / R exécuté sur les données. Linkr fournit un catalogue de plugins d’analyse prêts à l’emploi — Table 1, Plot Builder, Kaplan-Meier, régression, matrice de corrélation, diagramme de Sankey, tests statistiques, carte… — et un éditeur pour créer les vôtres.
C’est ici que se referme la boucle avec l’espace de travail : un plugin est partagé au niveau de l’espace de travail, donc réutilisable dans tous ses projets. Un widget d’analyse mis au point pour une étude sert directement à la suivante.
Créer ses propres plugins
La conception d’un plugin — structure, exécution Python/R, publication — sera traitée à part, dans la section Plus → Créer un plugin (à venir). Leur usage dans les tableaux de bord est détaillé dans Widgets intégrés et Code R, Python et SQL.
Client-only ou full-stack ?
Tout ce parcours — import de fichiers, schémas, cohortes, datasets, analyses, plugins — fonctionne intégralement en mode client-only, dans le navigateur, sur des fichiers locaux ou des extractions. Se connecter directement à un entrepôt hospitalier en base relationnelle (PostgreSQL, SQL Server, Oracle…) pour interroger la donnée à la source relève du mode full-stack, en cours de développement. Voir Modes de déploiement.
Pour aller plus loin
- Votre premier projet — parcourir entrepôt, cohorte, dataset et tableau de bord en pratique.
- Alignement de concepts — traduire les codes locaux vers des vocabulaires standards.
- Tableaux de bord — composer des vues à partir de widgets.