FHIR répond-il entièrement aux défis de l'interopérabilité des données de santé ?

La rétention d'informations est une pratique courante dans de nombreux secteurs, mais elle est particulièrement répandue dans le domaine de la santé. Les payeurs et les prestataires ont évité de se pencher sur le coût des soins dispensés et sur les remboursements qu'ils percevaient. Par conséquent, le blocage de l'information est devenu l'un des principaux obstacles au passage d'un modèle de paiement à l'acte à un modèle plus transparent basé sur la valeur soins (VBC). Bien entendu, le blocage de l'information n'est pas absolu ou explicite. Il se manifeste plutôt par des barrières infrastructurelles telles que la lenteur de la transition des dossiers papier, les processus manuels et le besoin persistant d'intégrations ponctuelles, point à point, entre des plateformes propriétaires. Parfois, le blocage des informations est un effet secondaire de la HIPAA et de l'utilisation rationnelle, où des lignes directrices bien intentionnées peuvent empêcher ou décourager le partage d'informations lorsque la technologie ou le processus n'est pas suffisamment granulaire ou flexible pour permettre le partage sans sacrifier la sécurité et la vie privée.

Le Congrès a élaboré la loi Cures Act de 2016 pour lever ces obstacles au partage d'informations et apporter plus de transparence aux coûts et aux remboursements des soins de santé. En outre, l'Office of National Coordination of Healthcare Information Technology (ONCHIT et maintenant ONC) a défini des normes spécifiques de partage de données (interopérabilité), des lignes directrices pour l'utilisation et des délais de mise en œuvre obligatoires pour les payeurs et les fournisseurs afin qu'ils se mettent d'accord. La norme d'interopérabilité qui en résulte, Fast Healthcare Interoperability Resources (FHIR, prononcé "Fire"), est la dernière mise à jour de Health Layer 7 (HL7), HL7V4 en l'occurrence. D'ici 2024, il est prévu de remplacer la norme de facto actuelle HL7v2 (HL7v3 n'a pas été mise en œuvre à grande échelle aux États-Unis) par FHIR. Étant donné que plus de 95 % des organismes de soins de santé utilisent la norme HL7v2, vous souhaiterez peut-être mieux comprendre l'impact de cette évolution sur vos activités dans le secteur de la santé.

Pourquoi FHIR plutôt que HL7v2 ?

Pourquoi s'en préoccuper ? HL7v2 présente plusieurs inconvénients, dont les principaux sont les suivants :

• Tout d'abord, HL7v2 ne permet pas à un être humain de visualiser le contenu de chaque message transmis.
• Deuxièmement, les messages relatifs aux soins de santé peuvent être volumineux et se composer de plusieurs éléments d'information que l'on peut vouloir envoyer, recevoir ou consulter séparément ; HL7v2 n'offre pas de moyen simple de le faire.
• En outre, HL7v2 est limité à la dernière génération de normes pour le formatage et le transfert de données semi-structurées, XML et SOAP.
• Enfin, HL7v2 n'a pas commencé en tant que norme ouverte et gratuite et ne l'est devenue qu'en 2013, et la plupart des versions des principaux utilisateurs précoces sont antérieures à ce changement. Il en résulte de multiples implémentations avec des problèmes de rétrocompatibilité et d'intégration entre fournisseurs.

FHIR résout chacune de ces lacunes de HL7v2 de la manière suivante :

• FHIR est une norme ouverte et gratuite, conçue pour être utilisée par n'importe quel développeur, et pas seulement par ceux qui travaillent dans le secteur de la santé.
• Les messages FHIR sont basés sur les formats de données XML, RDF et JSON, et utilisent des API RESTful pour exposer les données sous la forme d'un ensemble de services web.
• Le format exact des données est également normalisé afin de respecter le format de données US Core Data Interoperability (USCDI), qui doit être stocké et téléchargeable dans une architecture de documents cliniques consolidés (CCDA). Lorsqu'il s'agit de normes réglementées, l'adoption dépend de la fourniture d'un ensemble de données convenu dans un format que tous les systèmes peuvent lire.
• Les messages FHIR sont lisibles par l'homme et sont modulaires, ce qui permet de partager des éléments spécifiques et de vérifier si l'on a reçu ce que l'on attendait.

Des comparaisons plus approfondies entre FHIR et HL7v2 ainsi que des descriptions détaillées de l'USCDI et du CCDA sont disponibles sur le site Web HealthIT du gouvernement. Il faut retenir que la nouvelle norme FHIR offre beaucoup plus de simplicité, de granularité et de normalisation en ce qui concerne les données à partager et la manière dont elles doivent être formatées pour permettre ce partage. Si FHIR supprime les obstacles à l'interopérabilité, il ne garantit pas un partage des données santé ouvert et accessible si l'on ne s'attaque pas aux autres problèmes d'intégration des données qui entourent les silos de données de santé. Si vous ne l'associez pas aux changements appropriés apportés à votre stratégie d'analyse des données et à sa mise en œuvre, les silos subsisteront. Par extension, cela ne favorisera que marginalement le passage du FFS au VBC.

L'interopérabilité n'est que le point de départ de l'intégration

L'interopérabilité FHIR permettra sans aucun doute aux prestataires de partager plus facilement leurs données cliniques entre eux et avec les payeurs. Elle facilitera également l'intégration de données cliniques externes (telles que les référentiels de données sur la santé de la population des États et du gouvernement fédéral) en exposant ces référentiels externes en tant que services web. Bien entendu, cela obligera vos équipes informatiques à créer davantage de connexions point à point. Et, bien que vous puissiez réutiliser ces connexions point à point, il existe un meilleur moyen d'optimiser l'utilisation de FHIR : l'Embarquer dans un hub de données.

Grâce à la fonctionnalité de hub de données, vous pouvez ingérer, préparer et combiner des données financières et opérationnelles complémentaires provenant des systèmes administratifs des prestataires et des payeurs avec les données cliniques FHIR. Généralement, les données des payeurs - et les données qui leur sont envoyées - sont dans des formats EDI tels que les formats X.12 8xx. Une grande partie des données sur les déterminants sociaux de la santé (SDOH) se présente sous d'autres formats en dehors du domaine des soins de santé. Les données provenant des ressources FHIR doivent être décompactées et transformées en données EDI ou dans d'autres formats, et vice versa. Souvent, il est nécessaire de combiner des données cliniques, SDOH et financières, ce qui rend les connexions point à point sous-optimales.

Au lieu de cela, un emplacement central virtuel pour connecter toutes les données possibles est un moyen plus efficace et plus flexible de traiter la variété et la diversité des données de soins de santé. C'est le concept qui sous-tend l'existence d'un centre de données. Historiquement, les hubs de données de santé ont été des plateformes intégration de données très complexes utilisées par des ingénieurs de données et d'autres spécialistes de l'intégration des technologies de l'information. Mais, dans l'esprit de démocratisation des données que le Cures Act et FHIR promeuvent, le hub de données de santé "à être" du futur devrait inclure la capacité d'éviter le codage en dur et les scripts uniques. Un menu "glisser-déposer", une approche sans code/à faible code évitent de trop solliciter les équipes informatiques des soins de santé et permettent aux analystes et aux autres utilisateurs d'accéder aux données en libre-service . En outre, les centres de données sur les soins de santé devraient disposer de modèles de transformation intégrés puisque les structures USCDI et CCDA et les formats EDI tels que le 837 sont bien définis. Cela permet d'éliminer l'une des plus grandes pertes de temps pour l'informatique et de permettre aux super utilisateurs non informaticiens de travailler directement avec les données.

L'augmentation du partage des données données ne signifie pas automatiquement une meilleure qualité des données

La qualité des données est une autre question que FHIR n'aborde pas et qui, au contraire, risque d'exacerber le problème. Étant donné le partage des données plus large et, espérons-le, plus fréquent des données, il y aura toujours des erreurs de conversion de données inhérentes à l'envoi de ressources spécifiques distinctes au lieu d'enregistrements monolithiques, comme c'est le cas avec HL7V2. En outre, la nécessité de transformer les données demeurera et augmentera à mesure que des ensembles de données plus divers et plus disparates seront partagés. Un hub de données de santé doit maîtriser FHIR, EDI X.12 8xx, les anciennes versions de HL7 et d'autres normes pour effectuer des ingestions de données, réaliser les transformations entre les normes et fournir des fonctions de qualité des données telles que la déduplication et la capacité de mettre en place une reconnaissance des modèles pour les erreurs de conversion courantes. Enfin, les normes relatives aux formats de données dans chaque ressource FHIR peuvent changer au fil du temps. Un hub de données de santé doit être au courant des modifications apportées à la façon dont des données spécifiques doivent être transformées.

Tout ce partage des données entre les différents prestataires et payeurs s'effectue entre les applications et les référentiels de données. Les intégrations point à point représentent les connexions de données entre des processus opérationnels et commerciaux spécifiques et support analyse automatisée des données et l'support la décision pour les prestataires de soins et les travailleurs du savoir. L'automatisation de l'ingestion de données et de la sortie vers et depuis les différentes applications, services web et référentiels de données, la préparation, la transformation et l'unification est également un facteur essentiel pour un partage des données réussi. Là encore, FHIR facilite la solution, mais ne la complète pas.

Conclusions

La loi de 2009 sur la protection des patients et les soins abordables (Patient Protection and Affordable Care Act) a été un bon début pour élargir l'accès aux soins de santé pour des millions de citoyens sans avoir recours à un système à payeur unique. En outre, les sections de la loi qui encouragent les organisations de soins responsables axées sur les résultats répondent en partie à la nécessité - ou du moins la reconnaissent - de s'éloigner du modèle de paiement à l'acte. Le Cures Act, l'interprétation de l'ONC et le support FHIR en tant qu'outil de partage des données accéléreront sans aucun doute le passage à des soins basé sur la valeur en créant des conditions de concurrence équitables pour le partage des données. Une stratégie d'intégration des données plus complète est encore nécessaire et devrait se concentrer sur la combinaison et l'amélioration de la qualité des données médicales et non médicales.

Une stratégie globale d'intégration des données avec un hub de données est le moyen le plus efficace de s'assurer que toutes les données pertinentes et nécessaires sont rassemblées et ne peuvent pas répondre aux questions sur ce qui doit être ajusté dans un processus clinique, opérationnel ou financier donné ou une décision pour améliorer les résultats. Un entrepôt de données cloud et des outils d'analyse doivent être intégrés au hub de données afin d'analyser et d'extraire les informations nécessaires au passage du FFS au VBC. Dans mon dernier blog, nous avons décrit l'Actian Healthcare Data Analytics Hub, un moyen plus efficace d'extraire des informations pour les soins basé sur la valeur . Dans le prochain blog, nous examinerons quelques cas d'utilisation où l'analyse permet de passer du FFS au VBC.

À propos d'Actian Corporation

Actian facilite l'accès aux données. Notre plateforme de données simplifie la façon dont les gens connectent, gèrent et analysent les données dans les environnements cloud, hybrides et sur site . Avec des décennies d'expérience dans la gestion des données et l'analyse, Actian fournit des solutions de de haute performance qui permettent aux entreprises de prendre des décisions basées sur les données. Actian est reconnu par les principaux analystes et a reçu des prix de l'industrie pour sa performance et son innovation. Nos équipes partagent des cas d'utilisation éprouvés lors de conférences (par exemple, Strata Data) et contribuent à des projets à code source ouvert. Sur le blog d'Actian, nous abordons des sujets tels que l'ingestion de données en temps réel, l'analyse de données, la gouvernance données, la gestion des données, la qualité des données, l'intelligence des données et l'analyse pilotée par l'IA.