Interopérabilité dans le monde de la santé

L’amélioration de la qualité des soins du patient et la maîtrise des informations médicales deviennent plus que jamais une priorité. Il est impératif de répondre avec rapidité, pertinence et qualité aux demandes des services, médecins et partenaires sociaux, tout en assurant la confidentialité et l’intégrité des données échangées.

Les nouvelles applications de la santé devant communiquer avec les applicatifs existants, assurer une bonne gestion des flux d'informations est l'une des priorités des établissements de santé. En effet, chaque spécialité possède souvent son propre applicatif. Des données identités peuvent par exemple être saisies autant de fois qu'un patient est admis dans un nouveau service. Ainsi de manière à éviter les saisies multiples et les erreurs éventuelles, il est nécessaire de mettre en place des flux d'informations entre les applications.

Pour ce faire, des standards de format d'échanges ont été élaborés afin de permettre ces échanges : HL7, HPRIM, PN13... Toutefois, les réponses apportées par ces "standards", si elles simplifient les réalisations d'interfaces dans certains domaines, ne sont pas suffisantes dans d'autres, où existent encore de nombreux formats ou API propriétaires. Des conversions de formats sont alors nécessaires.

D'autre part, le respect des normes par les éditeurs est souvent aléatoire, et les formats échangés, bien qu'ayant une base commune, sont donc souvent propres à chaque éditeur, voire à chaque application. La communication entre deux applications devient donc impossible, chaque éditeur campant sur son format et ne souhaitant pas modifier des interfaces déjà installées sur de nombreux sites : il n'est pas rare que 2 applications ne puissent communiquer parce qu'un simple champ a été ajouté dans un message.

Les versions des formats d'échanges peuvent également être distincts entre applications, ce qui pose également un problème de compatibilité pour la communication, mais également la question de la mise à jour et du suivi des interfaces par les éditeurs : faut-il disposer de plusieurs versions des interfaces dans chaque application ? A quelle moment intégrer une nouvelle version ? Est-ce la vocation d'un éditeur de fournir des interfaces multiples ?

La réponse à la problèmatique de l'incompatibilité de formats est souvent la mise en place de passerelles spécifiques entre applications, mais la prolifération des passerelles entraîne cette fois des problèmes :

-  d'administration : les passerelles sont bien souvent développées dans des langages distincts en fonction de l'éditeur qui l'a mise en place, et disposent chacune de procédure de démarrage / arrêt spécifique.

- de supervision : comment vérifier l'état des passerelles (démarrée, arrêtée, en erreur...); là encore, ce n'est souvent qu'au bout de quelques heures que le site s'aperçoit que des informations ne sont pas parvenues à une application, et que la recherche de l'état de la passerelle s'effectue.

- de traçabilité des échanges : la visibilité sur les données échangées est bien souvent limitée à une recherche dans le journal d'émission / réception de données de chaque application, lorsqu'il existe. De plus, la reprise de données en cas d'erreur est alors une opération manuelle.

De plus, il faut tenir compte également des différentes types d'interfaces techniques (fichier, socket, script...) mis en oeuvre pour la communication de chaque application. L'arrivée de nouveaux types d'interfaces techniques, tel que les Web Services (SOA), proposés par les applications récentes, ne permettent pas une communication immédiate avec des applications plus anciennes. Des conversions techniques doivent alors être mises en oeuvre.

S'ajoute à cela, les problèmes de communications sécurisées avec les organismes externes (envoi d'informations vers le Dossier Médical Personnel - DMP, la Trésorerie...), pour lesquels des solutions techniques doivent être trouvées, les protocoles étant souvent complexes et non disponibles au sein des applications. Il est donc nécessaire de mettre en place des outils spécifiques pour traiter ces échanges.

C'est au travers d'une solution d'E.A.I. que la cohérence et la réactivité du SIH peut être garantie, de même que son ouverture vers les partenaires externes. Le choix d'une solution E.A.I. prend tout son sens quand on se rend compte de l'hétérogénéité des applicatifs sources et destinataires de données au sein de tout centre hospitalier composé de multiples services ou unités de soins. 

Ainsi, de manière à éviter les saisies multiples et les erreurs éventuelles, une solution E.A.I. doit être mise en place. Sans remettre en cause l'architecture du SIH, l'E.A.I. va récupérer, transformer et transporter les données d'applications à applications et ce, de manière complètement autonome et automatisée ; les saisies multiples ne sont alors plus nécessaires et les problèmes de communication liés aux formats, aux protocoles, ou aux technologies disparaissent.

La centralisation des flux permet une meilleure supervision des flux de données, la visibilité sur l'ensemble des flux s'effectuant au travers d'un outil unique, tout en offrant la traçabilité des échanges internes et externes, ainsi que la reprise des données en cas d'erreur.

Une fois les problèmes d'interopérabilité entre applications résolus, il est alors possible d'aller plus loin dans la vision du système d'information : ce n'est plus juste une juxtaposition d'applications échangeant des données, mais les briques de base pour mettre en oeuvre de véritables processus métier.

La complexité des processus métier auxquels doit répondre le système d'information, nécessite généralement de s'appuyer sur plusieurs applications pour réaliser un processus : la prescription d'une analyse nécessite sa prescription dans le dossier patient, (le patient devant être au préalable identifié dans la gestion administrative), son envoi vers le logiciel de laboratoire, la remontée des résultats vers le dossier patient et sa facturation dans la gestion financière. Ce type de processus métier est difficile à mettre en oeuvre avec de simples passerelles, même si elles sont la base des échanges.

Cette fois encore, c'est au travers de la mise en place d'un outil de gestion des processus métier (Business Process Management - BPM), s'appuyant lui-même sur l'outil d'E.A.I., que le système d'information répond aux besoins d'amélioration de la qualité des soins, et de la maîtrise des informations médicales.