• Aucun résultat trouvé

Les défis d’interopérabilité biomédicale dans un contexte de systèmes de soins de santé apprenants

Hétérogénéité des sources de données

L’hétérogénéité découle des différentes caractéristiques des sources considérées. Premièrement, la structure de la source de données elle-même peut s’appuyer sur différentes technologies (ex. les bases de données relationnelles, les fichiers Extensible Markup Language – xml – les documents avec valeurs séparées par des virgules – csv…) qui varient en plus selon l’implémentation spécifique préconisée par la compagnie proposant la technologie. De plus, le monde biomédical peut être modélisé de plusieurs façons, selon plusieurs angles, en fonction de l’auteur et des prémisses de modélisation. Finalement, le niveau de granularité peut aussi varier. Donc, même si plusieurs éléments sont largement repris dans le monde de la santé, par exemple la date de naissance ou le numéro de dossier de santé du patient, ils seront souvent modélisés différemment. L’ensemble de ces aspects est identifié dans ce travail comme « hétérogénéité structurelle ».

Deuxièmement, afin de faciliter les échanges d’informations, plusieurs terminologies et vocabulaires contrôlés ont été créés dans le monde biomédical. Ils permettent une utilisation uniforme et constante des termes partagés par les utilisateurs. On peut ici citer des exemples internationaux comme la classification internationale des maladies dixième édition (CIM 10), la classification internationale des soins primaires (ICPC) ou la nomenclature systématisée de la médecine (SNOMED). Néanmoins plusieurs terminologies sont utilisées à un niveau national comme les Read Codes au Royaume-Unis. De plus, les logiciels et plateformes qui sont utilisés dans les systèmes de santé contiennent plusieurs codifications internes (ex. 1 pour les hommes et 2 pour les femmes) qui ne sont pas standard et qui peuvent même être la propriété exclusive des sociétés ayant créé ces logiciels. Globalement, ces aspects sont identifiés ici comme l’hétérogénéité terminologique.2

2 Certains auteurs utilisent le terme « hétérogénéité sémantique » à cet effet, mais tel que démontré dans ce travail, déterminer la sémantique (signification) d’une donnée nécessite l’intégration des aspects structurelles et terminologiques.

98

Interdépendance des modèles structurels et terminologiques

Les deux types d’hétérogénéité et les modèles sous-jacents peuvent être décrits séparément tels que présentés ci-haut, mais sont au final très interdépendants. Afin de pouvoir déterminer la sémantique (signification) complète d’une donnée, les modèles structurels et terminologiques doivent être intégrés.

Par exemple, le code E11 de la terminologie CIM 10 réfère à l’entrée E11 qui contient plusieurs informations pertinentes pour comprendre la signification du code, incluant son intitulé : Diabète sucré non insulino-dépendant. Les pathologies incluses et exclues sont aussi mentionnées (ex : exclusion du diabète de grossesse). Néanmoins, ceci nous donne seulement une connaissance partielle de ce qui est représenté par cette instance de code E11. Est-ce qu’il représente un diagnostic pour le patient index (ce patient souffre de diabète) ou est-ce l’indication qu’un membre de la famille souffre de diabète ? Est-ce un diagnostic fait à l’admission, alors que l’histoire n’est pas encore très claire, ou est-ce un diagnostic final lors du congé d’une hospitalisation ? Est-ce un diagnostic fait par un interne ou un patron ?

Pour les événements ponctuels, par exemple les pneumonies (J18 dans la CIM 10), le code peut représenter une pathologie existante au moment de l’entrée de la donnée ou plutôt faire référence au fait que le patient a souffert d’une pneumonie dans le passé. Les choses sont encore plus complexes pour les maladies épisodiques comme les dépressions majeures (F32 dans la CIM 10). Un deuxième code pour un même patient 18 mois après le premier peut représenter un suivi de l’épisode de soin initié 18 mois plus tôt ou représenter un tout nouvel épisode de dépression. Ces variations sont d’autant plus importantes lorsqu’on essaie d’intégrer les codes de plusieurs institutions. Il est alors bien hasardeux de faire une extraction simple des codes sans prendre le contexte structurel en compte, car c’est lui qui contient les éléments d’information pour compléter la sémantique des codes terminologiques. Bien que ce défi ait été identifié par A. Rector il y a quelques années pour les informations cliniques, l’ajout des données « omic » incluant l’épigénomique ajoute un niveau de complexité.

Autres exigences

Étant donné que plusieurs institutions doivent participer au système de santé apprenant, chacune évoluant potentiellement dans un environnement légal et administratif différent, une simple copie de toutes les données vers un site central n’est pas possible. De

99 plus, plusieurs institutions ont déjà plusieurs systèmes en place, structurés et encodés d’une certaine façon afin de répondre à leur mission première. Au final, les systèmes de santé apprenants ne contrôlent pas ces organisations et ne peuvent donc pas imposer des modifications à la structure des données existantes ou futures. D’ailleurs, étant donné la quantité importante de projets qui demandent la coopération des organisations de santé avec des budgets limités, il est important de minimiser les ressources nécessaires pour participer à un système de santé apprenant.

Finalement, le système de santé apprenant se doit de supporter les approches prospectives. Contrairement à d’autres domaines, plusieurs requêtes qui devront être exécutées par le système de santé apprenant ne seront pas connues à l’avance. De nouveaux concepts et de nouvelles façons d’interagir avec les données émergeront dans les prochaines années et le système devra être capable de les supporter. De la même façon, toutes les sources ne seront pas connues au jour un. Le système doit donc être capable de croître organiquement et d’intégrer de nouvelles sources en limitant au maximum les impacts négatifs sur le système déjà en place. Conséquemment, l’approche choisie pour gérer l’interopérabilité ne pourra pas être développée statiquement, sur la base des exigences obtenues de focus groupe ou du contenu disponible dans les sources connues au départ.

Revue des approches disponibles en regard de la gestion de

Documents relatifs