En résumé
Un pipeline ETL remplit une base cible à partir d’une base source, avec des scripts SQL. Les scripts ne nomment jamais les bases directement : ils écrivent source. et target., que Linkr remplace à l’exécution. C’est ce qui permet de reprendre le pipeline de conversion OMOP d’un autre établissement et de le faire tourner sur vos propres bases.
Le seul endroit qui écrit
Partout ailleurs, Linkr lit. Les bases sont attachées en lecture seule, les widgets et les scripts d’analyse ne peuvent rien modifier.
Un pipeline ETL est l’exception, et elle est étroite : seule la base cible est ouverte en écriture, et seulement pendant l’exécution. La source et le vocabulaire restent en lecture seule dans la même connexion, si bien qu’un script peut lire l’une et écrire l’autre — INSERT INTO target.person SELECT … FROM source.patients — sans jamais pouvoir modifier ce qu’il lit.
À ne pas confondre avec le pipeline d'un projet
Un pipeline ETL vit dans l’entrepôt et va d’une base à une base : c’est là qu’on convertit un modèle source vers OMOP.
Le pipeline d’un projet part de l’entrepôt et produit des jeux de données pour l’analyse — du format long vers le format large. Le premier construit l’entrepôt, le second l’exploite.
Les trois rôles
Un pipeline connaît ses bases par leur rôle, jamais par leur nom.
source. — d’où viennent les données
Votre base métier : l’export du dossier patient, les tables d’un logiciel de réanimation. En lecture seule.
target. — où elles vont
Typiquement une base OMOP vide, créée depuis un schéma avec Nouveau depuis un schéma. La seule ouverte en écriture.
vocab. — la terminologie de référence
Le vocabulaire ATHENA d’un projet d’alignement, pour traduire vos codes locaux en concepts standard. Facultatif, en lecture seule.
INSERT INTO target.person (person_id, gender_concept_id, year_of_birth)
SELECT p.id, v.target_concept_id, EXTRACT(year FROM p.birth_date)
FROM source.patients p
LEFT JOIN vocab.concept_relationship v ON v.source_code = p.sex_codeN'écrivez jamais le nom réel d'une base dans un script ETL
C’est la règle la plus importante de cette page. Le nom technique d’une base contient un identifiant propre à votre instance : un script qui le code en dur cesse de fonctionner dès qu’il est exporté ailleurs, où cet identifiant n’existe pas.
Les rôles survivent au voyage. Celui qui importe votre pipeline resélectionne ses deux bases dans les menus déroulants, et tous les scripts fonctionnent — sans qu’une seule ligne de SQL soit modifiée.
La substitution est faite au moment d’exécuter, pas au moment d’enregistrer : ce qui part dans git reste portable. Elle est aussi prudente — un source. à l’intérieur d’une chaîne de caractères, d’un commentaire ou d’un identifiant plus long n’est pas touché.
Les onglets
| Onglet | Ce qu’on y fait |
|---|---|
| Pipeline | Le tableau de bord d’exécution : les scripts en cartes, dans l’ordre où ils s’enchaînent. C’est ici qu’on choisit les bases source et cible, qu’on réordonne, qu’on active ou désactive une étape et qu’on lance. |
| Scripts | L’éditeur SQL proprement dit, avec le résultat des requêtes. |
| Explorer les schémas | Voir côte à côte les tables de la source et celles de la cible — indispensable quand on écrit la correspondance. |
| Vocabulaire | Générer les scripts de traduction depuis un projet d’alignement de concepts. |
| Contrôle qualité | Vérifier ce que l’exécution a produit : les effectifs des deux bases, et le détail concept par concept de ce qui a été aligné. |
S’y ajoutent Aperçu, Readme, Licence et Versioning, comme pour les autres entités.
Le vocabulaire, sans le réécrire à la main
C’est la partie qui fait gagner le plus de temps, et la moins évidente à deviner.
Aligner des codes locaux sur des concepts standard se fait dans un projet d’alignement de concepts — une interface faite pour ça, avec suggestions et évaluation. L’onglet Vocabulaire d’un pipeline sait lire ce travail et le transformer en SQL.
On choisit le projet d’alignement, on choisit la forme voulue — CONCEPT + CONCEPT_RELATIONSHIP, la représentation OMOP actuelle, ou SOURCE_TO_CONCEPT_MAP, ou les deux — et Linkr écrit les scripts qui chargent ces correspondances dans la base cible.
Le projet d'alignement doit avoir son vocabulaire de référence
Sans base de vocabulaire ATHENA importée dans l’onglet Concepts cibles du projet d’alignement, il n’y a rien à traduire. Voir Concepts cibles.
Linkr signale si un script généré a été modifié à la main depuis, ou s’il est déjà à jour — pour éviter d’écraser un ajustement sans s’en apercevoir.
Exécuter, et vérifier
On exécute un script isolé pendant la mise au point, ou toute la chaîne dans l’ordre. La progression s’affiche requête par requête, avec le nom du script en cours et le temps écoulé — sur un script de vocabulaire dont une seule instruction peut durer plusieurs minutes, c’est ce qui distingue un traitement qui avance d’un blocage.
Une exécution qui échoue s’arrête au premier script en erreur, et Linkr ouvre directement le panneau de détail sur le script fautif.
Mettre en pause et arrêter ne sont pas la même chose
Pause suspend l’exécution sans la terminer : la reprise repart du script interrompu, dans la même exécution.
Arrêter y met fin. Dans les deux cas, l’instruction déjà envoyée à la base va jusqu’au bout — une partie du script a donc pu être appliquée. Sur une base cible à moitié remplie, mieux vaut la recréer à vide plutôt que relancer par-dessus.
Ensuite vient l’onglet Contrôle qualité, qui répond à la seule question qui compte : la conversion a-t-elle perdu quelque chose ? Il propose deux vues.
Statistiques met les deux bases côte à côte : patients, hospitalisations, séjours en unité, répartition par sexe, durées de séjour, et le nombre de lignes de chaque table. Un écart inattendu — trois mille patients d’un côté, deux mille huit cents de l’autre — signale une jointure qui a éliminé des lignes en silence.
Concepts est plus fin, et fonctionne autrement qu’on ne l’imagine : les deux colonnes sont lues dans la base cible. Une base source dans son format d’origine n’a pas de colonnes comparables ; en revanche, une fois convertie en OMOP, chaque table porte à la fois le concept d’origine et le concept standard auquel il a été aligné. Comparer les deux dit exactement combien de lignes sont arrivées avec un code source, et combien ont effectivement trouvé une correspondance.
Chaque concept reçoit un verdict — Absent, Moins, Plus ou OK — utilisable comme filtre, et le tout s’exporte en CSV. « Absent » est celui qu’on regarde en premier : des lignes sont arrivées, aucune n’a été alignée.
La colonne « Lignes attendues » n'est pas redondante
Quand plusieurs codes source pointent vers le même concept cible, le nombre de lignes d’un code pris isolément ne correspond pas au total attendu. La colonne affiche donc la somme de tous les codes qui alimentent ce concept — sans quoi un verdict « OK » à côté de deux nombres différents ressemblerait à un bug.
Les comptages patients demandent un schéma des deux côtés
Sans mapping de schéma sur une base, Linkr ne sait pas ce qu’est un patient : il ne peut compter que des lignes par table. Voir Schémas.
Partager un pipeline
Un pipeline s’exporte, se versionne et se publie comme les autres entités — et c’est là que les rôles prennent tout leur sens.
Ce qui voyage, ce sont les scripts, jamais les données. Un établissement qui a converti son modèle local vers OMOP peut publier ce travail ; un autre l’installe, rebranche ses deux bases, et lance. C’est probablement la forme la plus directement réutilisable de tout Linkr : une conversion OMOP représente des mois de travail, et elle se transmet en un export.
Les fichiers de données sont exclus du versioning par défaut
Un pipeline manipule parfois des fichiers auxiliaires — tables de correspondance, référentiels. Ils sont ignorés par git par défaut, et se réintègrent un par un, explicitement. La règle par défaut est que la donnée ne part pas ; l’inclure est une décision consciente, prise fichier par fichier.
Pour aller plus loin
- Bases de données — créer la base cible vide depuis un schéma.
- Alignement de concepts — produire les correspondances que le vocabulaire consomme.
- Qualité des données — contrôler la base cible une fois remplie.
- Pipeline d’un projet — l’autre pipeline, celui qui produit des jeux de données.