En Janvier 2009, un rapport européen [Stroetmann 2009] a dressé un panorama de la problématique d’interopérabilité des systèmes de santé. Une définition de l’in- teropérabilité sémantique des systèmes de santé y est proposée : "L’interopérabilité d’un système de santé est sa capacité à :
– échanger, comprendre et agir sur des informations et de la connaissance au sujet des citoyens/patients
– au-delà des différences linguistiques et culturelles des acteurs de la santé (pa- tients, professionnels)
– à l’intérieur et à travers le système de santé de manière collaborative" C’est dans ce contexte que l’interopérabilité sémantique est traitée afin de fa- ciliter le codage, la transmission et l’utilisation du sens à travers les services de soins, entre les fournisseurs, les patients, les citoyens, les autorités et la recherche. L’étendue géographique de l’interopérabilité sémantique peut être locale, régionale, nationale ou trans-frontalière. L’information échangée peut être une information au niveau du patient, mais aussi de l’information agrégée utilisée dans le cadre d’études épidémiologiques, comptables ou de recherche8.
Dans les guides de bonnes pratiques européens [Stroetmann 2009], différents niveaux d’interopérabilité sont proposés en contraste avec l’approche "plus tech- nique" proposée dans [Gorman 2006]
Niveau 0 : pas d’interopérabilité
Niveau 1 : interopérabilité technique et syntactique
Niveau 2 : 2 niveaux orthogonaux d’interopérabilité sémantique Niveau 2a : interopérabilité unidirectionnelle
Niveau 2b : interopérabilité bidirectionnelle de fragments Niveau 3 : interopérabilité sémantique complète, permettant
le partage du contexte et la co-opération
Prenons un exemple permettant d’illustrer les 4 niveaux d’interopérabilité pro- posés ici : Mr Doisneau a 56 ans, il vient de déménager pour aller vivre en Espagne. Quelques semaines après son déménagement, il tombe malade. Il arrive chez son mé-
8. La recommandation européenne, COM(2008)3282 finale, définit : “Semantic interoperability means ensuring that the precise meaning of exchanged information is understandable by any other system or application not initially developed for this purpose”, où “interoperability of electronic health record systems means the ability of two or more electronic health record systems to exchange both computer interpretable data and human interpretable information and knowledge”, p.14.
decin généraliste local et est transféré à l’hôpital le plus proche pour des tests plus approfondis. Suivant le niveau d’interopérabilité de l’hôpital, les actions suivantes sont entreprises :
– Niveau 0 (pas d’interopérabilité) : Mr Doisneau est soumis à beaucoup de tests pour que le médecin puisse comprendre l’origine de sa douleur aigüe.
– Niveau 1 (interopérabilité technique et syntactique) : Le médecin hospitalier de Mr Doisneau peut recevoir les documents électroniques de son pays d’origine et de son généraliste local, par exemple par mail ou en se connectant sur le site web de son hôpital Français. Malheureusement, le médecin espagnol ne parle pas Français.
– Niveau 2 (interopérabilité sémantique partielle) : Le médecin espagnol peut accéder via l’internet au dossier patient de Mr Doisneau. Malgré le fait que la langue soit différente, certaines parties du rapport médical sont codées grâce à des classifications internationales et sont donc traduisibles par le système (informations démographiques, allergies, diagnostics et certaines parties de son passé médical).
– Niveau 3 (interopérabilité sémantique totale, co-opération) : Dans cette situa- tion idéale et après qu’une identification sécurisée ait été effectuée, le système d’information espagnol est capable d’intégrer et d’analyser les informations provenant du système d’information de l’hôpital Français et du généraliste local. Aucune barrière n’existe et les informations remontées au médecin lo- cal sont équivalentes aux informations qu’il a l’habitude de traiter pour ses patients habituels. En allant plus loin même, les données anonymisées sont automatiquement remontées aux systèmes publiques et à la recherche pour un usage secondaire des données.
Cet exemple nous permet de comprendre les enjeux de l’interopérabilité dans le domaine de la santé et son utilité pour tout citoyen. Il exprime aussi l’enjeu économique de l’interopérabilité qui permet par exemple, de diminuer le nombre de tests diagnostics faits lorsque le citoyen est en déplacement, ce qui est de plus en plus courant. Enfin, de partager des avis sur des cas médicaux complexes avec d’autres spécialistes.
Dans cette section, nous allons présenter des projets de recherche portant sur le domaine de l’intéropérabilité sémantique en santé suivant les approches définies précédemment.
4.2.1 Aggrégation de modèles, approche entrepôt de données
L’approche centralisée visant à intégrer des données dans le domaine biomédi- cal à été mis en oeuvre dans divers projets ces dernières années, parmi lesquels ATLAS[Shah 2005], BioWarehouse[Lee 2006] et BioDWH[Töpel 2008]. Le projet le plus récent et qui tend à être de plus en plus utilisé, car ouvert, est i2b29.
Le projet de recherche innovant i2b2 a démarré en 2004. Il permet d’intégrer des données médicales diverses (biologie, génétique, clinique, etc.) afin de pouvoir effectuer des interrogations multicritères sur le temps (par exemple dans le domaine génétique, tenter de prédire à partir de données cliniques et génétiques le risque de survenue de polyarthrite rhumatoïde). L’architecture fonctionnelle de cet outil, orienté services (SOA10
), propose une organisation en cellules, chaque cellule ayant une fonction spécifique au sein de l’applicatif. La cellule CRC (correspondant à l’entrepôt de données) est dédiée à la gestion du stockage, et présente une modéli- sation en étoile des données. Une originalité du projet concerne la définition de la cellule « Ontology Management » qui permet le stockage et l’interrogation de res- sources terminologiques. Elle supporte aujourd’hui plusieurs classifications comme par exemple LOINC11
. Elle permet la navigation dans les données stockées dans la cellule CRC selon les ressources terminologiques, chaque terme étant relié à la donnée qu’il désigne. i2b2 ne gère pas tous les types de ressources terminologiques et notamment ne prend pas en charge le typage des relations d’ontologies formelles. La cellule CRC a pour particularité d’avoir pour dimension le « concept terminolo- gique » associé au fait mesuré, à savoir l’observation d’un patient. Une observation sera liée au concept de prélèvement biologique, et un résultat de prélèvement y sera associé comme mesure. Dans i2b2 les ressources ontologiques et les données médi- cales sont gérées indépendamment, par un lien bidirectionnel qui rend l’évolutivité de l’outil complexe. L’intégration d’ontologies dans des bases de données dans le but de permettre l’évolutivité pose différentes problématiques. Il est proposé dans l’outil OntoDB [Pierra 2005] d’inclure l’ontologie et un méta-modèle de l’ontologie directe- ment dans la base de données où sont stockées les modèles physique et conceptuel de données. Cette architecture est d’ailleurs très proche de l’architecture metadata du MOF12
(Meta Object Facility). L’utilisation d’un méta modèle permet à l’ontologie
9. Informatics for Integrating Biology and the Bedside, https://www.i2b2.org. Siteaccédéle28/08/2011.
10. Forme d’architecture de médiation ou de modèle d’interaction applicative mettant en œuvre des services
11. Logical Observation Identifiers Names and Codes
12. 4 couches de représentation des données en UML : méta-méta-modèle, méta-modèle, modèle et données.
et aux données d’être indépendantes et génériques, puisque le modèle de l’ontologie est une instance du méta-modèle. Dans cette approche, le modèle logique est créé à partir de l’ontologie, le modèle conceptuel ne pouvant évoluer que de manière si- multanée avec le modèle logique des données. Il n’y a pas encore de mise en œuvre d’OntoDB dans le domaine de la santé.
4.2.2 Alignement de modèles : fédération et médiation de données
Dans le cas de l’alignement de modèles en santé, des travaux visent à proposer un modèle normalisé permettant de fédérer les différentes sources de données. HEWAF repose sur une modélisation multidimensionnelle se basant sur les classes du RIM HL7 [Stolba 2006]. D’autres projets ont été proposés. HEMSYS[Pillai 1987], TSIMMIS[Garcia-Molina 1997], BioKleisli[Davidson 1996] et TAMBIS[Stevens 2000]. La médiation peut être aidée par des ontologies, comme dans les projets MOMIS[Beneventano 2001] avec des ontologies lexicales, ou bien PICSEL[Goasdoué 1999].
Un exemple de réseau de médiation à grande échelle pour la gestion des données en cancérologie est le projet américain caBIG. Ce projet vise (comme DebugIT en Europe pour la résistance aux antibiotiques) à mettre en oeuvre une infrastructure de partage d’informations qui pourra être utile à la recherche sur le cancer. caGrid (l’infrastructure du projet, figure4.4) est une approche d’interconnection de données basée sur les modèles et orientée services. Une architecture et des protocoles de type grille sont utilisés. caGrid utilise trois framework de type middleware : Globus Toolkit (GT), OGSA-DAI et Mobius13. GT est utilisé pour le management des ser- vices de la grille afin de déployer, de créer et d’invoquer les services. OGSA-DAI est utilisé pour virtualiser les sources de données et les promouvoir au rang de services de données en grille. Mobius permet la gestion de la distribution des données et des métadonnées, Mobius est par exemple employé pour gérer la gestion des schemas XML représentant la structure des types de données communs au projet. L’architec- ture middleware d’OGSA-DAI14 permet l’intégration de données réparties ayant des modèles de données et des structures de stockages hétérogènes. Ainsi, il est possible d’interconnecter dans le grid15 des bases de données relationnelles, XML, un système de fichiers ou des données volatiles [Antonioletti 2005]. Les sources de données sont embarquées dans des services de caGrid. Chacune implémente une in-
13. http://projectmobius.osu.edu
14. Open Grid System Architecture :http://www.ogsadai.org.uk/. Site accédé le 04/10/2010. 15. (ou grille informatique) Désigne une infrastructure virtuelle constituée de ressources infor- matiques partagées, distribuées, hétérogènes, délocalisées et autonomes
terface de visualisation des données locales. Le fournisseur de données doit lier les éléments des datasets locaux dans des objets partagés du projet qui sont décrits sous forme de modèles et de vocabulaires par un autre élément du projet, caDSR (cancer data standards repository) et EVS (entreprise vocabulary service).
Figure 4.3 – Vue de l’architecture de caGrid.
La valeur ajoutée du projet caBIG est son architecture de management de l’in- formation, à savoir les modèles de données partagés et les vocabulaires. L’interopé- rabilité sémantique de données biomédicales a été cependant expérimentée dans le projet caBIG au travers de leur méthodologie semCDI ([Shironoshita 2008]). Leur approche n’a pas encore pu être validée correctement à cause d’un manque de for- malisation de la connaissance de leur domaine (ontologies de domaine). Cependant, des propositions d’architecture sémantique sont actuellement publiées16 afin d’en- richir les possibilités de gestion sémantique des données de caBIG (inférence). Ceci est actuellement en cours de mise en oeuvre.
4.2.2.1 Intégration à la volée et "mashup"
L’Internet et le web de données offrent aujourd’hui des capacités d’intégration de données directement dans des applications, à la volée. Ces applications intègrent des données au moment du démarrage de l’application. Les données intégrées pro- viennent généralement de services web qui sont capables de distribuer des données
16. https://cabig.nci.nih.gov/2010_caBIG_Annual_Meeting_Presentations/ tuesday-september-14-2010/concurrent-breakout-sessions-10-2013-14/ breakout-sessions/session-13-cabigae-semantic-infrastructure-v2-overview
sur demande sur invocation du service web. Dans le domaine de la santé, quelques applications de "mashup" sont récemment apparues, comme par exemple Health- Map17qui vise à intégrer en temps réel une vue graphique (cartographique) de l’ap- parition mondiale des épidémies de maladies infectieuses ou virales. La carte intègre des données venant de différents contributeurs d’information comme "google news" ou des contributeurs locaux d’information lorsque les web services sont disponibles.
Figure4.4 – Une vue des alertes d’épidémie au cours des 3 derniers mois précédent le 01/02/2011.
Il se pose évidement la question de la qualité de l’information produite et utilisée à la volée. Ce type d’application est cependant intéressante pour la mise en oeuvre de systèmes de surveillance à l’échelle d’un pays, d’un continent ou d’une région.