--- { "title": "FHIR R4 vs R5 vs R6 : comparaison de toutes les versions (2026)", "description": "Comparaison côte à côte des versions FHIR R4, R5 et R6 : fonctionnalités, adoption, abonnements R4B et ce qu'on attend de R6 — conseils pratiques de l'équipe Aidbox.", "date": "2025-10-07", "author": "Vlad Zholnerchuk", "reading-time": "7 minutes", "tags": [ "System Design", "FHIR Standard" ] } --- Lorsque les personnes qui implémentent FHIR demandent « Quelle version de FHIR devrais-je utiliser? », les néophytes supposent souvent qu'il est raisonnable de choisir la dernière version publiée. En octobre 2025, il s'agirait de FHIR R5, qui semble être le choix évident. Cependant, la décision est plus complexe, car elle nécessite une réflexion approfondie sur des facteurs tels que la compatibilité, l'adoption et la stabilité. Cet article offre un tour d'horizon pratique des points clés, des avantages et inconvénients, ainsi que des leçons tirées de notre expérience dans le soutien aux [implémentations FHIR](/articles/how-to-create-a-fhir-implementation-guide), avec un aperçu de ce que R6 pourrait apporter. ## Les nouveautés de FHIR R5 Dans l'ensemble, FHIR R5 compte plus de 4 000 modifications de différentes envergures par rapport à la version précédente. Consultez le [lien](https://hl7.org/fhir/R5/history.html#normative) pour obtenir la liste des principaux changements apportés dans FHIR R5. Parmi ceux-ci, deux se démarquent comme particulièrement significatifs : les nouveaux types de ressources et la fonctionnalité d'abonnement basé sur les sujets entièrement repensée. Examinons chacun de ces points plus en détail. ### Nouveaux types de ressources FHIR R5 introduit plus de 20 nouveaux types de ressources, dont 8 dans le nouveau module Medication Definition. Ce module décrit les médicaments en détail — couvrant les ingrédients, l'emballage, les formes d'administration, le statut réglementaire et les usages cliniques. Il rend FHIR plus utile pour les catalogues de médicaments, les soumissions réglementaires et les systèmes de sécurité qui nécessitent des informations complètes sur les produits. Bien que ces nouvelles ressources améliorent les capacités de FHIR, elles ne constituent pas nécessairement un « changement de paradigme » en matière d'interopérabilité. La plupart des [serveurs FHIR](https://www.health-samurai.io/fhir-server) ont comblé certaines lacunes de la spécification en utilisant des ressources personnalisées. Ceux qui avaient besoin de ces types de ressources avaient déjà trouvé des solutions de contournement. Même si vous adoptez R5 et ses nouveaux types de ressources, vos partenaires d'intégration pourraient avoir du mal à les utiliser directement, puisque la plupart des systèmes, y compris les grands écosystèmes nationaux et ceux des fournisseurs, fonctionnent encore sur R4. Cela annule l'avantage d'utiliser des types de ressources R5 normalisés. ### Abonnements FHIR R5 a entièrement remanié le cadre d'abonnement en introduisant la fonctionnalité d'abonnement basé sur les sujets afin de normaliser les notifications événementielles, ce qui facilite la définition et l'abonnement aux types d'événements (p. ex., « nouveau résultat de laboratoire pour le patient X ») et permet aux personnes qui implémentent de mieux activer les flux de travail en temps réel, importants pour les alertes des DSE, la santé publique et les SAC. C'est un atout pour les systèmes qui nécessitent des alertes en temps réel. Cependant, vous n'avez pas besoin de FHIR R5 pour bénéficier de cette fonctionnalité : HL7 a introduit une version intermédiaire — R4B — qui est essentiellement R4 avec le cadre SubscriptionTopic rétroporpté. De plus, les [serveurs FHIR](https://www.health-samurai.io/fhir-server) ne sont pas non plus limités ici, et il est possible d'utiliser des ressources personnalisées pour activer les abonnements dans n'importe quelle version de FHIR (comme nous l'avons fait dans [Aidbox](https://www.health-samurai.io/docs/aidbox/modules/topic-based-subscriptions/wip-dynamic-subscriptiontopic-with-destinations)). Maintenant que nous avons vu les nouveautés de R5, soupesons ces améliorations par rapport aux défis liés à la mise à niveau. ## Pourquoi les clients hésitent à utiliser FHIR R5 FHIR R5 est la version officielle la plus récente de FHIR, pourtant les taux d'adoption demeurent faibles dans l'ensemble du secteur, y compris parmi nos clients. FHIR R5 introduit des changements incompatibles et manque de rétrocompatibilité, ce qui rend la transition depuis FHIR R4 difficile pour les organisations sans efforts considérables. Les raisons se répartissent en deux catégories. ### Problèmes de rétrocompatibilité L'une des principales préoccupations concernant R5 est son manque de rétrocompatibilité. De nombreuses organisations ont bâti leurs systèmes sur FHIR R4, qui est actuellement la version la plus stable et la plus largement utilisée. Bien que certaines ressources comme Patient et Observation aient subi des modifications minimales entre R4 et R5, d'autres ont été profondément remaniées. Voici quelques exemples. L'une des ressources les plus utilisées — AllergyIntolerance — a introduit 3 nouvelles propriétés (dont une obligatoire), supprimé 2 propriétés, et modifié le type de données de l'élément type de `code` à `CodeableConcept`. Ainsi, cet extrait de ressource AllergyIntolerance en FHIR R4 : ```json { ... "type": "allergy", "recorder": { "reference": "Practitioner/example" }, "asserter": { "reference": "Patient/example" } ... } ``` Deviendrait ceci en FHIR R5 : ```json { ... "type" : { "coding" : [{ "system" : "http://hl7.org/fhir/allergy-intolerance-type", "code" : "allergy", "display" : "Allergy" }] }, "participant" : [{ "actor" : { "reference" : "Practitioner/example" } }, "actor" : { "reference" : "Patient/example" } }] } ``` Vous pouvez juger par vous-même de l'ampleur de la différence — et il ne s'agit là que d'un des dizaines d'ajustements de ce genre. Vous pouvez consulter la liste complète ici : [https://hl7.org/fhir/R5/diff.html](https://hl7.org/fhir/R5/diff.html) Les grands fournisseurs de DSE comme Epic et Oracle Health (anciennement Cerner) ont massivement investi dans les API et intégrations basées sur R4 — Epic avec sa plateforme « Epic on FHIR », et Oracle avec les API FHIR R4 de la plateforme Millennium, y compris l'accès aux données en lot. Les deux entreprises **ne prennent officiellement pas en charge FHIR R5**. Cela signifie que toute personne s'intégrant à ces écosystèmes a tout intérêt à travailler nativement avec R4 pour assurer l'interopérabilité. En parallèle, la mise à niveau vers R5 exige de reconcevoir les modèles de données, les API et les intégrations — et d'entreprendre des migrations de données complexes — ce qui rend cette transition à la fois coûteuse et risquée pour les organisations qui dépendent fortement d'une interopérabilité FHIR sans accroc. ### La norme de l'industrie : FHIR R4 Étant donné que la majeure partie du monde fonctionne actuellement sur FHIR R4, cette version restera vraisemblablement dominante pendant des années. Aux États-Unis, la position de R4 est renforcée par la réglementation — par l'intermédiaire du [Guide d'implémentation US Core](https://build.fhir.org/ig/HL7/US-Core/index.html) et de sa connexion à la [norme USCDI](https://www.healthit.gov/isp/united-states-core-data-interoperability-uscdi), qu'ONC exige pour la certification des technologies de l'information en santé. Des programmes gouvernementaux similaires dans d'autres pays ont également standardisé sur R4, poussant les fournisseurs et les prestataires vers la conformité. Même le [Guide d'implémentation International Patient Summary](https://build.fhir.org/ig/HL7/fhir-ips/index.html), [approuvé par l'OMS](https://www.who.int/initiatives/global-digital-health-certification-network) et adopté dans plusieurs régions pour faciliter l'échange transfrontalier de données de santé, est construit sur FHIR R4. Notre registre public de paquets FHIR contenant tous les IG publics fournit également des données analytiques qui appuient ces affirmations. ![](image-1.avif) En raison de cette intégration profonde, le respect de FHIR R4 améliore la compatibilité avec la grande majorité des API et écosystèmes basés sur FHIR existants. Cette adoption généralisée facilite la connexion avec d'autres systèmes de santé, favorisant un échange de données et une interopérabilité plus fluides au sein des réseaux de santé nationaux et transfrontaliers. Ces facteurs expliquent pourquoi certains membres de la communauté FHIR débattent de l'opportunité de passer à R5 maintenant ou d'attendre et de passer directement à R6. ## L'avenir : sauter R5 pour aller directement à R6? Certains membres de la communauté FHIR suggèrent de sauter complètement R5 et de passer directement de R4 à R6, bien que ce ne soit pas la position officielle de HL7. Puisque FHIR R5 est une version à usage expérimental avec des changements incompatibles et une adoption limitée chez les fournisseurs et les implémentations nationales, de nombreux implémenteurs hésitent à investir dans une version qui pourrait bientôt devenir obsolète. **On s'attend à ce que R6 rétablisse une certaine rétrocompatibilité et consolide les changements introduits dans R5** en rendant les ressources les plus utilisées [normatives](https://build.fhir.org/versions.html#std-process) — c'est-à-dire stables, prêtes pour la production et garanties contre les changements incompatibles. La communauté FHIR s'efforce désormais d'éviter d'autres changements perturbateurs, en visant la stabilité. Par conséquent, les organisations qui privilégient la stabilité à long terme et l'alignement avec l'écosystème pourraient trouver plus stratégique de rester sur R4 pour l'instant et de planifier une migration directe vers R6 une fois que celui-ci aura atteint une adoption plus large et un meilleur soutien en matière d'outillage. Chez Health Samurai, nous prévoyons fournir des outils qui permettront une migration directe plus fluide vers [FHIR R6](/blog/getting-ready-for-fhir-r6-what-you-need-to-know) dans Aidbox. Le [calendrier de R6 est délibéré](https://confluence.hl7.org/spaces/FMG/pages/256509111/Release+Plan+for+R6) : le premier scrutin « Normative » est prévu pour janvier 2026, avec deux scrutins supplémentaires déjà planifiés. D'autres tours sont attendus avant une version finale, de sorte que la norme ne devrait pas être achevée avant 2027. Entre-temps, les prochaines [extensions de versions croisées FHIR](https://build.fhir.org/ig/HL7/fhir-cross-version/) permettront d'adopter certaines fonctionnalités de R5 ou R6 tout en continuant à fonctionner sur R4. Cette approche permet aux organisations de profiter de certains avantages des versions plus récentes sans les risques et les coûts d'une migration complète prématurée. ## Quelle version de FHIR devriez-vous choisir? Bien qu'Aidbox prenne en charge FHIR R5, nos métriques montrent que seulement ~5 % des utilisateurs l'ont adopté. À moins qu'il n'existe des exigences impérieuses et spécifiques que seul FHIR R5 peut satisfaire, nous recommandons sérieusement d'envisager de reporter son adoption pour l'instant. Rester avec FHIR R4 offre stabilité, large soutien de l'industrie et de l'écosystème, ainsi qu'un chemin d'intégration clair avec les API FHIR et les guides d'implémentation existants. FHIR R4 demeure le choix le plus sûr et le plus pratique. Nous continuerons à surveiller l'évolution de la transition vers R6, mais pour ceux qui envisagent une mise à niveau, il vaut probablement mieux attendre plutôt que d'adopter R5 prématurément — surtout avec R6 à l'horizon. Voir aussi : [Le guide FHIR pour les DIT](/blog/the-fhir-guide-for-ctos-and-technical-leaders).