Pourquoi migrer vers FHIR R5
FHIR R5, publié comme standard normatif par HL7 International en 2024, introduit des améliorations substantielles par rapport à R4. L'ONC recommande l'adoption de R5 pour les nouvelles implémentations et encourage la planification de migration pour les systèmes R4 existants.
La raison la plus convaincante est le cadre de souscription par thème. Les souscriptions R4 reposaient sur un filtrage par critères qui passait mal à l'échelle. R5 introduit les ressources SubscriptionTopic avec une diffusion de notifications agnostique du canal.
Les ressources de raisonnement clinique ont été étendues. PlanDefinition et ActivityDefinition supportent la logique de branchement complexe. Les nouvelles ressources Task et Transport standardisent la coordination des soins.
Le règlement EHDS référence explicitement les capacités R5 dans ses spécifications techniques, faisant de la conformité R5 un prérequis pour la participation à l'infrastructure européenne.
R5 apporte également un suivi amélioré de la provenance, le support des données génomiques via MolecularSequence et un ensemble mature de ressources de médecine fondée sur les preuves.
Ruptures de compatibilité clés de R4 à R5
Comprendre les ruptures est essentiel pour planifier la migration.
Remplacement du modèle de souscription : la ressource Subscription R4 est remplacée par SubscriptionTopic et Subscription avec une architecture fondamentalement différente. La migration nécessite la réécriture de la logique de souscription.
Renommages et scissions de ressources : MedicationStatement devient MedicationUsage. DeviceUseStatement devient DeviceUsage. CatalogEntry est supprimé. Ces changements nécessitent la mise à jour de toutes les références.
Modifications des paramètres de recherche : certains paramètres ont été renommés ou modifiés. L'outil de comparaison HL7 permet d'identifier les requêtes impactées.
Promotion d'extensions : des extensions courantes R4 deviennent des éléments de premier niveau en R5, nécessitant une transformation des données.
Changements de liaisons terminologiques : certains value sets sont renforcés de « example » à « required », nécessitant des mises à jour de mapping.
Planification et évaluation de la migration
Un plan structuré réduit les risques et assure la continuité des opérations cliniques.
Inventaire : cataloguer chaque type de ressource FHIR utilisé, incluant profils, paramètres de recherche, opérations et extensions.
Cartographie des dépendances : identifier tous les systèmes consommant ou produisant des données FHIR. Chaque dépendance doit être évaluée pour la compatibilité R5.
Migration des profils : les profils personnalisés doivent être mis à jour vers les ressources de base R5. Le SDK Firely fournit des outils de validation et de migration automatisés.
Environnement de test : établir un environnement R5 parallèle au système R4 de production. Charger des données représentatives et valider les flux critiques.
Chronologie : planifier une période de double support R4/R5. La spécification FHIR inclut la négociation de version via le paramètre fhirVersion.
Stratégie de retour arrière : définir des critères et procédures de rollback clairs.
Étapes techniques de migration
La migration technique suit un processus systématique.
Étape 1 — Mise à jour des bibliothèques FHIR : upgrader le SDK vers une version compatible R5 (HAPI FHIR 7.x, Firely SDK 5.x, fhir.js).
Étape 2 — Mise à jour des définitions de ressources : remplacer les ressources renommées, mettre à jour les chemins d'éléments, promouvoir les extensions.
Étape 3 — Migration des souscriptions : implémenter le modèle par thème. Définir les ressources SubscriptionTopic. Mettre à jour la logique de traitement des notifications.
Étape 4 — Mise à jour des requêtes de recherche : réviser les paramètres de recherche. Tester chaque requête contre le serveur R5.
Étape 5 — Migration des données : transformer les données R4 en format R5. Valider les ressources converties. Maintenir l'intégrité référentielle.
Étape 6 — Tests d'intégration : valider chaque point d'intégration externe avec les données R5.
Double support de version et interopérabilité
En pratique, les écosystèmes fonctionneront avec des implémentations mixtes R4/R5 pendant des années.
Négociation de version : les mécanismes de capability statement et de négociation de contenu permettent de servir R4 ou R5 selon les capacités du client.
API de conversion FHIR : l'opération $convert transforme les ressources entre versions. Un service de conversion au niveau de la gateway API permet d'accepter des requêtes R4 tout en stockant en R5.
Compatibilité SMART on FHIR : les applications SMART doivent continuer à fonctionner, le protocole de lancement étant indépendant de la version. Tester les apps contre le serveur R5 avant la production.
Export Bulk Data : l'implémentation doit pouvoir produire du NDJSON en R4 et R5 selon les demandes.
L'infrastructure FHIR d'On-Kare supporte les opérations simultanées R4 et R5, avec négociation de version automatique et conversion, assurant une interopérabilité transparente.
Optimisation post-migration
La complétion de la migration est le point de départ pour exploiter les capacités avancées de R5.
Architecture événementielle : refactoriser les flux batch en patterns événementiels. Les événements cliniques déclenchent un traitement en temps réel.
Aide à la décision clinique : exploiter les ressources PlanDefinition et ActivityDefinition enrichies pour encoder la logique CDS comme des artefacts partageables.
Conformité EHDS : mapper l'implémentation R5 aux exigences techniques de l'Espace européen des données de santé. Implémenter les profils International Patient Summary.
Optimisation des performances : les capacités de recherche améliorées et l'efficacité des souscriptions de R5 révèlent des opportunités d'optimisation.
Monitoring : implémenter une surveillance complète des fonctionnalités R5 incluant les taux de livraison des souscriptions et les patterns de négociation de version.