Limites et risques des dossiers de santé électroniques régionaux

Il ne suffit pas de choisir le même logiciel pour avoir le même dossier médical ou pour pouvoir partager des processus et des données cliniques.

La centralisation des achats au niveau régional a été fortement dynamisée par le PNRR et les appels d’offres numériques santé du Consip. Les investissements les plus importants se concentrent sur le dossier médical informatisé hospitalier que certaines régions acquièrent au travers de contrats spécifiques uniques même s’ils sont ensuite ventilés pour chaque entreprise de santé bénéficiaire des fonds disponibles.

Ces contrats prévoient un prestataire unique qui contracte l’obligation et le droit de fournir la même solution logicielle à toutes les entreprises de santé qui en font la demande. Il s’agit d’une tentative d’homogénéisation sinon de standardisation de l’un des logiciels les plus importants pour le diagnostic et le traitement des patients. L’objectif sous-jacent est de pouvoir collecter, agréger et partager des données cliniques d’une manière plus simple que ce n’était le cas jusqu’à présent. Motivation certainement partageable et utile.

En examinant en détail les modalités et les exigences exprimées dans les spécifications techniques des appels d’offres spécifiques, on s’aperçoit que le montage de ces appels d’offres n’est pas fonctionnel et cohérent avec les objectifs décrits ci-dessus. Il n’y a pas de conception commune de dossier de santé électronique. Les exigences décrivent les caractéristiques et fonctionnalités de base avec lesquelles “construire“e”Personnaliser” les dossiers médicaux basés sur les besoins des différentes entreprises de soins de santé et, au sein de celles-ci, des différents services médicaux / spécialités.

Le manque de gouvernance, peut-être partagée, sur ce que doit être un dossier médical informatisé, quel modèle de données il doit avoir, quelles fonctions il doit assurer, a fait qu’il n’a pas été voulu ou a pu changer le modus operandi qui voit toute entreprise de santé décider en toute autonomie comment mettre en place et créer son propre dossier médical électronique. Le résultat de ce choix sera une vaste hétérogénéité de données et de fonctions, en vérité rien de différent de ce qui se passe déjà aujourd’hui.

Pourtant, en présence d’une offre qui voit aujourd’hui, également en réponse à la demande du marché, des logiciels qui sont en fait des plateformes configurables pour la gestion des données et des documents cliniques plutôt que des systèmes équipés de leur propre modèle de données, de workflows cliniques et d’un ensemble de fonctions”intelligent« , la décision d’acquérir la même solution pour toutes les entreprises de santé au niveau régional devait être précédée et accompagnée d’une forte initiative de planification et gouvernementale avec la participation des parties prenantes, doctor in primis. Une opération complexe et pas facile, qui demande du temps, de grandes compétences et une connaissance du domaine clinique.

Au lieu de cela, la voie la plus simple a été choisie, ce qui préserve le statu quo tout en introduisant un risque très élevé. La sélection d’un fournisseur unique, aussi large soit-il, par région, soulève de sérieux doutes quant à la capacité réelle de ceux-ci à faire face à un engagement aussi large et articulé. Toutes les difficultés ou échecs affecteront toutes les entreprises de soins de santé. Il s’agit d’un risque important qui ne trouve, pour les raisons exposées ci-dessus, aucun avantage en termes d’homogénéisation et de standardisation des processus et des données cliniques.

Tout part du malentendu ou, si vous préférez, de la simplification qu’il suffit de choisir le même logiciel pour avoir le même dossier médical électronique sur toute la région. Pour rendre l’erreur plus grave est la prise de conscience que les expériences acquises jusqu’à présent montrent comment, même dans les cas où il y a le même logiciel (par exemple le laboratoire d’analyse), la mise en réseau et le partage de données entre ceux-ci est extrêmement difficile (codages différents, différents méthodes, etc.). La seule exception concerne le diabète qui a pourtant une tout autre histoire et type de solution logicielle – un produit et non une plateforme.