Epic, Cerner et d’autres révèlent à quel point leurs DSE sont interopérables

De nombreux fournisseurs de dossiers de santé électroniques affirment que leurs technologies sont interopérables avec d’autres systèmes d’information sur les soins de santé. Et ces affirmations peuvent être vraies – ou vraies à un certain point.

Healthcare IT News a interviewé des cadres clés de l’interopérabilité avec quatre fournisseurs de DSE de haut niveau – Cerner, DrChrono, eClinicalWorks et Epic Systems – pour discuter de la manière dont leurs systèmes sont interopérables ainsi que de l’interopérabilité globale des TI de santé.

Interopérabilité chez Epic

Le premier type d’interopérabilité de base est de système de santé à système de santé, pour coordonner les soins d’un patient entre les organisations, a déclaré Dave Fuhrmann, vice-président de l’interopérabilité chez Epic Systems.

Il a expliqué qu’Epic prend en charge cela de quatre manières :

  • Instance partagée – Connexion communautaire : Une organisation utilisant Epic peut partager son instance avec d’autres fournisseurs de la communauté. Le dossier du patient se trouve sur une base de données partagée.
  • Lien Web – Lien EpicCare: Les fournisseurs communautaires peuvent accéder au dossier du patient via un portail Web, afin qu’ils puissent suivre les soins du patient dans l’ensemble du système de santé, planifier des rendez-vous, passer des commandes, envoyer des notes et plus encore.
  • Interopérabilité Push / Pull C-CDA – Soins partout: c’est ce que les gens considèrent traditionnellement comme « interopérabilité », a-t-il déclaré. Lorsqu’un patient se présente pour des soins dans un système de santé utilisant Epic, Care Everywhere envoie des demandes à d’autres systèmes de santé, reçoit le résumé normalisé (C-CDA) et intègre les nouvelles données dans le dossier du patient. De plus, Care Everywhere peut recevoir une demande automatisée et envoyer le résumé au système de santé demandeur.
  • Messagerie directe : C’est un sous-ensemble d’interopérabilité Push/Pull. L’organisation qui voit actuellement le patient peut envoyer le résumé normalisé du C-ADC à une autre organisation. Ceci est mieux utilisé pour les références.

Epic propose également sa fonction Happy Together, qui permet aux patients et aux fournisseurs de voir les données provenant de plusieurs sources dans une seule vue de portail fusionnée, et de travailler ensemble, ce qui permet aux systèmes de santé de prendre des mesures telles que la vérification des ordres de laboratoire en double, la récupération d’images de qualité de référence, la planification, la messagerie et la recherche dans les systèmes de santé, en travaillant ensemble.

« Le deuxième type d’interopérabilité de base est l’interopérabilité dirigée par le patient », a déclaré Fuhrmann.  » Share Everywhere d’Epic utilise le portail patient, MyChart, où les patients peuvent consulter leur propre dossier et diriger une vue Web temporaire du résumé de leur dossier vers n’importe qui dans le monde qui dispose d’une connexion Internet. »

« Nous vous recommandons de demander la définition de l’interopérabilité du fournisseur de DSE, pour voir si elle correspond à la vôtre. »

Dave Fuhrmann, Epic Systems

De plus, Lucy d’Epic est un dossier de santé personnel autonome. Les patients peuvent diriger un résumé de leurs informations à partir du DSE Epic, d’autres DSE et de sources autres que le DSE (PDF, JPEG, etc.) à Lucy, où les données peuvent être téléchargées sur leur ordinateur, enregistrées sur un lecteur flash ou stockées en toute sécurité dans le cloud.

« Nous prenons également en charge un troisième type d’interopérabilité : lier ensemble les nombreux autres produits logiciels utilisés par une organisation de soins de santé », a expliqué Fuhrmann.  » Nous prenons en charge cela via des API, des interfaces et d’autres technologies, avec des dizaines de milliards de messages d’interface et d’appels d’API par mois. »

Interopérabilité chez Cerner

Chez Cerner, son DSE dispose de capacités d’interopérabilité intégrées pour accéder et échanger des informations sur les patients à travers les systèmes informatiques de santé, a déclaré Kashif Rathore, vice-président de l’interopérabilité de l’entreprise.

« Notre interopérabilité permet aux données de circuler librement et en toute sécurité afin qu’elles puissent être utilisées par les fournisseurs et les consommateurs pour informer les soins et générer des résultats positifs pour la santé », a déclaré Rathore.  » Nous partageons et accédons à des données sur des systèmes disparates à l’aide de normes d’interopérabilité du secteur, de connexions réseau et d’échanges nationaux. »

Cerner, comme d’autres fournisseurs d’informatique de santé, contribue depuis des années à des organisations et à des initiatives d’élaboration de normes qui contribuent à favoriser l’adoption, afin que l’industrie puisse parvenir à un langage commun permettant un échange gratuit et sécurisé de données de santé.

« Nous avons lancé Direct, une norme de l’industrie qui spécifie un moyen sécurisé pour les fournisseurs d’envoyer des informations de santé authentifiées et cryptées directement à des destinataires connus et de confiance sur Internet », a déclaré Rathore. « Nous sommes également un membre fondateur de la CommonWell Health Alliance, une association professionnelle à but non lucratif vouée à la vision simple selon laquelle les données sur la santé devraient être accessibles aux personnes et aux soignants, quel que soit l’endroit où les soins sont prodigués. »

 » Chaque DSI du pays devrait demander ou s’attendre à ce que l’interopérabilité soit la lignée des DSE, de la santé de la population, des soins de longue durée et post-actifs ou de tout logiciel de santé. »

Kashif Rathore, Cerner

Cerner a également été activement impliqué dans le projet Argonaut pour faire progresser et appliquer la norme HL7 FHIR afin d’étendre l’interopérabilité à l’utilisation d’API Web ouvertes, a-t-il ajouté.

 » Nous intégrons des données externes, ainsi que des données de DSE natives, dans le flux de travail quotidien de l’équipe soignante pour éclairer les décisions critiques « , a-t-il expliqué.  » Nous aidons également à déplacer en toute sécurité les communications et les alertes entre l’équipe de soins, à l’intérieur et au-delà des quatre murs de l’organisation de soins de santé. Notre objectif autour de l’interopérabilité est de placer la personne au centre afin que ses informations la suivent numériquement. »

Quel que soit l’endroit où le parcours de santé de la personne la mène, ses informations doivent être accessibles, a-t-il ajouté.

Interopérabilité chez eClinicalWorks

L’interopérabilité est une cible en mouvement, et sa portée s’est élargie au fil des ans à mesure que la technologie et les ensembles de données appropriés ont évolué, a déclaré Girish Navani, PDG et cofondateur d’eClinicalWorks.

« Au début, pouvoir communiquer avec les systèmes auxiliaires, les pharmacies et les centres d’échange a nécessité un effort particulier, mais de telles intégrations sont désormais prêtes à l’emploi dans nos produits », a déclaré Navani.  » Dans l’état actuel des choses, le DSE d’eClinicalWorks est aussi interopérable que la technologie et les normes le permettent. »

Les normes telles que les API HL7, CDA ou FHIR sont « des facilitateurs pour un échange d’informations significatif entre diverses parties prenantes comme les autres fournisseurs de soins, les payeurs, les agences de santé publique et les patients eux-mêmes, et nous avons des exemples concrets d’échange de données avec chacune de ces parties prenantes », a-t-il déclaré.

Une adoption accrue, a ajouté Navani, a été réalisée dans les domaines suivants:

  • La messagerie sécurisée directe prend en charge l’interopérabilité directe pour combler les lacunes dans les transitions de soins. Actuellement, 500 000 transactions ont lieu par mois via le HISP eClinicalDirect.
  • Le cadre d’échange de confiance facilite le flux d’informations et améliore les échanges basés sur des requêtes. 1 000 000 de documents sont échangés par jour par les cabinets eClinicalWorks via Carequality et CommonWell.
  • Les applications centrées sur le patient pour les API FHIR continuent d’augmenter, avec plus de 40 développeurs d’applications pouvant désormais se connecter.

Interopérabilité chez DrChrono

DrChrono s’engage dans une culture de l’innovation; sa mission est de permettre une plate-forme ouverte où les développeurs, les clients, les patients, les établissements d’enseignement et les chercheurs peuvent obtenir leurs données, brancher une application sur DrChrono ou travailler avec un autre fournisseur, a déclaré Daniel Kivatinos, cofondateur et directeur de l’exploitation.

« Pour la pratique médicale, nous avons un modèle d’API « live in five minutes » où n’importe qui, y compris un client, un partenaire ou un développeur, peut simplement commencer à créer une application sur la plate-forme », a expliqué Kivatinos.  » Nous avons une API Restful moderne. Nous avons également un répertoire d’applications où, si un développeur le choisit, il peut être répertorié comme partenaire officiel. »

DrChrono permet à un développeur de commencer très rapidement à coder sur la plate-forme EHR, a-t-il ajouté.

« Pour les patients, nous avons environ 3 pour cent de la population américaine dans DrChrono et avons un dossier de santé des patients qui permet aux patients, par exemple, d’envoyer un message à leur médecin et de prendre des rendez-vous », a-t-il déclaré.  » Du côté du dossier de santé des patients, nous avons une API FHIR pour les développeurs et les applications partenaires. »

Questions clés sur l’interopérabilité à poser aux fournisseurs

Lorsque les DSI des soins de santé approchent les fournisseurs de DSE lorsqu’ils envisagent un achat, l’interopérabilité est l’un des divers sujets qu’ils devraient examiner. Les fournisseurs de DSE proposent ici des suggestions pour les questions que les DSI devraient poser à tout fournisseur de DSE en matière d’interopérabilité des DSE.

« Nous vous recommandons de demander la définition de l’interopérabilité du fournisseur de DSE, pour voir si elle correspond à la vôtre », a déclaré Fuhrmann d’Epic.

Il suggère également de poser ces questions:

  • Combien de dossiers de patients vos systèmes de santé échangent-ils quotidiennement? Soutenez-vous l’échange C-CDA?
  • Quel pourcentage de vos clients sont capables d’interopérer ?
  • Offrez-vous un portail patient qui permet aux patients d’accéder à leurs propres dossiers, de partager leurs dossiers avec les membres de leur famille et de diriger leurs données de santé vers d’autres fournisseurs?
  • Comment le système intègre-t-il des informations extérieures au point de service : s’agit-il d’un écran séparé pour afficher des données extérieures ou est-il mêlé aux données du système du clinicien?

Soutien aux initiatives nationales?

Navani d’eClinicalWorks a déclaré que l’une des questions que les DSI devraient poser est: Le fournisseur prend-il en charge des initiatives nationales de partage de données et des cadres de confiance en fonction du but de l’utilisation?

« La majorité des fournisseurs du marché ambulatoire n’ont pas encore participé à l’échange de données à l’échelle nationale en utilisant les deux, ou l’un ou l’autre, Carequality ou Commonwell », a soutenu Navani.  » Le manque d’implication démontre la réticence des fournisseurs à faire confiance aux cadres de confiance et aux technologies existants pour améliorer l’échange de données. Le mécanisme de l’ADC est loin d’être parfait, mais il s’agit d’une approche itérative. Les fournisseurs qui n’investissent pas encore dans l’interopérabilité sont désavantagés dans la création d’une image globale du dossier de santé d’un individu. »

Une autre question que Navani a conseillée : Le fournisseur s’engage-t-il dans des organismes standard axés sur le consensus comme le projet Argonaut pour les API FHIR ou prend-il en charge des API propriétaires ?

« Des initiatives comme le projet Argonaut aident à faire progresser l’adoption de normes d’interopérabilité ouvertes et standardisées dans l’industrie de la santé », a déclaré Navani.  » Les guides de mise en œuvre prennent en compte diverses parties prenantes et déterminent des normes consensuelles pour favoriser l’adoption des API FHIR. L’approche facilite le processus de mise en œuvre, par opposition à une approche API propriétaire spécifique au fournisseur, qui n’est pas acceptable lorsqu’il s’agit de plusieurs plates-formes. »

Et une autre question de Navani est la suivante: Que doit montrer le fournisseur pour les capacités d’échange de données dans le monde réel et est-il intégré à un cadre d’échange de confiance sans coût supplémentaire?

« En comparaison, certains fournisseurs discutent principalement de l’interopérabilité, et d’autres sont proactifs avec l’interopérabilité à intégrer dans leurs flux de travail », a soutenu Navani. « Un fournisseur qui a des données réelles à montrer pour des volumes d’échange de données réussis en production pourra se distinguer des autres. »

Utilisation significative?

Une autre question importante à se poser est de savoir si le logiciel est une utilisation significative et certifié MACRA / MIPS, a déclaré Kivatinos de DrChrono.

« Si la réponse est oui, c’est une bonne chose, car l’industrie dans son ensemble pousse de nombreux fournisseurs à se conformer aux normes auxquelles l’industrie des logiciels médicaux devrait être tenue », a-t-il déclaré.  » Un exemple est avec le CCDA. Le CCDA fait partie d’une utilisation significative et permet une exportation rapide d’un dossier médical dans un format standard qui peut être récupéré par un autre fournisseur auprès d’un patient ou d’un fournisseur. Recherchez toujours les dernières certifications; c’est un mauvais signe si un fournisseur n’est pas à jour sur sa certification. »

Rathore de Cerner a conseillé aux directeurs informatiques des soins de santé de se demander :  » Comment ce DSE envoie-t-il et consomme-t-il des informations provenant d’ailleurs? »

 » Chaque DSI du pays devrait demander ou s’attendre à ce que l’interopérabilité soit la lignée des DSE, de la santé de la population, des soins de longue durée et post-actifs ou de tout logiciel de santé », a-t-il insisté. « L’envoi ou la consommation des données des patients devrait être sans effort et devrait augmenter l’expérience des cliniciens pour prendre des décisions éclairées. Les données externes doivent interagir avec les informations natives pour fournir des informations, telles que l’aide à la décision clinique. »

Innovation et intégration ?

Une autre question clé que les organisations fournisseurs devraient se poser, a déclaré Rathore, est la suivante :  » Le DSE soutient-il l’innovation et l’intégration? »

 » Il est important d’investir dans les DSE qui soutiennent l’innovation et l’intégration des soins de santé en utilisant des API basées sur des normes qui peuvent répondre aux besoins de flux de travail des systèmes de santé et sélectionner des cas d’utilisation « , a-t-il déclaré. « Les DSI des soins de santé devraient investir dans des DSE qui invitent à la collaboration avec n’importe quel système et ne forcent pas une approche de fournisseur unique qui limite la collaboration entre sites. Nous utilisons des API basées sur des normes pour favoriser une interopérabilité significative et permettre l’intégration d’applications externes dans les flux de travail de DSE. »

Rathore a ajouté que les DSI de la santé devraient également se demander: « Quelle est la capacité de mes fournisseurs à consommer et à utiliser de manière significative les données de santé des patients? »

« Afficher les informations d’un patient ne suffit pas – les fournisseurs doivent être en mesure de lire et d’extraire rapidement et efficacement les données pertinentes des patients et de les utiliser pour améliorer les résultats sur la santé », a-t-il déclaré. « Un DSE interopérable aura les données de santé pertinentes d’un patient pour le fournisseur, donnant un contexte supplémentaire à l’épisode de soins particulier et au bien-être général de la personne. »

Twitter: @SiwickiHealthIT
Envoyez un e-mail à l’auteur: [email protected]

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.