Libérer et unifier les données pour dépasser la notion d’interopérabilité

L’interopérabilité accompagne l’histoire de l’informatique de santé depuis les années 1980. Mais il existe aujourd’hui une alternative, un modèle qui permet de dépasser ce concept.

L’interopérabilité accompagne l’histoire de l’informatique de santé depuis les années 1980. Le besoin d’échanger des données entre systèmes s’est rapidement développé et avec lui sont nés les premiers standards. La version 2 de HL7 a été définie en 1989, suivie de la version 3 en 2005 et, six ans plus tard, en 2011, de la spécification FHIR. Trois normes très différentes en vingt-deux ans. Pour compléter le tableau, il faut également mentionner DICOM, dont l’histoire commence en 1980 et IHE fondée en 1998.

Parce que l’interopérabilité est nécessaire

La raison de l’interopérabilité réside dans le fait que les systèmes de santé possèdent et exploitent leur propre base de données, généralement développée sur des bases de données relationnelles SQL et, plus récemment, sur des bases de données non relationnelles. Chaque base de données contient tout ce dont les applications ont besoin, des dossiers des patients au codage en passant par les données opérationnelles. L’ensemble de données et d’applications est cohérent et peut donc fonctionner sans autre chose. Chaque système remplit une fonction spécifique et, pour couvrir tous les besoins d’un hôpital ou d’un territoire, de nombreux systèmes sont nécessaires. Juste pour donner quelques chiffres, nous parlons de dizaines, voire de centaines de systèmes différents. Dans certains cas, il existe des ensembles de systèmes d’un même fabricant qui partagent la même base de données et qui forment des ERP. Cependant, en raison de la grande hétérogénéité fonctionnelle des soins de santé, il n’existe pas d’ERP capable de couvrir à lui seul tous les besoins d’un hôpital ou d’un territoire, même à l’étranger.

Chaque base de données possède sa propre structure, parfois très détaillée et complexe. Il n’est pas rare d’avoir des bases de données contenant des centaines de tables, souvent avec des noms difficiles à comprendre, et des milliers de relations. Les tableaux, à leur tour, définissent la structure des données. Souvent, plusieurs systèmes gèrent les mêmes données (par exemple des diagnostics ou des mesures) qui ont cependant des structures différentes même lorsqu’ils utilisent peut-être le même codage.

Pour éviter de devoir saisir les mêmes données dans plusieurs systèmes, il a été décidé d’échanger, c’est-à-dire de partager, ces données par le système d’où elles proviennent qui assume donc le rôle de “maître» avec les autres systèmes qui l’utilisent – ​​«esclave». Par exemple, le système du laboratoire – LIS – partage ses résultats avec le dossier médical électronique, le système de transfusion, etc. Le partage peut s’effectuer par l’envoi de messages (HL7 v.2 et 3) qui sont générés lors de la survenance d’événements particuliers (déclencheurs ), avec une logique de diffusion ou en exposant les données comme “ressources» (FHIR). L’échange concerne un sous-ensemble des données selon la logique Pareto 80/20. Reprenant l’exemple du laboratoire, je partage les tests, les résultats, les unités de mesure mais pas les méthodes, les réactifs utilisés, les contrôles et autres données spécifiques et importantes pour le laboratoire mais pas pour les autres systèmes.

Le référentiel, maison commune des données

Pour surmonter la fragmentation des données distribuées et en partie répliquées sur plusieurs systèmes, est né le concept de Data Repository, une base de données centrale qui contient un sous-ensemble des données les plus significatives produites par les systèmes les plus importants. Le référentiel est alimenté en utilisant le même modèle d’interopérabilité utilisé (messages, ressources ou les deux).

Le référentiel provoque donc une duplication des données dont il est alimenté, un aspect qui a un impact sur la confidentialité et les règles d’accès. Sa structure peut être propriétaire ou basée sur un standard (FHIR, openEHR, OMOP).

Coûts et complexité de l’interopérabilité

Rendre les systèmes interopérables est très complexe et coûteux. Malgré les standards et les profils d’intégration avec les Connectathons associés, pour que deux systèmes communiquent, il faut consacrer du temps et des ressources à étudier les cas d’utilisation, comprendre comment les deux fournisseurs ont interprété les spécifications et comment ils améliorent les domaines attendus, développer les changements éventuels. et transformations, faire les tests, mettre le tout en production. Mais ce n’est pas suffisant. Une fois mise en service, l’intégration doit être constamment surveillée et des interventions manuelles doivent être effectuées si quelque chose se produit.ça va mal”par exemple un message a été perdu. Si vous multipliez tout cela par le nombre d’intégrations présentes, généralement plusieurs dizaines, vous réalisez combien de travail est nécessaire pour que tout reste opérationnel, ce qui, il convient de le noter, est d’une importance vitale pour pouvoir utiliser les systèmes.

Choix forcé ?

Même si cela a toujours été le cas, nous devons nous demander s’il existe une alternative, un modèle capable de dépasser le concept d’interopérabilité. La réponse est oui et consiste à séparer les données des applications, en les centralisant. Mais comment structurer les données ? Le choix le plus logique est d’utiliser un standard comme openEHR. Une base de données commune où chaque système lit et écrit les données dont il a besoin, sans flux de données entre l’un et l’autre, sans duplications, sans perte d’informations.

Une base de données complète qui «vive” quel que soit le cycle de vie de l’application, sans avoir besoin de migrer les données à chaque fois que vous changez de système. Ouvert, accessible, longitudinal, où tous les fournisseurs peuvent opérer.

Une piste possible ?

Mais quelles sont les implications ou les complications pour les fournisseurs ? Que signifie abandonner le modèle de données propriétaire interne aux applications ? D’un point de vue technique rien de problématique. Il s’agit d’étudier openEHR et d’adopter, lorsque cela est possible, les archétypes et éventuellement les modèles disponibles. Un effort qui porte ses fruits en peu de temps. Autrement dit, plutôt que d’inventer à chaque fois votre propre structure, appuyez-vous sur un modèle de données standard et ouvert. Je tiens à souligner que pour faire ce choix, il n’est pas nécessaire que tout le monde le fasse ; openEHR peut être adopté même si le reste de l’offre reste sur le modèle de données propriétaire traditionnel et qui n’est pas antithétique aux standards que nous utilisons aujourd’hui. Le choix se situe au niveau de la couche de données.

Il existe cependant un inconvénient et un avantage : le verrouillage sur les clients est perdu et ces derniers deviennent libres d’utiliser les données, seuls ou avec d’autres ; des applications sont créées qui peuvent également fonctionner dans des environnements tiers (à condition qu’elles soient basées sur openEHR) en Italie et à l’étranger. Enfin, il existe un autre aspect qui peut représenter un avantage ou un inconvénient : l’honneur de l’interopérabilité qui peut représenter une entreprise ou un problème est réduit et finalement éliminé.

Ce n’est pas un hasard si openEHR devient le modèle de persistance des données que de nombreux États, régions et entreprises de santé ont choisi pour leurs systèmes d’information du futur. En l’examinant attentivement, il s’agit d’un modèle gagnant-gagnant pour tous, clients et fournisseurs.

Je rappelle que, dans le cadre de la Digital Health Academy, nous avons prévu des cours pour comprendre les aspects innovants et méconnus de l’innovation. Parmi ceux-ci se trouve openEHR, le standard de gestion des données cliniques qui s’impose de plus en plus dans le monde et qui est choisi par les hôpitaux européens les plus importants et les plus prestigieux. Si vous souhaitez en savoir plus, inscrivez-vous et participez, vous ne payez rien !

Le cours openEHR

Une opportunité de découvrir openEHR et de comprendre pourquoi il devient le standard de référence en matière de persistance des données cliniques. Le webinaire est divisé en deux sessions :

mardi 26 novembre de 18h à 19h

• Introduction et bref historique d’openEHR
• Architecture et modèle de référence
• Les archétypes
• je modèle
• Le langage AQL

Pour accéder au webinaire, vous devez vous inscrire qui.

Jeudi 28 novembre de 18h à 19h

• Modèle de données ouvert pour éviter le verrouillage des fournisseurs
• Utilisation d’openEHR dans le développement de solutions cliniques
• openEHR, FHIR et OMOP, trois standards différents mais complémentaires
• Programmation low-code dans openEHR, exemples pratiques

Pour accéder au webinaire, vous devez vous inscrire qui.

Je vous attends!