On-Kare
    Retour au Blog
    Gestion de cabinet

    La révolution de l'interopérabilité : HL7 FHIR R5 et l'avenir de l'échange de données de santé

    Comment la dernière norme FHIR, les applications SMART on FHIR et l'Espace européen des données de santé décloisonnent les systèmes d'information de santé et permettent une prise en charge véritablement connectée.

    Erwan Deschamps

    Co-Fondateur & CTO

    Architecte health-tech spécialisé en systèmes cliniques IA, normes d’interopérabilité et cybersécurité.

    Publié le 10 juin 2025Mis à jour le 20 novembre 20259 min de lecture2,255 mots

    L'impératif de l'interopérabilité

    Le secteur de la santé reste l'une des dernières grandes industries où les données critiques sont régulièrement enfermées dans des systèmes incompatibles. Une enquête HIMSS de 2024 révèle que 73 % des établissements de santé sont encore confrontés à la fragmentation des dossiers patients sur plusieurs plateformes, et qu'un hôpital moyen maintient plus de 16 intégrations distinctes avec des systèmes de dossiers de santé électroniques. Le coût humain est considérable : l'ONC estime que les défaillances dans l'échange d'informations de santé contribuent à environ 80 % des erreurs médicales graves, tandis que les examens redondants dus à l'inaccessibilité des données coûtent au système de santé américain quelque 45 milliards de dollars par an.

    La dynamique réglementaire contraint désormais l'industrie à agir. Les dispositions relatives à l'interopérabilité du 21st Century Cures Act, appliquées depuis 2023, interdisent explicitement le blocage d'information et imposent un accès normalisé par API aux informations de santé électroniques. En Europe, le règlement sur l'Espace européen des données de santé (EHDS), adopté en 2024, établit un cadre juridique exigeant de tous les États membres la mise en place d'une infrastructure interopérable de données de santé d'ici 2028. Il ne s'agit pas de recommandations aspirationnelles : ces textes comportent des mécanismes d'application et des sanctions financières.

    Pour les éditeurs de technologies de santé et les gestionnaires de cabinet, le message est sans équivoque : l'interopérabilité n'est plus un avantage concurrentiel, mais un socle réglementaire. Les plateformes incapables de démontrer un échange de données conforme aux normes s'exposent à une exclusion croissante du marché, à des risques de conformité et, in fine, à une responsabilité clinique.

    Les nouveautés de FHIR R5

    FHIR R5, publié en tant que standard normatif complet par HL7 International en 2024, représente l'évolution la plus significative de la spécification FHIR depuis sa création. Si FHIR R4 avait établi le paradigme basé sur les ressources qui a remplacé la messagerie HL7 v2 pour les implémentations modernes, R5 répond aux difficultés concrètes apparues lors des déploiements R4 à grande échelle.

    L'ajout le plus déterminant est le cadre de souscription par thème (topic-based subscription). Les versions précédentes de FHIR reposaient sur le polling ou des modèles de souscription rudimentaires peu adaptés à la montée en charge. R5 introduit les ressources SubscriptionTopic définissant des événements déclencheurs précis, associées à une diffusion de notifications agnostique du canal de communication : hooks REST, WebSockets, courriel et files de messages. Cela permet de bâtir des architectures véritablement événementielles, où les systèmes en aval réagissent aux événements cliniques en quasi temps réel, au lieu d'interroger périodiquement les sources de données.

    Les ressources de raisonnement clinique ont été considérablement enrichies. Les ressources PlanDefinition et ActivityDefinition prennent désormais en charge une logique de branchement complexe, permettant d'encoder des workflows sophistiqués d'aide à la décision clinique sous forme de ressources FHIR partageables. Les nouvelles ressources de workflow, notamment Task et Transport, fournissent des schémas standardisés pour la coordination des soins au-delà des frontières organisationnelles.

    R5 apporte également un suivi amélioré de la provenance, une prise en charge renforcée des données génomiques via la ressource MolecularSequence, et un ensemble plus mature de ressources dédiées à la médecine fondée sur les preuves. Pour les implémentations encore sous R4, HL7 fournit des guides de migration détaillés, mais les avantages architecturaux des modèles de souscription et de workflow de R5 font de la migration une priorité stratégique.

    SMART on FHIR : bâtir l'écosystème applicatif

    Le cadre SMART (Substitutable Medical Applications, Reusable Technologies) on FHIR a transformé la manière dont les applications cliniques sont développées, distribuées et lancées au sein des environnements de dossiers de santé électroniques. En combinant le modèle de données FHIR avec l'autorisation OAuth 2.0 et l'authentification OpenID Connect, SMART on FHIR fournit un protocole de lancement applicatif normalisé permettant d'intégrer des applications tierces directement dans le flux de travail du clinicien.

    L'impact pratique est considérable. Un spécialiste développant un outil d'analyse d'images dermatologiques n'a plus besoin de créer des intégrations sur mesure pour chaque éditeur de DSE. Une seule application SMART on FHIR peut se lancer dans Epic, Cerner ou tout système conforme, en recevant un jeton d'accès FHIR dont la portée est limitée au contexte patient en cours. La galerie SMART App référence déjà plus de 200 applications certifiées couvrant l'aide à la décision clinique, l'engagement patient, la génomique et les fonctions administratives.

    La spécification Backend Services de SMART étend le modèle à la communication serveur-à-serveur, rendant possibles l'analyse en santé populationnelle, le reporting qualité et l'extraction de données en masse sans interaction utilisateur. Combinée à la spécification Bulk FHIR, elle permet aux organisations d'exporter des cohortes entières de patients au format NDJSON à des fins de recherche, d'audit ou de pipelines d'apprentissage automatique.

    Pour les plateformes de santé, la prise en charge de SMART on FHIR est devenue incontournable. Les critères de certification de l'ONC exigent désormais les capacités de lancement SMART, et les organismes payeurs commencent à imposer des API d'accès conformes à SMART dans le cadre de la règle finale CMS sur l'interopérabilité et l'accès patient.

    L'échange transfrontalier de données de santé : l'Europe et au-delà

    Le règlement sur l'Espace européen des données de santé constitue l'initiative transfrontalière la plus ambitieuse jamais entreprise en matière de données de santé. Englobant les 27 États membres de l'UE, l'EHDS établit deux cas d'usage principaux : l'utilisation primaire, accordant aux citoyens un accès électronique à leurs données de santé à travers les frontières, et l'utilisation secondaire, permettant aux chercheurs, régulateurs et décideurs d'accéder à des jeux de données de santé anonymisés via des Organismes d'accès aux données de santé agréés.

    L'infrastructure technique de l'EHDS repose sur des normes existantes, notamment HL7 FHIR, le résumé patient international (IPS) et le format européen d'échange de dossiers de santé électroniques (EEHRxF). En imposant la conformité IPS, le règlement garantit qu'un patient se rendant dans un hôpital à Barcelone pourra voir sa liste de médicaments, ses allergies et ses pathologies actives provenant d'une clinique berlinoise rendues dans un format localement compréhensible, le tout en quelques secondes.

    Au-delà de l'Europe, des initiatives similaires s'accélèrent. Le Global Digital Health Partnership, représentant plus de 30 pays, a approuvé des profils d'échange basés sur FHIR. Le My Health Record australien, le Health Information Exchange sud-coréen et la stratégie pancanadienne sur les données de santé intègrent tous FHIR comme standard fondamental. Le TEFCA aux États-Unis, bien que centré sur le territoire national, adopte des principes d'interopérabilité alignés sur les standards internationaux.

    Pour les plateformes de santé multinationales, concevoir l'échange de données transfrontalier dès l'origine évite un réaménagement coûteux. L'adoption des profils IPS, la prise en charge de services terminologiques multilingues via SNOMED CT et CIM-11, et la mise en place de cadres de gestion du consentement alignés à la fois sur le RGPD et le HIPAA ne sont plus des objectifs lointains, mais des exigences pratiques pour toute plateforme opérant dans plusieurs juridictions.

    Architecture orientée API pour la santé numérique moderne

    Le passage des systèmes monolithiques de DSE à des architectures fondées sur les microservices et les API transforme l'infrastructure technologique de santé. Une approche « API-first » signifie que chaque fonctionnalité, qu'il s'agisse de la planification, de la prescription, de la commande de laboratoire ou de la facturation, est conçue comme un service déployable indépendamment, exposant des points de terminaison RESTful ou GraphQL documentés. FHIR sert de lingua franca pour l'échange de données cliniques, tandis que des API spécialisées gèrent les workflows opérationnels.

    L'architecture événementielle (EDA) complète ce modèle en découplant les services via une messagerie asynchrone. Lorsqu'un résultat de laboratoire est enregistré, un événement est publié sur un courtier de messages tel qu'Apache Kafka ou ses équivalents cloud natifs. Les abonnés, qu'il s'agisse d'un service de notification, d'un moteur d'aide à la décision clinique ou d'un module de facturation, consomment et traitent l'événement de manière indépendante. Ce schéma, combiné au cadre de souscription de FHIR R5, rend possibles des workflows cliniques en temps réel auparavant irréalisables avec les moteurs d'intégration orientés batch.

    Les plateformes de santé modernes adoptent également des passerelles API intégrant nativement la limitation de débit, le versionnement et l'application du consentement. Chaque appel API passe par des couches d'autorisation qui vérifient non seulement l'identité de l'utilisateur, mais aussi le consentement au partage de données, en conformité avec les exigences réglementaires. Les outils d'observabilité, incluant le traçage distribué et l'analytique d'API, offrent une visibilité sur les flux de données absente des intégrations point-à-point traditionnelles.

    Les bénéfices sont mesurables. Les organisations adoptant une architecture de santé orientée API rapportent des délais d'intégration réduits de 60 % avec les nouveaux partenaires, une diminution de 40 % de la charge de maintenance par rapport aux approches basées sur des moteurs d'interface, et une expérience développeur sensiblement améliorée. Pour On-Kare et les plateformes similaires, cette architecture permet une livraison rapide de fonctionnalités tout en maintenant la posture de conformité qu'exige le secteur de la santé.

    2 156 capacités cliniques et opérationnelles. Une seule plateforme.

    8 domaines métier, 25 spécialités, 7 cadres de soin et 343 capacités augmentées par l'IA — sans multiplier les logiciels.

    Voir la couverture