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 afin de lever ces obstacles au partage de l’information et d’apporter davantage de transparence sur les coûts des soins de santé et les remboursements. De plus, l’Office of National Coordination of Healthcare Information Technology (ONCHIT, désormais ONC) a défini partage des données spécifiques partage des données (interopérabilité), des lignes directrices d’utilisation et des délais de mise en œuvre obligatoires pour que les payeurs et les prestataires se mettent au diapason. La norme d’interopérabilité qui en résulte, Fast Healthcare Interoperability Resources (FHIR, prononcé « Fire »), constitue la dernière mise à jour de Health Layer 7 (HL7), à savoir la version HL7v4 actuellement en vigueur. D’ici 2024, il est prévu de remplacer la norme de facto actuelle, HL7v2 (HL7v3 n’ayant pas été largement mise en œuvre aux États-Unis), par FHIR. Étant donné que plus de 95 % des établissements de santé utilisent HL7v2, vous souhaiterez peut-être mieux comprendre l’impact que cela pourrait avoir sur votre activité 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.

Le site web HealthIT du gouvernement propose des comparaisons plus approfondies entre FHIR et HL7v2, ainsi que des descriptions détaillées des normes USCDI et CCDA. Le point essentiel à retenir est que la nouvelle norme FHIR offre une simplicité, une granularité et une standardisation bien supérieures quant aux données à partager et à la manière de les formater pour permettre ce partage. Si FHIR élimine les obstacles à l’interopérabilité, il ne garantit pas pour autant partage des données ouvert et accessible partage des données de santé partage des données vous ne relevez pas les autres défis liés à l’intégration des données, notamment ceux liés aux silos de données de santé. Sans une adaptation concomitante de votre stratégie d’analyse des données et de ses mises en œuvre, ces silos persisteront. Par extension, cela ne favorisera que marginalement la transition du système de rémunération à l’acte (FFS) vers le paiement basé sur la valeur (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.

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, s’appuyant sur un hub de données comme moyen le plus efficace de garantir la consolidation de toutes les données pertinentes et nécessaires, ne suffit pas à répondre aux questions concernant les ajustements à apporter à un processus ou à une décision clinique, opérationnelle ou financière donné(e) afin d’améliorer les résultats. Un entrepôt de données cloud des outils d’analyse doivent être intégrés au hub de données pour analyser et extraire les informations permettant de mener à bien la transition du modèle de rémunération à l’acte (FFS) vers le modèle de rémunération basé sur la valeur (VBC). Dans mon dernier article de blog, nous avons présenté l’Actian Life Sciences Data Analytics Hub, une méthode plus efficace pour extraire des informations utiles à la mise en œuvre basé sur la valeur . Dans le prochain article, nous examinerons quelques cas d’utilisation où l’analyse de données favorise la transition du paiement à l’acte (FFS) vers le paiement basé sur la valeur (VBC).

À propos de l'auteur