normes et schéma D’interopérabilité
Les Activités d’élaboration de normes entreprises depuis le début des années 1980 visaient à apporter des solutions à ces problèmes d’interopérabilité., Le Digital Imaging and Communications in Medicine (DICOM®), comité de normalisation de la National Electrical Manufacturers Association (NEMA), a été l’un des premiers à développer une norme pour communiquer des informations d’imagerie médicale, maintenant publiée par L’Organisation Internationale de normalisation (ISO12052:2017). Toutes les normes de niveau de santé sept (HL7) sont publiées par un organisme national de normalisation officiel, L’American National Standards Institute (ANSI)., Il est important de noter que les normes HL7 (Health Level Seven) se concentrent sur l’interopérabilité technique (échange de données de santé), ce qui entraîne une interopérabilité opérationnelle (sémantique) limitée .
la norme FHIR® (Fast Healthcare Interoperability Resources), désormais très populaire, a considérablement amélioré les flux d’informations opérationnelles . Le modèle de référence HL7 FHIR® est défini par un ensemble de modèles d’information (ressources). Ceux-ci peuvent être profilés (ou non) pour générer un modèle d’information clinique., Les ressources FHIR® sont produites à partir d’un surensemble de données trouvées dans les systèmes existants pour être directement utilisées par les développeurs. À proprement parler, ce ne sont pas des « modèles” car aucun des héritages habituels, encapsulation d’éléments communs ou pratiques de typage n’est utilisé. L’utilisation réussie de la norme FHIR® dépend du degré d’accord conclu entre les parties. Il est plus facile de parvenir à une entente de cette façon au sein des organisations par un petit nombre d’intervenants, y compris des cliniciens, que de conclure des ententes pour convenir à des réseaux plus étendus. Cela limite les possibilités de réutilisation des logiciels .,
Un examen de six organisations de soins responsables de L’assurance-maladie américaine a de nouveau mis en évidence la nécessité d’adopter une approche standard. Il a été constaté que ceux qui utilisaient un système unique de dossiers de santé électroniques dans leurs réseaux de fournisseurs étaient en mesure de partager des données en temps réel, ce qui améliorait la capacité des fournisseurs à coordonner les soins. D’autres ont eu accès à des échanges d’informations solides sur la santé permettant d’accéder aux données sur les patients provenant de fournisseurs externes. Malgré cela, il a été noté que le plein potentiel de la santé il N’a pas été réalisé.,e le résultat d’une mauvaise interopérabilité compromettant la capacité de soins entraînant:
•
Le recours à d’autres moyens pour partager des données, y compris les appels téléphoniques et les télécopies,
•
L’utilisation fastidieuse et frustrante des DSE,
•
l’épuisement professionnel des médecins en raison de la charge de travail associée à la gestion des DSE,
•
L’accès aux échanges d’information sur la santé avec peu de données ou des données incomplètes créant des difficultés en matière de coordination des soins,
•
•
incapacité d’utiliser l’analyse pour personnaliser les soins en fonction des besoins d’un patient.,
Une initiative du secteur privé entreprend actuellement un projet visant à faire progresser l’adoption par l’industrie de normes d’interopérabilité ouvertes et modernes, connu sous le nom de projet Argonaut . L’objectif de ce projet est de développer une API de première génération basée sur FHIR®et une spécification des services de données de base pour permettre un partage élargi de l’information pour les dossiers de santé électroniques et d’autres technologies de l’information sur la santé basées sur les normes Internet et les modèles et styles architecturaux. Ce travail est parrainé par de nombreux fournisseurs, dont Cerner, Epic et Accenture., L’objectif de ce travail est d’accélérer le développement du modèle FHIR® en se concentrant sur des profils et une documentation FHIR® plus spécifiques, notamment sur les spécifications de sécurité et la documentation qui les accompagnent afin de permettre l’interopérabilité entre les systèmes propriétaires hérités, où leurs fournisseurs contrôlent contractuellement l’accès aux données. L’utilisation de ces API crée des risques inhérents aux erreurs et à la sécurité des patients en raison de la cartographie des données.
les organisations de soins de santé sont maintenant en train de gérer l’adoption rapide de FHIR® et l’utilisation accrue des API., Du point de vue de l’infrastructure nationale, il doit y avoir les moyens de faciliter la réutilisation de certains modèles clés FHIR® fréquemment utilisés. Ceux-ci peuvent être choisis pour devenir des normes HL7 approuvées. Sans l’adoption de modèles standard convenus, il y aura une prolifération de modèles FHIR® développés pour répondre aux besoins locaux, de nombreuses répétitions et incohérences limitant les progrès nationaux globaux vers la réalisation d’un écosystème de santé numérique bien connecté., Les modèles FHIR® ne sont pas conformes aux conventions de modélisation bien connues, comme l’a démontré Beale qui a conclu que:
les ressources FHIR semblent être le résultat de comités distincts travaillant avec presque aucune référence croisée, méthodologie ou base de conception commune. Le résultat est que chaque ressource est quelque chose comme un « sac d’attributs”, probablement en raison de l’application de la règle dite des 80/20 dans le contexte du Comité.
Les modèles FHIR® doivent prendre en compte un nombre très important et ingérable de points de données., Cette limitation est surmontée par l’adoption de modèles génériques parfaitement adaptés à la messagerie mais pas au stockage de données cliniques sémantiquement cohérentes. Le contexte fait partie intégrante de la façon dont les cliniciens traitent l’information. Le contexte doit être pris en compte lors de l’élaboration de systèmes d’aide à la décision ou d’intelligence artificielle, lors de l’adoption de diverses stratégies d’analyse de données et pour un certain nombre de normes pertinentes, y compris celles utilisées pour la cartographie des données.,
on dit que les ressources FHIR® contiennent un continuum de niveaux ontologiques, elles présentent deux caractéristiques indésirables dans un modèle d’information stable :
volatilité — les ressources cliniquement spécifiques devront clairement changer au fil du temps. La façon dont cela affecte les profils dépendants est une question intéressante;
ouverture-il faut présumer que l’ensemble des ressources ne cessera de croître pour s’adapter aux nouvelles grandes catégories d’information clinique.,
les conséquences de ces facteurs sont que le modèle n’est « jamais terminé” et que toutes les bases de données ou logiciels basés sur celui-ci auront également besoin d’une maintenance continue. Il existe un autre problème lié au traitement de l’information en aval pour l’utilisation secondaire des données. C’est une incapacité à savoir si les structures de données qui semblent être presque les mêmes peuvent être traitées de la même manière; la valeur par défaut avec FHIR est que chaque ressource est sa propre chose ., Un expert en normes internationales a noté que:
FHIR® a été conçu et conçu comme une norme API / interchange, la plupart des grandes organisations ITC (Google, Microsoft, IBM, etc.) et au moins un fournisseur majeur de DSE (Cerner) ont adopté FHIR® comme un schéma d’objet de persistance et FHIR® reste sous-spécifié au niveau international, car la liaison des ensembles de valeurs est reléguée aux guides de mise en œuvre (par exemple, le US Core FHIR® implementation guide)., Compte tenu des prédispositions nationales actuelles aux codes nationaux de technologie de l’Information sur la santé (HIT) (pratiquement tous les pays ont leur propre publication de codes de procédure, et curieusement le monde entier n’utilise pas encore la CIM 11), cette séparation est très pragmatique. Les obstacles à l’interopérabilité internationale des HIT ont moins à voir avec les spécifications de syntaxe technique, et beaucoup plus à voir avec la tendance presque insoluble des pays à spécifier leurs propres systèmes de codage, parfois propriétaires.,
L’Adoption du framework architectural openEHR nécessite l’utilisation d’une approche de modélisation plus complète . Ces modèles peuvent être reliés aux modèles FHIR® lorsque cela est nécessaire, par exemple l’archétype de risque d’effets indésirables openEHR et la ressource FHIR® AllergyIntolerance ont été publiés conjointement et alignés à la fin de 2015., Les archétypes intègrent le travail collaboratif entrepris par une vaste communauté internationale virtuelle de professionnels multidisciplinaires transformant les données de santé en une forme électronique (calculable) fondée sur des preuves pour assurer l’interopérabilité universelle au sein de tout écosystème de santé numérique. Cette approche consiste en une modélisation multi-niveaux à source unique au sein d’une architecture logicielle orientée services délimitée par un ensemble de spécifications publiées par la fondation openEHR et librement accessibles à tous.,
openEHR est une spécification standard ouverte régie par une fondation à but non lucratif, elle est disponible gratuitement pour être implémentée par n’importe quel développeur. Les spécifications OpenEHR, le résultat de 25 ans de recherche et développement, représentent la seule instanciation sérieuse du modèle de référence ISO 13606 pour la communication des dossiers de santé électroniques qui détaille une structure hiérarchique pour les informations cliniques . Cette norme est de plus en plus utilisée dans des projets massifs au Royaume-Uni, en Norvège, en Finlande, en Slovénie et en Allemagne., La Chine, Le Chili, Le Brésil, l’Italie et les Caraïbes ont également adopté cette approche. En fait, ISO 13606 a été dérivée de l’expérience d’openEHR, et plus récemment a été influencée par l’expérience d’autres normes, y compris FHIR®. Le travail de modélisation clinique est plus vaste que celui entrepris ailleurs auparavant avec une communauté de bénévoles de plus de 2000 personnes de 93 pays.
Les modèles cliniques du domaine ISO13606 appelés « archétypes” sont externes au logiciel., Chaque archétype définit un nombre maximal de points de données et de groupes de données possibles qui s’appliquent au concept modélisé. Cela permet un nombre maximal de contextes différents pour s’adapter à toutes les spécialités cliniques et à toutes les utilisations potentielles des données. Les modèles, qui consistent en une couche de modèles de” recombinaison « pour définir des ensembles de données, utilisent uniquement les points de données d’un ensemble (n’importe quel nombre ou sélection) d’archétypes requis pour tout” cas d’utilisation » ou application spécifique, tel que tout type d’évaluation clinique., Les modèles peuvent être utilisés comme définitions de message pour les systèmes hérités, ainsi que comme ensembles de données pour les nouvelles applications, y compris les formulaires. Cela signifie que n’importe quel ensemble d’archétypes Peut être réutilisé pour plusieurs cas d’utilisation. Il permet à des parties importantes du logiciel d’être dérivées de la machine à partir des archétypes. Les archétypes représentent des données atomiques dans un standard ouvert; un facteur de succès critique capable de résister aux changements technologiques, en particulier l’échange et la persistance.,
ces « archétypes” (modèles) sont utilisés par diverses applications, y compris dans le National Health Service du Royaume-Uni où ils sont utilisés pour la conversion de systèmes fantômes permettant l’utilisation de référentiels de données neutres vis-à-vis des fournisseurs. Les autres utilisateurs sont: Queensland Health et certains hôpitaux privés pour leurs systèmes de contrôle des infections, un certain nombre d’établissements de santé primaires de L’ouest de Sydney et le DSE partagé de Northern Territory Health, et les partenaires industriels d’openEHR dont les systèmes sont largement mis en œuvre dans les pays scandinaves., Les composants et systèmes conformes sont « ouverts » en termes de modèles de données et D’API. Stratégiquement, l’approche openEHR se concentre sur les dossiers de santé bien adaptés aux soins centrés sur le patient. Cette approche permet un marché de logiciels basés sur une plate-forme ou « back-end ouvert” dans lequel les fournisseurs de l’industrie de la santé et les développeurs de solutions s’interfacent les uns avec les autres via des modèles d’information standardisés, des modèles de contenu, des terminologies et des interfaces de service.,
Une collaboration ouverte entre les particuliers, l’industrie, les organismes de normalisation et les fournisseurs de soins de santé a convenu de travailler ensemble pour accélérer le développement de normes ouvertes pour l’interopérabilité dans le secteur de la santé et du social. Ils ont fourni un forum collaboratif pour partager des expériences et fournir des solutions visant à surmonter ce paysage confus. En juillet 2018, ils ont publié un aperçu de ce qui a été décrit ici . Il a été noté que ces normes sont en train de converger. Les normes FHIR® et openEHR ne répondent pas au même problème., Ils créent tous deux des modèles d’information clinique, mais les modèles openEHR (archétypes) sont centrés sur les données et indépendants des fournisseurs sur les plateformes openEHR. FHIR® est centré sur les applications car il crée un modèle commun à utiliser dans toutes les applications pour ensuite constituer la base de la définition de l’interopérabilité entre les applications, quels que soient les modèles ouverts ou propriétaires sur lesquels elles ont été construites. Ceux qui utilisent des solutions d’interopérabilité centrées sur les applications le font pour permettre l’utilisation continue de systèmes hérités coûteux.,
openEHR et FHIR® offrent des approches complémentaires mais différentes pour relier une mosaïque complexe d’applications en un seul système cohérent . L’approche openehr centrée sur les données se concentre sur la normalisation des données de santé d’abord, et la construction de nouveaux systèmes au-dessus des systèmes existants pour éviter les problèmes d’interopérabilité tous ensemble. Il s’agit de définir une couche de données dans une architecture système ouverte. Il s’agit de la couche la plus importante, car elle facilite l’utilisation optimale des données pour améliorer les résultats, mieux gérer les maladies chroniques et permettre une meilleure gestion de la santé de la population., Cela nécessite que les données soient stockées dans des formats neutres vis-à-vis du fournisseur, par opposition aux formats propriétaires de la plupart des systèmes hérités. L’approche centrée sur les données permet le stockage et l’utilisation des données de santé numériques tout au long de la vie de tout patient.
presque tous les systèmes basés sur openEHR développent actuellement des interfaces FHIR® pour s’assurer qu’elles peuvent soutenir le parcours du patient entre les systèmes openEHR et non openEHR . le schéma de connectivité openEHR peut être créé une seule fois et partagé entre tous les fournisseurs openEHR car ils sont basés sur des archétypes openEHR communs., Les Applications regroupées sur une plate – forme basée sur openEHR n’ont pas besoin de solutions d’échange telles que FHIR® car elles sont capables de communiquer directement entre elles via des référentiels de données cliniques partagés. Cela permet aux nouveaux entrants sur le marché de se concentrer sur le développement d’applications vraiment innovantes et de répondre fonctionnellement aux exigences cliniques de niche. La capacité FHIR® n’est nécessaire que pour leur permettre de communiquer avec des applications propriétaires de fournisseurs d’écosystèmes plus larges .
Leave a Reply