— 16 mai 2026 · 10 min de lecture

FHIR et HL7 v2 coexistent : architectures hybrides 2026

L'idée selon laquelle FHIR remplacerait HL7 v2 reste, en 2026, une prophétie commerciale plus qu'une réalité hospitalière. Les architectures hospitalières matures combinent les deux protocoles via des passerelles, un modèle strangler-fig et des disciplines de dual-write. Trois patterns pour durer.

Le mythe du remplacement

Quand FHIR a été publié en ballot en 2014, beaucoup d'observateurs annonçaient la fin proche de HL7 v2 : REST moderne, JSON, IG sectoriels, profils de référence — l'argumentation était séduisante. Onze ans plus tard, FHIR R5 (publié en mars 2023) est massivement déployé pour les interfaces patient-facing, les outils de coordination et les échanges inter-établissements ; HL7 v2.5.1 reste massivement déployé pour les flux internes hospitaliers — ADT, ORM, ORU, MDM en particulier.

Les raisons de cette coexistence sont structurelles. HL7 v2 a un poids d'installation considérable (estimé à plus de 95 % des hôpitaux américains actifs en 2025 par HIMSS), des dizaines de milliers d'intégrations bidirectionnelles avec les ADT, LIS, RIS, PACS, EMR, et des SLAs contractuels qui imposent de maintenir les flux historiques. Remplacer cela d'un coup, c'est de fait remplacer le système d'information de l'hôpital — un projet à 50-100 millions d'euros pour un CHU moyen.

Pattern 1 : Strangler-fig migration

Le pattern strangler-fig, popularisé par Martin Fowler en 2004, consiste à faire croître un nouveau système à côté de l'ancien, en redirigeant progressivement les responsabilités. Appliqué à FHIR vs HL7 v2 :

• On installe un FHIR server (HAPI FHIR, Microsoft FHIR Service, Google Cloud Healthcare API, etc.) à côté de l'interface engine v2 (Mirth, Rhapsody, Cloverleaf).
• On configure des routes dans l'interface engine qui dupliquent vers le FHIR server certains événements ADT et ORM. À chaque ADT^A01 reçu, par exemple, l'engine crée ou met à jour une ressource Patient et un Encounter FHIR.
• Les nouvelles applications (mobile, portail patient, outil d'aide à la décision clinique) consomment exclusivement le FHIR server, en GET /Patient/{id} ou GET /Observation?patient=....
• Les applications historiques (PACS, RIS, SI labo) continuent de consommer v2 par TCP/MLLP comme auparavant.
• Au fil du temps, application par application, on bascule les consommateurs v2 vers FHIR. La rampe est mesurée en années, pas en mois.

Le strangler-fig évite le big-bang et permet de maintenir la production pendant toute la migration. Son coût est l'infrastructure dupliquée (FHIR server à maintenir en parallèle) et la discipline de synchronisation (cohérence entre v2 et FHIR).

Pattern 2 : Gateway v2-FHIR

Le pattern gateway consiste à exposer une API FHIR au consommateur, et à traduire chaque appel REST vers/depuis HL7 v2 derrière. L'engine d'origine n'est pas modifié.

Concrètement :

• Un POST /Observation entrant déclenche l'émission d'un ORU^R01 v2 vers le LIS interne, après traduction des champs FHIR vers les segments OBR/OBX.
• Un GET /Patient/{id} déclenche un QRY^A19 v2 sortant vers l'ADT, dont la réponse RSP^K23 est traduite vers une ressource Patient FHIR retournée au client.
• Le gateway maintient typiquement un cache LRU avec invalidation par événements ADT^A01/^A08, pour absorber la charge des lectures fréquentes sans saturer l'ADT historique.

Ce pattern est moins invasif que strangler-fig — l'engine v2 d'origine n'est pas modifié — mais il introduit un point de couplage fort entre le gateway et les sémantiques v2. Toute évolution des messages v2 (nouveaux segments Z, changements de qualifier) doit être réfléchie côté gateway.

Des produits commerciaux dédiés existent : 1upHealth FHIR Bridge, InterSystems IRIS for Health (avec ses HSI Health Connect Productions), Redox Engine, Rhapsody FHIR Gateway. Côté open source, Apache Camel HL7 couplé à HAPI FHIR permet d'implémenter ce pattern.

Pattern 3 : Dual-write contrôlé

Le dual-write consiste à écrire chaque événement métier simultanément dans les deux systèmes — v2 ET FHIR. Pratique techniquement, mais piégée sur la cohérence si elle est mal disciplinée.

Trois précautions sont indispensables :

• Source unique de vérité : une seule base est autoritative. L'autre est dérivée. Si v2 reste autoritative, FHIR est un projection éventuelle ; si FHIR devient autoritative, v2 est dégradé en flux sortant compatible avec les systèmes legacy.
• Idempotence des deux écritures : chaque message v2 (MSH-10) et chaque ressource FHIR (resource.id) doit avoir un identifiant stable qui permet de dédupliquer en cas de rejeu. Les Bundle FHIR avec Bundle.entry.request.method = PUT sur un identifiant métier sont particulièrement bien adaptés.
• Réconciliation périodique : un job de comparaison quotidien identifie les écarts entre les deux bases et les remonte en alerting. Sans cela, la dérive est inévitable.

Exemple concret : un CHU français en 2026

Pour fixer les idées, voici l'allure d'une architecture hospitalière française moderne :

• Engine v2 historique (Mirth Connect ou OpenPaaS-PI selon les établissements) : 4 000 à 8 000 messages/jour ADT, ORM, ORU, DFT, SIU entre ~30 applications internes (ADT, LIS, RIS, PACS, EMR, pharmacie, biomédicaux).
• FHIR server (HAPI FHIR ou IRIS for Health) : expose les ressources Patient, Encounter, Observation, MedicationRequest pour le portail patient (DMP, espace de santé), pour les applications mobiles (eParcours, prescription connectée), et pour les échanges inter-établissements via le réseau eINS (Identité Nationale de Santé).
• Gateway v2→FHIR : traduit les flux ADT et ORU vers des ressources FHIR consommables par les applications modernes. Le coeur du SIH reste v2, la périphérie est FHIR.
• Interconnexion nationale : les échanges hors établissement (DMP, INSi, MSSanté) sont en FHIR R4 (le DMP français est aligné sur le profil IHE PDC FHIR, publié par l'ANS). Les flux légacy historiques passent encore par v2.5 sur des passerelles dédiées.

Cette coexistence n'est pas une transition. Elle est un état stable, parce que les deux protocoles ont des forces distinctes : v2 reste plus économe pour les flux internes haute fréquence (le pipe-delimited est 2-3x plus compact que JSON), FHIR domine pour la lecture par des applications hétérogènes et pour les échanges réseau.

Recommandations pour 2026

1. Ne pas remplacer v2. Le coût d'une migration big-bang dépasse de loin les bénéfices attendus. Conserver v2 sur les flux internes haute fréquence.
2. Construire une couche FHIR pour les nouvelles applications. Toute nouvelle interface (mobile, portail, outil de coordination) doit consommer FHIR — c'est la couche d'interopérabilité moderne.
3. Choisir un pattern de coexistence et s'y tenir. Mélanger strangler-fig et gateway crée une dette d'architecture difficile à rembourser ; il vaut mieux choisir un pattern dominant par périmètre.
4. Investir dans la gouvernance terminologique. SNOMED-CT, LOINC, ICD-10/11, RxNorm — la cohérence des codifications entre v2 et FHIR est l'enjeu le plus sous-estimé.
5. Aligner sur les profils nationaux. En France : IHE PDC, INSi, eINS. Aux États-Unis : US Core, USCDI v4 publié en 2024. Ces profils sont contraignants pour les certifications et appels d'offres.

La coexistence est l'état stationnaire

En 2026, FHIR et HL7 v2 ne sont pas en compétition : ils cohabitent dans des architectures hospitalières pragmatiques où chacun occupe le terrain pour lequel il est efficace. Le bon réflexe n'est pas de choisir l'un contre l'autre, mais de désigner explicitement les périmètres de chacun et d'investir dans les passerelles. Pour creuser, la page Introduction à FHIR donne les bases, et la page FHIR R5 vs HL7 v2.5.1 détaille les forces respectives. Côté ressources techniques, FHIR chez ediverse et HL7 v2.x chez ediverse recensent les ressources et messages les plus échangés.