Navigation des données de Terminology FHIR : observations et défis

Introduction

Lorsque nous avons entrepris de créer une solution de Terminology pour Aidbox et commencé à travailler sur le projet Babylon, nous avons décidé d'examiner de plus près l'état des données de Terminology au sein de la communauté FHIR. Nous nous sommes concentrés sur le registre IG FHIR, qui offre un ensemble de données complet. Ce faisant, nous avons cherché à cerner les problèmes les plus pressants, les défis et les cas d'utilisation que nous étions susceptibles de rencontrer. Cet article présente nos conclusions, notamment des observations générales, des problèmes de qualité des données, des patterns spécifiques observés dans l'ensemble de données, ainsi que les défis rencontrés lors de la mise en œuvre.

Comme source de données, nous avons utilisé le serveur de paquets FHIR [1]. Nous avons téléchargé tous les paquets disponibles, extrait les ressources liées à la Terminology [2], puis les avons chargées dans une base de données Postgres. À des fins de visualisation, nous avons créé des tableaux de bord Grafana, inclus en annexe. Cette analyse a été réalisée le 14 juin 2024.

Observations

Quelques chiffres

Nous avons téléchargé 2 357 paquets différents depuis le registre, représentant 468 noms de paquets uniques et leurs versions. Comme l'illustre la figure 1 (notez que nous utilisons une échelle logarithmique), le paquet comptant le plus grand nombre de ressources de Terminology était, de loin, us.nlm.vsac, composé majoritairement de ValueSets, suivi de hl7.terminology.* et hl7.fhir.**. Fig 1. Les 20 premiers paquets par ressource (échelle logarithmique) * Après le chargement des ressources, nous avons trouvé 75,8 k ressources CodeSystem, comprenant 6,36 k URL canoniques uniques. À partir de celles-ci, nous avons pu extraire 15 millions de concepts individuels, dont 3,89 millions sont uniques [3]. De plus, nous avons chargé 454 k ressources ValueSet, dont 33,7 k sont uniques.

La plupart des ressources n'ont pas de nom d'éditeur ; parmi celles qui en ont un, HL7 est le principal éditeur, bien que la dénomination ne soit pas toujours cohérente (voir figure 2). Fig 2. Les 20 premiers éditeurs En analysant la publication de nouvelles ressources au fil des années [4] (figure 3), nous remarquons une pointe de nouvelles ressources en 2014, ce qui coïncide avec DSTU 1. Fig 3. Ressources au fil des années En observant les principaux éditeurs dans le temps (figure 4) Fig 4. Part des principaux éditeurs au fil des années

Problèmes de qualité des données

Notre analyse des données de Terminology FHIR a révélé plusieurs problèmes de qualité des données susceptibles de nuire à la facilité d'utilisation et à la fiabilité de ces ressources. Ces problèmes compliquent la tâche des implémenteurs qui souhaitent prendre en charge de manière fiable des opérations telles que la validation, la recherche, l'expansion, etc. Nous décrivons ci-dessous certains des principaux problèmes rencontrés.

Ressources invalides

L'un des défis que nous avons rencontrés lors du chargement des ressources est que celles-ci ne se conformaient parfois pas à la spécification de base FHIR, par exemple en raison de champs obligatoires manquants, de types de données invalides et de violations de contraintes. Certains de ces problèmes sont corrigés dans les versions ultérieures des paquets, mais d'autres demeurent invalides dans les dernières versions. Dans certains cas, ces problèmes rendent pratiquement impossible le chargement complet des données, car il ne semble pas exister de stratégie ou de solution de contournement pour gérer ces ressources. Dans certains cas extrêmes, nous n'obtenons qu'une liste de concepts, rien de plus ; dans d'autres, comme pour les codes nuls, il n'existe tout simplement pas de valeur de substitution [5].

Nous avons également remarqué une autre catégorie de problèmes. Bien que ceux-ci ne rendent pas une ressource invalide ou non conforme aux contraintes, ils posent tout de même un problème du point de vue de l'implémentation. Plus précisément, nous avons trouvé des systèmes de codes avec des URL malformées. Heureusement, dans la dernière version des paquets, il n'en reste plus qu'un seul [6].

Doublons et conflits

Parfois, la même ressource est publiée dans différentes versions d'un même paquet. Dans d'autres cas, la ressource est transférée vers un paquet différent, mais la version reste la même. Ces scénarios ne devraient pas poser de problème tant que la ressource reste identique, mais ce n'est pas toujours le cas, surtout lorsque les modifications sont conflictuelles [7].

Les types de conflits les plus problématiques apparaissent dans les concepts, car ils représentent le contenu réel du système de codes. Il arrive souvent que nous chargions deux concepts provenant du même système de codes logique (même url et version), qu'ils aient un code correspondant, mais que leur display, definition ou property ne concordent pas.

Une stratégie possible consiste à toujours faire confiance aux modifications les plus récentes, mais cela ne fonctionne pas toujours. Par exemple, en examinant eng.fhir.profile.dev, de la version 0.0.4-beta à 0.0.7-beta, l'un des affichages a été modifié comme suit :

• Oscuramento del oscuramento

• Oscuramento del documento

Il semble que ce soit une régression introduisant une faute typographique préalablement corrigée.

Il est fréquent de trouver des systèmes de codes conflictuels où les concepts dont les propriétés diffèrent ne représentent pas véritablement des conflits de contenu, mais plutôt des conflits de présentation (c'est-à-dire que la sémantique est préservée, mais la syntaxe change). Voici quelques-uns des cas les plus courants :

• changement de type de données, p. ex. valueString vers valueCode.
• changement de locale/configuration, p. ex. valueDateTime: "2009-08-20" vers valueDateTime: "2009-08-20T00:00:00-04:00" Parfois, un CodeSystem peut avoir deux concepts avec le même code, violant ainsi csd-1. Ce serait une simple erreur de données s'il s'agissait uniquement d'une duplication, mais ces codes pourraient représenter des concepts sémantiquement différents, ce qui aggrave considérablement le problème.

Conflits sémantiques : ISO-3166 (codes de pays)

Un CodeSystem peut contenir des concepts qui partagent un code mais représentent essentiellement des concepts différents ; c'est particulièrement problématique pour l'implémentation, car l'unicité sémantique des concepts est l'un des axiomes fondamentaux de la Terminology FHIR.

Prenons l'exemple de ISO-3166 (urn:iso:std:iso:3166|57) : le CodeSystem chargé depuis fhir.tx.support.r4 jusqu'à la version 0.18.0 contenait une liste de concepts d'ISO-3166 mélangeant des codes Alpha-2, Alpha-3 et numériques comme code des concepts, et ajoutant une propriété canonical avec le code Alpha-2.

Or, pour certains pays qui ont changé de nom (p. ex., Birmanie devient Myanmar, Zaïre devient RDC, Yougoslavie devient Serbie-et-Monténégro, etc.), le code numérique est conservé, seuls les codes Alpha changent. Ils représentent donc deux concepts différents dans ISO-3166, mais ont le même code dans la ressource FHIR.

Quelques chiffres supplémentaires

Dans cette section, nous explorons les aspects quantitatifs de l'ensemble de données de Terminology FHIR, en examinant les totaux, les distributions et les patterns.

Systèmes de codes

À la figure 5, on peut constater que, parmi les systèmes de codes qui listent explicitement leurs concepts, la majorité des plus volumineux sont des recueils de données géographiques ; le plus grand étant les codes postaux du Québec, avec plus de 200 k concepts, suivi de quelques versions de la CIM-10. Fig 5. Les 20 plus grands systèmes de codes En termes de popularité, le système de codes le plus référencé est, sans surprise, SNOMED. Après SNOMED, les autres systèmes fréquemment référencés comprennent LOINC, ICD10, ICD9, RxNorm, DICOM et CPT (voir figure 6). Fig 6. Systèmes de codes les plus référencés À la figure 7, on peut voir que la majorité des systèmes de codes incluent explicitement tous leurs concepts dans la ressource [8]. Seulement 41 sont des suppléments ; bien que cette approche semble être un moyen très utile d'enrichir les concepts existants, elle est peu répandue ; la plupart d'entre eux sont des traductions [9]. Fig 7. Répartition du contenu des systèmes de codes

Ensembles de valeurs

Lors de l'analyse des ensembles de valeurs, leur aspect le plus intéressant est, sans conteste, leurs règles compose. Nous avons classé les ensembles de valeurs en 5 grandes catégories [10] :

• Extensionnel : énumération explicite de concepts
• Intensionnel (copie) : copie d'un système de codes ou d'un ensemble de valeurs existant
• Intensionnel (filtre) : défini algorithmiquement à partir de règles de sélection sur un système de codes existant
• Mixte : combinaison des techniques précédentes
• Sans Compose : le champ compose est absent

Fait intéressant, la majorité (plus de 60 %) sont classés comme extensionnels et seulement 10 % utilisent les capacités de filtrage des ValueSets, comme le montre la figure 8. Fig 8. Classification des ensembles de valeurs par Compose Bien que la majorité des ensembles de valeurs ne soient pas expansés (voir figure 9), près de 40 % apparaissent pré-expansés dans leurs paquets. Fig 9. Répartition des expansions de ValueSet

Analyse des filtres

FHIR fournit un mécanisme puissant et extensible permettant de définir des critères de sélection pour définir algorithmiquement des ensembles de valeurs à partir de systèmes de codes existants. Le principal outil pour exprimer ces règles sont les filtres.

Re : valueset-rules-text et valueset-expression

Bien que les ensembles de valeurs puissent être définis de deux façons supplémentaires, seule l'une d'elles est réellement utilisée en dehors des ressources d'exemple.

• valueset-expression [...] Une expression qui fournit une définition alternative du contenu de l'ensemble de valeurs [11]

• valueset-rules-text [...] des instructions qui ne pourraient être suivies que par un humain. [12]

C'est peut-être une bonne nouvelle pour les implémenteurs, puisque les deux autres options semblent difficiles à gérer du point de vue de l'interopérabilité.

Les ensembles de valeurs peuvent utiliser l'ensemble des filtres de base définis pour tous les systèmes de codes, ainsi que tout filtre supplémentaire défini dans CodeSystem.filter. À la figure 10, on peut voir que la combinaison filtre + op la plus couramment utilisée est, sans surprise, concept is-a, car c'est un moyen facile d'exploiter la nature hiérarchique de nombreuses terminologies. Fig 10. Propriété + op selon l'utilisation

Systèmes de codes populaires

Nous avons également analysé certains des systèmes de codes les plus populaires afin de dégager des observations sur les patterns et les cas d'utilisation. À la figure 11, on peut voir une comparaison des totaux ; veuillez noter que nous utilisons une échelle logarithmique [13]. Fig 11. Comparaison des totaux des systèmes de codes populaires Pour plusieurs de ces systèmes de codes, il est peu pratique de lister explicitement leurs concepts dans la définition de la ressource ; c'est pourquoi la plupart d'entre eux indiquent simplement not-present et c'est à l'implémenteur de fournir une source indexée pour répondre aux requêtes. À la figure 12, on peut voir que les seuls systèmes de codes complete sont ICD-10 et DICOM (SNOMED apparaît dans le graphique comme complete, mais ce n'est pas réellement le cas ; il s'agit d'une erreur dans certaines ressources CodeSystem). Fig 12. Répartition du contenu des systèmes de codes populaires

Filtres

La figure 13 présente une comparaison de l'utilisation des filtres personnalisés par rapport aux filtres de base prédéfinis de FHIR, par exemple l'ECL de SNOMED. Nous montrons également une comparaison des expressions, en orange pour les filtres personnalisés. On peut remarquer que la grande majorité des expressions utilisent les filtres de base de FHIR, même si certains de ces systèmes offrent une ontologie appropriée avec une sémantique puissante et, dans le cas de SNOMED, un langage de requête mature. Fig 13. Analyse des filtres des systèmes de codes populaires

Fautes typographiques

Lors de l'analyse de ces systèmes de codes, nous avons constaté que certains ensembles de valeurs présentaient des fautes typographiques ou des erreurs subtiles dans la définition de l'URL canonique, ce qui peut provoquer des erreurs inattendues lors de l'utilisation de ces ensembles de valeurs. Certaines de ces erreurs apparaissent encore dans les dernières versions de certains paquets.

Quelques exemples

• http://snomed.info/sct - remarquez l'espace en début de chaîne

• http://snomed.info/sct/731000124108

• snomed-ct

• https://loinc.org - https au lieu de http

• http://loinc.org/ - barre oblique en fin de chaîne

SNOMED srt

Initialement, les codes DICOM étaient répertoriés dans le paquet fhir.tx.support. L'URL canonique SNOMED utilisée dans ces cas était http://snomed.info/srt (srt au lieu de sct). Une fois déplacés vers le paquet fhir.dicom, l'URL a été corrigée.

Pour approfondir la Terminology FHIR et tester ses capacités, vous pouvez installer la version gratuite d'Aidbox. Elle vous permet d'explorer et d'expérimenter ces avancées dans un environnement entièrement fonctionnel, idéal pour le développement et les tests.

Annexe

1. Packages2 et Simplifier sont synchronisés ; il nous arrive parfois d'utiliser des URL Simplifier pour créer un lien vers un paquet, car cette plateforme offre une interface permettant de visualiser le contenu des paquets.
2. CodeSystem, ValueSet et ConceptMap
3. Nous considérons qu'un concept est unique selon son système, son code et sa version.
4. Une ressource publiée en 2161 est vraisemblablement une faute typographique ou peut-être un futur ValueSet ; elle est publiée par la Fédération Unie des Planètes et contient les quadrants de la Voie lactée.
5. Dans certains de ces cas, il semble que les auteurs utilisent des concepts de remplacement à des fins de regroupement et n'ont pas de valeur appropriée à utiliser comme code pour l'indicateur de groupe.
6. ValueSet HealthCareProviderTaxonomy du paquet hl7.fhir.us.directory-attestation
7. Modifications qui entraînent une perte d'information plutôt que des ajouts.
8. Ce n'est pas toujours le cas : certains systèmes de codes ont content = complete mais n'incluent aucun concept. Voir le tableau 1.
9. D'après ceux que nous avons analysés, il semble qu'ils soient tous des traductions vers différentes langues.
10. Intensionnel et extensionnel sont issus de la définition FHIR habituelle.
11. https://build.fhir.org/ig/HL7/fhir-extensions/StructureDefinition-valueset-expression.html
12. https://build.fhir.org/ig/HL7/fhir-extensions/StructureDefinition-valueset-rules-text.html
13. Afin de visualiser des comptes très différents dans un même graphique, nous utilisons une échelle log_10 ; cela peut fausser les attentes, car les différences entre les valeurs élevées ne sont pas aussi prononcées visuellement qu'elles ne le sont dans les données, notamment en comparaison avec les totaux plus petits.