Évitez la fragmentation des données, surmontez l’interopérabilité

Nous devons repenser le paradigme des systèmes d’information sur la santé, le même depuis quarante ans, pour surmonter les limites et les problèmes présents aujourd’hui.

Le besoin de partager des données est apparu à la fin des années 70, lorsque les premiers systèmes d’information se sont généralisés dans les hôpitaux, chacun opérant sur un domaine d’application spécifique.

Au fil du temps, jusqu’à nos jours, le paradigme n’a pas changé. La tentative d’introduire des ERP n’a pas abouti en raison de la grande variété de fonctions et de processus présents dans une organisation de soins de santé. Dans un hôpital ou une ASL, il existe des dizaines de systèmes d’information qui, dans certains cas, dépassent les centaines.

Chaque système fonctionne sur un domaine d’application spécifique. L’architecture, autrefois monolithique, est désormais divisée en plusieurs niveaux et la logique applicative est organisée en services ou microservices. Les données sont majoritairement gérées avec des bases de données relationnelles, aux formats propriétaires. Pour y accéder, il est nécessaire d’avoir une connaissance approfondie de la structure physique de la base de données, souvent composée de centaines de tables, ainsi que des relations et contraintes existantes. L’écriture dans ces bases de données est encore plus compliquée. Cela détermine effectivement le «verrouillage» du fournisseur ; Pour accéder à ses données, l’entreprise de santé doit contacter l’éditeur du logiciel qui crée des requêtes, des rapports et des extractions en fonction des demandes qu’elle reçoit. La présence d’entrepôts de données d’entreprise systématise ce processus, mais avec une forte rigidité.

Chaque système gère donc les données sur lesquelles il opère ; cependant, certains d’entre eux sont communs à d’autres applications, avec un certain niveau de duplication. Par exemple, les données d’une hospitalisation se trouvent dans le système ADT mais certaines d’entre elles intéressent de nombreuses autres applications qui, à leur tour, les stockent dans leurs bases de données. D’où la nécessité de partager ces informations entre plusieurs systèmes via l’échange de messages (HL7 version 2) ou en exposant les données comme “ressources” (HL7 FHIR), c’est-à-dire travailler à l’interopérabilité entre les systèmes. Quiconque a de l’expérience dans ce domaine sait à quel point c’est compliqué et fatigant.”laisse les gens parler« deux systèmes, malgré les normes et profils IHE, sans parler du management.

Les données sont donc fragmentées et en partie dupliquées dans de multiples systèmes. Si je dois changer de système, je dois migrer les données de l’ancien vers le nouveau, une opération très complexe, risquée et souvent inefficace. Pour faciliter l’accès et le partage des données cliniques, on utilise des référentiels qui peuvent stocker des documents (Document Repository), des données (Data Repository) ou les deux. Le référentiel de données cliniques (CDR) est alimenté par les systèmes qui produisent des données et contient un sous-ensemble d’informations de la base de données de chaque système, les répliquant.

Le format de données des CDR peut être propriétaire ou, plus récemment, HL7 FHIR. Dans ce blog j’ai écrit plusieurs articles dans lesquels j’ai souligné les limites de cette approche (par exemple ici).

La question que nous devons nous poser est de savoir si le paradigme actuel – centré sur les applications – est la seule possibilité dont nous disposons pour créer des systèmes d’information de santé. Quelles sont les alternatives ? Comment pouvons-nous éviter la fragmentation des données, la dépendance vis-à-vis des fournisseurs et le fardeau de l’interopérabilité ?

La réponse consiste à utiliser openEHR pour le stockage des données, en créant une plateforme de données centralisée, ouverte et indépendante du fournisseur. Mettez les données »en dehors des applications”, les rendant facilement accessibles aux entreprises et fournisseurs de soins de santé, créant ainsi un écosystème de données de santé au vrai sens du terme.

Voyons quels avantages vous pouvez obtenir :

• Les données, étant extérieures aux applications, n’ont pas besoin d’être migrées lors d’un changement de système ;
• Les données sont accessibles avec AQL, le langage de requête openEHR qui, contrairement à SQL, ne nécessite pas de connaissance de la structure physique de la base de données ;
• Il n’y a pas de duplication de données ;
• Un référentiel de données cliniques externe n’est pas nécessaire, la base de données openEHR contient toutes les données ;
• L’interopérabilité n’est pas nécessaire, les applications accèdent directement aux données ;
• Avoir une seule base de données facilite la surveillance des données, la protection de la vie privée et la régulation de l’accès ;
• Disposer d’une structure de données standardisée et ouverte permet une plus grande concurrence entre les fabricants et la possibilité de choisir des solutions spécifiques pour les startups et les petites entreprises, encourageant ainsi l’innovation.

Ce sont les raisons qui déterminent le succès et la diffusion d’openEHR, notamment en Europe du Nord, en Asie et en Australie. Le dernier exemple en date est celui du Karolinska Institutet de Stockholm, l’hôpital le plus grand et le plus prestigieux d’Europe, qui a choisi openEHR pour créer sa propre plateforme de données sur laquelle construire le nouveau système d’information.

J’anticipe une éventuelle objection : en Italie il n’existe pas de solutions basées sur openEHR, comment puis-je établir un cahier des charges ou une demande de devis avec ce cahier des charges ? Même en Europe du Nord, il n’existait pas de systèmes basés sur openEHR, les fabricants ont dû s’adapter aux demandes des clients et le marché s’est donc développé. S’il y a une demande, l’offre se comporte en conséquence.

Il faut dire aussi que l’approche data-centric n’est pas exclusive, elle ne se fait pas d’un coup. Vous pouvez commencer avec les nouveaux systèmes et, au fil du temps, converger vers ce paradigme. Il y a aussi quelques pionniers en Italie, certaines administrations commencent à utiliser openEHR…