Aller au contenu

Pont terminologique & émission (Mondo→SNOMED)

En une phrase : Messier résout d’abord vers Mondo (le pivot maladie), puis émet un code d’interopérabilité — idéalement SNOMED CT — via un pont à plusieurs routes, sous une politique d’émission qui sait s’abstenir plutôt que produire un code faux.

C’est le cœur intellectuel de Messier : la qualité finale ne dépend pas tant du linker que de ce qui se passe entre Mondo et SNOMED. Cet article explique le problème (le trou-pivot), la politique d’émission, les routes du pont, et la discipline de licence qui les contraint.


1. Pourquoi un pont (et pas un linker SNOMED direct) ?

Section intitulée « 1. Pourquoi un pont (et pas un linker SNOMED direct) ? »

Messier résout vers Mondo parce que Mondo est CC0 (redistribuable), riche en synonymes et en cross-references (xrefs) vers les autres terminologies, et pivot naturel entre vocabulaires. Mais les biobanques et SPHN attendent du SNOMED CT. Il faut donc un pont de sortie Mondo→SNOMED.

2. Le trou-pivot : une limite structurelle, pas un bug

Section intitulée « 2. Le trou-pivot : une limite structurelle, pas un bug »

Mesuré de bout en bout (gold DisTEMIST, linker réel, pondéré par fréquence) :

MesureValeur
Couverture rencontrée (mentions qui peuvent aboutir)~95 %
Justesse end-to-end~42 % exact / 57 % en tolérant la granularité
Disease-only (gold disorder, 88 % du gold)44,8 % / 61 %
Part des échecs imputable au trou-pivot~85 % (disease-only ~56 %)

Le diagnostic est net : le pont n’est pas le levier (couverture rencontrée OK, ~0 erreur propre de pont). Le plafond vient du pivot Mondo lui-même : Mondo (~26 700 concepts) est plus grossier que les disorders SNOMED (~100 000). Beaucoup de maladies fines n’ont pas de pivot Mondo à la bonne granularité — router via Mondo plafonne donc la justesse exacte, quelle que soit la qualité du pont.

Conséquence produit : une exigence de granularité doit être posée au CHU partenaire pilote — SCTID niveau maladie (granularité Mondo, atteignable) vs SCTID clinique exact (nécessiterait un linker SNOMED-direct, piste O3). Voir Décisions d’architecture (ADR).

3. La politique d’émission : précédence + abstention

Section intitulée « 3. La politique d’émission : précédence + abstention »

Émettre aveuglément le « meilleur » code donne 33–39 % de codes faux (la précision plafonne à ~41–47 % quel que soit le palier). D’où une politique déterministe : on n’émet un code automatique que sur ancre confiante, sinon on dégrade vers un statut qui demande une confirmation humaine — ou on s’abstient (uncoded).

Précédence (du plus fiable au moins fiable) :

exact > confirmed > candidate > approximate > ncit > uncoded

  • exact : la route directe Mondo→SNOMED (xref exactMatch) sur une ancre que le linker juge sûre. ~85 % de précision → seul palier auto-émis sans humain.
  • candidate : code SNOMED atteint via UMLS — laissé PENDING ; la cardinalité est un signal de confiance (1 SCTID = candidat fort ; plusieurs = choix humain).
  • ncit : si SNOMED est absent pour ce concept, on émet un code NCIt (CC0) plutôt que rien — code d’interop alternatif, jamais un SNOMED douteux.
  • uncoded : assumer l’absence de code fiable est préférable à un faux.

Trois routes mènent à un code, de tiers de licence différents — ce qui détermine ce qui est redistribuable (voir Modèle de licence (open-core)).

  • 🟢 Directe (CC0) — les xrefs SNOMED sont dans mondo.json (CC0) : l’identifiant est redistribuable. Source de l’exact/approximate.
  • 🔴 UMLS (licenciée) — atteint des SCTID via les CUI + intermédiaires (OMIM/Orphanet/MeSH/NCIt/MedDRA/ICD10CM) dans MRCONSO. La carte de candidats est un artefact dérivé licencié : BYO, gitignorée, jamais redistribuée. Source du candidate.
  • 🟢 NCIt (CC0) — xref NCIt de mondo.json : repli quand SNOMED manque.

5. Confirmation des candidats (write-path voie 1.5)

Section intitulée « 5. Confirmation des candidats (write-path voie 1.5) »

Un code candidate (UMLS) n’est jamais émis tel quel : le curateur le confirme dans l’IDE. À l’acceptation, le SCTID choisi est validé contre les codes offerts (sinon 422), puis le snapshot passe confirmed. Marche en curation standard et onco. Voir Produit de curation (UX).

6. Libellés SNOMED : lus à la volée, jamais persistés

Section intitulée « 6. Libellés SNOMED : lus à la volée, jamais persistés »

Le snapshot d’émission ne stocke que des identifiants (SCTID + qualification + provenance) — aucun libellé (contenu licencié). Pour l’affichage, les libellés SNOMED sont hydratés à la lecture depuis un index licencié (BYO), avec la mention légale (clause 8.3). En base, le snapshot reste label-free. C’est l’invariant identifiant vs contenu en pratique.

  • Émission par précédence + abstention (notes/49) — un faux code coûte plus qu’un trou.
  • Voie 1 (CC0) vs 1.5 (UMLS licenciée) (notes/50) — séparation par tier de licence.
  • Repli NCIt CC0 (notes/53/historique) — préférer un code d’interop alternatif au silence.
  • Exigence de granularité au pilote (ouverte) — maladie vs clinique exact (piste O3).

→ Fiches dans Décisions d’architecture (ADR).