HL7, ou Health Level-7, est une norme de message internationale fournissant un cadre pour la communication des informations sur les patients entre les entités du secteur de la santé, par exemple entre les prestataires de soins ou entre les applications logicielles de différents fournisseurs. L’intégration HL7 fait référence au processus ou aux solutions logicielles qui traitent ces données de manière à ce que le prestataire ou le système logiciel qui les reçoit puisse les interpréter. Cela semble relativement simple, mais l’intégration HL7 pose un certain nombre de défis aux fournisseurs de logiciels et aux organisations de soins de santé.
Comprendre les interfaces HL7
Les spécifications des interfaces HL7 comprennent des spécifications de données pour divers types de messagerie, tels que ADT, ORM ou ORU (entre autres). Une interface HL7 se compose de quelques éléments clés :
- Un point d’extrémité d’exportation (pour l’application qui envoie le message)
- Un point d’extrémité d’importation (pour l’application qui reçoit le message)
- Une méthode de transfert de données (pour déplacer les données entre les deux points d’extrémité)
Il y a quelques préoccupations avec les interfaces HL7 qui rendent cette configuration beaucoup plus problématique qu’il n’y paraît en surface. Tout d’abord, les modules d’envoi et de réception sont créés par les fournisseurs de logiciels au cours du processus de développement des applications. Comme HL7 permet une personnalisation étendue, les applications utilisent souvent différents formats HL7. En fait, il existe de nombreuses variantes et adaptations des normes d’interface HL7, de sorte qu’il n’existe pas de norme unique pour la mise en œuvre de ces systèmes ou le traitement des données. Et cela signifie que pour que les applications puissent envoyer et recevoir des données qu’elles peuvent comprendre, une traduction et un mappage des données sont nécessaires.
Il existe quelques options pour répondre à ces préoccupations :
- Modifier les modules d’envoi et de réception
- Utiliser un moteur d’interface pour traduire les messages
- Mettre en œuvre une solution API
Regardons de plus près les défis de l’intégration HL7 et comment les surmonter.
Les défis de l’intégration HL7
1. L’intégration est essentielle pour qu’une application soit viable.
Les cliniciens ne quitteront pas la plateforme du DSE, se connecteront à un système non lié et dupliqueront les données qui sont déjà dans le DSE. Ce n’est tout simplement pas pratique ou efficace, et les cliniciens sont déjà sous pression pour faire plus en moins de temps. Peu importe l’utilité de l’application, si elle les oblige à redoubler d’efforts, ils ne l’utiliseront tout simplement pas si elle ne s’intègre pas dans leur flux de travail. Les applications doivent donc être facilement accessibles aux cliniciens et éliminer la nécessité de dupliquer les données. Elles doivent également être intégrées en boucle fermée, les données étant à la fois extraites et introduites dans le DSE. Les équipes informatiques ont généralement des arriérés importants, ce qui signifie que les organisations pourraient attendre des mois (ou des années) que les TI construisent les interfaces nécessaires à ces intégrations.
2. Il y a une variance importante dans la façon dont les fournisseurs mettent en œuvre les normes HL7.
La variance importante dans la mise en œuvre de HL7 ralentit les cycles et rend l’intégration à la fois longue et coûteuse. Essentiellement, elle nécessite de maintenir une base de code et des points d’intégration différents pour chaque DSE. De plus, il faut consacrer des ressources importantes au développement de l’intégration, ce qui signifie que moins de ressources sont disponibles pour d’autres besoins, comme l’amélioration des caractéristiques et des fonctionnalités. De plus, le remplacement ou l’ajout d’interfaces a une incidence sur chaque application qui s’interface avec l’application mise à jour, ce qui peut avoir des répercussions sur l’ensemble du système. Chaque point de terminaison de l’app mise à jour doit être créé ou modifié pour faciliter la communication, et chaque fournisseur de logiciels avec des interfaces attachées à l’app doit remplacer ou modifier leurs points de terminaison, également.
3. Une meilleure intégration est nécessaire pour créer de meilleures apps.
Un manque de surveillance centralisée signifie que plus de temps et d’argent doivent être consacrés à la surveillance. Les problèmes peuvent passer inaperçus jusqu’à ce qu’ils deviennent une crise à part entière, et même dans ce cas, il est difficile d’identifier la source du problème. Il n’y a pas d’informations significatives et disponibles en temps utile sur l’ensemble du système, de sorte qu’il n’y a pas de moyen efficace d’évaluer la pression globale exercée sur un système. Il est donc difficile d’estimer les besoins en ressources, notamment la taille des serveurs, les communications réseau et le personnel d’assistance. Davantage de données en temps réel et de capacités de lecture-écriture sont désespérément nécessaires.
4. Une mauvaise sémantique des données HL7 laisse la porte ouverte à une mauvaise interprétation.
Dans le paysage complexe des soins de santé d’aujourd’hui, il est impératif que les applications comprennent non seulement les valeurs des données, mais aussi ce que ces valeurs signifient réellement. Pour éviter les erreurs d’interprétation, les interfaces HL7 doivent communiquer leur interprétation de la norme d’interface HL7 utilisée. Par exemple, la valeur « NA » signifie-t-elle « No Allergies » ou « Not Applicable » ? Une valeur de « 3 » peut indiquer qu’un patient est un fumeur actuel dans un système, mais dans un autre, cette même valeur pourrait signifier que le patient est un ancien fumeur ou n’a jamais fumé du tout. Ces interprétations erronées, ainsi que la qualité générale des données, ont de graves répercussions sur la prestation des soins aux patients. Comme les systèmes de soins de santé d’aujourd’hui sont de plus en plus régionaux, avec de multiples points de contact avec les patients, une interprétation correcte des données est encore plus critique.
5. La migration vers un nouveau DSE peut entraîner une perte des données héritées.
La migration vers un nouveau DSE pose également un défi aux organismes de soins de santé. Certains organismes de soins de santé choisissent simplement de maintenir plusieurs DSE, ce qui oblige les cliniciens à se connecter à plusieurs plateformes, ou pire, à demander des dossiers papier. D’autres décident de transférer les données existantes vers le nouveau système. Cependant, ils doivent établir des priorités parmi les données à migrer. (Quelles sont les données les plus importantes ? Quelles sont les données à transférer en premier ?) Les données essentielles, comme les médicaments, les allergies et les diagnostics, sont généralement transférées en priorité, ce qui signifie que d’autres données, comme les anciens résultats de laboratoire, les images et d’autres données, peuvent être laissées de côté. De plus, il se peut qu’il soit impossible de convertir certains types de données (comme les images), ou que les données comportent des erreurs après la conversion. En général, la migration entraîne des coûts substantiels en termes de ressources et de technologie, et les délais de migration sont souvent longs.
Comment résoudre les défis d’intégration HL7
Les moteurs d’interface sont une solution d’intégration HL7 courante, mais ils ne parviennent pas à surmonter ces défis et à atteindre les objectifs d’interopérabilité. Avec les moteurs d’interface, les PHI doivent être stockés dans une deuxième base de données, ce qui introduit des risques de sécurité inutiles – particulièrement importants dans l’ère moderne de la confidentialité des données et de la responsabilité. Le code doit être écrit à plusieurs reprises, et la mise en œuvre est généralement lente. Ils ne sont pas non plus agnostiques au DSE, et ils ne fournissent pas l’accès aux données en temps réel qui est si essentiel pour les fournisseurs de soins de santé aujourd’hui.
Heureusement, les fournisseurs de logiciels et les fournisseurs de soins de santé peuvent surmonter ces défis avec l’utilisation des API. Integrate permet l’échange d’informations de santé à travers n’importe quelle plateforme de DSE sans compromettre la sécurité des PHI. Elle prend en charge l’échange transparent d’informations entre les DSE et les applications cliniques et administratives et fournit un accès en temps réel aux données cliniques et administratives. Cela signifie un accès en temps réel aux dossiers des patients entre les fournisseurs et une facturation rationalisée, ce qui se traduit par une réduction des coûts grâce à la diminution de la demande de temps du personnel.
Integrate présente un ensemble robuste d’API REST qui lisent et écrivent dans les DSE par le biais de modules logiciels pris en charge par les fournisseurs de DSE, normalisant l’intégration des DSE grâce à des API universelles en temps réel et un modèle de données unifié, ainsi que des outils pour aider à surveiller et à gérer l’environnement. L’API gère l’interface, de sorte qu’il n’est pas nécessaire d’attendre dans la file d’attente des projets d’intégration, ce qui réduit le temps d’intégration de plusieurs mois à quelques heures seulement. Bien entendu, tous ces avantages ne signifient rien si la convivialité est médiocre. Avec Integrate, vous bénéficierez d’une expérience utilisateur supérieure, de sorte que vous n’aurez jamais à craindre que les utilisateurs abandonnent votre plateforme.
La route vers l’intégration HL7 comporte de nombreux obstacles, mais les solutions API comme Integrate mettent une véritable interopérabilité à la portée des éditeurs de logiciels et des organismes de santé.