Vous-vous êtes très vite impliquée dans les projets d’informatique médicale européens, notamment le projet Synapses. En quoi consiste-t-il ?

En effet, en 1996, le Service d’Informatique Médicale de l’hôpital Broussais a intégré le projet européen Synapses. Synapses a débuté en janvier 1996 et se terminera en décembre 1998. Ce projet a été financé par la 4è Framework Health Telematics Programme de la Commission européenne et a associé 26 partenaires de 14 pays. Les partenaires les plus importants étaient implantés en Irlande, en Angleterre, aux Pays-Bas, en Norvège, en Suisse et en Italie. Industriels, hôpitaux et universités, ils se sont organisés en cinq clusters qui ont chacun pris en charge une implémentation du modèle que Synapses devait fournir.

Le but de Synapses était de répondre aux besoins, dans le monde médical, d’accès aux informations distribuées. En effet, les informations médicales concernant un patient donné sont " distribuées " entre des unités de soins et les différents plateaux techniques au sein d’un même établissement, des laboratoires d’analyses, des médecins de ville, etc…. On cherchait ainsi à promouvoir le " shared-care ", c’est-à-dire les " soins partagés ", fondés sur la disponibilité de l’information. Il s’agissait de construire une plate-forme d’intégration de systèmes d’informations propriétaires avec pour mission de fédérer les sources de données médicales hétérogènes et permettre de les visualiser, tout en masquant l’hétérogénéité de ces sources, c’est-à-dire obtenir un seul dossier patient, mais virtuel. Ce sont les spécifications de ce dossier médical " fédéré " ou Federated HealthCare Record (FHCR) qui seront dans le domaine public en décembre 1998.

Quels sont les grands principes du modèle Synapses ?

Le cœur du serveur Synapses est composé du SynOM (Synapses Object Model) et du SynOD (Synapses Object Dictionnary).

Pour la modélisation du SynOM et du SynOD, Synapses s’est appuyé sur les résultats de plusieurs projets. Le projet GHER d’une part, qui s'appuie sur la notion de " transaction " ou minimum d’information pouvant être transmise entre deux professionnels de santé et, d’autre part, des spécifications de l’EHCRA (Electronic HealthCare Record Architecture), pré-norme de référence pour l’architecture des dossiers médicaux électroniques. Cette dernière porte le nom de ENV12 265, et a été diffusée par le CEN TC251, Groupe technique en Informatique de santé du Comité européen de normalisation.

La nouveauté de Synapses par rapport aux spécifications de ces projets est de proposer une "architecture distribuée" de dossier médical informatisé dont les informations peuvent être locales ou distantes.

La structure du dossier repose sur 2 types d'objets, conformément à l'ECHRA :

• l'item, ou plus petite information élémentaire ;

• le complex, objet qui permet une description d’agrégation des données. Un taux de glycémie par exemple sera inscrit dans le complexe de données agrégées qu’est le bilan biologique. Synapses spécifie plusieurs types de complexe classés hiérarchiquement de telle sorte qu’un complexe d’un type particulier hérite des propriétés de son père. Synapses spécifie aussi selon quelles règles les items ou complexe peuvent être agrégés entre eux.

Synapses spécifie à la fois :

• le modèle de données fédérateur servant de réceptacle aux données des systèmes sources

• des interfaces de programmation ou API diverses, comme celle entre un client et le serveur ou les interfaces serveur-systèmes sources.

Un item est défini par une étiquette et un contenu. Il a également des attributs ou éléments contextuels : la personne responsable, la date de saisie de l’information ainsi que la date d’occurrence de l’événement médical, des commentaires éventuels associés, etc...

Quand une application cliente émet une requête vers le serveur Synapses, celle-ci est dispatchée vers les différentes sources de données, grâce au serveur. Les systèmes sources renvoient les données vers le serveur qui les fédère et les retourne au client. La communication peut être synchrone ou asynchrone. Le fonctionnement du système dépend de l’interface de programmation des systèmes sources. Ceci implique de pouvoir mettre en œuvre différents types d’intégration de ces systèmes, mais ces schémas d’intégration ne sont pas encore tous spécifiés par le modèle Synapses.

Pour illustrer ces problèmes d’intégration, prenons un exemple dans le cadre de l’hôpital : le serveur reçoit une requête. Celle-ci fait appel à des données dépendantes du serveur d’identité de l’hôpital, du serveur de biologie, du serveur d’imagerie, d’un serveur d’une unité de soins. Synapses ne spécifie pas dans quel ordre les différentes requêtes vers ces serveurs doivent être effectuées, par exemple si dans un premier lieu c’est le serveur d’identité qui doit être interrogé. Si c’est le cas, on commence par cette interrogation, le résultat remonte vers le serveur Synapses et les autres requêtes sont alors lancées sur un patient bien identifié. L’interrogation des autres serveurs peut éventuellement être effectuée en parallèle. On peut aussi imaginer la mise en place d’un time out sur des requêtes vers certains systèmes sources qui ne sont pas toujours accessibles en ligne

Si la définition d’un intelligent broker (ndlr : "courtier intelligent" : système logiciel qui joue le rôle d'intermédiaire dans la récupération des données) ne fait pas partie des spécifications Synapses, il existe néanmoins dans la littérature des descriptions de modèles de communication entre client et serveurs multiples, donnant des règles pour ce type de problèmes concrets et dont on pourrait s’inspirer pour la suite.

Quels sont les résultats de Synapses aujourd’hui ?

On compte aujourd’hui cinq implémentations qui utilisent des technologies différentes et s’appliquent à des domaines médicaux différents.

A Amsterdam, l’implémentation concerne le suivi d’une pathologie chronique, le diabète, en reliant l'hôpital (Academic Medical Center) aux médecins de ville.

A Dublin, le projet a abouti à l’informatisation d’une unité de soins intensifs du St James's Hospital. Le serveur intègre les systèmes d’information " au pied du lit ", c’est-à-dire les appareils de monitoring, à ceux des laboratoires et des plateaux techniques, permettant une visualisation des données.

Le ROYAL Marsden NHS Trust de Londres a développé son serveur dans le domaine de l’oncologie, permettant l'intégration de données issues des dossiers patients de l'hôpital dans la base de données qu'est le Thames Cancer Registry.

A Oslo, le serveur permet de fédérer les dossiers des services de médecine interne et chirurgie générale de l’hôpital central Akershus avec les dossiers médicaux d’autres institutions...

A Genève, l’implémentation concerne le domaine de la médecine générale avec un système de gestion documentaire et une base de données reliés à l’hôpital universitaire de Genève dont l’accès est possible par les médecins de ville.

Comment un serveur de type Synapses répond-il quand il interroge des systèmes distants qui ne suivent pas les spécifications européennes ?

Il y a différents problèmes. D’une part, les implémentations de Synapses (même si les systèmes respectent les " normes " européennes) ont chacune intégré les éléments contextuels d’une manière plus ou moins spécifique, ce qui implique qu’aujourd’hui, l’interopérabilité entre deux serveurs Synapses doit encore être démontrée. Selon les cas, elle peut nécessiter la réalisation d’un adaptateur de la même façon qu’entre un système propriétaire (legacy system ou feeder system) et un serveur. D’autre part, chaque implémentation d’un serveur Synapses a inséré une sorte d’"adaptateur" entre un modèle source de données et le modèle du serveur Synapses. Notre participation dans le projet SynEx sera la définition d’un modèle générique d’adaptateurs qui permette la remontée vers le serveur de données qui ne correspondent pas toutes au même modèle, et qui puissent s’intégrer au modèle Synapses.

Vous évoquez un projet, Synex, qui marque un prolongement des travaux engagés dans le cadre de Synapses. Quelle est la tâche et les enjeux pour Broussais dans le cadre de ce projet ?

SynEx est un projet de 27 mois, qui a débuté en juillet 1998. Il poursuit et s’appuie sur les travaux de quatre projets européens : Synapses, Galen, Télénurse et I4C. Les différents partenaires sont regroupés par pays. Les pays impliqués sont la Suisse, l’Italie, la Norvège, les Pays-Bas, l’Angleterre, l’Irlande, la France et le Danemark. La mission de chaque pays est double : participer à la spécification et au développement de l’architecture commune et être un site de démonstration et de validation d’une implémentation.

SynEx a pour objectif d’intégrer dans une même plateforme le dossier fédéré issu de Synapses et des services utiles aux applications médicales. En fait, il a été choisi de partir de la plateforme d’intégration HISA (Hospital Information Structure Architecture) telle qu'elle est spécifiée par le CEN/TC251 et d’ajouter les services à cette plateforme. L’aspect sécurité (authentification, protection des données, etc,...), par exemple, n’a pas été intégré dans Synapses : l’équipe Suisse va se charger de l’étude de ces services. Des services d’accès à la connaissance sont également prévus. Les résultats de Galen et de Galen in use sont utilisés en vue de l’intégration d’un service de terminologie. Des modules d’aide au diagnostic et au pronostic médical doivent également être intégrés. L’objectif commercial de SynEx est d’amener à un stade industriel ce dossier fédéré auquel seront intégrés les modules développés.

Broussais sera un lieu d’implémentation de la plate-forme SynEx et du développement et de l’intégration de différents modules d’aide à la pratique médicale et à la gestion de la connaissance.

Nous allons continuer de développer un " risk modelling manager " ou module de gestion d’équations de risque servant à la fois à la prévention et à l’aide au diagnostic dans le domaine de la cardiologie et de la médecine interne. Un tel module existe déjà à Broussais pour la prévention des maladies cardio-vasculaires. Ce que nous mettons au point est un module qui permette la formulation de nouvelles équations dans n’importe quel autre domaine médical sans l’intervention d’un programmeur : le médecin non informaticien pourra définir lui-même de nouvelles équations de risques et les intégrer dans leurs dossiers. Ce module utilise la technologie Java.

Nous comptons également développer une version pré-industrielle (il existe aujourd’hui une version prototype) du système IDEM (Image and Diagnosis from Exemple in Medicine). Le principe d’IDEM est la recherche pour le clinicien d’un cas similaire au cas clinique dont il a la charge dans une base de données, dite base de cas. La base que nous utilisons est une base d’images sur les pathologies mammaires. L’effort de modélisation a abouti à une base de 35 cas environ avec un module de description d’une image selon ses caractéristiques sémantiques et structurelles : le clinicien décrit son nouveau cas et le module recherche dans la base de cas les plus proches voisins. Une de nos ambitions est de fournir d’autres modules pour des domaines médicaux différents : des travaux en dermatologie et sur les pathologies thyroïdiennes ont débuté à Broussais.

Enfin, le dernier volet est la conception de l’adaptateur qui permet de connecter aussi bien deux systèmes propriétaires que deux serveurs SynEx, d’intégrer ou de migrer un système propriétaire vers un serveur SynEx, et bien sûr de connecter un client à un serveur SynEx. Nous travaillons déjà sur un système générique d’adaptateurs. Ce système modélise tout type d’échanges entre une source et une cible. Il utilise XML afin de faciliter l’intégration d’applications dans une plate-forme telle que SynEx.

Les défis pour Broussais sont de mettre en place SynEx localement afin de tester et valider nos modules, de s’assurer par le biais du partenariat européen que le développement obtenu répond bien aux besoins et que les interfaces sont standards donc utilisables hors de notre contexte.

Quelques mots sur les technologies que vous employez : vous dites utiliser XML pour votre adaptateur, serait-ce le moyen "universel" d’échange de données ?

Si on prend l'exemple de SynEx, l’adaptateur doit pouvoir intégrer l’interface de programmation du système source et produire en sortie une description XML des données. Pour cela, il convertit le message source, par exemple un message EDIFACT ou bien les résultats d’une requête SQL en structure de données XML. Le " Document Type Declaration " (ou DTD) décrit le modèle objet du système cible en XML. Si le système cible change, le DTD est modifié et le code de l’adaptateur reste le même.

Si le modèle cible n’est plus un modèle SynEx et si par exemple c’est un modèle utilisant des agrégations comme dans LIED : il suffit de changer le DTD, de relancer l’adaptateur : ce dernier commence par lire le DTD, et génère alors un message XML qui sera dépendant du système cible.

La technologie CORBA est-elle adaptée à des serveurs du type SynEx ?

Certaines implémentations de Synapses ont utilisé CORBA, d’autres pas. CORBA me semble plus adapté à des échanges synchrones qu’asynchrones. C’est une version très élaborée des remote procedures call ou " appel à distance " mais elle utilise le même paradigme ; elle peut être difficile à utiliser avec des systèmes propriétaires qui sont difficiles à faire évoluer.

Cependant, dans le cadre de SynEx, une tâche d’exploitation est a été définie (pour l'un des partenaires) afin de développer les liens avec CorbaMed : le but est de promouvoir au sein de ce groupe les services développés dans le cadre de SynEx. Le risk modelling manager pourrait par exemple devenir un objet CorbaMed. Nous devrons de toute façon fournir une interface CORBA pour tous nos objets.

Pensez-vous qu’il existe un marché pour des modules type serveurs Synapses ou SynEx prêts à l’emploi que d’autres hôpitaux pourront intégrer, et quelles sont les ouvertures possibles vers la médecine de ville?

Si je n’y croyais pas, je ne le ferais pas ! Je pense que, par exemple, dans une grande institution telle que l’AP-HP, il y a une mine de données hétérogènes. Un dossier fédéré du type Synapses et tel qu’on le trouvera grâce à SynEx aura sa place dans une structure hospitalière : à la fois à l’intérieur d’un hôpital où bien souvent chaque unité a développé ses propres moyens informatiques avec ses propres données et puis dans un cadre extra-hospitalier. Que ce soit pour qu’un examen ne soit pas répété X fois et dans l’optique d’une optimisation de la qualité des soins, il y a un besoin évident de partage de données.

Depuis juin, nous sommes impliqués à Broussais dans un projet financé par la CANAM, un projet franco-français cette fois, nommé ESPER. Ce projet associe Broussais à l’hôpital de la Timône (Marseille) et à une unité de l’INSERM qui gère des données de mortalité. Le but est de mettre à la disposition des médecins de ville un serveur de prévention et d’aide au diagnostic dans les domaines cardiovasculaire et oncologique. Les outils développés à Broussais tels que les modules d’équations de risque seront intégrés dans ce serveur de la même manière que pour le serveur SynEx. Nos partenaires vont traiter les données de mortalité de l’INSERM dans cette même optique. ESPER est dans la lignée de notre travail à Broussais et des outils précieux vont être mis à disposition de la médecine de ville et peut-être, à plus long terme, des patients eux-mêmes.

Retrouvez toutes les autres interviews.