En résumé
Un schéma apprend à Linkr à lire une base : quelle table contient les patients, laquelle les hospitalisations, où trouver une date de naissance. Il porte deux choses — le DDL, qui décrit les tables, et le mapping, qui leur donne un rôle. C’est lui qui transforme une base interrogeable en SQL en un entrepôt que Linkr comprend.
Le problème que résout un schéma
Deux hôpitaux stockent la même information sous des noms différents. Ici la table des patients s’appelle person et la date de naissance birth_datetime ; là c’est patients et dob. Un troisième a gardé son modèle maison.
Linkr ne devine pas. Sans indication, une base n’est qu’un ensemble de tables : on peut écrire du SQL dessus, rien de plus. Aucune page patient, aucune cohorte, aucune statistique démographique.
Le schéma est cette indication. Il dit : la table des patients, c’est person ; son identifiant, c’est person_id ; la date de naissance, c’est birth_datetime. À partir de là, toutes les fonctionnalités de l’entrepôt savent où regarder — et le même tableau de bord fonctionne sur OMOP à Rennes et sur un modèle maison ailleurs.
Les deux moitiés d’un schéma
Le DDL
La structure : les CREATE TABLE qui décrivent tables, colonnes et clés.
Il sert à deux choses : dessiner le diagramme, et fabriquer une base vide — c’est lui qu’exécute « Nouveau depuis un schéma ». Sans DDL, un schéma reste utilisable, mais il ne peut pas créer de base.
Le mapping
Les rôles : quelle table est celle des patients, des hospitalisations, des notes.
C’est la moitié dont dépendent les pages de Linkr. Un schéma sans mapping ne sert qu’à créer des tables vides ; c’est le mapping qui rend la base lisible.
Les deux sont indépendants. On peut avoir un DDL sans mapping — la structure est connue mais les rôles ne le sont pas — ou l’inverse, pour une base qui existe déjà et qu’on se contente de décrire.
Obtenir un schéma
Quatre chemins, du plus simple au plus long.
Installer depuis le catalogue
Le cas le plus courant. OMOP CDM 5.3 et 5.4, MIMIC-III et MIMIC-IV sont publiés et s’installent en quelques secondes, DDL et mapping compris. Onglet Catalogue de la fenêtre d’import.
Importer un ZIP ou cloner un dépôt git
Pour reprendre le schéma d’un collègue ou d’un autre établissement. Le clonage git demande le mode serveur ; le ZIP fonctionne partout.
Dupliquer un schéma existant
Partir d’OMOP pour décrire votre variante locale. L’original reste intact.
Créer un schéma vierge
Pour un modèle maison qui ne ressemble à rien de publié. Seul le nom est obligatoire ; le DDL et le mapping se remplissent ensuite.
La page d’un schéma
Trois onglets, plus les habituels Readme, Licence et Versioning derrière le menu Plus.
Aperçu
Quatre compteurs — tables, clés étrangères, index, tables mappées — et le readme. Chaque compteur est cliquable et mène à l’onglet correspondant.
Les trois premiers compteurs lisent le texte du DDL
Ils sont obtenus en analysant le DDL, pas en l’exécutant. Un DDL qui déclare une clé primaire à l’intérieur du CREATE TABLE plutôt que par un ALTER TABLE ne sera pas compté, alors qu’il est parfaitement valide. Le compteur est un repère, pas un audit.
DDL
Deux vues, avec un sélecteur en haut à gauche. Cet onglet s’ouvre sur le diagramme.
- Diagramme — les tables en boîtes, les colonnes avec leurs rôles de clé, les relations en traits. On peut déplacer les tables pour arranger la lecture, et la disposition est conservée. Un bouton Filtrer masque les parties qui ne vous intéressent pas.
- Source — l’éditeur de texte, avec un sommaire à gauche qui liste tables, clés et index, et un champ de recherche. Cliquer une entrée fait défiler jusqu’à elle.
Cmd/Ctrl+Senregistre.
Les groupes rassemblent des tables liées sous un nom et une couleur — « Données cliniques », « Vocabulaires ». Ils rendent un modèle comme OMOP, qui compte des dizaines de tables, effectivement lisible. Ils déterminent aussi la disposition automatique du diagramme tant que vous n’en avez pas arrangé une à la main.
Écrivez une colonne par ligne
Le dessin du diagramme découpe le corps d’un CREATE TABLE ligne par ligne. Plusieurs colonnes sur une même ligne, et seule la première apparaîtra — dans le diagramme et dans les compteurs. Le DDL s’exécute correctement malgré tout : seule la représentation est tronquée.
Le DDL doit être écrit en SQL compatible DuckDB : il est réellement exécuté quand on crée une base vide à partir du schéma.
Mapping
C’est ici qu’on donne un rôle aux tables. Même bascule diagramme/source, mais l’onglet s’ouvre cette fois sur la source, où l’édition se fait par formulaires — jamais en JSON brut.
Cinq sous-onglets :
| Sous-onglet | Ce qu’on y déclare | Ce qui en dépend |
|---|---|---|
| Patient | La table patient, les valeurs de genre, la table de décès | Tout. Sans table patient, la page Données patient refuse de s’afficher. |
| Hospitalisation | La table des séjours et celle des séjours en unité | Les critères de cohorte par séjour, les durées, la chronologie des admissions. |
| Notes | La table des comptes rendus | Le widget Notes et les critères de cohorte textuels. |
| Événements | Les tables de mesures, prescriptions, diagnostics… | La page Concepts, les critères de cohorte, la frise du patient. |
| Concepts | Les dictionnaires : tables de libellés et de terminologies | L’affichage des noms au lieu des codes, partout. |
Chaque champ « table » propose en autocomplétion les tables connues du schéma, sans jamais forcer la valeur : un modèle à moitié décrit reste modifiable.
Le dictionnaire d'une table d'événements se choisit explicitement
Chaque table d’événements indique quel dictionnaire traduit ses codes. Laissé vide, c’est le premier dictionnaire qui sert. La valeur none signifie « pas de jointure » — la colonne contient déjà le libellé, comme un champ MIMIC drug qui porte « Vancomycine » et non un identifiant numérique.
Se tromper ici ne produit pas d’erreur : la jointure se fait quand même, entre un nom de médicament et un identifiant, et ne ramène rien. C’est la première chose à vérifier quand une page Concepts reste vide.
Un schéma, plusieurs bases
Une base copie le schéma au moment où on le lui rattache. Elle n’y renvoie pas.
C’est ce qui rend une base robuste : elle continue de fonctionner si le schéma est modifié, supprimé, ou s’il n’a jamais été installé sur l’instance où elle arrive.
Modifier un schéma ne met pas à jour les bases existantes
La correction ne se propage pas. Pour l’appliquer à une base déjà créée, ouvrez Modifier sur cette base et resélectionnez le schéma : la copie est alors refaite.
Symétriquement, supprimer un schéma ne casse aucune base — chacune garde sa copie. Sa carte affiche simplement « Schéma (non installé) » et cesse d’être un lien.
Voir un schéma réel
La démo contient les schémas OMOP et MIMIC. OMOP CDM 5.4 est le plus parlant : des dizaines de tables, regroupées et colorées, avec un mapping complet.
Quelques limites à connaître
- Certains réglages fins n’ont pas de champ dans l’éditeur. Les colonnes de lieu de soins d’une table de séjours, ou les jointures composites terminologie + code de certaines tables d’événements, existent et sont utilisées par Linkr, mais ne se saisissent pas dans l’interface. Ils arrivent par un schéma importé ou installé. Un modèle qui en a besoin se prépare donc hors de l’application, puis s’importe.
- Un nom de table ou de colonne inhabituel est écarté sans message. Les noms sont vérifiés avant d’entrer dans une requête ; ce qui n’est pas un identifiant SQL valide disparaît du mapping au lieu d’être signalé. Si un champ « ne se sauvegarde pas », c’est presque toujours un caractère exotique ou un guillemet.
- Le nom du schéma est enregistré dans la langue de l’interface. Un schéma nommé en français s’affichera en français à un utilisateur anglophone. Rien n’est traduit automatiquement.
- L’identifiant est figé après la création. Le nom, lui, se change quand on veut.
Pour aller plus loin
- Bases de données — rattacher un schéma à une base.
- Concepts — ce que les dictionnaires rendent possible.
- Alignement de concepts — faire correspondre vos codes locaux à une terminologie standard.
- Catalogue communautaire — d’où viennent OMOP et MIMIC.