Export

La page est organisée en deux blocs : un filtre en haut décide quels alignements partent à l’export, et une grille de quatre cartes en bas — une par format. Le compteur d’alignements à exporter se met à jour en temps réel quand vous changez le filtre, et chaque carte télécharge sa version au clic.

Filtres de l’export

Statuts à inclure

En haut, une case à cocher par statut effectif, avec à côté le compteur du projet pour ce statut. Cinq lignes dans cet ordre :

• Approuvé — alignements validés par les relecteurs. Cocher cette case fait apparaître trois sous-options qui précisent ce qui compte comme « approuvé » dans le contexte du vote multi-relecteur :

  • Au moins une approbation — le plus permissif. Un seul vote « approuvé » suffit, même s’il y a aussi des rejets sur le même alignement.
  • Plus d’approbations que de rejets — majorité simple. Le compromis raisonnable pour une équipe à plusieurs relecteurs.
  • Aucun rejet — le plus strict. Le moindre vote « rejeté » exclut l’alignement, quel que soit le nombre d’approbations.

  La règle s’applique au concept source : Linkr regroupe tous les avis posés sur l’ensemble des alignements (source, *) pour un même code source, et applique la règle sur le total.

• Rejeté — alignements rejetés par un ou plusieurs relecteurs.

• Signalé — alignements signalés (vote flagged) pour discussion.

• Non vérifié — alignements posés mais qui n’ont reçu aucun vote.

• Ignoré — alignements marqués comme « pas d’équivalent » (target = 0, ou statut ignored).

Par défaut, seul Approuvé est coché, avec la règle « Au moins une approbation » — c’est la sortie la plus courante : l’alignement consolidé, prêt pour la production. Vous pouvez cocher plusieurs statuts pour produire un export plus large (par exemple Approuvé + Signalé pour partage entre relecteurs).

Inclure tous les concepts sources

En bas du filtre, séparée par un trait, une case à cocher indépendante : « Inclure tous les concepts sources ». À côté, un badge indique combien de concepts source seraient ajoutés s’il était activé (ceux qui n’apparaissent dans aucun alignement filtré ci-dessus).

Cette option existe surtout pour l’export STCM destiné à un ETL OMOP. La table source_to_concept_map doit idéalement contenir une ligne par concept source de votre base, y compris ceux qui n’ont pas (encore) de cible standardisée — sinon votre ETL ne pourra pas convertir leur source_concept_id en quoi que ce soit, et perdra l’information à la jointure. En cochant cette case, les concepts non alignés sont ajoutés avec target_concept_id = 0, mais avec leur source_concept_id correctement attribué — c’est précisément ce qui rend l’export exploitable.

À l’usage, l’option adapte le format de chaque export :

• STCM — ajoute les concepts manquants avec target_concept_id = 0.
• SSSOM — ajoute les concepts manquants avec object_id = sssom:NoTermFound (cardinalité 1:0).
• Usagi — ajoute les concepts manquants avec mappingStatus = UNCHECKED, equivalence = UNREVIEWED.

Total à exporter

Tout en bas du filtre, le compteur Total à exporter somme les alignements filtrés et les concepts sources non mappés ajoutés. C’est le nombre de lignes qui partiront dans le fichier exporté.

Les quatre formats

Les cartes de format sont toujours visibles. Le bouton Télécharger de chaque carte est désactivé quand le total à exporter est nul (sauf pour le Linkr ZIP qui reste téléchargeable, voir plus bas).

Linkr ZIP

L’archive complète et ré-importable dans une autre instance Linkr — le format de sauvegarde et de partage entre instances Linkr. Contenu :

• project.json — l’objet projet complet (métadonnées, badges, configuration, hors fichier source brut traité à part).
• mappings.json — tous les alignements au format Linkr interne (voir Évaluation → Structure de mappings.json).
• source-concepts.csv — les concepts sources du projet, toujours sous forme de CSV :
  • pour un projet « fichier », c’est le fichier source brut tel qu’il a été importé ;
  • pour un projet « base de données », c’est le résultat de la requête source matérialisé en CSV — DuckDB exécute la requête définie dans le mapping de schéma du projet, et Linkr écrit les lignes dans le ZIP. Pas de SQL exporté, pas de connexion conservée : juste les données figées au moment de l’export.

Le bouton Linkr ZIP ignore le filtre des statuts : il exporte toujours l’intégralité des alignements du projet, parce que c’est la sauvegarde — vous voulez tout récupérer si vous ré-importez.

SSSOM TSV

SSSOM (Simple Standard for Sharing Ontological Mappings) est le standard d’échange pour les alignements d’ontologies, soutenu par la communauté biomédicale (Monarch Initiative, OBO Foundry, OHDSI…).

En-tête YAML

Le fichier commence par un en-tête de métadonnées au format YAML — chaque ligne préfixée d’un # :

• curie_map — déclare les préfixes utilisés dans le fichier. Un CURIE (Compact URI, convention W3C) est une URI écrite sous forme abrégée préfixe:identifiant_local au lieu de l’URI complète. Le curie_map associe chaque préfixe à sa base d’URI, ce qui permet à un consommateur SSSOM de comprendre que skos:exactMatch veut dire http://www.w3.org/2004/02/skos/core#exactMatch, ou que OHDSI:4353843 veut dire http://ohdsi.org/concept/4353843. Linkr y déclare skos, semapv, sssom et OHDSI.
• mapping_set_id — l’identifiant unique du projet d’alignement Linkr.
• mapping_set_title — le nom lisible du projet.
• mapping_date — la date de l’export, au format YYYY-MM-DD.
• license — la licence du jeu d’alignements. Linkr met CC0 1.0 (Creative Commons Zero, https://creativecommons.org/publicdomain/zero/1.0/) : l’alignement est versé au domaine public, librement réutilisable sans attribution. Vous pouvez modifier cette ligne avant publication si vous voulez une licence différente.

Colonnes du tableau

Vient ensuite un tableau tabulé (TSV) avec ces douze colonnes :

• subject_id — l’identifiant du concept source, sous forme de CURIE (ex. MIMIC-IV:50912).
• subject_label — le libellé du concept source (ex. Creatinine).
• subject_source — le vocabulaire d’origine du concept source (ex. MIMIC-IV).
• predicate_id — l’équivalence SKOS entre source et cible : skos:exactMatch, skos:closeMatch, skos:broadMatch, skos:narrowMatch, skos:relatedMatch. Reprend directement l’équivalence choisie dans Linkr.
• object_id — l’identifiant du concept cible, sous forme de CURIE (ex. OHDSI:3016723). Pour un alignement sans cible (ignored ou target_concept_id = 0), la valeur vaut sssom:NoTermFound — conformément à la spec SSSOM.
• object_label — le libellé du concept cible.
• object_source — le vocabulaire cible (ex. LOINC, SNOMED). Pour un NoTermFound, Linkr met OHDSI par défaut pour indiquer où la recherche a eu lieu.
• mapping_cardinality — la cardinalité de l’alignement. Pour un alignement sans cible, vaut 1:0. Laissée vide sinon (les cardinalités multiples ne sont pas exposées dans Linkr).
• mapping_justification — la justification de l’alignement, au format semapv:* (vocabulaire SEMAPV). Linkr met semapv:ManualMappingCuration pour les alignements revus (approuvés, signalés, rejetés, ignorés) et semapv:UnspecifiedMatching pour les non revus.
• confidence — le score de match (entre 0 et 1) hérité du pré-classement, si disponible.
• author_id — l’auteur de l’alignement dans Linkr (ou la méthode automatique : Syntactic, BioLORD, Claude Sonnet…).
• comment — les commentaires associés à l’alignement, concaténés par |.

C’est le bon choix pour partager publiquement un alignement ou contribuer à un projet inter-établissements.

OMOP STCM CSV

Le format OMOP CDM pour la table source_to_concept_map, directement importable dans un ETL OHDSI. Une ligne par couple (source, cible). Les neuf colonnes (source_code, source_concept_id, source_vocabulary_id, source_code_description, target_concept_id, target_vocabulary_id, valid_start_date, valid_end_date, invalid_reason) sont décrites dans la référence de la table.

Linkr fixe valid_start_date à 1970-01-01 et valid_end_date à 2099-12-31 (validité totale) ; invalid_reason est laissé vide.

Usagi CSV

Format compatible avec Usagi, l’outil OHDSI historique pour l’alignement de concepts. Le fichier reprend les dix-sept colonnes du WriteCodeMappingsToFile d’Usagi :

• sourceCode — le code du concept source.
• sourceName — son libellé.
• sourceFrequency — la fréquence observée du concept dans la source (nombre d’enregistrements), si elle a été renseignée.
• sourceAutoAssignedConceptIds — l’identifiant source_concept_id natif (s’il existe), sinon 0.
• matchScore — le score de match (0 à 1) hérité du pré-classement, si disponible.
• mappingStatus — le statut Usagi (voir mapping ci-dessous).
• equivalence — le degré d’équivalence Usagi (voir mapping ci-dessous).
• statusSetBy — l’auteur du statut courant.
• statusSetOn — la date du statut courant, en timestamp Unix en millisecondes.
• conceptId — l’identifiant OMOP du concept cible (0 si aucune cible).
• conceptName — le libellé du concept cible.
• domainId — le domaine OMOP du concept cible (Measurement, Condition, Drug…).
• mappingType — le type d’alignement Linkr, mis en majuscules.
• comment — les commentaires associés à l’alignement, concaténés par |.
• createdBy — l’auteur de l’alignement.
• createdOn — la date de création, en timestamp Unix en millisecondes.
• assignedReviewer — le relecteur explicitement assigné à l’alignement, le cas échéant.

Correspondance des statuts (Linkr → Usagi)

Correspondance des équivalences SKOS (Linkr → Usagi)

Utile si vous travaillez en allers-retours avec une équipe qui utilise Usagi, ou pour déposer un alignement dans un dépôt OHDSI standard.

Intégration ETL

Une fois le source_to_concept_map.csv exporté, vous pouvez l’injecter dans le pipeline ETL de votre warehouse Linkr :

1. Dans Entrepôt de données → ETL → Vocabulaire, importez le fichier STCM.
2. Linkr génère un script SQL 00_vocabulary.sql qui peuple la table source_to_concept_map de votre base OMOP cible.
3. Ce script s’intègre au reste de votre pipeline ETL (transformation des données patients, etc.).

L’alignement de concepts devient ainsi le pivot entre vos données brutes et un entrepôt OMOP exploitable. Pour un export consolidé à l’échelle de plusieurs projets — typiquement tout un hôpital — passez plutôt par la Vue d’ensemble, qui déduplique les alignements identiques entre projets et attribue les source_concept_id sans collisions.