— 15 mai 2026 · 10 min de lecture

FHIR R5 vs HL7 v2.5.1 : que choisir en 2026 ?

La question revient à chaque RFP d'intégration hospitalière : faut-il continuer sur HL7 v2.5.1 ou basculer sur FHIR R5 ? La bonne réponse n'est ni « tout v2 » ni « tout FHIR », mais un partage explicite des cas d'usage. Cinq angles pour décider.

Deux standards, une même organisation

HL7 v2 et FHIR sont édités par la même organisation, Health Level Seven International, fondée en 1987 et basée à Ann Arbor (Michigan). HL7 v2 sort en 1989 ; la dernière version mineure encore largement déployée est 2.5.1 (2007), mais la branche officielle a continué jusqu'à 2.9.1 (2023). FHIR, lancé en 2011 par Grahame Grieve, est passé par DSTU (2014), STU2 (2015), STU3 (2017), R4 (2019), R4B (2022) et atteint la normalisation R5 en mars 2023.

Le double catalogue n'est pas un accident : HL7 v3, lancé en 2005, n'a pas convaincu cliniquement (trop académique, trop verbeux), et l'organisation a choisi de relancer une approche pragmatique en gardant v2 comme rail historique et en construisant FHIR à côté, comme rail moderne — sans déprécier officiellement v2.

En 2026, HL7 v2.5.1 reste massivement déployé : une étude HIMSS Analytics de 2024 estimait que plus de 80 % des hôpitaux nord-américains opèrent encore des moteurs d'intégration sur v2. FHIR est en montée régulière, accélérée par les régulations CMS Interoperability aux États-Unis et le European Health Data Space en Europe.

Syntaxe : lire les deux côte à côte

Un message HL7 v2.5.1 est une suite de segments séparés par \r, avec à l'intérieur de chaque segment des champs séparés par |, des composants séparés par ^ et des sous-composants par &. Un fragment d'admission patient (ADT^A01) typique :

MSH|^~\&|HIS|HOPITAL|EDI|GENERAL|20260515102000||ADT^A01|MSGID12345|P|2.5.1
EVN|A01|20260515102000
PID|1||4567890^^^HOPITAL^MR||DUPONT^MARIE^J^^MME||19851210|F|||12 RUE DU MARCHE^^PARIS^^75001^FRA

Le même cas en FHIR R5 devient un POST sur /Patient, avec en body :

{ "resourceType":"Patient", "identifier":[{"system":"urn:oid:1.2.250.1.213.1.4.8","value":"4567890"}], "name":[{"family":"DUPONT","given":["MARIE","J"],"prefix":["MME"]}], "gender":"female", "birthDate":"1985-12-10", "address":[{"line":["12 RUE DU MARCHE"],"city":"PARIS","postalCode":"75001","country":"FRA"}] }

Le contraste est saisissant — et trompeur. Les deux portent exactement la même information clinique. La différence est de niveau d'abstraction : v2 sérialise au caractère près, FHIR sérialise au schéma JSON ou XML. C'est la différence entre un protocole binaire et une API d'application.

Paradigme d'échange : messaging vs REST

Sous la syntaxe, c'est le paradigme d'échange qui diffère. HL7 v2 est un protocole de messaging orienté événement : le système source détecte un fait (admission, sortie, prescription, résultat) et émet un message ADT, ORM, ORU, MFN à destination de un ou plusieurs récepteurs configurés. Le transport historique est MLLP (Minimal Lower Layer Protocol) sur TCP — un cadrage binaire ultra-simple — souvent réinséré dans un moteur d'interface (Mirth Connect, Rhapsody, Cloverleaf, InterSystems Ensemble).

FHIR est, de naissance, une API REST : GET/POST/PUT/DELETE sur des ressources individuelles, avec des opérations spéciales comme $everything ou $expand pour les terminologies. Le serveur FHIR — HAPI, Smile CDR, Microsoft FHIR Server, AWS HealthLake — expose un endpoint HTTPS unique pour toutes les ressources. Le mode d'interaction par défaut est pull : c'est le consommateur qui demande, contrairement à v2 où c'est l'émetteur qui pousse.

FHIR supporte aussi le messaging (FHIR Messaging) et les Subscriptions (push push via webhook ou WebSocket depuis R4), mais le cas d'usage canonique reste l'API REST.

Profilage : IGs FHIR vs segments Z

Les deux standards partagent un problème commun : l'écart entre la spec générique et les besoins locaux. La façon de le résoudre diffère radicalement.

En HL7 v2, on ajoute des segments Z : ZIN (informations d'assurance étendues), ZBE (mouvements de séjour spécifiques), etc. Ces segments ne font pas partie du standard ; ils sont définis bilatéralement entre l'émetteur et le récepteur. Le risque connu : deux hôpitaux qui utilisent un ZIN différent pour stocker la même information, et donc deux mappings nécessaires.

En FHIR, on publie des Implementation Guides (IG) : US Core, IPS (International Patient Summary), Interopérabilité Santé France (publié par l'ANS), CARIN BB pour les payeurs aux États-Unis, etc. Un IG est un ensemble de profiles (StructureDefinition) qui restreignent les ressources, plus des ValueSets et des CapabilityStatements. Le tout est versionné, packagé en NPM-like package, et téléchargeable depuis HL7.org. Les serveurs FHIR savent valider une ressource contre un IG, contrairement aux moteurs v2 qui doivent embarquer la logique des segments Z en code applicatif.

La conséquence pratique : un IG FHIR est un contrat partageable ; un segment Z reste une convention bilatérale.

SMART on FHIR et l'écosystème applicatif

Un autre point de divergence est l'écosystème applicatif. FHIR a, depuis 2014, défini SMART on FHIR : une couche d'authentification OAuth 2.0 + OpenID Connect qui permet à une application tierce (web, mobile) d'accéder aux données d'un patient depuis un EHR (Electronic Health Record) avec le consentement explicite du patient ou du clinicien. Cet écosystème a donné naissance à plus de 700 applications certifiées (gestion du diabète, suivi médicament, dashboards cliniciens) qui plug-and-play sur n'importe quel serveur FHIR conforme.

HL7 v2 n'a pas d'équivalent. Un moteur v2 ne se « branche » pas : chaque intégration est codée à la main dans le moteur d'interface (Mirth, Rhapsody). Le marché des applications cliniques tierces s'est donc structuré autour de FHIR, pas autour de v2.

Là où v2 reste pertinent

Trois cas d'usage où HL7 v2.5.1 reste le bon choix en 2026 :

• Communication intra-hôpital legacy. Le système d'information d'un hôpital est typiquement un cluster d'applications (ADT du HIS, LIS du laboratoire, RIS-PACS de l'imagerie, PIS de la pharmacie) qui se parlent depuis quinze ou vingt ans en v2. Migrer tout l'écosystème vers FHIR a un coût prohibitif, et l'apport clinique est marginal. v2 reste le langage interne.
• Événements à haut volume, basse latence. Un ADT^A08 (update patient) émis vers vingt récepteurs internes dans la même minute est plus efficace en v2 sur MLLP qu'en POST FHIR sur HTTPS, à débit comparable. La surcharge HTTPS (handshakes TLS, headers) compte à l'échelle hospitalière.
• Imagerie / observations en flux. ORU^R01 (résultat d'observation) en v2 est massivement déployé pour les flux LIS→HIS et reste plus rapide que Observation en FHIR pour les volumes typiques d'un laboratoire de routine.

Là où FHIR R5 est meilleur

Trois cas symétriques où FHIR R5 doit être préféré :

• Exposition externe / API patient. Toute interface destinée à une application tierce, à un patient (dossier médical partagé, application mobile), ou à un partenaire externe (assurance, recherche) doit être en FHIR. Le surcoût v2-vers-FHIR à la frontière externe est ingérable à terme.
• Échange transfrontalier. L'EHDS (European Health Data Space) adopté en 2025 désigne FHIR R4/R5 + l'IG IPS comme socle pour le partage transfrontalier de résumés de patient et de prescriptions. v2 n'est pas une option ici.
• Décisionnel et data plateforme. Les pipelines data modernes (data lake, lakehouse, fournisseurs cloud) ingèrent du JSON nativement ; FHIR JSON s'y plug-and-play, alors qu'un message v2 doit être parsé puis re-sérialisé.

La stratégie de coexistence

En 2026, le consensus opérationnel est la coexistence stratifiée. À l'intérieur de l'hôpital, on garde HL7 v2.5.1 — pas par conservatisme mais parce qu'il fonctionne et que la migration n'est pas justifiée économiquement. À la frontière externe (vers les apps patients, les payeurs, les autorités sanitaires, les partenaires de recherche), on expose une couche FHIR R5. Le moteur d'interface (Mirth Connect, Rhapsody, Smile CDR) joue le rôle de traducteur entre les deux univers, pratiquant des transformations bidirectionnelles.

Cette stratégie suppose une discipline de mapping rigoureuse — qui est exactement le sujet de la page d'introduction à FHIR. Les pièges classiques : cardinalités v2 0..* qui deviennent FHIR 0..1, identifiants v2 sans system URI explicite, codes v2 non mappés à des terminologies FHIR (LOINC, SNOMED, ICD-10).

Choisir, c'est expliciter le cas

La question « v2 ou FHIR ? » est mal posée. La vraie question est « quel flux concerne quel acteur, à quel débit, avec quel besoin de partage ? ». Pour les flux intra-hôpital legacy stable, v2 reste meilleur. Pour tout ce qui sort, FHIR R5 est meilleur. Le moteur d'interface est le lieu où les deux mondes se rencontrent, et un bon mapping bidirectionnel — testé, versionné, monitorisé — est le vrai livrable.

Pour aller plus loin sur FHIR et son écosystème, voir la page FHIR R5 chez ediverse et la page d'HL7 v2.x côté legacy.