Notes
-
[1]
EDIFACT est un langage qui définit une syntaxe, des éléments de données, des segments (par exemple, adresse ou ligne de commande), des messages (par exemple, « Order » pour la commande, « Medruc » pour la demande de remboursement de soins) et c’est aussi toute une organisation de normalisation dirigée par l’ONU et reconnue par les instances de normalisation. Aux Etats-Unis, cependant, c’est ANSI X12 qui lui correspond. XML, de son côté, est une grammaire formelle, donc permettant un contrôle rigoureux, mais ne précisant rien, dans la norme proposée par le Web Consortium, en ce qui concerne les modes d’implémentation. Il faut à partir de là écrire des langages, définir des dictionnaires, etc. Le système est donc souple mais il sera nécessaire de récupérer tout l’acquis de l’EDI préexistant pour passer à un XML EDI qui sera certainement plus souple, parfois plus complexe en fait, mais accessible aux PME parce que dynamisé par toute l’industrie informatique et intégré à de nombreuses applications. EDIFACT est avant tout un langage positionnel (après telle information on doit trouver telle autre) alors que XML est fondé sur le sens, des balises délimitant les informations et s’organisant dans un arbre.
1Parler des EDI dans la santé est particulièrement difficile parce que le thème est à la charnière de deux sujets mal connus et objets de multiples confusions : les EDI et la communication électronique dans la santé.
2Il ne peut être question de réhabiliter ici les EDI, qui ont été victimes d’une très mauvaise communication de la part de leurs promoteurs et d’une réputation justifiée de complexité et de coûts élevés que beaucoup d’acteurs avaient tout intérêt à maintenir. Aussi a-t-on pu entendre que les EDI étaient remplacés par l’internet, ou par XML, etc. La confusion est totale : ces propos font référence au système de normalisation EDIFACT, qui est très complet et couvre à la fois la syntaxe, les termes (la sémantique), les phrases et textes (les messages) [1]. Ces messages ont été mis en œuvre sur des réseaux spécialisés parce que l’internet – et c’est encore le cas en pratique – n’était pas diffusé quand les EDI sont nés, et ne présente toujours pas, sans adjonctions importantes, les caractéristiques de fiabilité et sécurité nécessaires à des échanges massifs, automatiques et réguliers entre systèmes d’information, ce que sont les EDI. Aujourd’hui, c’est encore EDIFACT (ou son équivalent américain X12) qui est utilisé même pour de nouveaux développements de ce type, même si tous les groupements sectoriels travaillent à l’échelle internationale sur le passage à la grammaire XML et le transit sur l’internet. Qui plus est, le plus long et le plus important dans les développements d’échanges de données n’est pas la mise en forme informatique mais l’identification des flux, l’accord entre les acteurs d’un secteur pour échanger d’une part, pour se donner des normes communes d’autre part, enfin la définition de sémantiques précises, de processus métier qui permettent l’enchaînement des messages et des actions, de codes pour les différents types de produits et services. Evidemment, le fait d’utiliser EDIFACT, XML ou toute autre syntaxe ne change rien à ces problèmes – et c’est pourquoi il est absurde de croire que l’utilisation des techniques issues du web va miraculeusement faciliter les échanges. Ce qui les facilite, c’est la banalisation du réseau et l’appropriation par les acteurs des méthodes et des pratiques de la communication électronique.
3Cette évolution importante s’observe aussi dans la santé. Réputés rétifs, les professionnels de santé ont, en France et dans le monde, largement adopté l’informatique et ils exigent maintenant de pouvoir communiquer.
4Or, un deuxième type de confusion prévaut au sujet des échanges de données dans la santé. En effet, la frontière est difficile à tracer entre la structuration de l’information dans les systèmes et celle qui est appliquée dans les échanges. Le principe des EDI est de permettre l’échange entre des systèmes divers, hétérogènes, n’utilisant pas forcément les mêmes langages et codages pour les données. Ainsi, la discussion sur les échanges d’informations de santé doit, elle, rester distincte de celle sur la structure du dossier médical – le problème le plus difficile et le plus débattu dans la santé. Pourtant, les structures utilisées pour les échanges vont influencer progressivement celles appliquées pour la gestion et le stockage. L’un des paris des acteurs de l’EDI est souvent que c’est l’échange extérieur qui va peser sur les systèmes internes des acteurs, plus que l’inverse. Et c’est bien ainsi que le Comité européen de normalisation l’entend lorsque son travail sur le dossier de santé s’oriente désormais exclusivement sur les règles et les structures pour l’interopérabilité : c’est la norme en cours de définition EHCR COM (Electronic Healthcare Record Communication).
5Enfin, il faut clairement distinguer les EDI des formes directes de communication et en particulier de la messagerie simple. L’EDI va faire intervenir une structuration de l’information et une automatisation même partielle. Il est destiné à décharger les utilisateurs de tâches routinières tout en apportant plus de sécurité et en permettant des intégrations plus grandes. Cette structuration doit permettre, par exemple, qu’un message arrivant dans un hôpital ou au cabinet d’un médecin soit routé vers le bon destinataire. Celui-ci peut être un humain ou, plus souvent, une application capable d’exploiter les données et de déclencher éventuellement les alertes ou les réponses prévues. En particulier, l’application pourra ainsi, avec un contrôle possible de l’utilisateur, intégrer le contenu du message dans un dossier.
6Dans l’ensemble des communications dans la santé, l’EDI tient donc apparemment une place modeste, puisqu’il s’agit d’information structurée, textuelle, échangée automatiquement. Il a donc été d’abord limité à la gestion, à la protection sociale, à la logistique, très loin des applications de télémédecine et de la circulation de l’information médicale et des images. Il en est pourtant un élément potentiellement important, mais il ne peut se développer qu’avec la banalisation et l’industrialisation des systèmes d’information dans la santé.
L’EDI correspond à la normalisation, qui ne devient vraiment une contrainte qu’avec la communication. Dans toute la mesure du possible, les échanges en santé doivent se conformer aux normes générales et les développements spécifiques à la santé doivent rester limités au strict nécessaire – même si les tentations sont souvent fortes dans le secteur.
Enfin, l’EDI doit pouvoir être supporté par les divers types de réseaux et de logiciels de communication. En particulier, en France, il doit tourner sur les réseaux spécialisés existants, sur les réseaux privés virtuels aux normes internet, c’est-à-dire le réseau Santé social géré par Cegetel RSS, mais aussi sur ses concurrents mis en place notamment par France Télécom et Cégédim (pour les couches applicatives) et enfin sur l’internet. Même si les questions de transport ne ressortent pas de la réflexion EDI, il serait illusoire de ne pas les considérer, d’autant qu’elles vont en fait influer sur le type des messages et des données d’accompagnement.
L’association EDISANTE
7Pour présenter, même de façon rapide, les EDI dans la santé en France et en 2001, il n’est pas possible de ne pas se référer à EDISANTE. La principale raison est que l’existence même, le fonctionnement d’une association comme EDISANTE sont révélateurs des enjeux et des développements concrets dans le secteur. Avant d’expliquer pourquoi, il faut rappeler ce qu’est l’association.
8Comme toutes les associations EDI… (transport, vins, ou automobile même si elle s’appelle Galia), EDISANTE est à la fois un regroupement d’organisations du secteur dans une perspective économique et politique et un forum de travail technique. Elle reflète ainsi l’exigence des EDI : développer des standards techniques permettant l’échange et leur mise en œuvre et pour cela rassembler des acteurs et identifier les raisons qu’ils ont de communiquer, les axes de développement qui permettent de trouver des avantages mutuels à la facilitation, la simplification et l’automatisation des échanges.
9Dans cette mesure, le développement d’EDISANTE reflète la plus ou moins grande maturité du secteur et ses avancées comme ses faiblesses. L’association apporte des réponses techniques à condition que les acteurs aient commencé d’exprimer un besoin. C’est pourquoi les fondateurs ont d’abord été les grandes institutions du secteur et, en leur sein, les personnes les plus convaincues de l’importance des réseaux ouverts, des normes, de la communication multipartenaires. Cette démarche rompt en effet avec une tradition d’isolement, de formats propriétaires, de méfiance vis-à-vis des progiciels du marché, qui était encore très présente en 1990, quand le travail a commencé. L’informatisation de l’information médicale était très peu développée et les professions de santé pratiquement pas informatisées, à l’exception notable de la pharmacie. Aussi les premières préoccupations ont elles porté, avec le développement national de Sesam-Vitale, sur les échanges relatifs au remboursement par l’assurance maladie et sur les relations entre les assurances obligatoires et complémentaires. Par ailleurs, les échanges dans la chaîne de distribution de la pharmacie, déjà largement développés en ville sur des réseaux spécialisés mais utilisant des échanges EDIFACT (association EDIPHARM) rejoignaient l’association. C’est ainsi que, avec ensuite la création de groupes de travail relatifs à l’achat des hôpitaux avec le ministère de l’Economie, les chaînes logistiques ont été considérées.
10Il est un peu étonnant pour l’observateur connaissant mal le secteur que ces aspects soient passés avant l’échange d’informations médicales, mais c’est parce que les problèmes posés sont beaucoup plus simples, et aussi que les organismes de gestion et de tutelle ont des moyens et des politiques informatiques d’entreprise. Ce n’est donc que vers 1998 que la normalisation des échanges d’informations médicales est devenue une préoccupation assez forte pour que des groupes de travail se constituent. En 2001, il est clair pour tous que c’est l’enjeu principal.
11L’important est que, au cours des dix ans d’existence d’EDISANTE, les acteurs aient progressivement tous rejoint le mouvement – professionnels, établissements, assurance maladie obligatoire et complémentaire, industriels de la pharmacie, administration – et que très peu aient quitté l’association. Au contraire, celle-ci a été rejointe par de nouveaux partenaires et en particulier par un nombre croissant des industriels de l’informatique et des télécommunications, qui au début n’étaient pas invités. En 2001, la préoccupation est d’établir des liens avec les associations de patients, ce qui correspond à l’orientation maintenant générale vers une maîtrise par le patient ou sa famille des informations le concernant.
12Ainsi, des acteurs qui, dans le courant de l’action politique, s’opposent ou sont concurrents, n’ont jamais cessé de travailler très concrètement de concert dans EDISANTE car, malgré les difficultés du moment, l’échange d’informations reste une contrainte permanente. L’association est certes étroitement associée aux bouleversements, voire aux affrontements qui agitent le monde socio-sanitaire mais le travail lui-même se poursuit. Les groupements et syndicats de professionnels, les assureurs privés, les mutuelles et l’assurance maladie obligatoire, les industriels concurrents se sont rencontrés dans les groupes de travail même au plus fort de leurs divergences.
13Du point de vue technique, il est aussi très important de noter que les échanges de données informatiques n’ont pas grand chose à voir avec une religion, ce qui n’est pas toujours évident en observant certains affrontements. Aussi, un succès d’EDISANTE – et une leçon de l’expérience – est d’avoir réuni tous les acteurs réellement engagés dans les échanges sans se raidir sur une norme – tout en affichant sa préférence pour la normalisation ouverte, internationale, officielle et tout en recherchant une convergence entre les membres. Aussi se sont réunis dans l’association des groupements qui utilisaient des syntaxes et formats divers, à commencer par Hprim, association du monde de la biologie utilisant une norme américaine pour les transferts de résultats –standard de fait actuel–, ou encore l’association EDIPHARM, utilisant EDIFACT mais sans être passée par toutes les étapes de la normalisation officielle. En fait, le travail sur les EDI doit privilégier la réflexion sur les processus, les avantages mutuels, les sémantiques et non les formats et syntaxes informatiques. Aussi le rapprochement actuel avec la syntaxe d’origine américaine HL7 et bien sûr l’évolution XML n’a pas de raison de poser de problème particulier à EDISANTE.
14Les différents groupes de travail d’EDISANTE représentent une bonne illustration des orientations actuels des EDI dans la santé. Ce sont notamment :
- la demande de remboursement,
- la demande de prise en charge et d’entente préalable,
- la détermination d’identifiants non ambigus pour les acteurs de l’assurance complémentaire,
- la dématérialisation des prescriptions,
- l’échange d’éléments de dossier médical,
- la détermination d’une codification commune de biologie,
- la détermination de méthodes communes pour le développement de messages utilisant la grammaire XML et la préparation de répertoires de schémas et entités XML permettant d’exprimer les objets et processus métier de la santé.
La situation et les travaux
15Les échanges dans la santé peuvent, en première analyse, porter sur trois types principaux de données : données de gestion et de financement du système, données commerciales et logistiques, données médicales. Cependant, les choses ne sont pas si simples, et la célèbre feuille de soins montre bien que les deux types d’information sont mêlés.
16Dans l’information médicale elle-même, quelques grands domaines peuvent être distingués :
- messages accompagnant l’activité médicale proprement dite (échanges d’informations, demandes de mouvement, etc.),
- échanges entre les professionnels et l’assurance maladie pour les autorisations, les demandes de remboursement et les justificatifs,
- transfert d’informations pour la médicalisation du système de gestion et de statistique,
- épidémiologie, vigilance, pharmacovigilance.
Un existant divers mais limité
18En dehors des échanges pour la commande de médicaments et des flux très importants définis par les diverses formes de l’assurance maladie, et qui sont tous en format propriétaire, les échanges de données dans la santé sont encore très limités, et il n’y en a pratiquement pas dans le domaine médical qui suive une normalisation officielle.
19En fait, une seule forme d’échanges automatiques existe en France – et dans beaucoup de pays –, c’est le transfert de résultats de biologie entre les laboratoires d’analyse et les systèmes des médecins ou des hôpitaux. Jusqu’ici, ils ont fonctionné en mode point à point sur réseau téléphonique, sous le contrôle de l’association Hprim, qui rassemble pratiquement tous les acteurs informatiques avec les représentants des biologistes. L’association développe maintenant le transfert sur l’internet avec sécurisation et passage par des serveurs respectant sa nouvelle norme HprimNet. Le format initial des informations est un standard d’origine américaine (ASTM) maintenant intégré à l’ensemble HL7 (Health Level 7, ensemble de messages EDI américains de la santé).
20Les autres acquis importants n’en sont encore essentiellement qu’au stade des développements et de la normalisation, ou encore de briques qu’il reste à assembler.
21En effet, les échanges qui ont lieu jusqu’ici dans le domaine médical ressortent soit de la messagerie interpersonnelle soit du transfert de fichiers point à point, sans structure associée et surtout sans processus automatisé. Le cas des images est un peu particulier. Le standard mondial Dicom s’est maintenant imposé (cf. article d’Emmanuel Cordonnier). En matière d’échanges d’informations médicales, un consensus semble en voie de s’établir autour du projet de norme EHRCOM du CEN et l’importance de ce travail a conduit à un rapprochement avec le consortium HL7, lequel ne dispose pas de développements très avancés en matière d’échange d’informations médicales sur les réseaux ouverts. Les échanges devraient commencer de se développer, au-delà d’expérimentations, à partir de 2003.
Les développements en cours
22Ils sont parallèles dans tous les pays. Il s’agit de permettre l’automatisation partielle des échanges, sur les trois volets évoqués – les échanges d’informations, les mouvements, la prescription.
23Pour les échanges d’informations médicales et d’éléments des dossiers, la première étape est la mise en place de systèmes de messagerie multimédia, avec des enveloppes informatives structurées (cf. article d’Emmanuel Cordonnier).
24Comme cela a été indiqué précédemment, les échanges de biologie, qui ont une forte avance, font l’objet de nouveaux développements autour de services sur l’internet et de schémas XML définis par Hprim.
25Pour les mouvements de malades, les efforts qui ont été faits pour développer des messages EDIFACT n’ont guère porté leurs fruits. En revanche, de tels messages existent dans le système de standards HL7 et vont actuellement être largement repris dans les échanges envisagés par certains établissements et certains réseaux. L’association Hprim, le GIP Modernisation des systèmes d’information hospitaliers et d’autres acteurs de la normalisation s’engagent dans cette voie. Les messages s’exprimeront progressivement en XML, le rythme et les conditions d’évolution de HL7 actuel à sa version XML ne faisant pas encore l’unanimité.
26Le troisième type de flux, peut-être le plus structurant, est associé au transfert des prescriptions. Au sens le plus large, c’est-à-dire en incluant les demandes d’examen et d’avis, elles sont l’acte élémentaire central du système. Des messages de prescription peuvent jouer plusieurs rôles :
- déclenchement d’actions – c’est l’ordonnance initiale, la demande d’examen, etc.,
- ensuite élément d’information pour les dossiers médicaux,
- élément de justification pour le financement des actes, transmis à l’assurance maladie,
- élément d’information marketing pour les acteurs de la pharmacie, transmis anonymisé.
La difficile prise en compte des impacts
27Une première génération d’EDI consistait à des échanges entre deux systèmes très spécialisés au travers d’un opérateur de réseau assurant des fonctions importantes, dont la traçabilité des échanges et leur notarisation (ce qui n’était pas lié au format employé mais à la non-banalisation des accès réseau). Désormais, l’évolution de l’EDI accompagne une ouverture qui pose de nombreux problèmes en termes de sécurité mais aussi d’organisation. En effet, si la sécurité technique fait l’objet de beaucoup d’attentions – et d’un souci légitime compte tenu du caractère des informations manipulées – les questions d’organisation ne pourront réellement être abordées que progressivement, par la confrontation avec des fonctionnements réels. Echanger des informations médicales de manière partiellement automatique va en fait modifier les relations entre les acteurs et va exiger des changements dans les pratiques de travail. Les possibilités offertes par la technique obligent aussi à poser des problèmes nouveaux et à faire des choix. Un exemple en est donné par la prescription.
La généralisation de l’ordonnance dématérialisée va en effet permettre une gestion plus fine, notamment en ce qui concerne le recours au générique, la modification de la prescription, les durées de validité pour les différents items. Surtout, la gestion de cette ordonnance pose un redoutable problème de « tiers dépositaire ». En effet, en ville (mais non à l’hôpital), il n’est pas possible d’adresser l’ordonnance ou la demande d’avis de professionnel à professionnel, ce qui serait gravement contraire au libre choix du patient. Il faut donc identifier un état de stockage intermédiaire du message, sur un serveur, sur la carte, chez le prescripteur, etc. Il est possible aussi que ce soit le patient qui la stocke sur un service notaire de son choix, ou qui autorise le professionnel à l’adresser à un correspondant. Dans les réseaux, il est possible d’imaginer des fonctionnements du type hôpital, avec accord préalable ou systématique du patient. Cet exemple montre que les vrais problèmes ne sont pas techniques mais que les outils amènent à remettre en cause les fonctionnements actuels.
La mise en œuvre des EDI
Les choix, des supports aux langages
29Le développement des EDI implique des choix pour les supports et protocoles de communication – choix qui ont d’abord porté en France sur les réseaux X25 et les normes de messagerie X400, mais aussi sur les protocoles concurrents des différents industriels. L’accord est maintenant général sur les protocoles et formats de l’internet, qui sont notamment ceux du RSS.
30Il faut ensuite s’accorder sur des formats de transfert des données. Dans ce domaine, il était clair que la syntaxe EDIFACT, très rigide, ne pouvait véhiculer efficacement des informations du dossier médical, qui peuvent certes être organisées du point de vue du contenu mais de façon très flexible en ce qui concerne la mise en forme et la présentation. L’introduction d’XML va permettre une bien plus grande flexibilité. Il est vraisemblable que la notion de message va s’effacer : les échanges feront appel à des éléments préfabriqués (objets, schémas XML) qui seront assemblés en fonction des besoins par les automates. Ceux-ci auront intégré les modèles des process, et c’est pour les définir que les chantiers vont s’ouvrir.
31L’autre point essentiel est l’accord sur les sémantiques et sur les codifications. Il n’est plus question d’obliger tous les acteurs à parler le même langage et à utiliser les mêmes classifications et listes de codes, mais il faut éviter la prolifération et surtout savoir clairement ce que chacun utilise. Dans les nouvelles démarches, et c’est particulièrement possible avec XML, le système récepteur peut se référer à des services sur le web pour interpréter les sémantiques et les codes. Dans le cas d’un échange fréquent, il sera amené à les stocker localement. Quoi qu’il en soit, cela suppose non une unification mais un enregistrement des sémantiques et des codes – et il faut que les acteurs essaient d’en limiter le nombre, pour éviter d’alourdir la charge des systèmes et des réseaux. Des travaux nombreux sont en cours, en particulier autour des codifications de biologie. Il s’agit aussi de gérer l’internationalisation et la question des langues, ce qui va être plus aisé avec les capacités de transformation incluses dans les outils XML mais exige un effort qui ne fait que commencer.
Les EDI dans un système et un middleware
32Les EDI s’expriment dans des messages mais ils sont de plus en plus attachés à des process complets, c’est-à-dire que le travail initial de modélisation doit déterminer des séquences d’échanges. Par ailleurs, le développement des EDI suppose l’existence non seulement des réseaux mais d’un middleware puissant, autrefois assuré par des serveurs spécialisés, aujourd’hui par des services sur l’internet. Il faut en effet des annuaires précis permettant aux messages d’atteindre la bonne application sur le bon serveur. Il faut des répertoires pour les sémantiques, les schémas XML ou les messages d’autres langages. Il faut des référentiels pour les codes et il faut qu’ils soient accessibles sur l’internet. En santé, ces référentiels sont très nombreux (classifications des maladies, codes de la pharmacie, classification et codage des actes, etc.).
Enfin, la sécurisation des messages doit respecter les contraintes strictes qui sont celles de la santé et les choix qui ont été faits pour le système. Ainsi, les message incluront une signature et des éléments d’identification de l’émetteur qui seront fournis par la carte Professionnel de santé.
La méthode de développement
33La mise en place des EDI suppose l’analyse d’un domaine et la modélisation du process d’échange. La démarche est de plus en plus systématisée (cf. site EDISANTE). Les principaux éléments en sont :
- modélisation, expression du modèle des échanges dans le langage UML (Unified Modeling Language) ;
- détermination des flux à dématérialiser, identification des sous-modèles correspondants ;
- passage à des DTD ou des schémas XML (ou EDIFACT le cas échéant) ; de plus en plus, des outils vont permettre la production directe des schémas ou DTD XML (ou des messages EDIFACT ou autres) à partir des modèles UML ;
- détermination des codes pouvant être utilisés, des conditions concrètes d’implémentation ;
- détermination des méthodes pour le suivi, la mise à jour, la gestion des annuaires, des répertoires de schémas, des conditions de sécurité ;
- détermination des acteurs et groupements qui vont gérer les différents éléments en cause et garantiront la pérennité des référentiels ;
- accords permettant les interchanges, validation des aspects juridiques.
EDI et messagerie
34Dans un autre article, Emmanuel Cordonnier présente les nouvelles techniques de messagerie qui constitueront un outil essentiel pour les systèmes de santé. Ses propositions constituent le cœur du GT11 d’EDISANTE, comme de plusieurs autres actions nationales et internationales. Il est même apparu à EDISANTE qu’elles dépassaient le cadre du seul échange d’éléments de dossier pour représenter l’outil générique central de transport de l’ensemble des messages médicaux ou du domaine socio-sanitaire.
35La relation entre l’EDI et la messagerie est à la fois étroite et complexe. En effet, la messagerie est le support privilégié de l’EDI, à condition d’être améliorée à de nombreux points de vue. C’est cette évolution qui est commencée avec les travaux sur l’enveloppe, avec l’interopérabilité des messageries sécurisées de Cégétel RSS et France Télécom, avec les différents développements utilisant la CPS ou avec les échanges de biologie en HprimNet, entre autres.
36Dans les systèmes qui se mettent en place, la messagerie va supporter aussi bien les messages interpersonnels libres que les échanges de messages structurés initiés par des humains comme des comptes rendus plus ou moins automatisés et codés (EDI généré par le logiciel) ou enfin des messages automatiques. Ces derniers pourront être les messages de mouvement qu’un système d’information hospitalier peut générer et adresser aux professionnels qui suivent le patient, ou des messages envoyés par des automates de surveillance, par exemple.
Néanmoins, beaucoup reste à faire, surtout s’agissant de messages automatiques, au niveau de la conception même des logiques de messagerie, de l’intégration dans un système EDI. Le professeur Régis Beuscart a étudié ces aspects dans le cadre du réseau d’Armentières. Il a relevé les problèmes de remise des messages : si un message n’a pas été retiré dans un certain délai, il n’est pas possible de se contenter de renvoyer un avis d’échec, comme c’est fait normalement. Si le message est urgent, il faudra avoir prévu un envoi alternatif, une alerte pour l’émetteur, etc. Par ailleurs, le serveur de messagerie est loin d’être un simple support technique. Il va assurer des fonctions essentielles de traçabilité, voire de notarisation des messages. Il va de fait être un système de gestion d’information médicale…
Du message à l’assemblage d’éléments : la liberté des utilisateurs
37Comme cela a été indiqué précédemment, XML va offrir une bien plus grande souplesse, d’un double point de vue. D’abord pour permettre l’assemblage de messages divers à partir de composants de base, d’autre part pour permettre aux différentes spécialités, institutions ou pays, d’utiliser leur propre langage grâce à la technique des espaces de nommage (NameSpaces) – on peut d’ailleurs craindre que la grande indépendance d’esprit des acteurs de la santé ne les amène à profiter un peu trop largement de ces facilités, avec des conséquences redoutables en ce qui concerne la charge des systèmes d’information et de communication.
38Un élément-clé va être le développement de répertoires permettant de trouver, choisir et assembler des schémas XML, représentatifs d’objets métier, afin de créer des messages. Le process de l’avenir est en effet le suivant :
- un administrateur de système identifie un besoin d’échange, ou une modification dans les process ou dans les échanges ;
- il définit le nouveau process et les flux correspondants (en relation avec ses partenaires) ;
- il recherche sur des sites les éléments lui permettant de communiquer : les process de ses partenaires exprimés dans un modèle UML le cas échéant, les schémas XML adaptés à cet échange, les objets métier, les types et codes de variables qu’il devra utiliser ;
- il intègre ces éléments grâce à des outils de génie logiciel et définit les messages correspondant au nouveau process (ces messages peuvent être déjà stockés sur un des sites si des besoins identiques ont déjà été relevés par la communauté de métier à laquelle le développeur en cause appartient) ;
- dans le cas contraire, il informe le système serveur du nouveau type d’échange qui a été développé et des messages qu’il a définis, afin d’enrichir le répertoire.
40(On reconnaîtra au passage des types de fonctionnement qui sont aujourd’hui ceux de tous les développements objet, avec le recours à des bibliothèques, particulièrement dans le monde du logiciel libre).
41Cette perspective a conduit EDISANTE à faire de la constitution de répertoires de schémas XML un élément central de son programme d’action. L’équipe de Bertrand Poisson, au Centre technique informatique de l’assurance maladie (CNAMTS) à Metz conduit les développements dans ce domaine.
42Les travaux qui ont été réalisés dans ce cadre sont libres d’utilisation et se trouveront tous placés sur le site d’EDISANTE. Un aperçu en est donné ici par des extraits des documents techniques (voir encadré).
Ce chantier est en cours. Il illustre la complexité des tâches de construction des référentiels middleware indispensables à un nouveau développement de l’EDI dans un système qui n’est pas seulement hétérogène pour les techniques informatiques mais aussi très diversifié en ce qui concerne les techniques médicales, les pratiques et les habitudes de travail.
C’est une base outil, qui doit permettre de construire rapidement des schémas, des messages, des documents XML à partir de composants métier, en respectant des règles, en capitalisant sur les acquis, en se conformant aux normes ou aux standards acceptés par le groupe, le cas échéant.
C’est donc un outil, un entrepôt structuré. Si un utilisateur entre dans l’entrepôt, il va indiquer dans quel scénario il recherche une structure (par exemple entente préalable ou prescription) puis il va se trouver dirigé, en fonction de ses caractéristiques, dans une arborescence. Il peut aussi entrer à un niveau inférieur, indiquant qu’il veut seulement, pour un scénario bien défini d’entente préalable et en utilisant une structure de message précise, obtenir un composant métier ou encore, à un niveau inférieur, une entité particulière qui lui manque. Dans tous les cas, il ne peut construire que des messages cohérents et ne va pas se trouver confronté à de simples dictionnaires.
5 niveaux sont définis :
- types simples (XM),
- types complexes (adresses…), structurés sur des types simples,
- classes dont les attributs sont de types simples ou complexes,
- composants métiers : hiérarchie de classes,
- modèles de messages : hiérarchie de composants métiers.
A la réception d’un message ainsi préparé, et qui contient un document XML, le destinataire, s’il ne dispose pas du schéma permettant d’interpréter le document ou des types de données ou codes, pourra de son côté s’adresser à l’entrepôt pour identifier et traiter l’information.
Pour les types de données de base (noms, adresses, poids, etc.), il est actuellement proposé par EDISANTE de se référer à la norme ISO 7372 de définition EDIFACT des éléments de données, en fait indépendante de cette syntaxe, mais d’autres dictionnaires sont possibles.
Au-delà, il est exclu, dans la santé encore plus qu’ailleurs, de chercher à imposer des sémantiques à toute une profession. Dès lors, le problème de l’entrepôt est de fournir des structures (pour une prescription, un compte rendu, une demande d’autorisation) mais en laissant relativement libres les vocabulaires (pour un même message, ils peuvent varier suivant les destinataires).
C’est pourquoi, pour permettre différents usages et l’intégration dans des espaces de noms différents, l’entrepôt devrait utiliser des « composants caméléons ». Avec de tels composants (définis par des normes du Web Consortium), lorsqu’un schéma sans espace de noms cible est indu dans un autre schéma, ses composants endossent (comme un caméléon) l’espace de noms cible du schéma appelant. Le schéma appelant doit en outre déclarer son espace de noms cible comme espace de noms par défaut.
Les enjeux de l’EDI dans la santé
43Le développement des EDI n’est qu’un élément dans l’évolution profonde du système d’information de santé. Il correspond cependant à des aspects fondamentaux de ce développement : l’ouverture d’une part, l’accroissement de la coopération et des échanges entre les professionnels d’autre part.
44L’évolution des affections, les progrès de la médecine, les exigences et la mobilité des malades impliquent de plus en plus la coopération des professionnels de santé et des institutions, dans le temps et dans l’espace, autour du patient. L’exigence centrale est la continuité des soins, qui est un objectif important de la politique de santé.
45Sous l’effet de ce mouvement ainsi que sous la pression de réorganisation liée à la volonté de maîtriser et en tout cas optimiser la dépense de santé, les réseaux de soins se développent. Le progrès d’EDI normalisés est une condition pour que ce développement se fasse de façon ouverte. Il est en effet possible à un ensemble bien coordonné de définir en son sein des mécanismes d’échange, tels ceux existant à l’intérieur de chaque entreprise, et de partager ainsi l’information médicale, gérer les mouvements, etc. Cependant, aucun système ne peut aujourd’hui être fermé. Ainsi, des échanges seront inévitables pour accueillir un nouveau patient dans le réseau ou pour permettre le départ d’un autre. Un danger important serait que les réseaux, sous l’effet de la concurrence, cherchent à se protéger plus ou moins consciemment en limitant l’interopérabilité. Cette évolution est cependant peu probable car elle rencontrerait immédiatement des oppositions fortes chez tous les partenaires d’un réseau. L’heure n’est certainement pas à la fermeture mais à la sécurisation de réseaux ouverts. Il est à noter qu’aux Etats-Unis, où les organisations de santé et d’assurance maladie sont gérées avec une faible intervention de l’Etat, celui-ci a défini une norme qui va devenir obligatoire et qui vise à permettre l’interopérabilité et donc la concurrence entre les offres. C’est L’Health Insurance Portability and Accountability Act (HIPAA), dont le développement amènera aussi à permettre l’échange des dossiers et donc d’informations médicales entre les différents organismes de protection et de gestion de la santé.
46Plus immédiat sans doute que les possibilités de fermeture est le risque d’encombrement si des EDI ne sont pas mis en place et si seule la messagerie internet, fût-elle sécurisée, assure le transport d’informations entre professionnels, avec des fichiers attachés. C’est à ce risque que répondent les efforts pour des messageries et des messages structurés.
47Au-delà de la limitation de risques, l’EDI, dans ses formes actuelles, prend en compte de mieux en mieux les sémantiques et les process métier. Il passe de la définition de messages isolés à la réflexion sur la mise en relation de systèmes d’information indépendants et hétérogènes mais de plus en plus intégrés dans des processus déterminés par un commun accord. De ce fait, la démarche EDI est inséparable d’une réflexion sur le fonctionnement, sur la simplification des procédures, l’optimisation des relations et la conception d’un système coordonné de santé, avec suffisamment d’autonomie et de souplesse pour les différents acteurs mais avec la certitude de faire circuler l’information. L’ouverture permet seule la mobilité des patients et des professionnels, et ceci bientôt au niveau européen et international. L’EDI est en même temps un puissant facteur pour réduire les divergences entre les systèmes et diffuser en fait des langages et codages communs mais de façon progressive.
48De ce fait, les EDI appliqués aux données médicales permettront d’informer les systèmes de vigilance et d’épidémiologie.
49Enfin, du point de vue des coûts et des conditions de travail, le développement de systèmes automatisés, sous contrôle humain, peut libérer du temps pour les médecins et les personnels des établissements et des cabinets. Il doit permettre de réduire la charge administrative souvent importante et de dégager des forces pour les tâches médicales et de soins. La capacité d’échange de l’information médicale permet en outre d’informer les systèmes d’évaluation, de contrôle et de statistiques. L’EDI s’inscrit donc comme un outil dans l’optimisation de la dépense de santé.
Ce plaidoyer pour l’EDI peut paraître excessif. L’informatique en général, et les échanges électroniques en particulier, ne sont que des outils. Leur mise en œuvre n’apporte évidemment pas à elle seule des solutions aux difficultés du système de santé. En fait, tous ces avantages de l’EDI sont ceux de la communication. Ils apparaissent singulièrement importants dans le cas de la santé où le manque de communication dans le système est largement reconnu comme un défaut majeur et de plus en plus dangereux pour les malades comme pour la gestion de l’ensemble. La tendance à organiser des réseaux, des communications ville-hôpital, du travail de groupe, n’est pas une mode mais correspond à une nécessité. Le développement de l’EDI sera un élément de ce mouvement.
Bibliographie
Sites internet
- EDISANTE
- http://www.edisante.org
- Normalisation générale et informatique de santé
- http://www.afnor.fr
- http://www.centc251.org/
- Promotion du dossier médical informatisé
- http://www.prorec-france.org/index.php
- Normalisation et le développement des EDI en France
- http://www.edifrance.org
- EDI au niveau européen
- http://www.cenorm.be/isss/Workshop/eBES/Default.htm
- OPHIS (Organisation pour l’harmonisation en informatique de santé)
- http://www.ophis.org/
- HealthLevel7
- http://www.hl7.org/
- Groupe de travail de l’Object Management Group
- http://cgi.omg.org/corbamed/
Date de mise en ligne : 01/09/2010.
Notes
-
[1]
EDIFACT est un langage qui définit une syntaxe, des éléments de données, des segments (par exemple, adresse ou ligne de commande), des messages (par exemple, « Order » pour la commande, « Medruc » pour la demande de remboursement de soins) et c’est aussi toute une organisation de normalisation dirigée par l’ONU et reconnue par les instances de normalisation. Aux Etats-Unis, cependant, c’est ANSI X12 qui lui correspond. XML, de son côté, est une grammaire formelle, donc permettant un contrôle rigoureux, mais ne précisant rien, dans la norme proposée par le Web Consortium, en ce qui concerne les modes d’implémentation. Il faut à partir de là écrire des langages, définir des dictionnaires, etc. Le système est donc souple mais il sera nécessaire de récupérer tout l’acquis de l’EDI préexistant pour passer à un XML EDI qui sera certainement plus souple, parfois plus complexe en fait, mais accessible aux PME parce que dynamisé par toute l’industrie informatique et intégré à de nombreuses applications. EDIFACT est avant tout un langage positionnel (après telle information on doit trouver telle autre) alors que XML est fondé sur le sens, des balises délimitant les informations et s’organisant dans un arbre.