L’informatique hospitalière ou la dérive vers le privé

Les années 80

Dans les années 80, l’informatique hospitalière était limitée à la paye, à la facturation. L’informatique était gérée par les CRIH (Centre Régionaux d’Informatique Hospitalière), les développements étaient pour la plupart nationaux et réalisés par le CNEH (Centre National de l’Expertise Hospitalière). Chaque hôpital contribuait, par le biais d’une cotisation, au fonctionnement de ces centres. Les CRIH développaient aussi des solutions, orientées télétraitement et les mettaient à disposition des hôpitaux ou d’autres CRIH. Les participations aux développements se faisaient par conventions entre les hôpitaux, permettant de mutualiser les coûts.

C’est aussi la période où les hôpitaux développaient leurs infrastructures autour de « hosts » (Bull ou IBM). L’offre était limitée, la couverture fonctionnelle administrative (gestion du personnel, gestion comptable, gestion du dossier administratif du patient). Jusqu’à la fin des années 80, l’offre publique s’est progressivement développée afin de commencer à prendre en compte le dossier médical, le dossier infirmier, les prises de rendez-vous.

Tandis que les gros hôpitaux ouvraient petit à petit leur couverture fonctionnelle, les établissements plus petits peinaient à la mise en place de solutions. Les développements n’étaient pas coordonnés au niveau du ministère de la santé, des offres publiques, concurrentielles entre elles virent le jour. Des forums d’informatiques hospitaliers permettaient à chaque hôpital de présenter ses développements.

La somme des budgets alloués aux services informatiques dans les hôpitaux subit une première explosion. En 1991, l’IGAS fut missionnée pour faire une « Mission d’audit de l’informatique Hospitalière et d’évaluation de la Politique publique en ce domaine »[1].

Les années 90 et 2000

L’audit de l’IGAS fut confié à la société Bossard Consultants, société contrôlée par le groupe Cap Gemini. Cet audit dénonça l’émiettement de l’offre, les coûts importants, les objectifs non atteints, tout en relevant la pertinence d’un GIE référence, GIE intimement lié à Cap Gemini (« Cap Sesa Informatique Hospitalière »).

Dans ses conclusions, l’IGAS souhaitait une meilleure coordination des offres publiques afin de permettre les coopérations pour développer la couverture fonctionnelle, notamment autour du dossier patient. Elle alertait sur un risque « … fort de voir les sociétés privées “acheter” par ce biais, et en dehors de toute mise en concurrence, une clientèle alors que les centres producteurs déclineraient » alors que paradoxalement dans sa gestion actuelle ce projet risque d’être le “cheval de Troie” d’une offre particulière, celle de Cap Sesa Informatique Hospitalière. En page 58 de l’audit, toutes les propositions allaient dans le sens d’une offre publique, pour limiter les coûts. La plupart de ces propositions n’ont pas été suivies.

Dans les années qui ont suivi, faute de prise en compte des propositions de l’IGAS, une offre concurrente privée, s’est développée. Un cas type est celui de la société « Pyrénées informatique », offrant une solution intégrée sur AS400. IBM, voyant une opportunité de marché a racheté cette société puis a délaissé l’offre privée en logiciels hospitaliers, faute de rentabilité.

Siemens s’est très vite porté acheteur de cette offre, vendue par IBM, y voyant un moyen d’acheter un « portefeuille hospitalier existant » et arrêta rapidement la maintenance de la solution existante pour obliger les sites hospitaliers à installer son offre propre « Clinicom » venue des USA. Tous les hôpitaux s’étant engagé sur AS400 se trouvaient face à une obligation de migration, avec les coûts que cela représente… Et quelques années plus tard (2011) Siemens vendit à son tour son portefeuille « Clinicom » à la société « Intersystem » qui s’empressa de tuer la solution pour la remplacer par sa solution « Trakcare » venue des USA.  À chaque revente, les hôpitaux se retrouvaient captifs, comme l’avait prévu l’audit de 1991, à chaque migration obligatoire, les hôpitaux faisaient exploser leur budget informatique.

Parallèlement, des grosses sociétés, souvent dirigées par des multinationales virent dans cette désorganisation de l’informatique hospitalière un marché juteux. Le libre choix des hôpitaux, puis l’obligation de mettre en concurrence les solutions publiques et privées ouvrit le marché à ces sociétés à vocation lucrative.

La situation actuelle

Une offre complète, trop complète

L’informatique est dorénavant partout, dans toutes les unités de soins, les sociétés privées ont trouvé peu à peu leur créneau, leur spécialité.

Quel que soit le domaine, la spécialité médicale ou médico-technique, il existe plusieurs solutions sur le marché. Le règne de l’appel d’offre a diversifié les choix pour des hôpitaux partageant parfois le même personnel, obligé à se former à plusieurs solutions totalement différentes au niveau ergonomique pour pouvoir exercer son métier de soignant.

Une intégration complexe

Cet éclatement des solutions rend souvent très difficile leur intégration au niveau de l’hôpital. Cette intégration est chronophage et source de problème de sécurité. Les informaticiens hospitaliers ne sont plus maîtres de leur système mais simples intermédiaires entre les services et les prestataires informatiques. Très souvent les centres hospitaliers doivent gérer 4 à 5 SGBD[2] différents avec tous les problèmes que cela représente en formation, en sauvegardes. Une série de choix qui aboutit à l’externalisation des prestations informatiques[3]. Si l’usage de HL7[4] tente à se généraliser, s’il permet des échanges standards entre les applications, on est très loin du système intégré.

Des failles de sécurité énormes

Chaque solution a ses contraintes, en version de système d’exploitation serveur, parfois même en version de système d’exploitation client et même en version de navigateur. Ce nombre multiple de versions de systèmes n’est pas sans risque au niveau des failles. Et l’intégration des appareils médicaux dans les systèmes d’information hospitaliers apporte son lot de failles[5].

Vitry-le-François : cyber-attaque à l’hôpital, les pirates demandent une rançon (francetvinfo.fr)

Internet : des hackers revendent nos données médicales (francetvinfo.fr)

En 2022, un établissement hospitalier est rançonné par un malware chaque semaine en France. En avril, le système centralisé d’approvisionnement des pharmacies en France a été attaqué. Et en juin, le système AMELIE a été siphonné, et les données revendues sur le Dark Net.

Les GHT (Groupement Hospitalier de Territoire), une fausse « bonne solution »

L’informatique doit évoluer vers une homogénéité au niveau des GHT, mais le mal est déjà fait et le pansement sur une jambe de bois risque d’être très coûteux.

L’homogénéité va se faire en imposant aux plus petits hôpitaux des solutions privées, qui vont amputer le budget de ces derniers. L’offre privée en informatique hospitalière est trop souvent une niche et les solutions sont vendues à coût pharamineux.

Les pistes de réduction du TCO ne sont pas explorées

L’informatique hospitalière est le règne du tout Windows, sur serveur et sur station. Les équipes informatiques sont mobilisées sur les évolutions matérielles et logicielles, aucune solution de réduction du coût total de possession TCO[6] n’est envisagée, comme cela a été fait dans la gendarmerie nationale.

Les hôpitaux sont tributaires des tarifs imposés par les sociétés qu’ils ont choisies et ne sont plus maîtres de leur budget informatique, transféré en partie sur les GHT. Tout cela dans un contexte budgétaire global sous pression.

La sécurité informatique globale est donc laissée de côté, faute de moyens[7].

Retrouver le contrôle en développant un pôle public d’informatique hospitalière

« Easily[8] » est à ce jour un des logiciels publics de gestion de dossiers médicaux qui s’implante dans de nombreux hôpitaux. Mais repose sur une concurrence public-public.

Dans ce contexte, la seule solution serait de repartir de certaines propositions de L’IGAS en 1991[9], des solutions libres dans chaque domaine existent déjà, il faudrait une volonté gouvernementale pour participer à leur développement et les imposer. Il faut pour ce faire utiliser et mobiliser les personnels informatiques en place pour développer de manière coordonnée des outils dans un cadre national.

Les revendications des professionnels (et des patients) s’articulent autour de deux objectifs :

  • Un outil ergonomique permettant de colliger et d’avoir un accès simple, rapide et ubiquitaire aux informations concernant le patient pour assurer une prise en charge optimale ;
  • Une collecte de données anonymisées permettant la réalisation d’études cliniques, épidémiologiques et autres sous le contrôle des professionnels en accord avec les patients.

Nous avons donc deux besoins différents, donc de deux outils différents qui doivent bien entendu communiquer entre eux, mais qui doivent aussi permettre une certaine étanchéité afin d’assurer la meilleure sécurité possible en termes de protection des données. Deux exigences dont la France maitrise les moyens d’y répondre.

Le premier point correspond en fait au fameux Dossier médical partagé (DMP), serpent de mer et échec très coûteux, qui fait qu’aujourd’hui nous ne disposons toujours pas de l’outil qui apparaît de plus en plus essentiel pour assurer un suivi efficace et sécurisé des patients.

Le seul progrès de ces dernières années est l’informatisation du dossier hospitalier du patient, de qualité variable selon les hôpitaux qui ont fait appel à différents prestataires, ce qui signifie une grande hétérogénéité des systèmes installés. De fait les systèmes ne communiquent pas entre eux. Ils offrent en général une qualité et une ergonomie acceptable limitée au travail au sein de l’hôpital. Or le besoin essentiel aujourd’hui se focalise sur un dossier interopérable entre les professionnels de ville et hospitaliers.

Afin de pouvoir disposer de ce type d’outil, il est essentiel de privilégier une architecture légère, souple et décentralisée. En effet, si le dossier du patient doit pouvoir être consulté en tant que de besoin tout au long de sa vie, l’essentiel des accès se feront localement par les professionnels du bassin de vie du patient (ville, hôpital général et jusqu’au CHU de référence).

Le deuxième point concerne l’opération Health Data Hub très contestée, puisque le conseil d’administration de la CNAM a récemment rejeté le projet du gouvernement au motif que « conditions juridiques nécessaires à la protection de ces données ne semblent pas réunies pour que l’ensemble de la base principale soit mis à disposition d’une entreprise non soumise exclusivement au droit européen ».

Dans le même temps, il rappelle que « compte tenu du caractère spécifique des données au regard de leur complétude et de leur enjeu stratégique, seul un dispositif souverain et uniquement soumis au RGPD permettra de gagner la confiance des assurés dans l’utilisation de leurs données » et demande que le Système national des données de santé (SNDS) soit confié « à un opérateur souverain et de confiance pour l’hébergement des données ». Nous disposons donc là d’un appui pour que la base de données de la Sécurité sociale qui, rappelons-le est une des plus complètes au monde, reste sous un contrôle national.

La question qui se pose aujourd’hui est de pouvoir disposer de prestataires français, voire européens, dans le cadre de la stratégie industrielle qui est proposée dans le texte. L’annonce faite en octobre 2021 d’un accord entre Thales et Google en vue de la constitution d’un « cloud souverain » est très grave. Il aggrave notre dépendance et notre manque d’autonomie alors qu’il nous faut mobiliser les forces endogènes du pays. Si ce n’était pas une annonce officielle, cela pourrait passer pour une blague, tant l’association des termes « Google » et « Cloud souverain » sont antinomiques !

La situation mondiale fait déjà état d’une hégémonie des mastodontes Amazon, Microsoft et Google en termes d’offre Cloud, pourquoi s’associer à l’un des 3 monopoles pour « construire un Cloud Européen indépendant » ? La longueur de la cuiller n’y fera rien, il s’agit bien de « souper avec le diable», le Cloud European Act du commissaire européen Thierry Breton (et ancien patron de THOMON ou d’ATOS) est très mal parti …

Nous dénonçons ici ce double langage, cette contradiction entre les déclarations de principe et les actes. Il faut cesser les « coopérations » avec les Microsoft ou Google, et remettre les chercheurs européens sur des pistes indépendantes (des brevets indépendants existent, mais ils sont anciens : il faut reprendre les recherches). Pour cela, il faut des moyens en hommes et en financements, mais il faut d’abord une politique claire, et autonomes par rapport aux GAFAM ou aux puissances tiers (USA, Chine, Taiwan …).

Sylvain Delaitre, CGT Thales

Notes annexes

1. Choix des gendarmes sur les OPENSOURCES.

Ils ont résisté à l’injonction du Gouvernement Sarkozy de passer à Microsoft. Le FIC de Lille (cybersécurité), avec le Général Marc WATIN AUGOUARD (4 étoiles) refuse de s’aligner sur le système privé américain.

Aujourd’hui, 90% des postes informatiques de la Gendarmerie sont sous Linux, un système d’exploitation libre. Une preuve qu’il est possible, pour une administration, de se passer des Gafam, et de réaliser 40% de gain.

https://lafibre.info/tutoriels-linux/gendarmerie-libre/

2. La concurrence public-public fait rage … aussi.

Après avoir longtemps travaillé avec le CHU de Grenoble sur le dossier médical “Crystal Net”, les Hospices Civils de Lyon développent leur propre logiciel “Easily”, puis affichent à nouveau une volonté de travailler ensemble, qui finit par l’abandon total de la première solution. Si Easily est devenu au fil des années l’un des logiciels de gestion de dossiers médicaux les plus connus dans le monde hospitalier, au point de tuer le concurrent dont il est issu que de temps perdu dans cette concurrence public-public.   

3. Christophe Prudhomme, médecin urgentiste

“En ce qui concerne l’interopérabilité, je voudrais citer deux exemples en rapport avec mon activité quotidienne. Premièrement, l’absence d’interopérabilité des systèmes de gestion des interventions entre les SAMU de Paris et de la petite couronne et la Brigade des sapeurs-pompiers de Paris. La conséquence est une perte de chance pour le patient lors des interventions où le facteur temps est déterminant, comme l’arrêt cardiaque. En effet, aujourd’hui que l’appel tombe sur le 15 ou le 18, la prise d’adresse se fait d’abord dans un système puis l’opérateur prend son téléphone pour contacter son collègue pour lui transmettre les informations afin qu’elles soient rentrées dans un autre système ! Deuxième carence ; l’absence d’accès direct aux dossiers de patients complexes lors d’un appel en urgence, notamment pour les patients en hospitalisation à domicile ou atteints de pathologies complexes.”

[1]http://www.lesiss.org/offres/file_inline_src/445/445_P_15163_1.pdf

[2] Système de Gestion de Base de Données

[3] Stratégie « de recentrage sur le cœur » comme dans l’industrie.

[4] Health Level 7 est une organisation qui définit un ensemble – auquel elle donne son nom – de spécifications techniques pour les échanges informatisés de données cliniques, financières et administratives entre systèmes d’information hospitaliers.

[5] https://www.toolinux.com/?securiser-les-dispositifs-medicaux-un-imperatif

[6] Le coût total de possession est plus souvent rencontré sous son abréviation anglophone de TCO (Total Cost of Ownership). Il représente la somme totale qu’a dû dépenser le propriétaire d’un bien au cours du cycle de vie de ce dernier. Les coûts directs et indirects sont pris en compte.

[7] https://www.reseau-hopital-ght.fr/actualites/sante-publique/politique-de-sante/350-millions-d-euros-pour-renforcer-la-cybersecurite-des-etablissements-de-sante-et-medico-sociaux.html

[8] https://www.ticsante.com/story/4042/informatique-et-ght-le-dossier-patient-informatise-easily-a-le-vent-en-poupe.html

[9] http://www.lesiss.org/offres/file_inline_src/445/445_P_15163_1.pdf

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *