Octobre 2000

Norbert Paquel,
délégué général d'Edisanté

"Paradoxalement, demain, les réseaux de soins pourraient être équipés de systèmes d'information plus précis, plus rapides et plus flexibles que les hôpitaux."

Propos recueillis par Christine Bouchet et Gaëlle Layani

25 septembre 2000

Norbert Paquel est délégué général d'Edisanté, association française dont la mission est de favoriser le développement des échanges normalisés dans le secteur socio-sanitaire. Il a réalisé une étude sur l'opportunité de l'utilisation d'XML dans le cadre des EDI pour la MTIC (mission interministérielle de soutien technique pour le développement des technologies de l’information et de la communication dans l’administration). Cette étude est disponible sur le site du MTIC.

Vous avez rédigé un rapport sur l'utilisation d'XML dans les EDI, nouvelle pièce au dossier déjà volumineux des nouvelles technologies en santé. Pensez-vous que les choses vont évoluer concrètement ?

Oui, c'est clair. Nous le disons dans le rapport. XML a des vertus propres. C'est une très bonne grammaire, mais sa principale vertu est qu'il est transapplicatif et que tout le monde, notamment les grands offreurs en informatique comme Microsoft, y croit. C'est fondamental dans ce domaine. De plus, c'est une technologie lancée par le consortium W3, ce qui constitue en général un gage de succès.

Personne ne conteste que c'est un langage remarquable, à la différence de ce qui s'est passé pour Edifact ou même pour Java.

Normalisation, interopérabilité des échanges sont des termes très employés actuellement. Pensez-vous que des avancées soient réellement réalisées dans ce domaine ?

Oui. Et ce n'est pas uniquement à cause d'XML. XML est là pour permettre aux offreurs de ne pas enfermer leurs clients. C'est encore une tentation. Malgré tout, de plus en plus de personnes, y compris les utilisateurs, veulent pouvoir faire communiquer des systèmes différents. Ce n'est plus un souhait utopique.

On ne veut pas commettre l'erreur de tout normaliser, ce qui engendrerait un "monstre" beaucoup trop lourd (règles, grammaires, vocabulaires, processus, etc.). On va normaliser un certain nombre d'éléments clés qui permettront de communiquer.

Edifact, c'est très bien, mais cela ne marche que pour les acteurs qui se mettent bien d'accord, ce qui prend du temps, car il faut tout normaliser : les mots, les phrases, les messages, les protocoles, les codes. Et à l'échelon mondial, sinon ce n'est pas de la normalisation. Dans le cas d'XML, on normalise plutôt des méta-informations, des processus. On normalise la manière de dire ce que l'on communique.

Avez-vous l'impression que l'informatique médicale progresse ? 

Elle devrait progresser en tout cas. Les professionnels de santé sont de plus en plus équipés, ce qui a un impact sur le développement de l'informatique médicale.

C'est vrai également pour les grands systèmes hospitaliers qui seront amenés à évoluer sous l'impact de l'offre (mondialisation des logiciels, Internet) même s'il existe une inertie liée au passé et au passif de ces systèmes. Paradoxalement, demain, les réseaux de soins pourraient être équipés de systèmes d'information plus précis, plus rapides et plus flexibles que les hôpitaux.

Toutefois, cette progression ne réglera pas tous les problèmes, loin de là, mais il existe un réel besoin de communication entre les différents acteurs et une véritable exigence du public. Celui-ci ne supporte plus bien qu'on lui dise qu'on ne peut plus transférer des informations quand il faut, où il faut. C'est la grande nouveauté. 

En quoi XML menace-t-il EDIFACT ?

Non XML ne menace pas EDIFACT. Disons qu'EDIFACT a trouvé ses limites. A long terme, il est vrai, EDIFACT ne sera plus l'outil de développement des nouveaux messages. Par exemple, à EDISANTE, nous ne comptons pas développer de nouvelles choses avec EDIFACT. La prescription ou l'échange de dossiers seront désormais toujours conçus en XML. EDIFACT est une étape de l'histoire. Il continue de se développer là où il fonctionne, mais il ne s'étendra pas aux domaines où il ne s'est jamais étendu, c'est-à-dire dans beaucoup de secteurs économiques. Car, finalement, EDIFACT n'a pas "percé" quand il n'existait pas un ou quelques grands acteurs désireux de l'imposer. De plus, parfois, certains secteurs, comme la banque, avaient déjà développé leur propre système. Pour la prescription et le dossier médical, EDIFACT n'a jamais été utilisé et ne sera jamais utilisé. Donc c'est vrai, XML annonce la fin d'EDIFACT, mais sur dix ou quinze ans. 

Quelles sont les perspectives d'utilisation d'XML dans le commerce électronique B-to-B ?

Les perspectives sont évidentes. Jusqu'ici, l'EDI était avant tout utilisé dans le commerce B-to-B en "back office". Là où d'autres langages que XML sont utilisés, XML s'imposera en back office, mais ce sera long, car ces langages fonctionnent.

Les PME sont évidemment concernées en premier chef par votre question de même que les entités où il y a interaction entre la personne et le système. Je m'explique. Aujourd'hui, vous avez d'un côté les entreprises qui utilisent pour le moment toutes sortes de formats d'EDI en back office, et de l'autre les places de marchés où XML sert avant tout d'outil commun d'expression des données.

XML est donc déjà utilisé sur les serveurs interapplicatifs, les différents middlewares et les plates-formes d'intermédiation. On convertit tout en XML, c'est d'ailleurs pourquoi il est tellement utilisé. C'est du Web EDI. L'entreprise saisit (pour le moment) ses données à la main sur l'interface HTML de la place de marché. Celle-ci "déshabille" le document HTML pour le traduire en XML. Il est ensuite archivé dans une base et la place le récupère pour communiquer avec l'entreprise après l'avoir retraduit dans son langage initial. Tout ce qui rentre devient de l'XML, tout ce qui sort vient de l'XML.

Dans la phase 2, sur laquelle travaille le Web Consortium, le formulaire de saisie à l'apparence d'un formulaire HTML. En fait, il génère un fichier contrôlé XML. Les données envoyées sont donc immédiatement converties en XML.

La phase 3, c'est l'interopérabilité des applications des différents acteurs. Il faut, par exemple, que suite à une commande envoyée par le logiciel d'achat d'un client, la place de marché puisse envoyer automatiquement un bon de livraison. La PME pourra utiliser directement XML pour communiquer avec la place de marché. Ce type de relation ne va sans doute pas s'installer rapidement entre entreprises, car elles ont peur pour leur sécurité. Les protocoles de sécurité, les règles générales d'archivage et les règles de signature ne sont pas encore définies. Un minimum de normes, de règles de sécurité, de protocoles de validation et d'interfaces communes est donc nécessaire. L'automatisation des processus (le logiciel commande pour moi) est à ce prix.

Quels sont selon vous les obstacles les plus importants à la normalisation des échanges de données en santé ?

Pourquoi la normalisation s'est-elle plus développé dans le secteur bancaire, par exemple, que dans le secteur de la santé ? Tout simplement, parce que, pendant logtemps, le besoin n'a pas été ressenti assez fortement en santé. L'évolution des comportements sociaux et des techniques le fait désormais exploser. C'est la même raison qui explique que l'informatisation des médecins ne se soit pas faite rapidement, par exemple. Le besoin n'était pas fondamental. Je sais que c'est choquant de dire cela. Il n'existait pas de besoin urgent de normaliser contrairement au secteur bancaire. Les banques se sont mises d'accord très vite. Pourtant, elles sont concurrentes.

La seconde raison, c'est que la santé est un secteur très complexe. Il existe des centaines de spécialités, etc. Il faut normaliser l'ordinateur, le protocole de transmission, les formats de fichier, les systèmes de réception et de signature, et surtout, le plus difficile, il faut normaliser le langage médical. Un cardiologue n'organise pas ses données comme un néphrologue, par exemple.

La troisième raison, c'est qu'il n'y a pas assez d'informatique. Tant qu'un milieu n'est pas suffisamment informatisé, il y a beaucoup d'offreurs et ces derniers ne s'occupent pas de normalisation faute d'argent notamment. De plus, le marché de l'informatisation hospitalière n'était pas un vrai marché. Chacun a cherché à préserver son territoire. Ajoutez à cela la tentation des offreurs de conserver un marché non normalisé, la propension des informaticiens à penser que leurs travaux sont les plus intéressants (et tant pis pour la norme !) et la tendance des médecins à penser qu'ils sont les mieux placés pour en parler…

Le besoin en communication a un impact sur la normalisation. Comme je veux communiquer avec mon voisin, je commence à mettre en place des passerelles entre nous. Les normes utilisées à cette occasion tendent à rejaillir alors sur l'organisation interne. Ainsi, les systèmes Internet sont devenus des Intranets. TCP/IP, par exemple, devient un standard pour les réseaux locaux. La communication est un préalable à la normalisation et non l'inverse, j'en suis convaincu.

Retrouvez tous les autres articles et interviews de la rubrique Télémédecine.