Le nombre de sources de données de santé dans le secteur médical ne cesse de croître, de nouveaux systèmes et applications étant continuellement ajoutés au flux de travail. Aujourd'hui, un hôpital moyen aux États-Unis utilise plus de 80 systèmes. Bon nombre de ces systèmes sont utilisés par plusieurs hôpitaux et sont connectés à des systèmes utilisés par d'autres institutions et organisations liées aux soins de santé, comme les pharmacies ou les laboratoires.

Le défi a été d'assurer l'interopérabilité entre ces multiples systèmes afin de pouvoir visualiser toutes les données en un seul endroit en temps réel. Cela a poussé les organisations de développement des normes HL7 à créer une nouvelle norme pour le format et une méthode de transfert des données cliniques et administratives.

Dans cet article, préparé en coopération avec Łukasz Śliwowski, Business Analyst Principal, nous expliquerons ce qu'est la norme FHIR et aborderons son architecture et sa mise en œuvre.

Qu'est-ce que FHIR en termes simples ?

FHIR (Fast Healthcare Interoperability Resources) est une norme mondiale développée par l'organisation HL7, qui décrit le format des données médicales pour l'échange de dossiers de santé électroniques entre divers systèmes médicaux de manière unifiée.

Avant l'introduction de la norme, les grands hôpitaux et centres médicaux disposaient parfois de jusqu'à 100 systèmes différents, par exemple pour l'information de laboratoire ou la gestion des lits d'hôpitaux, qui utilisaient tous un format de données différent. Cela causait de nombreuses difficultés dans l'échange de données, c'est pourquoi HL7 a élaboré une norme qui unifiait les formats de données. L'objectif était de faciliter l'interopérabilité entre les systèmes de santé existants et de permettre de fournir facilement des informations de santé sur une grande variété d'appareils à toutes les parties intéressées.

Cependant, les premières versions de la norme, HL7 v.2 développée dans les années 90 et HL7 v.3 du début des années 2000, étaient assez difficiles à mettre en œuvre et ne répondaient pas à toutes les exigences. En réponse à cela, en 2012, les développeurs de logiciels ont commencé à travailler sur la première itération de FHIR.

FHIR a été considéré comme un véritable changement de donne, car il intégrait une méthode d'échange d'informations moderne et plus standardisée basée sur l'API REST. Un autre avantage révolutionnaire de FHIR pour l'époque était qu'il avait été créé par des développeurs de logiciels, pour des développeurs de logiciels, contrairement aux normes HL7 antérieures élaborées par des cliniciens.

La différence résidait également dans l'approche du format des données. Les standards antérieurs à FHIR utilisaient un format contenant une grande quantité d'informations, semblable aux données traditionnelles et statiques d'un PDF. Extraire les informations pertinentes et les rendre exploitables dans tout autre format était assez laborieux et chronophage. FHIR, au contraire, a introduit une approche granulaire des données, ce qui signifie que seules les données nécessaires sont transférées. De plus, FHIR a résolu les défis séculaires de réconciliation des données en s'appuyant sur une API standardisée. Grâce à FHIR, les applications peuvent être facilement connectées à n'importe quel système de dossier médical électronique et des données spécifiques peuvent être facilement échangées entre les systèmes.

FHIR est un standard convivial pour les développeurs car il utilise JSON (XML et Turtle sont également une option), un format familier à presque tous les ingénieurs logiciels. Les données en JSON sont unifiées, ce qui donne une idée de ce à quoi un modèle de données devrait ressembler et de la manière dont les interfaces devraient être implémentées. L'implémentation des interfaces repose sur un concept connu sous le nom de ressources.

Architecture FHIR : ressources, références et profils

Que sont les ressources dans FHIR ?

Les ressources sont des éléments de données. Chaque donnée, par exemple les données d'un patient telles que son nom, son prénom et son âge, ses antécédents médicaux, les médicaments prescrits, etc., est considérée comme une ressource unique. Par exemple, vous pourriez trouver son nom, son adresse ou son numéro de téléphone dans une ressource nommée « patient ». Si vous souhaitez savoir quand un patient a été hospitalisé, vous devriez extraire cette information d'une ressource appelée «rencontrer». Pour en savoir plus sur leurs résultats de test, la ressource appropriée serait les « observations ». Il existe 145 ressources au total, mais seulement 20 sont d'usage courant.

Les ressources FHIR sont unifiées mais diffèrent par les détails de leur structure. Certains éléments sont liés aux métadonnées (qui décrivent quelle ressource, quel ID, etc. est utilisé), aux extensions possibles, au narratif et au modèle de données. Le narratif est un élément hérité des normes précédentes, qui contient un résumé lisible par l'homme des informations cliniques et métier de la ressource. Le cœur de chaque ressource réside dans les données contenues dans les balises JSON, qui sont échangées entre différents systèmes et peuvent être traitées ultérieurement.

Les ressources FHIR sont basées sur la règle des 80/20 – le FHIR de base doit s'appliquer à 80 % des cas et les 20 % restants sont dédiés aux cas spéciaux et rares. Pour pouvoir gérer ces derniers, FHIR a introduit les extensions, qui constituent une manière standardisée d'ajouter des données supplémentaires à une ressource.

Que sont les profils dans FHIR ?

Les profils dans FHIR sont utilisés pour personnaliser les ressources selon des cas d'usage spécifiques. Les organisations de santé peuvent préciser quelles ressources elles souhaitent utiliser.

Par exemple, une clinique pour enfants a besoin des informations sur le « parent le plus proche » (parents ou tuteurs légaux) de ses patients. Dans un tel cas, nous devrions définir dans un profil qu'une ressource « patient » doit toujours inclure cette information dans le système de la clinique, mais pas nécessairement dans d'autres systèmes.

En d'autres termes, grâce aux profils, FHIR permet la création d'une définition de ressource personnalisée et plus spécifique en spécifiant un ensemble de contraintes et d'extensions sur la ressource de base. Grâce à une communauté FHIR robuste, vous pouvez également choisir gratuitement parmi de nombreuses listes de profils prédéfinis, les plus couramment utilisés. Ils se trouvent dans les guides d'implémentation FHIR (IG), par exemple le US Core.

Que sont les références dans FHIR ?

Les références sont utilisées pour appliquer la granularité des données. Elles relient une ressource source à une ressource cible ; par exemple, une ressource appelée « Observations » peut être liée à une ressource nommée « Patient ». Supposons que « Observation » se rapporte à la mesure du poids d'un certain patient. Une référence renvoie alors à une ressource cible spécifique, dans ce cas, l'identifiant d'un patient. Les références rendent l'échange de données beaucoup plus simple.

Cependant, les références FHIR ne permettent pas d'échanger facilement toutes les données des patients entre hôpitaux à l'aide d'une seule ressource. C'est possible, mais cela nécessite d'utiliser plusieurs dizaines de ressources FHIR pour télécharger toutes les données nécessaires d'un hôpital à un autre.

Quels sont les défis liés à la mise en œuvre de FHIR ?

Actuellement, la plus grande difficulté dans l'adoption de FHIR est la qualité des données entre les différents systèmes. Par exemple, recherche montre qu'il existe une grande variation dans les conventions de nommage des laboratoires dans les DSE au sein des hôpitaux et entre eux aux États-Unis. Les données sont souvent sous forme de texte non structuré ou enregistrées de manière incohérente, ce qui les rend difficiles à gérer.

Vaut-il la peine d'adopter FHIR ?

En mars 2020, les Centers for Medicare & Medical Services (CMS) des États-Unis ont publié la règle sur l'interopérabilité et l'accès des patients afin d'améliorer davantage l'échange électronique de données de santé – le partage d'informations avec les patients ou entre un payeur et un prestataire, ou entre deux payeurs. La date de renforcement de cette règle est le 1er janvier 2023.

Pour permettre une méthode d'échange d'informations plus fluide, les réglementations CMS incluent des politiques qui exigent ou encouragent la mise en œuvre d'API pouvant se connecter à des applications mobiles ou à un EHR de fournisseur ou à un système de gestion de cabinet. Le CMS recommande que les organisations utilisent FHIR pour mettre en œuvre les API afin de répondre aux nouvelles exigences. Par conséquent, le moment est venu d'adopter la norme, car elle deviendra bientôt une nécessité plutôt qu'une option.

Notre équipe peut vous aider à développer un logiciel intégré à la norme FHIR qui répondra à toutes les exigences de la réglementation CMS ainsi qu'à intégrer votre logiciel actuel avec un autre système utilisant FHIR. Contactez-nous pour plus d'informations.