2024-01-09 12:37:37
Une approche en trois étapes pour séparer les applications de données.
Dans l’article précédent, j’ai expliqué les avantages de séparer les données des applications en utilisant une architecture « data-centric » basée sur openEHR. Mais comment les entreprises de soins de santé peuvent-elles mener à bien ce voyage ?
La première étape consiste à créer un référentiel de données indépendant basé sur openEHR alimenté par les principaux systèmes. La tendance actuelle est de créer des référentiels FHIR pour la persistance des données en utilisant à mauvais escient une norme créée pour l’interopérabilité. Ceux qui souhaitent en savoir plus peuvent consulter cet article ainsi que celui-ci pour une comparaison entre FHIR et openEHR.
La création d’un référentiel de données indépendant permet de profiter des avantages d’openEHR même en présence de systèmes existants et de leurs données dans un format fermé et propriétaire.
La deuxième étape est l’adoption de plateformes low-code basées sur openEHR pour numériser de nouveaux processus, surtout s’ils sont transversaux à plusieurs applications. L’adoption de plateformes low-code permet de réduire les temps de développement et de créer des solutions openEHR natives capables de fonctionner directement sur le référentiel de données, séparant ainsi les données des applications.
Les formes ainsi créées peuvent également être «injecté» dans les applications conventionnelles et invoqué via un simple appel contextuel. Par exemple, si j’ai besoin de consulter ou de mettre à jour un plan de traitement, au lieu de créer cette fonction dans le code de l’application (qui ne la gère pas) et de transférer les données vers le référentiel openEHR, je pourrais rappeler le formulaire créé avec le low-code plate-forme, réduisant ainsi la complexité et les efforts requis.
Il s’agit d’une extension logique du concept « data-centric », c’est-à-dire la création de fonctions centrales simples, basées sur des données, pouvant être intégrées aux systèmes utilisés par les professionnels de santé plutôt que de nécessiter, comme c’est habituellement le cas, la mise en œuvre de fonctions supplémentaires. .
La troisième étape concerne enfin la demande auprès des fournisseurs de solutions openEHR capables de fonctionner sur des données centrales. Il s’agit d’inciter et de promouvoir cette pratique, peut-être à travers des mécanismes d’incitation ou de récompense dans les appels d’offres, de manière à stimuler l’offre d’adopter le paradigme « data-centric ». C’est ce qui se passe dans certains pays, par exemple en Europe du Nord, où l’offre de solutions capables de fonctionner sur des données centrales se généralise.
#appcentric #datacentric #chemin
1704920680