Séparez les applications des données, il est temps de passer d’architectures « centrées sur les applications » à des architectures « centrées sur les données »

Les données font aujourd’hui partie intégrante des applications et sont donc fragmentées et dupliquées entre différents systèmes. L’interopérabilité est une solution de contournement mais pas la solution pour résoudre ce problème.

La plupart des applications logicielles de santé sont basées sur des architectures « centrées sur les applications » dans lesquelles les données sont stockées en tant que partie intégrante de l’application elle-même, chacune étant chargée de stocker, protéger, vérifier et partager les informations qu’elle gère.

Même les encodages utilisés par l’application font partie intégrante des données qui sont presque toujours dans un format fermé et propriétaire, tout comme les fonctions et les formulaires sont à l’intérieur du code et il n’y a presque jamais de logique de workflow ; les événements sont gérés dans le code.

Les systèmes d’information sur la santé, comme nous le savons, sont constitués de dizaines, voire de centaines d’applications différentes. Cette situation détermine quatre conséquences importantes :

• Fragmentation et duplication des données
• La nécessité, pour que toutes ces applications communiquent entre elles, de poursuivre l’interopérabilité entre les systèmes, un aspect très complexe et exigeant
• La nécessité, lorsqu’un aspect impliquant des données, des fonctions ou des flux de travail change, d’écrire le code, tâche qui nécessite des ressources techniques et du temps
• Il en résulte un fort verrouillage du fournisseur.

Il faut noter que, pour pallier cette criticité, il ne suffit pas du tout, comme l’exigent de nombreux spécifications, de posséder la licence ni même les codes sources (j’y reviendrai peut-être dans un article ad hoc).

La présence de nombreux silos de données crée également un autre problème : le travail dur et difficile lorsqu’il faut remplacer une application et migrer ses données.

Pour toutes ces raisons, il est utile de réfléchir à passer d’une architecture centrée sur les applications à une architecture centrée sur les données. Cette étape élimine les silos de données, élimine les intégrations point à point entre les applications et fournit une architecture composite qui accélère le développement.

Et document d’EY sur l’architecture de l’information illustre très bien ce concept avec le schéma suivant.

Les établissements de santé qui envisagent ce changement devront réfléchir attentivement à la manière de gérer leurs données, surtout si celles-ci doivent être au centre de leur architecture, car il s’agit d’une décision stratégique et à long terme, c’est pourquoi il est important de ne pas être lié à un seul fournisseur.

Il faut également considérer que puisqu’ils devront gérer des données de santé complexes, il faudra une approche qui gère cette complexité et permette de définir précisément les informations. Ils devront ensuite créer un écosystème d’applications autour des données, ils auront donc besoin d’un cadre de modélisation robuste qui encourage l’agilité et la réutilisation.

openEHR aborde chacune de ces considérations comme un élément fondamental de sa conception. Il dispose d’une architecture ouverte, permettant de stocker les informations centrées sur le patient dans un format durable, indépendant du fournisseur, avec gestion des versions. Deuxièmement, il possède une architecture sémantique qui permet de définir précisément le sens des informations de santé et de soins. Enfin, il dispose d’un cadre de modélisation robuste, dans lequel les modèles de domaine sont créés par des experts du domaine (tels que des médecins) et sont séparés des couches techniques, ce qui conduit à une plus grande agilité et réutilisation.

Une approche centrée sur les données – mise en œuvre avec openEHR – permettra l’émergence d’un écosystème d’applications intuitives et centrées sur l’utilisateur. En outre, il permettra l’innovation dans la recherche clinique, la thérapie numérique, la prévention des maladies et la gestion de la santé de la population, en tirant parti de normes complémentaires telles que FHIR, OMOP CDM et de modèles tels que Data Mesh.

Il existe de nombreux exemples d’adoption à travers le monde. L’exemple le plus récent et le plus médiatisé est peut-être celui du Service de Santé Catalan. Le Service de Santé de Catalogne a l’intention d’utiliser openEHR pour sa nouvelle plateforme de dossiers de santé dans toute la région. L’annonce souligne que le système actuel de partage d’informations est un «obstacle à l’utilisation systématique des données de santé“, escroquer “l’interopérabilité sémantique qui est probablement le plus gros problème« .

Une solution de planification des soins partagée a été mise en œuvre à Londres via une plate-forme de données persistante avec openEHR couplée à un environnement low-code permettant aux professionnels de la santé et des soins de faire évoluer de manière dynamique les services de planification des soins numériques.

Au Pays de Galles, Digital Health and Care Wales (DHCW) a annoncé un contrat pour mettre en œuvre un référentiel de données cliniques qui sera un «partie intégrante” de l’architecture nationale et “contribuera à transformer les soins et le traitement des patients« .

En Slovénie, le ministère slovène de la Santé utilise openEHR depuis 2012, créant ainsi des services nationaux d’interopérabilité dans tout le pays. Dans la ville de Moscou, plus de 670 prestataires de soins de santé utilisent une plateforme openEHR pour gérer les dossiers de santé et de protection sociale de plus de 12,6 millions de citoyens.

Dans le NHS, la dernière stratégie « Data Saves Lives » s’engage à «séparer la couche de données de la couche d’application [per fornire] un ensemble de données standardisées… propres« .

Mais comment répondre à ce changement de paradigme ? Quel est le chemin à suivre ?

Nous en parlerons dans le prochain article. Rester connecté!