GHT et convergences fonctionnelles

Petit rappel : avant la version définitive de la loi de santé 2016, plusieurs moutures à l’étude ont circulé et, dans les premières versions, il était question d’unité fonctionnelle : comprendre qu’un seul logiciel doit couvrir l’ensemble du GHT par fonction métier. Il est vite apparu qu’une telle approche relevait de la gageure et qu’il fallait tabler sur la convergence, à savoir qu’il fallait tendre vers l’unicité logicielle par fonction métier, avec la cible 2022 (qui est impossible à tenir dans la plupart des cas ; dans les faits on est plutôt aux environs de 2030 – et encore pas partout). Quoi qu’il en soit, on laisse du temps au temps, et les deux événements qui permettent d’accélérer la convergence sont l’obsolescence (le renouvellement d’un logiciel au sein d’un établissement doit se faire en tenant compte de la stratégie de convergence du GHT) et la fusion administrative de deux établissements, qui n’en font alors plus qu’un seul. À ce sujet d’ailleurs, si certains persistent à penser qu’un seul établissement (deux qui auraient fusionné) peut conserver deux logiciels RH distincts, je leur souhaite bon courage, sincèrement.

La partie complexe concerne évidemment le SPI. Le volet RH n’est pas une mince affaire bien entendu (qu’il s’agisse d’utiliser le même logiciel avec des bases séparées, la même base, mais avec une séparation logique ou la même base avec une implémentation de la notion de site). C’est un projet complet, mais qui ne présente pas de « sensibilité politique extrême », pour le dire de façon mesurée. Avec la question de la convergence du DPI, on change de braquet.

Il faudrait être d’une extrême mauvaise foi pour affirmer que le logiciel RH – ou plutôt la suite de logiciels et de modules du SIRH – convienne à l’établissement support et ne puisse convenir à un établissement périphérique du GHT. Du temps de feus les CRIH, les critiques sur l’inadéquation de l’offre logicielle des CHU à l’hôpital local d’à côté ne portaient pas spécialement sur les modules administratifs du SI. Sauf exception tordue, la paye, c’est la paye, la gestion des carrières aussi. Mais, côté DPI, c’est une autre paire de manches, et il faudrait vraiment être de mauvaise foi pour ne pas le reconnaître.

Un DPI, au sens progiciel intégré, qui couvre absolument toutes les fonctions d’un gros CHU y compris les laboratoires, l’imagerie et la pharmacie, on peut dire qu’il n’en existe pas. La biologie est tellement spécifique que des éditeurs se sont spécialisés sur ce créneau et que même les grands DPI du marché s’associent avec eux pour couvrir toute l’informatique de soins. Ne parlons même pas de la pharmacie, qui est très complexe sur le plan fonctionnel puisqu’elle associe elle-même des aspects logistiques, industriels (la stérilisation), liés au marché, aux métiers, etc. Mais sans même parler de la fonction soins, hors ces trois fonctions supports, le meilleur DPI pour l’unité de soins et le circuit du médicament atteint vite ses limites dans deux environnements très spécifiques : la réanimation et le bloc. C’est un sujet que je ne maîtrise pas, mais certains responsables fonctionnels de ma connaissance pensent qu’il faudrait choisir un DPI en fonction de sa capacité à couvrir bloc + réa et utiliser ensuite le reste des modules dans l’environnement moins contraignant de l’unité de soins. Évidemment, presque tous les établissements qui se sont équipés il y a cinq à huit ans ont fait l’inverse, mais il est difficile de les blâmer dans le sens où cette appréhension du sujet n’était pas alors ce qu’elle est aujourd’hui.

Et il ne s’agit là que de l’activité MCO (médecine, chirurgie et obstétrique). Quand on attaque le médico-social, non seulement ce secteur diffère très sensiblement de l’activité MCO (ne serait-ce que sur les contraintes de confidentialité), mais en plus il n’est pas homogène. Il m’est arrivé de constater, dans certains établissements qui couvraient le champ de l’addiction, des différences considérables dans la saisie de l’activité (et dans les chiffres compilés remontés aux pouvoirs publics) avec des Ehpad ou des établissements SSR. Un GHT qui regrouperait des établissements officiant dans toutes ces catégories d’activité ne pourrait tout simplement pas, même à moyenne échéance, envisager sérieusement de remplacer tous les progiciels métiers par un DPI unique, celui de l’établissement support (qui comprend souvent une activité MCO) ou un autre.

Si, en outre, certains établissements ont signé des conventions de fonctionnement avec des établissements extérieurs au GHT (par exemple un établissement limitrophe mais hors département, donc souvent hors GHT, avec utilisation de progiciels communs pour faciliter la prise en charge médicale, que ce soit en MCO, en SSR ou autre), alors là, l’équation devient carrément kafkaïenne.

Le point le plus ennuyeux, c’est que le débat ne me semble pas tellement avancer – même s’il faut noter que je ne suis pas dans le secret des dieux : ces questions se posaient il y a 15 ans au bas mot, à l’échelon de l’établissement, et ce n’était déjà pas simple. Elles se reposent aujourd’hui, mais cette fois à l’échelle du GHT, et l’on recommence le même débat en ayant le sentiment d’avoir reculé.

Si quelqu’un a des idées pour faire avancer le schmilblick, je suis preneur…