ARCHITECTURE ET URBANISATION

MISE EN ŒUVRE DES SYSTEMES D INFORMATION DE PRODUCTION DE SOINS DANS LES ETABLISSEMENTS DE SANTE ARCHITECTURE ET URBANISATION [7] INTEROPERABILITE ET URBANISATION ELEMENTS DE DEFINITION

Copyright (c) 2006 GMSIH Permission vous est donnée de copier et distribuer ce document selon les termes de la Licence D-GMSIH, ou ultérieure publiée par le GMSIH. Une copie de cette Licence peut être consultée à l adresse http://www.gmsih.fr/licences/. 16/11/06 2/26 SI35INT V1.0.doc

Références Le GMSIH a produit les références suivantes relatives à l Architecture et l urbanisation des systèmes d information de production de soins : [1] Guide méthodologique - Architecture et urbanisation des systèmes d information Hospitaliers - SI35GUI [2] Exemple d architecture métier d un système de prise en charge du patient en unité de clinique SI35MOD [3] Présentation de l architecture métier exemple - SI35MODM [4] Exemple d architecture fonctionnelle d un système de prise en charge du patient en unité clinique SI35FON [5] Tableau de description des éléments d un système d information SI35MFAP [6] Glossaire applicable à l étude SI35REF [7] Interopérabilité et urbanisation Eléments de définition SI35INT (Le présent document) [8] Scénarios d utilisation du référentiel d urbanisation SI35SCN [9] Outil d'évaluation des pratiques d'urbanisation et de gouvernance des systèmes d'information - SI35RAD En complément, le lecteur se reportera utilement aux études précédentes qui complètent cette présente étude : [10] Alignement stratégique du système d information Décembre 2004 [11] Guide méthodologique pour l Alignement Stratégique du Système d Information SI32MEG (Inclus dans l étude ci-dessus) [12] Outil d alignement stratégique du SI SI32ASSI (Inclus dans l étude ci-dessus) [13] Analyse de l existant et des besoins des systèmes d information de production de soin Mars 2005 [14] Méthodologies et outils de conduite du changement dans les projets SI 2003 [15] Sécurité des systèmes d information des établissements de santé Juin 2004 16/11/06 3/26 SI35INT V1.0.doc

SOMMAIRE 1. Introduction...5 1.1 Objet du document...5 1.2 Définitions...5 1.2.1 Interopérabilité...5 1.2.2 Cadre d interopérabilité...6 1.2.3 Interface...7 1.2.4 Intégration...7 2. Urbanisation et interopérabilité...9 2.1 Cadres communs d interopérabilité français, européens et internationaux...9 2.1.1 DGME...10 2.1.2 Exemple : IHE - Integrating Healthcare Enterprise...10 2.2 Urbanisation et interopérabilité...11 2.2.1 Plan d urbanisme et cadre d interopérabilité...11 2.2.2 L intégration comme élément d urbanisation...12 2.3 Le cadre d interoperabilité d un établissements de santé...14 3. Architectures et technologies d intégration...17 3.1 Politique d intégration...17 3.1.1 Étude des flux d informations inter applications...17 3.1.2 Déploiement d une politique d intégration...18 3.2 Architectures de service...18 3.3 Problématiques techniques...19 3.3.1 Natures et niveaux d interface...19 3.3.2 Technologies d intégration...20 3.3.3 Les solutions techniques...21 4. Annexes...24 4.1 Références...24 4.2 Définitions complémentaires...24 4.2.1 Norme...25 4.2.2 Standard...25 4.2.3 Norme «de fait»...26 4.2.4 En conclusion...26 16/11/06 4/26 SI35INT V1.0.doc

1. INTRODUCTION 1.1 OBJET DU DOCUMENT L objectif de ce document est de fournir les éléments permettant de faciliter la compréhension des rapports existant entre une démarche d urbanisation des systèmes d information hospitaliers et la problématique générale de l interopérabilité et de l intégration logicielle. Ce document doit donc répondre à deux questions : Que signifie l interopérabilité dans le cadre de l urbanisation du système d information? Comment la mettre en œuvre lors de la mise en place d applications dans le cadre d une urbanisation? Il vise à ce titre essentiellement à fixer les notions clés de cette problématique. 1.2 DEFINITIONS Nous voulons ici donner quelques définitions initiales des termes qui seront systématiquement utilisés dans la suite de ce document. 1.2.1 Interopérabilité L'interopérabilité permet l'échange de données et de services entre des systèmes, humains et techniques, distribués, ou, considérée dans une perspective plus large, l'échange d'informations entre administrations, entre une administration et un citoyen ou une entreprise, sans impliquer de leur part un effort particulier. Au-delà de la dimension spatiale de l'interopérabilité (l'échange entre deux systèmes), la dimension temporelle doit aussi être prise en compte : l'interopérabilité vise également la pérennité des données et leur accessibilité dans le futur (persistance, intégrité, authenticité, continuité). (Abstract European Interoperability Framework for pan-european egovernment Services) L interopérabilité se décline généralement selon 3 axes : L interopérabilité organisationnelle, domaine notamment des processus métiers ; L interopérabilité sémantique ; L interopérabilité technique. L interopérabilité correspond, notamment pour les applications informatiques 1 : à la capacité, plus ou moins grande, qu ont ces applications, quelle que soit leur origine, appartenance, diversité, à coopérer entre elles, ce qui nécessite la mise en œuvre d interfaces, autant d interfaces communes qu il existe de connexions 2 à 2 d applications. L'interopérabilité est très importante, voire critique, dans de nombreux domaines, dont le médical au sens large, les activités industrielles (activités ferroviaires, l'électrotechnique, le domaine aérospatial, le domaine militaire, l'industrie en général et l'informatique) ou de service (banque, télécommunications, etc.). Les différents systèmes, appareils et éléments divers utilisés doivent pouvoir interagir sans heurts, notamment avec leurs utilisateurs humains. 1 Par application informatique, on entend tout système permettant l acquisition, le stockage, la transformation et la restitution d information de façon totalement ou partiellement automatisée. 16/11/06 5/26 SI35INT V1.0.doc

Compte tenu du fait que ces éléments sont produits par des constructeurs divers, avec des méthodes variées, et qu'ils répondent à des besoins spécifiques, l'idée la plus simple consiste à définir une base explicite, une norme, que chaque élément va «implanter» dans son propre fonctionnement. L interopérabilité ne doit pas être confondue avec l interchangeabilité et la portabilité. Les exemples ci après précisent ces différences : Interchangeabilité : Aptitude ou caractéristique de pièces, d'objets semblables ou de même destination à être utilisés sans modification à la place d'une autre pour satisfaire aux mêmes exigences : L automobile : Quel que soit le véhicule dont vous disposez, son origine, sa marque, sa catégorie, son type de motorisation, etc, il se conduit toujours avec un volant pour gérer la direction, la pédale d accélération est toujours celle de droite, la pédale de frein celle du centre, celle d embrayage (quand il y en a une) celle de gauche n importe quel conducteur peut ainsi s accoutumer très rapidement à n importe quel véhicule. Il existe plusieurs fabricants de pneumatiques, tous fournissent des pneus répondant à des normes, notamment de dimension, ce qui permet de chausser toute automobile avec des pneus de n importe quelle marque. Les bases de l interchangeabilité ont été jetées au début de l ère industrielle (Honoré Blanc, Eli Whitney XVIIIème) Portabilité, notamment dans le contexte de l informatique : Capacité d'un logiciel à être utilisé sur des systèmes informatiques de types différents : Applications écrites en Java par exemple ; Systèmes d exploitations tels que NetBSD par exemple, disponible sur plus de cinquante architectures matérielles. Mise en œuvre de l interopérabilité, exemples : Règlement à l aide d une carte bancaire : Pour la mise en relation, la communication, la facturation, le paiement par prélèvement et le relevé d opération, de très nombreux systèmes sont interconnectés. Ils mettent en œuvre des moyens organisationnels, humains et techniques différents. Mise en relation téléphonique de 2 correspondants : un appel téléphonique sous-entend, depuis le «décroché du téléphone» jusqu à la fin de la communication, la mise en œuvre de systèmes interconnectés et inter opérants hétérogènes sur l ensemble de la chaîne permettant d assurer la liaison entre ces 2 personnes. Cette chaîne comprend, outre l utilisateur, le téléphone (interchangeable) et l ensemble des moyens tant organisationnels que techniques et humains. 1.2.2 Cadre d interopérabilité Un cadre d interopérabilité est l ensemble structuré des bonnes pratiques, des normes, standards et des techniques qui décrivent le contenu du consensus auquel sont parvenues des organisations pour travailler ensemble. Ce n est donc pas quelque chose de statique, mais quelque chose qui est susceptible d évoluer dans le temps dans la mesure même où changent les techniques, les standards et les exigences des tutelles. Ce cadre peut aussi être défini comme un ensemble de politiques, de normes, de conseils et de directives décrivant comment des organisations s accordent, ou devraient s accorder, pour échanger des informations et des processus. 16/11/06 6/26 SI35INT V1.0.doc

Un cadre d interopérabilité va s appuyer sur des normes, des standards d échange et des protocoles 2 : Norme : ensemble de règles d usage et de prescriptions (références) gérées et publiées par un organisme officiel : ISO, CEN, AFNOR Standard d échange : Ensemble de règles techniques (référentiel) fixant la structure de l information qu il est possible d échanger Les standards sont généralement gérés par des organismes ad hoc (W3C, OASIS, IETF, etc.) ; Protocoles d échange : Un protocole est un ensemble des conventions nécessaires pour faire coopérer des entités distantes ou non, en particulier pour établir et entretenir des échanges d'informations entre ces entités. Par exemple, dans le domaine des télécommunications un protocole décrit les méthodes et procédures qui définissent l'accès à un support, le mode de codage et de transmission des données entre deux appareils électroniques. Certains protocoles sont des normes. : Par exemple FTAM (File Transfer Access and Management) est une norme ISO traitant du transfert, de l accès et de la gestion de fichiers. D'autres sont des standards (c'est le cas de TCP/IP, le protocole d Internet.). Par extension, un protocole est document fixant les règles et modalités procédurales d un échange et la norme ou le standard d échange utilisé ; Spécification : Définition ou détermination des caractéristiques d'une marchandise, le plus souvent un produit industriel, mais également un logiciel ou un service. En rapprochant ce cadre avec les définitions "usuelles" définies dans les cadres architecturaux utilisés pour la modélisation des entreprises, leurs processus, fonctions, etc. il s'agit de décrire, notamment au travers de l'interopérabilité organisationnelle, les politiques régissant les acteurs, leur fonctionnement et interactions, etc. Par exemple, la définition d'une charte d'identification du patient, d'une politique de sécurité, etc. entrent dans ce champ (Voir www.gmsih.fr, rubrique «étude» : Identification du patient., Sécurité des Systèmes d'information des établissements de santé.) 1.2.3 Interface Une interface est une zone, réelle ou virtuelle qui sépare deux éléments. L'interface désigne ainsi ce que chaque élément a besoin de connaître de l'autre pour pouvoir effectuer un échange d information correctement. Ce qui signifie pour les applications informatiques : Une interface est un procédé par lequel une application A met à disposition d une autre application A les éléments d information qu elle gère, en en précisant la structure afin que cette information soit interprétable. Une interface se compose de deux demi-interfaces, une demi-interface côté A permettant de publier de l information dans le format F et d intégrer de l information au format F, une demi-interface côté A permettant de publier de l information dans le format F et d intégrer de l information au format F. Ces demi-interfaces sont couramment aujourd hui appelées connecteurs. 1.2.4 Intégration Pour les systèmes d information, c est l opération qui consiste à mettre en œuvre des interfaces entre les systèmes pour qu ils puissent interopérer. 2 Veuillez vous reporter au chapitre 4.2 Définitions complémentaires en annexes pour la définition plus précise de ces notions. 16/11/06 7/26 SI35INT V1.0.doc

L intégration correspond à la mise en œuvre de solutions permettant de maximiser l interopérabilité dans un contexte technologique et fonctionnel donné. 16/11/06 8/26 SI35INT V1.0.doc

2. URBANISATION ET INTEROPERABILITE La relation entre urbanisation et interopérabilité doit être abordée selon trois points de vue : Celui du développement, dans de nombreux domaines, dont celui de l administration, de cadres communs d interopérabilité, tant au niveau français qu européen ; Celui de la relation générale entre urbanisation du SIH et interopérabilité ; Celui du contexte variable de l établissement lui-même, qui met en œuvre une démarche d urbanisation, et doit mettre en place un cadre d interopérabilité qui lui soit propre. 2.1 CADRES COMMUNS D INTEROPERABILITE FRANÇAIS, EUROPEENS ET INTERNATIONAUX Dans la sphère publique comme dans le secteur concurrentiel se manifeste une tendance forte à l ouverture des systèmes d information et à la dématérialisation des échanges. On observe fréquemment dans le secteur concurrentiel des initiatives visant : La mise en place de coopérations renforcées entre partenaires et fournisseurs ; La mise en place de nouvelles formes de commerce sur un nouveau canal : Internet par exemple. Dans les deux cas, il y a nécessité de transformer les modalités des échanges, et de favoriser cela en mettant en place des cadres communs d interopérabilité, c'est-à-dire une vision commune de l organisation (processus), des procédures et des contenus (information) à échanger. Les évolutions caractérisant durablement les administrations, qu il s agisse des services centraux de l état ou des services déconcentrés, ou encore des collectivités territoriales ou des établissements publics ou parapublics en général, dont l hôpital et les établissements de santé, sont aujourd hui les suivantes : La mise en place de services (notamment d information) aux entreprises et aux citoyens (et aux patients) ; Le développement de réseaux mettant en œuvre des coopérations nouvelles ou des éléments de mutualisation (par exemple les réseaux médicaux de spécialité) ; La dématérialisation de l information et des échanges (le dossier patient électronique, une «administration zéro papier»). Ce qui implique notamment l ouverture des systèmes d information publics, une logique de dématérialisation de l information et des échanges et la mise en place de cadres communs d interopérabilité aux niveaux français, européens ou internationaux. L émergence de ces cadres d interopérabilité se traduit notamment par la définition de formats (ou de standards) d échange et de protocoles d échange, qui concerne aujourd hui tous les secteurs d activité. Ces protocoles et standards d échange sont des langages «verticaux», c'est-à-dire couvrant des domaines métier bien délimités, qui adressent les différents secteurs des sciences, des techniques et de l économie, dans le but de fournir un support normalisé à tous les échanges : Mathématiques : MathML (Mathematical Markup Language) ; Astronomie : AIML (Astronomical Instrument Markup Language) ; 16/11/06 9/26 SI35INT V1.0.doc

Santé : HL7 (Health Level Seven), EHRCom (Electronic Health Record Communication - Norme EN 13606), DICOM (Digital Imaging and Communications in Medicine), IHE (Integrating Healthcare Enterprise) ; Banque : IFX (Interactive Financial exchange), etc. S aligner le plus possible sur ces cadres communs d interopérabilité est un gage de pérennité des choix, donc des investissements, humains, matériels et financiers, et donc une nécessité (et une obligation : cf. notamment «Circulaire du 21 janvier 2002 relative à la mise en oeuvre d un cadre commun d interopérabilité pour les échanges et la compatibilité des systèmes d information des administrations», «Ordonnance n 2005-1516 du 8 d écembre 2005 relative aux échanges électroniques entre les usagers et les autorités administratives et entre les autorités administratives», «Décret n 2005-1792 du 30 décembre 2005 portant c réation d'une direction générale de la modernisation de l'etat au ministère de l'économie, des finances et de l'industrie» qui aboutit au remplacement de l ADAE (Agence pour le Développement de l Administration Electronique) par la DGME) 2.1.1 DGME La DGME (Direction Générale de la Modernisation de l'état) succède à l'agence pour le Développement de l'administration Electronique (ADAE) et vise à centraliser tous les services en charge de ce domaine en une seule direction. Opérationnelle au 3 janvier 2006, la DGME regroupe l'ex-adae, la délégation aux usagers et aux simplifications administratives, la délégation à la modernisation de la gestion publique et des structures de l'état et la direction de la réforme budgétaire. La DGME aura désormais la charge du plan Adele d'administration électronique, qui coordonne l'ensemble des projets destinés à améliorer la diffusion des technologies de l'information dans l'administration (notamment dématérialisation des procédures administratives, télé déclaration, etc.). 2.1.2 Exemple : IHE - Integrating Healthcare Enterprise IHE est un exemple de cadre commun d interopérabilité technique propre au domaine des établissements de santé. IHE regroupe des professionnels de santé et des industriels (plus d une centaine) qui travaillent ensemble dans le but d améliorer les échanges d information entre systèmes informatiques dans le domaine de la santé. IHE promeut l utilisation de standards permettant de satisfaire des besoins cliniques spécifiques en assurant une prise en charge optimale du patient. Les systèmes informatiques compatibles avec IHE peuvent mieux communiquer les uns avec les autres, sont plus faciles à mettre en place, et permettent aux établissements de santé d utiliser l information dont ils disposent de manière plus efficace. 2.1.2.1 Prise en charge optimale du patient Une prise en charge optimale du patient requiert de pouvoir accéder efficacement à des informations de santé dématérialisées. IHE a pour but d accélérer l adoption des standards supportant une telle dématérialisation. IHE permet d améliorer ainsi la prise en charge du patient en harmonisant les échanges d informations de santé et en rendant possible de ce fait les réseaux de soins locaux, régionaux et nationaux. 2.1.2.2 Les quatre étapes de la démarche IHE IHE suit une démarche régulière pour l adoption des standards. Cette démarche se compose de quatre étapes sur un cycle annuel, pour promouvoir des améliorations concrètes de l intégration. 16/11/06 10/26 SI35INT V1.0.doc

1 Identifier les problèmes d interopérabilité : Des cliniciens et des experts SI travaillent à identifier des problèmes communs d interopérabilité en terme d information, de processus, d administration et d infrastructure. 2 Spécifier les profils d intégration : Des professionnels expérimentés des SIES (systèmes d information d établissements de santé) identifient, pour apporter une solution à des problèmes identifiés, les standards pertinents et définissent la façon de les mettre en œuvre. Ils les documentent sous la forme de «profils d intégration IHE». 3 Tester les systèmes au Connectathlon : Les éditeurs mettent en oeuvre les profils d intégration IHE dans leurs produits et testent le résultat au Connectathlon IHE annuel. Ceci leur permet d évaluer la maturité de leur implémentation et résout les problèmes éventuels dans un environnement de test supervisé. 4 Publier les décisions d interopérabilité : Les éditeurs publient les décisions d interopérabilité IHE afin de documenter les profils d intégration IHE que leurs produits supportent. Les établissements de soin peuvent alors référencer les profils d intégration IHE qui les intéressent dans leurs consultations, facilitant ainsi le processus d acquisition de solutions. 2.2 URBANISATION ET INTEROPERABILITE 2.2.1 Plan d urbanisme et cadre d interopérabilité Rappelons synthétiquement ce que l urbanisation des SIH vise : D abord à aider à traduire les axes stratégiques et objectifs des établissements de santé en une architecture métier cible (vision processus métier) partagée par l ensemble des acteurs du système d information ; Ensuite à traduire cette architecture métier en architecture fonctionnelle cible du système d information (vision fonctionnalités) ; Enfin à définir des principes directeurs du système d information. L ensemble de ces éléments constitue un plan d urbanisme qui doit servir de fondement à l élaboration d un schéma directeur, qui transforme une cible métier et fonctionnelle (plan d urbanisme) en un ensemble cohérent de projets, ordonnancés et hiérarchisés, permettant de construire une architecture applicative la mieux à même de satisfaire, sur le plan du système d information, les axes stratégiques et les objectifs opérationnels. En visant la construction d un système d information opérationnel, utilisé et utilisable, le plan d urbanisme concerne avant tout les utilisateurs eux-mêmes. Dans ce contexte, les aspects organisationnels de l interopérabilité visent à faire partager la vision «d un métier», ses aspects sémantiques permettent de faire partager une information sans altération et de se comprendre. Un plan d urbanisme, qui est le support d une vision partagée du système d information et de son devenir est à ce titre un outil d interopérabilité entre acteurs impliqués dans la modernisation du système d information. La définition d un cadre d interopérabilité est un élément qui découle d une démarche d urbanisation : La définition d une architecture métier cible (vision processus métier) permet de comprendre au niveau le plus général la structure des échanges entre acteurs (que ces acteurs soient internes à l établissement de santé ou non) ; Cette définition des acteurs impliqués dans les échanges et du contexte de leurs échanges permet de préciser le premier niveau d un cadre d interopérabilité (c est notamment ce niveau qui permet de définir des politiques et protocoles d échange). 16/11/06 11/26 SI35INT V1.0.doc

A partir d un cadre d interopérabilité plus général (de niveau supérieur), la définition d une architecture fonctionnelle cible du système d information (vision fonctionnalités) permet de préciser plus le contexte et surtout le contenu des échanges : Cette définition générale des contenus échangés permet de préciser le second niveau d un cadre d interopérabilité (c est notamment ce niveau qui permet de définir les besoins de formats d échange). Cette définition des contenus correspond à un travail sémantique sur les informations traitées dans le cadre d un métier. La définition des principes directeurs du système d information adresse notamment la formalisation d un cadre d interopérabilité propre à un établissement, conçu lui-même comme un ensemble de principes directeurs du système d information ou de sousensembles du SI : La connaissance de l existant, c'est-à-dire notamment la caractérisation de cet existant en terme de pérennité compte tenu de la définition d une cible, et la situation des éléments pérennes de cet existant dans la cible, est enfin un élément contributif à la définition du cadre d interopérabilité propre à un établissement. Les travaux portant sur la définition de cadres communs d interopérabilité propres à différents métiers, dont les métiers de la santé, dépassent largement le cadre d un établissement de santé en particulier. Ces cadres communs d interopérabilité s imposent, dans une démarche d urbanisation, comme un point de passage obligé. En effet, aujourd hui, le degré d urbanisation d un système d information hospitalier peut se mesurer à ses possibilités d évolution, qu il s agisse : De l ajout de fonctionnalités pour satisfaire des besoins jusque là mal pris en compte. Par exemple, l informatisation des unités de soins ou de certaines spécialités, l ajout d une solution de PACS ; De sa capacité à s ouvrir à de nouveaux utilisateurs ou partenaires, par exemple ceux d une médecine en réseau ; Ou de son aptitude à assimiler les nouvelles technologies de l information et de la communication (mobilité, télé-médecine, bases de connaissances en ligne, «abolition de la distance», etc.). Cette capacité d évolution repose d abord sur la qualité de l urbanisation du système d information, et, d un point de vue informatique notamment, sur la qualité de l intégration du système d information hospitalier, c'est-à-dire la maximisation de son respect de cadres communs d interopérabilité. Ces définitions de cadres communs d interopérabilité sont donc, nécessairement, des éléments à prendre en compte dans une démarche d urbanisation et dans la définition d une cible. 2.2.2 L intégration comme élément d urbanisation La mise en œuvre d un cadre d interopérabilité se traduit par la mise en place d une solution d intégration. Cette solution d intégration peut elle-même être complexe et diverse en mettant en œuvre des moyens divers. Les principales exigences auxquelles répond la mise en place d une solution d intégration du système d information hospitalier, quelle qu elle soit, sont les suivantes : Gérer l hétérogénéité ; Faciliter le changement ; Assurer l ouverture ; Assurer la qualité de service ; Sécuriser les flux ; 16/11/06 12/26 SI35INT V1.0.doc

Pérenniser les investissements. Cette solution d intégration se situant dans un cadre plus large qui inclut : La mise en place d une architecture technique performante et fiable (équilibrage de charge (load balancing), haute disponibilité liée au contexte hospitalier (24h/24, 7 jours/7), etc.) ; La mise en place de référentiels communs assurant la viabilité des échanges (structures, annuaires, nomenclatures, etc.). 2.2.2.1 Gérer l hétérogénéité du système d information hospitalier Le système d information hospitalier est composé de solutions hétérogènes. Ce n est pas un défaut, c est une réalité imposée par la nécessité de mettre à disposition de métiers différents des solutions diverses. L homogénéité est donc difficilement envisageable à l échelle d un établissement, car son système d information sert de multiples métiers et est en constante évolution. L homogénéité est impossible à l échelle de la relation entre l établissement et ses partenaires, fournisseurs et organismes de tutelles. La possibilité d échanger repose là sur la mise en place de cadres communs d interopérabilité. La capacité à supporter l hétérogénéité est la première exigence d une politique d intégration du SIH. 2.2.2.2 Faciliter l évolution du système d information hospitalier Le système d information doit servir la stratégie de l établissement et anticiper au mieux les changements dans son environnement. La connaissance des processus et des fonctions supports de ces processus permet de faciliter ces évolutions. La mise en place des nouvelles applications prévues pour couvrir les nouveaux besoins fonctionnels ne peut généralement pas attendre indéfiniment. La réactivité et la capacité à changer vite sans régressions sont des éléments vitaux pour un SIH. La capacité à faciliter le changement et l évolution est la deuxième exigence d une politique d intégration du SIH. 2.2.2.3 Assurer l ouverture du système d information de l hôpital La mise en place de réseaux d échange de l information médicale sur les patients, la télé-médecine, le télé-diagnostic, le DMP, l obligation d offrir au patient l accès à l information qui le concerne etc. sont autant d éléments qui plaident en faveur de la nécessaire ouverture du SIH. Cette ouverture signifie d abord mettre à disposition de partenaires médicaux, paramédicaux, autres établissements, réseaux, médecine de ville, patients, des informations et des services liés au cœur de métier de l établissement (informations relatives aux soins et aux dossiers des patients, la médecine en réseaux de spécialités). Cette ouverture signifie aussi mettre en œuvre des échanges commerciaux (y compris la dématérialisation) permettant plus de flexibilité et un plus faible investissement (solutions d achats électroniques (e-procurement), pour la pharmacie et les dispositifs médicaux, pour les fournitures, etc.). Cette ouverture nécessaire doit se faire dans un cadre contrôlé et sécurisé permettant notamment la protection du secret de l information médicale, la protection des flux financiers, etc. La capacité à supporter l ouverture est la troisième exigence d une politique d intégration du SIH. 16/11/06 13/26 SI35INT V1.0.doc

2.2.2.4 Sécuriser les flux Sécuriser les flux est une exigence forte dans un système gérant de multiples flux critiques dont la satisfaction nécessite : De gérer une authentification de qualité (Authentifier l auteur du message (flux externe), ou la référence de l application (flux internes) ou l identité du récepteur du message, etc.) ; De gérer la confidentialité (s assurer que le message ne peut être compris et déchiffré que par les parties, émettrice et réceptrice, assurer la traçabilité des flux, etc.) ; De gérer l intégrité (garantir que le contenu du message n a été ni altéré ni modifié par un tiers, garantir l intégrité des transactions (avec opération de compensation) ; De gérer la non-répudiation (disposer de la preuve de la qualité de l émetteur, de l émission et de la réception du message, etc.). La capacité à sécuriser les flux est la quatrième exigence d une politique d intégration du SIH (voir sur ce plan les études du GMSIH citées en référence. 2.2.2.5 Assurer la qualité de service L hôpital soigne 7 jours sur 7 et 24h sur 24. Un patient admis dans un état critique aux urgences un dimanche à trois heures du matin doit pouvoir être pris en charge dans des conditions de qualité et de sécurité des soins comparables à celui qui entre à l hôpital un mardi à 14H30. Il faut donc garantir la qualité de service et la haute disponibilité des applications et, implicitement des informations, compte tenu développement de la couverture fonctionnelle de ces applications et du recul des dossiers papier. Parce que l hôpital ne s arrête jamais, parce que l information qu il manipule est critique, il faut définir pour l informatique hospitalière des contrats de qualité de service en conséquence, et assurer la sécurité et la confidentialité des données. La capacité à assurer la qualité de service est la cinquième exigence d une politique d intégration du SIH. 2.2.2.6 Garantir la pérennité des investissements informatiques Le système d information d un hôpital est un patrimoine. Ses outils informatiques sont des composantes tangibles de ce patrimoine. Garantir la pérennité des investissements correspondants nécessite : De mettre en œuvre des services d infrastructure réutilisables et indépendants des évolutions du système d information ; De rationaliser des moyens d échanges entre applications au travers du respect des normes et des standards (cf. études et recommandations du GMSIH). La capacité à pérenniser les investissements informatiques est la sixième exigence d une politique d intégration du SIH. 2.3 LE CADRE D INTEROPERABILITE D UN ETABLISSEMENTS DE SANTE Le cadre d interopérabilité que doit mettre en place un établissement dans le cadre de son plan d urbanisme dépend du périmètre et de la nature de celui-ci. 16/11/06 14/26 SI35INT V1.0.doc

L intégration du système d information hospitalier est une question complexe compte tenu de la grande diversité des applications d ores et déjà déployées, ou à déployer dans un futur proche, diversité qui correspond aussi à la très grande diversité des métiers et des activités au sein de l hôpital. Les besoins d intégration, et de flux d informations entre applications, que le schéma suivant synthétise, sont les suivants : On y distingue les flux internes entre les différents domaines fonctionnels de l hôpital, et les flux externes, dont le nombre et la complexité ne cessent de croître ; L objectif de l intégration du SIH est de parvenir à relier ces différents domaines fonctionnels ; On notera l importance toute particulière des référentiels qui constituent une base de normalisation des échanges : Un référentiel de structure va permettre à toute application de disposer de la même vision de l organisation de l hôpital ; Une nomenclature médicale, par exemple la CIM10, va permettre à toute application médicale de partager la désignation d un même diagnostic ; Un référentiel de personnes partagé va permettre de retrouver les acteurs pertinents sans risque d erreur, etc. etc. Ce périmètre d intégration est un des éléments de la définition du cadre d interopérabilité propre à un établissement. Le schéma ci-après doit être lu comme une simple illustration : 16/11/06 15/26 SI35INT V1.0.doc

Référentiels (structures, nomenclatures) Ressources Humaines Trésor Public CNAMTS Gestion Economique et Financière Gestion Administrative du Malade Mutuelles ARH Imagerie Laboratoires Unités de soins DOSSIER PATIENT PATIENT Pharmacie Blocs Réseaux médicaux (régionaux, spécialités) Organismes de santé publique DMP Logistique Établissement Français du Sang 16/11/06 16/26 SI35INT V1.0.doc

3. ARCHITECTURES ET TECHNOLOGIES D INTEGRATION Pour assurer cette intégration il existe de multiples solutions, la réalité actuelle de tout SIH est parfois une combinaison de ces solutions. Nous présentons ici les principales solutions susceptibles de servir le déploiement des futurs systèmes d information hospitaliers en assurant au mieux les exigences de l intégration. 3.1 POLITIQUE D INTEGRATION Mettre en œuvre une politique cohérente d intégration nécessite d abord de connaître son système informatique existant, puis, en fonction des projets stratégiques d évolution et de l architecture cible définis dans le projet d urbanisation du SIH, de définir la politique d intégration. Les éléments permettant d instruire cette politique d intégration sont synthétiquement évoqués ciaprès. On y retrouve, sans surprise, nombre d éléments qui constituent les pièces d une démarche d urbanisation. 3.1.1 Étude des flux d informations inter applications Recensement des applications et des sources de données De ce travail résulte la carte d urbanisme contenant les domaines fonctionnels, pour chaque domaine la liste des applications utilisées, avec une description de chaque application : éditeur, fonctionnalités offertes et utilisées, définition des informations traitées (signification, règles et contraintes associées), informations techniques. Identification et description des flux de données inter applicatifs En complément de l étape précédente, l objectif est ici de construire une vision dynamique du système informatique en représentant les échanges entre applications. Le nombre important des flux (plusieurs centaines) et la nécessaire recherche de l exhaustivité dans le contexte de la mise en place d une politique d intégration incitent à réaliser plusieurs vues. Nous recommandons l étude des vues centrées sur les flux stratégiques suivants : Flux de structure ; Flux associés aux patients et personnes ; Flux de prescriptions, de demandes et de résultats ; Flux associés aux actes, diagnostics et PMSI ; Flux externes (en général en fort développement et soumis à des niveaux de sécurité élevés), etc. Détermination des modes d échanges et des formats de données Cela consiste, une fois les flux identifiés, à recenser et décrire les différents modes d échanges et les formats de données. Modes d échanges : fichiers, interrogation de file d attente, base de donnée tampon, utilisation d API, etc. Pour des raisons liées aux évolutions tant technologiques qu applicatives et fonctionnelles, les modes d échanges de données dans le domaine hospitalier sont en général très divers d un type de flux à l autre, mais peuvent l être également pour un même type de flux. Ces modes d échange s appuieront sur le cadre d interopérabilité ; 16/11/06 17/26 SI35INT V1.0.doc

Formats de données : Les formats de données doivent être identifiés avec précision pour pouvoir faire un état des lieux par rapport aux formats en vigueur dans le monde hospitalier : Echange de données médicales : HL7, DICOM, PN13, HPRIM etc. Echange de données administratives : HMandat, Htitre, Noé, B2 / Noémie, etc. 3.1.2 Déploiement d une politique d intégration Le déploiement d une politique d intégration est un chantier complexe et lourd dont il est impossible de considérer qu il peut se faire dans un temps court et en mode «big bang». Ce déploiement est progressif et accompagne (et prépare) les évolutions du système d information dans son ensemble. C est en fonction de la cible d évolution définie dans le projet d urbanisation que va être organisée la transition vers une nouvelle politique d intégration. Cette politique d intégration va influer sur : Le dispositif d administration et de supervision des flux ; Le dispositif de stockage et de sauvegarde des données ; Les orientations générales du Service Informatique en matière d architecture ; L organisation actuelle du Service Informatique etc. 3.2 ARCHITECTURES DE SERVICE Construire une architecture de services est une stratégie qui consiste à structurer le système d information comme un ensemble d applications ayant la capacité d exposer leur interface fonctionnelle : De fait, il s agit d une solution technique plus facile à adopter sur de nouveaux projets pour lesquels le recours à des technologies de développement à base de composants devient de plus en plus fréquent ; Cependant, elle peut aussi aider à rapidement intégrer des applications patrimoniales (legacy) pour satisfaire des besoins d'évolution fonctionnelle ou pour prolonger la vie des systèmes existants sans réécriture. Cette démarche conduit à un modèle d architecture plus élaboré mais aussi plus évolutif, dans lequel une couche spécifique prend en charge la logique d intégration. L avantage est de découpler les exigences d évolution les unes des autres. Ce modèle d intégration orientée «services» (SOA - Service Oriented Architecture) permet de satisfaire des besoins de collaboration plus forte entre les applications d un système ou avec celles des systèmes de partenaires. Cette cible architecturale est une infrastructure logicielle qui englobe des composants applicatifs relativement autonomes, les met à disposition au travers du réseau en les répertoriant dans un annuaire, et permet leur utilisation au travers d un modèle de communication indépendant des technologies d implémentation. Du point de vue de l interopérabilité, les avantages procurés par ce modèle architectural sont : Des interfaces indépendantes des plates-formes technologiques d implémentation des applications ; 16/11/06 18/26 SI35INT V1.0.doc

Un couplage faible entre les applications ; Une granularité des échanges de niveau «métier» (les services invoqués et les documents échangés ont un véritable sens fonctionnel) ; Une fluidité des échanges, pouvant se faire en temps réel (communication en mode synchrone) ou en temps différé (asynchrone) ; Des communications qui peuvent s appuyer sur des couches de transport hétérogènes ; Une intégration avec d autres systèmes qui peut se paramétrer rapidement. Donc un système d information informatisé plus évolutif, mieux urbanisé. Elle conduit ainsi à une réutilisation maximum et systématique des données et des applications. Le concept d architecture orientée services, après avoir été l objet d implémentations initiales, revient aujourd hui sous les feux de l actualité, du fait de l apparition d un ensemble de nouvelles technologies les Services Web directement dérivées du langage XML. 3.3 PROBLEMATIQUES TECHNIQUES Aujourd hui, il existe sur le marché des solutions susceptibles d aider à l intégration du SIH, ce sont ces solutions que nous présentons ici sommairement dans leur principe. 3.3.1 Natures et niveaux d interface L informatique centrée sur le réseau, y compris celle mettant en œuvre les technologies Internet, utilise un modèle client-serveur généralisé, où les applications ont entre elles des relations d échange de données et/ou d invocation de services, qui passent par la mise en œuvre d interfaces. On distingue 7 niveaux distincts de gestion des interfaces (les couches ISO) qui visent à permettre une approche modulaire qui rend indépendants les programmes traitant des divers niveaux : Niveau 1 : Physique. C est le niveau le plus bas de prise en compte de l interopérabilité, la couche physique (le câble par exemple) s'occupe de la transmission brute sur un canal de communication, cette couche garantit la transmission des données (un bit à 1 doit rester un bit à 1). L'unité d'information de la couche physique est le bit. Niveau 2 : Liaison. C est le niveau de gestion plus élaboré des signaux qui circulent sur un réseau en assurant une liaison exempte d'erreurs de transmission. Elle fractionne les flux de données en trames, les transmet en séquence et gère les trames d'acquittement. L'unité d'information de la couche liaison est la trame (quelques centaines à quelques milliers de bits). Les niveaux «physique» et «liaison» sont pris en charge par des solutions telles que X25, Frame Relay, Ethernet, RNIS, Token Ring, ATM, etc. Niveau 3 : Réseau. C'est la couche qui permet de gérer le routage et l'interconnexion des réseaux entre eux. L'unité d'information de la couche réseau est le paquet. Niveau 4 : Transport. Cette couche gère l acheminement de messages complets, qu elle prend, découpe s'il le faut et s'assure qu ils arrivent bien au destinataire. Cette couche effectue aussi le réassemblage de message à la réception des morceaux. L'unité d'information de la couche réseau est le message. 16/11/06 19/26 SI35INT V1.0.doc

Niveau 5 : Session. Cette couche organise les échanges de messages, les synchronise entre tâches distantes. Elle organise l'interaction. Une solution connue pour le niveau réseau et le niveau session est TCP/IP, niveau réseau IP (Internet Protocol), niveau transport TCP (Transport Control Protocol). Niveau 6 : Présentation. Cette couche s'intéresse au contenu transmis (syntaxe et sémantique). Elle traite l'information de manière à la rendre compatible entre acteurs et tâches communicantes, elle convertit les données, les reformate, les chiffre, etc. (la production d information est aussi concernée par cette couche). Niveau 7 : Application. Cette couche met en contact l'utilisateur et le réseau, elle apporte à l'utilisateur les services qu il offre, par exemple le transfert de fichier, la messagerie... (A ce niveau sont aussi intégrés HL7, EHRCom, CCOW, etc) Les solutions connues qui correspondent à ces niveaux 5 à 7 sont des protocoles tels que HTTP (Hyper Text Transfer Protocol), FTP (File Transfer Protocol), SMTP (Simple Message Transfer Protocol), POP (Post Office Protocol), etc. et des solutions telles que HTML (Hyper Text Markup Language) et CGI (Common Gateway Interface). Toute solution d interopérabilité va nécessairement mettre en œuvre nombre de ces protocoles. On distingue par ailleurs deux modes d interfaçage entre applications : Interfaçage sans connexion (asynchrone) : Chaque échange est mono-directionnel et n a pas de connaissance d autre contexte que le sien. Les deux applications ne sont pas nécessairement actives en même temps. On parle de communication asynchrone et de couplage faible entre les applications. Interfaçage avec connexion (synchrone) : Une session d échanges bi-directionnels est maintenue entre les applications. Les deux applications sont nécessairement actives en même temps et en permanence durant tout le dialogue. On parle de communication synchrone et de couplage fort entre les applications. Parce qu une des exigences que doit satisfaire l intégration est de faciliter le changement du SIH, les interfaçages sans connexion doivent être favorisés : cet interfaçage maximise la facilité à faire évoluer le système. 3.3.2 Technologies d intégration Un des supports habituel de l interopération est la mise en œuvre de middlewares. On distingue généralement six catégories de middleware : Accès aux bases de données : Ce type de middleware est fourni sous forme de pilotes permettant à une application de se connecter à une base de données et de lui transmettre des requêtes à traiter. Ces pilotes encapsulent directement l'interface du SGBD, et isolent ainsi l application cliente des particularités d une interface propriétaire de la base de donnée (le standard SQL n étant pas totalement respecté par les éditeurs). Appel de procédures à distance (ou RPC, pour Remote Procedure Call) : Ce mécanisme permet d'exécuter une fonction située dans un autre exécutable pouvant être sur une machine distante. Son but est de masquer à l appelant qu une procédure appelée s exécute sur une machine distante, et donc, de lui offrir une interface comme si elle était locale. File d attente de message : Des messages sont placés dans des files d attente auxquelles d autres applications sont abonnées. Ce type de middleware orienté message (ou MOM, pour Message Oriented Middleware) découple les applications communicantes. Il permet une communication asynchrone et autorise des échanges dans des environnements distribués hétérogènes. 16/11/06 20/26 SI35INT V1.0.doc

Invocation d objets ou de services à distance : Ce type de middleware (par exemple ORB, pour Object Request Broker, qui généralise le RPC au monde de la programmation objet) permet à des objets distribués de communiquer. Une variante actuelle de cette technologie est celle des Web Services basée sur les technologies Internet. Contrôle de transactions : Il s agit des moniteurs transactionnels (ou TPM, pour Transaction Processing Monitor) dont le rôle est de contrôler, dans un environnement distribué complexe, l exécution de traitements transactionnels en assurant le caractère ACID de la transaction (Atomique, Cohérente, Isolée, Durable). Interfaces propriétaires (par exemple les interfaces de type «objets métier» des progiciels) : Il s'agit de solutions sur-mesure optimisées pour une application particulière. Une solution d intégration logicielle va mettre en œuvre tout ou partie de ces catégories de middlewares et les combiner pour les besoins de l interopérabilités des applications d un système informatique déterminé. 3.3.3 Les solutions techniques 3.3.3.1 EAI (Enterprise Application Integration) Les multiples interconnexions nécessaires entre les applications du système d information hospitalier sont souvent développées dans une vision point à point. Il s agit d interconnecter chaque application avec les sources de données qu elle utilise ainsi qu avec les autres applications qui lui fournissent des événements sur ses données (changement d état, création d un nouvel objet etc.), ou d autres données qui lui sont nécessaires. Ce modèle aboutit à un développement qui rend redondantes de nombreuses fonctionnalités d interconnexion d applications, ce que le Gartner Group appelle «Système plat de spaghettis». Les principaux écueils rencontrés dans ce modèle de développement sont tout d abord le coût du développement (renouvelé pour chaque nouvelle application), puis le coût de la maintenance de ces nombreuses interfaces durant le cycle de vie de l application (n applications communicantes 2 à 2 = n(n-1)/2 interfaces : 10 applications=45 interfaces (soit 90 connecteurs), 100 applications=4950 interfaces (soit 9900 connecteurs), une application change et c est 99 interfaces (198 connecteurs) qui changent!). Fort heureusement, les systèmes d information n ont pas totalement ce niveau de connexité : le développement d un connecteur est l équivalent du développement d une application plus ou moins complexe. Un écueil majeur est lié à la grande complexité des échanges entre les applications. Cette architecture s oppose alors assez rapidement à l accroissement de la capacité d évolution et d ouverture du SIH. Les solutions d intégration visent donc à rompre avec cette vision point à point des communications inter-applicatives en fournissant une plate-forme unique et homogène de gestion des échanges, le modèle centralisé, généralement appelé «hub & spoke» (moyeux et rayons). Du point de vue de l exploitation, la plate-forme d intégration étant le point de passage obligé de toutes les communications inter-applicatives, elle fournit un outil homogène d administration des flux qui permet d en fédérer l utilisation, le nombre d interfaces se réduit strictement au nombre des applications, la mise en œuvre d un format pivot dans la solution d EAI permettant de minimiser encore plus l effort de développement de connecteurs : une interface se réduisant dans ce cas à la mise en œuvre d un seul connecteur. La plate-forme d intégration assurera diverses fonctions : Fonction de gestion des communications, synchrones ou non, et de transport ; Fonction d adaptation qui permet la transformation de formats de flux entrants ; Fonction de routage et de transformation en fonction du destinataire du flux. 16/11/06 21/26 SI35INT V1.0.doc

Ces fonctions minimales sont celles des solutions qu on appelle parfois «EAI tactique», elles simplifient déjà grandement l administration des flux. Les grandes solutions d EAI incluent généralement aujourd hui des fonctionnalités supplémentaires de gestion (BPM : Business Process Monitoring) et de supervision (BAM : Business Activity Monitoring) des processus. Elles permettent de gérer explicitement la logique métier d enchaînement des flux. 3.3.3.2 Enterprise Service Bus (ESB) Le principe des ESB est comparable à celui de l EAI à la différence qu il se contente d assurer les fonctions de communication et de routage sans prendre en charge les fonctions de transformation. En effet, la mise en place d un ESB correspond à un contexte où l ensemble des applications est capable de communiquer dans un format d échange commun et banalisé. Ce format est le langage du bus logiciel d échange, quel que soit par ailleurs le format interne de chaque application connectée. Dans cette approche, toute application, quelle que soit la structuration de l information qui lui est propre, communiquera dans un langage commun et banalisé avec toutes les autres applications : Le langage pivot du système d information, celui qui supporte l intégration. La mise en œuvre d une telle solution nécessite l adoption généralisée et la mise en œuvre contrôlée de standards d échange par les éditeurs de solution, nous en sommes loin aujourd hui. La mise en œuvre d un EAI avec un format pivot global est une solution technologique de mise en place d un ESB indépendamment de la bonne volonté des éditeurs. 3.3.3.3 Web Service Oriented Architecture (WSOA) Les technologies de Services Web sont édifiées sur un très important socle de spécifications, dont les plus importantes sont en cours de normalisation. Elles dérivent toutes du langage standard XML, normalisé en 1998, et font largement appel aux spécifications associées XML Namespaces et Schéma XML. La standardisation de ces technologies est placée sous le contrôle de deux organisations : Le W3C (World Wide Web Consortium) ; L OASIS (Organization for the Advancement of Structured Information Standards). Ceci est susceptible de contribuer à la réalité d un usage standard de ces solutions. Cette approche n est nullement alternative mais complémentaire d une approche EAI, notamment dans le cadre de la mise en œuvre de solutions de BPM. 3.3.3.4 Les portails d information et de service Un aspect particulier de l intégration, différent et complémentaire de ce qui a été évoqué précédemment, est celui de l intégration du poste de travail. Cette notion d intégration du poste de travail correspond au constat que de nombreux utilisateurs sont susceptibles d avoir à utiliser de nombreuses applications distinctes, et de devoir accéder à des sources d informations diverses. Plutôt que d obliger l utilisateur à lancer et à s authentifier sur les diverses applications qu il utilise et à aller à la recherche de l information dont il a besoin, l idée d un «portail» d information et de service est de proposer un point d entrée et d accès unique à l ensemble du parc applicatif et informationnel d un utilisateur déterminé. Un portail va être le point d entrée unique du SIH : un utilisateur qui s y connecte et s y authentifie, ouvre une interface homme machine (IHM) unique au travers de laquelle il va pouvoir accéder aux informations qui lui sont pertinentes (et autorisées), et aux applications qui lui sont utiles (et auxquelles il a droit). 16/11/06 22/26 SI35INT V1.0.doc