Publié le 1er avril 2017 par Pavel Smirnov
Pourquoi innover?
L'innovation en santé numérique au sein d'une organisation de santé n'est pas une mince affaire. Mener des activités de recherche et développement lorsque vos principales préoccupations tournent autour de réglementations sans fin, de la sécurité et de la sécurité des patients représente un défi de taille. Intégrer des entreprises en démarrage de santé numérique, avec des cultures totalement différentes, dans un milieu hospitalier conservateur est difficile. Mais pourquoi innover en premier lieu? N'est-il pas suffisant de simplement mettre en œuvre un DSÉ d'un grand fournisseur réputé?
Lorsqu'on implante un DSÉ d'un grand fournisseur, les clients reçoivent tous les modules — les bons comme les moins bons. Choisir un tel système est toujours un compromis, car aucun système unique ne peut satisfaire toutes les exigences des utilisateurs. Ouvrir la porte à l'innovation, à l'inverse, permet à votre organisation de santé de choisir ce dont elle a réellement besoin et envie, sans compromis. Grâce aux technologies modernes, cela peut être accompli en mobilisant beaucoup moins de ressources. Il existe d'excellentes équipes de développement capables de livrer ce dont votre organisation de santé a besoin de façon agile. Elles peuvent faire plus avec moins. Elles peuvent résoudre les problèmes qui touchent votre organisation de santé, mais pas nécessairement les autres clients de votre fournisseur de DSÉ. Et je ne parle pas de tâches mineures — je connais de petites équipes interfonctionnelles de moins de 10 personnes qui ont réussi à développer des produits DSÉ infonuagiques modernes, des portails pour les médecins et les patients, des systèmes de coordination des soins et des réseaux d'échange d'information sur la santé.
Mais l'innovation demeure ardue, coûteuse et jugée risquée par beaucoup. Ces équipes de développement compétentes peinent à franchir les portes des hôpitaux et sont ralenties par la nécessité d'intégrer leurs applications modernes à un écosystème cloisonné de logiciels patrimoniaux. Est-il possible de faciliter l'ensemble du processus d'innovation en santé numérique?
Recette pour l'innovation
Je crois qu'il existe aujourd'hui un moyen de favoriser l'innovation en santé numérique dans un hôpital sans compromettre les aspects critiques des systèmes d'information hospitaliers. Ouvrez les portes de votre organisation de santé aux technologies innovantes, mais uniquement à celles qui sont conformes aux normes actuelles de l'industrie. Ne perdez pas votre temps à des intégrations personnalisées laborieuses avec des applications sophistiquées qui ne sont pas interopérables d'emblée.
Commencez par mettre en place une infrastructure moderne pour les solutions de santé de prochaine génération. Choisissez et déployez une plateforme dotée d'un dépôt de données cliniques conforme à FHIR qui préparera vos produits pour l'avenir. Ensuite, configurez des environnements de production et des bacs à sable avec, respectivement, des données de production et des données de test. Fournissez des bacs à sable avec des données de test aux entreprises qui vous considèrent comme client potentiel, et laissez-les intégrer leur logiciel à ces bacs à sable via une API FHIR standard. Configurez votre environnement de production de façon similaire à vos bacs à sable afin de pouvoir facilement déplacer en production les technologies développées dans les bacs à sable qui vous conviennent. Ensuite, faites simplement la promotion de vos bacs à sable auprès des communautés d'innovation et soyez à l'affût des bonnes idées.
Les hôpitaux qui commencent à bâtir un écosystème d'applications de santé connectées réaliseront des économies sur l'intégration de nouvelles technologies grâce à la standardisation. Cela augmentera le nombre de technologies pouvant être adoptées. Et enfin, cela permettra d'accomplir les étapes nécessaires pour satisfaire aux exigences d'API ouverte de la Meaningful Use étape 3 du CMS.
Préoccupations potentielles
1. L'intégration d'une plateforme FHIR dans un écosystème patrimonial existant représente un défi. Il peut s'agir d'un défi pour certains logiciels patrimoniaux ou certaines données de santé spécifiques, mais les données médicales courantes, comme l'ensemble de données commun de Meaningful Use, sont généralement traduites vers la norme FHIR sans effort significatif. Une grande partie des données de santé peut être reçue en temps réel à partir de flux HL7 v.2 qui existent dans chaque hôpital. Il existe de nombreux outils pour traduire HL7 v.2 vers HL7 FHIR. Certains moteurs HL7 comme iFW Iguana peuvent le faire. Et même si votre moteur HL7 ne prend pas encore en charge la norme FHIR, vous pouvez utiliser un traducteur HL7 v2 vers FHIR d'autres entreprises. Notre serveur principal FHIR Aidbox peut recevoir des messages HL7 v.2 et les traduire en FHIR.
2. La norme HL7 FHIR n'est pas mature et continue d'évoluer. La migration vers de nouvelles versions est chronophage.
Toute solution informatique qui n'est pas obsolète évolue constamment. C'est vrai pour tous les autres secteurs des technologies de l'information, et cela devrait également l'être pour les technologies de l'information en santé. Considérez tous ces changements comme un signe positif. Vous investissez dans une technologie qui ne sera pas remplacée demain. En ce qui concerne la migration, la communauté HL7 FHIR reconnaît ce besoin. Grahame Grieve (le créateur de FHIR) a mentionné lors de la conférence HIMSS17 à Orlando qu'il envisage de proposer des scripts permettant de migrer les données de santé vers les versions plus récentes de la norme FHIR. Chez Health Samurai, nous faisons de même pour nos clients.
3. Comment puis-je rendre une nouvelle infrastructure fiable, évolutive et sécurisée? Je ne suis pas à l'aise avec l'infonuagique.
Premièrement, les normes d'interopérabilité n'influencent pas votre choix d'infrastructure. Si vous souhaitez continuer à utiliser votre ancien centre de données de santé interne, déployez simplement une plateforme HL7 FHIR sur place. Mais l'infonuagique peut apporter un tout nouveau niveau de fiabilité et d'évolutivité à votre organisation de santé. Par exemple, notre serveur principal FHIR Aidbox est habituellement déployé sur plusieurs serveurs situés dans différentes zones géographiques, ou chez différents fournisseurs d'infrastructure infonuagique (IaaS). Les données de santé sont répliquées entre ces serveurs de sorte que même l'arrêt complet d'une seule région AWS ne mettra pas Aidbox hors service. Une installation Aidbox en infonuagique offre également plusieurs autres propriétés d'infrastructure par défaut : sauvegardes automatisées, chiffrement de toutes les données de santé au repos et en transit, journaux d'audit détaillés avec interface graphique, et même un service de récupération à un instant précis qui annule toutes les modifications et répare les données de santé après des erreurs humaines préjudiciables.
N'attendez pas votre fournisseur de DSÉ!
Une autre considération que je souhaite partager avec vous : n'attendez pas les fournisseurs de DSÉ et leurs places de marché HL7 FHIR. La plupart des entreprises de DSÉ ont d'autres priorités que de perturber leur propre modèle d'affaires en bâtissant un écosystème d'applications de santé connectées provenant d'entreprises tierces. Elles travaillent sur l'API HL7 FHIR depuis des années, mais ne fournissent encore qu'un accès en lecture seule à un sous-ensemble limité de données de santé. Vous pouvez innover beaucoup plus rapidement par vous-même avec des produits HL7 FHIR commerciaux sur le marché, et cela ne prendra pas si longtemps.
Voir aussi : Le guide FHIR pour les directeurs techniques.
