En résumé
Une sous-base dérivée est la copie d’une base restreinte aux patients d’une cohorte : Linkr copie chacune de ses tables en ne gardant que les lignes de ces patients. Le résultat est une base comme les autres, autonome, qui garde la trace de son origine — la base parente et les critères de la cohorte — et peut donc être reconstruite quand l’entrepôt a changé. La copie s’exécute sur le serveur.
Le besoin
Un entrepôt hospitalier contient tous les patients. Une étude n’en concerne qu’une fraction : un service, une période, une pathologie.
Travailler sur l’entrepôt entier oblige chaque analyse à se souvenir du filtre — il suffit qu’une l’oublie pour produire un chiffre faux. Une sous-base définit le périmètre une fois et le matérialise : tout ce qui l’interroge travaille déjà dans le bon périmètre, avec les mêmes tables et les mêmes noms de colonnes que la base parente. Une requête écrite pour l’une fonctionne sur l’autre.
Ce n'est pas la même chose qu'une cohorte
Une cohorte est une liste de patients, qui sert de filtre aux analyses. Une sous-base est une base complète — les tables de la base parente, restreintes à ces patients —, que l’on interroge, explore et lie aux projets comme n’importe quelle base.
Dériver une base
La dérivation part d’une cohorte de la base elle-même — pas d’une cohorte de projet.
Ouvrir les cohortes de la base
Dans Entrepôt de données › Bases de données, ouvrez la base parente, puis son onglet Cohortes.
Construire la cohorte
Avec le constructeur de critères habituel — voir Cohortes —, au niveau Patient, Hospitalisation ou Séjour en unité.
Cliquer sur Dériver
Le bouton Dériver, dans la barre d’outils du constructeur, ouvre la fenêtre Dériver une base depuis cette cohorte.
Quand le bouton n'est pas là, ou ne dérive rien
- Il n’existe qu’en mode serveur : la copie est écrite par le serveur, dans une base qu’il gère. Voir Modes de déploiement.
- Une cohorte au niveau Événement ne se dérive pas : elle n’a pas d’identifiant unique sur lequel filtrer les tables.
- Le schéma de la base doit dire où sont ses patients — voir Mapper un schéma.
- La cohorte doit être définie par ses critères, pas par un SQL écrit à la main ; un SQL modifié non enregistré désactive le bouton.
La fenêtre Dériver
Dériver une base depuis cette cohorte
Copie toutes les tables de cette base en ne gardant que les lignes de « Choc septique ». La copie est autonome : elle ne lit pas cette base.
Vocabulaire, unités de soins, lieux… copiés en entier, pour que la copie soit interrogeable seule. Un vocabulaire OMOP complet pèse plusieurs Go.
| person | Patients de la cohorte (person_id) |
| observation_period | Patients de la cohorte (person_id) |
| visit_occurrence | Patients de la cohorte (person_id) |
| visit_detail | Patients de la cohorte (person_id) |
| condition_occurrence | Patients de la cohorte (person_id) |
| drug_exposure | Patients de la cohorte (person_id) |
| measurement | Patients de la cohorte (person_id) |
| observation | Patients de la cohorte (person_id) |
| procedure_occurrence | Patients de la cohorte (person_id) |
| death | Patients de la cohorte (person_id) |
| care_site | Copiée en entier |
| concept | Copiée en entier |
| concept_relationship | Copiée en entier |
| location | Copiée en entier |
| vocabulary | Copiée en entier |
- Déjà dérivée vers — les dérivations déjà faites depuis cette cohorte, avec leur date et leur nombre de patients. Reconstruire en refait une avec les critères actuels de la cohorte, et remplace son contenu.
- Dériver vers — une nouvelle base, ou un schéma dans une base existante (voir ci-dessous).
- Copier les tables sans données patient — coché par défaut : vocabulaire, unités de soins, lieux… sont copiés en entier, pour que la copie soit interrogeable seule. Un vocabulaire OMOP complet pèse plusieurs Go ; décoché, ces tables ne sont pas copiées.
- Le plan — ce qui arrivera à chaque table, avant que rien ne s’exécute : filtrée sur les patients, les séjours ou les séjours en unité de la cohorte, copiée en entier, ou non copiée. Une table en rouge est une table que le mapping lit sans colonne d’identifiant patient : ses lignes ne peuvent pas être filtrées, elle n’est donc pas copiée.
Le niveau de la cohorte décide du filtre : chaque table est filtrée sur l’identifiant le plus fin qu’elle porte, sans descendre sous le niveau de la cohorte. Pour une cohorte de séjours en unité, une table qui a un identifiant de séjour en unité garde ceux de la cohorte ; une table qui n’a qu’un identifiant d’hospitalisation garde les hospitalisations qui les contiennent ; une table qui n’a que l’identifiant patient garde les patients.
Deux destinations
Une nouvelle base DuckDB
Les tables filtrées sont écrites dans une base à part.
On lui donne un Nom et un Emplacement — le dossier de données de Linkr, ou un dossier du serveur. Rien n’est écrit dans la base parente : c’est la voie qui marche partout, y compris sur un entrepôt en lecture seule.
Un schéma SQL dans une base existante
Les tables filtrées vivent dans un nouveau schéma d’une base qui accepte l’écriture.
Une base DuckDB créée par Linkr, ou une base PostgreSQL dont les paramètres cochent Autoriser Linkr à écrire dans cette base — l’utilisateur doit y avoir le droit CREATE. On choisit le Nom du schéma SQL (minuscules, chiffres et tirets bas) ; sur PostgreSQL, L’ajouter aussi comme base le fait apparaître dans la liste des bases. Linkr ne modifie jamais les tables existantes.
Dériver lance la copie comme une tâche du serveur, suivie dans le panneau des tâches, en pied de page. Pour une nouvelle base, Linkr l’ouvre aussitôt : elle affiche « En cours de configuration » jusqu’à la fin de la copie, puis se connecte d’elle-même. Sur un gros entrepôt, comptez des minutes.
Ce que devient la sous-base
C’est une base comme les autres : elle apparaît dans la liste des bases, avec ses statistiques, son explorateur de schéma, le mapping de sa base parente, et elle se lie aux projets. Son onglet Aperçu porte en plus une carte Dérivée d’une cohorte.
Dérivée d'une cohorte
La reconstruire à partir des critères enregistrés ici, sur la base dont elle est dérivée.
C’est ce qui permet de répondre, six mois plus tard, à la question qui se pose toujours : qu’y a-t-il exactement là-dedans ?
Reconstruire, sur cette carte, remplace les tables par une nouvelle copie de la base parente, filtrée sur les critères enregistrés lors de la construction — pas sur ceux que la cohorte a peut-être depuis. C’est le geste à faire quand l’entrepôt a été mis à jour. Il faut que la base parente soit dans le même espace de travail, et connectée ; sinon la carte le dit.
Deux « Reconstruire », deux jeux de critères
Depuis la carte de la sous-base, on reconstruit avec les critères figés dans sa provenance : même périmètre, données à jour. Depuis la fenêtre Dériver de la cohorte, on reconstruit avec ses critères actuels : le périmètre suit la cohorte.
Supprimer une sous-base propose de supprimer aussi ce que Linkr a créé pour elle : son fichier, ou le schéma SQL et ses tables. Exportée, elle emporte sa provenance — et, comme toute base, jamais ses données : sur une autre instance, la carte nomme toujours la base parente, mais la reconstruction n’est possible que là où celle-ci existe.
Depuis un assistant IA
Le serveur MCP expose la même fonction : list_database_cohorts liste les cohortes d’une base, plan_cohort_derivation montre le plan table par table sans rien écrire, et derive_database_from_cohort lance la copie. Elle rend la main tout de suite, avec l’identifiant de la tâche, que l’assistant suit ensuite jusqu’à la nouvelle base.
Et en mode navigateur ?
La dérivation n’y existe pas. Deux approches couvrent une partie du besoin : une cohorte, qui définit le périmètre une fois et sert de filtre aux analyses, ou un pipeline ETL, où l’on écrit soi-même les requêtes de filtrage d’une base source vers une base cible.
Pour aller plus loin
- Cohortes — le constructeur de critères dont part la dérivation.
- Bases de données — ce qu’est une sous-base une fois construite, et le droit d’écriture d’une base PostgreSQL.
- Pipelines ETL — pour une transformation que la dérivation ne sait pas faire.