Vue d'ensemble

Pourquoi cette vue ?

Découper le travail d’alignement en plusieurs projets est souvent la meilleure approche : un projet par catégorie (Conditions, Drugs, Measurements…), un par source (laboratoire, prescription, dossier patient…), ou un par étude. Mais une fois ce travail réparti, on a besoin de recoller les morceaux — c’est ce que fait la Vue d’ensemble.

Deux scénarios typiques

Un seul hôpital, plusieurs projets

Vous découpez l’alignement de votre hôpital en plusieurs projets pour mieux organiser le travail (par exemple un projet « Biologie », un projet « Médicaments », un projet « Diagnostics »). Les projets peuvent se recouvrir : le même concept source apparaît parfois dans plusieurs fichiers, et donc dans plusieurs projets.

La Vue d’ensemble permet de :

• voir d’un coup d’œil où en est l’alignement, tous projets confondus ;
• regrouper les alignements par badge (le badge de l’hôpital) — Linkr déduplique alors automatiquement les alignements identiques (code source, concept cible) qui apparaissent dans plusieurs projets, en indiquant le nombre de projets dans lesquels ils existent ;
• générer un export source_to_concept_map consolidé sans avoir à concaténer les exports projet par projet.

Quand vient le moment de produire l’ETL, vous regroupez par le badge de l’hôpital, vous attribuez les source_concept_id sur l’ensemble (voir plus bas), et vous exportez un seul fichier source_to_concept_map qui contient tout le travail d’alignement réalisé pour cet hôpital.

Plusieurs hôpitaux, un workspace partagé

Plusieurs établissements contribuent au même workspace, chacun avec son propre badge (Hôpital A, Hôpital B…). Chaque hôpital travaille de son côté, dans ses propres projets.

L’enjeu spécifique ici concerne les source_concept_id : si chaque hôpital les attribue indépendamment (par exemple dans des workspaces séparés), vous risquez des collisions au moment de centraliser les données — deux hôpitaux utilisant le même ID OMOP custom pour deux concepts différents. La Vue d’ensemble centralise l’attribution : chaque badge (chaque hôpital) reçoit sa propre plage d’IDs disjointe des autres.

Pour le reste, vous bénéficiez aussi des fonctionnalités du scénario précédent : tableau consolidé de tous les alignements, filtrable par badge, et exportable en un seul source_to_concept_map couvrant l’ensemble des hôpitaux.

Le registre des Source Concept IDs

Un source_concept_id est l’identifiant numérique qu’OMOP attend dans la table source_to_concept_map pour chaque concept source. Si votre fichier d’origine ne contient pas cet identifiant (cas typique d’un CSV avec juste un libellé et un code), Linkr peut en attribuer un automatiquement dans la plage OMOP custom (2 000 000 001 à 2 147 483 647).

Un exemple concret

Imaginons un workspace partagé qui mélange les deux scénarios ci-dessus. Trois projets coexistent :

• Hôpital A découpe son alignement en deux projets, par catégorie : un pour la biologie (d_labitems.csv), un pour les médicaments (d_drugitems.csv). Les deux portent le badge Hôpital A.
• Hôpital B a fait l’alignement de toute sa terminologie locale en un seul projet, terminé. Il porte le badge Hôpital B.

Pour préparer l’export, vous attribuez une plage différente à chaque badge — typiquement une plage par hôpital. Linkr propose la prochaine plage libre dans l’espace OMOP custom, que vous pouvez accepter ou ajuster :

Côté Hôpital A, les concepts source qui apparaissent dans les deux projets (biologie et médicaments) reçoivent un unique source_concept_id — pris dans la plage 2 000 000 001 – 2 001 000 000. Pas de doublon, même si on ré-aligne plus tard un projet « Diagnostics » qui partage des concepts avec les deux premiers.

Côté Hôpital B, les IDs sont attribués dans la plage suivante (2 001 000 001 – 2 002 000 000), totalement disjointe de celle de l’Hôpital A. Les deux jeux de données peuvent donc être centralisés plus tard sans aucun risque de collision sur les source_concept_id.

Comment ça marche

Le registre fonctionne par badge :

• Chaque badge se voit attribuer un sous-intervalle d’IDs (par défaut 1 000 000 d’IDs).
• À l’intérieur d’un badge, le même (vocabulaire, code) obtient toujours le même source_concept_id, peu importe le projet où il apparaît — c’est ce qui permet de dédupliquer entre projets de l’hôpital.
• Entre badges, les plages sont disjointes — pas de collision possible quand on centralise des données venant de plusieurs hôpitaux.

Cliquez sur Attribuer les IDs sur la ligne d’un badge après avoir terminé un alignement. Le registre est peuplé, puis ré-exportez votre STCM pour obtenir des source_concept_id non nuls.

Autres onglets

La Vue d’ensemble est organisée en quatre onglets. IDs source est détaillé ci-dessus ; voici les trois autres :

Résumé

KPI agrégés (concepts source, alignés, approuvés, à revoir, ignorés) sur l’ensemble des projets, et barres empilées comparant l’avancement entre projets ou regroupés par badge. C’est la vue qui répond à « où en est le workspace globalement ? ».

Tableau

Tableau plat de l’ensemble des alignements du workspace, avec filtres par projet, badge, vocabulaire et statut. C’est la vue qui permet d’inspecter ligne par ligne, de visualiser les recouvrements entre projets, et de retrouver rapidement un alignement particulier.

Export

Mêmes formats que sur l’onglet Export d’un projet individuel, mais appliqués à l’ensemble du workspace. Pratique pour produire un fichier ETL unique couvrant tous les projets d’un hôpital — ou de plusieurs hôpitaux quand on consolide.