En France, tout logiciel de santé qui communique avec un SIH hospitalier, alimente le DMP ou s’inscrit dans le Ségur du numérique doit respecter les standards d’interopérabilité définis par l’ANS : FHIR R4 pour les nouveaux développements, HL7 v2 pour les intégrations existantes, et le CI-SIS comme cadre de conformité. Ce guide explique concrètement lequel choisir et comment l’intégrer.
Dernière mise à jour : mars 2026
Les standards : FHIR, HL7 v2, CDA — lequel pour quoi ?
HL7 v2 est le standard historique. Il est omniprésent dans les SIH français — ADT (admissions), résultats de labo, prescriptions. C’est du message texte structuré (pipes |), robuste mais rigide. Si vous devez vous connecter à un système hospitalier existant, vous tomberez probablement sur du HL7 v2.
HL7 CDA (Clinical Document Architecture) est un format XML pour les documents cliniques. C’est le format utilisé pour les volets du CI-SIS (comptes-rendus, lettres de liaison). Si vous devez alimenter le DMP ou Mon Espace Santé, vous passerez par du CDA.
FHIR R4 (Fast Healthcare Interoperability Resources) est le standard moderne. API REST, JSON natif, ressources modulaires (Patient, Observation, MedicationRequest…). C’est la direction prise par l’ANS, le Ségur du numérique, et la plupart des projets européens.
En 2025, 71 % des pays interrogés utilisent activement FHIR (source : State of FHIR Survey, HL7/Firely) et 73 % des pays avec une régulation e-santé imposent ou recommandent FHIR. Plus de 90 % des vendeurs d’EHR supportent FHIR comme standard d’interopérabilité de base.
Quel standard choisir ?
La réponse pragmatique : ça dépend de votre interlocuteur.
| Contexte | Standard recommandé |
|---|---|
| Connexion à un SIH existant (ADT, labo) | HL7 v2 — c’est ce que le SIH parle |
| Alimentation DMP / Mon Espace Santé | CDA (volets CI-SIS) |
| Nouveau projet, API-first | FHIR R4 |
| Ségur du numérique (vagues 1 & 2) | FHIR R4 + CDA selon le volet |
| Échanges européens (EHDS) | FHIR R4 |
Retour terrain : en France, HL7 v2 reste le standard dominant dans les échanges intra-hospitaliers. FHIR est plus avancé dans les projets européens et les nouveaux développements. Les deux coexistent — et coexisteront encore longtemps.
L’European Health Data Space (EHDS) vise plus de 80 % d’adoption FHIR en Europe d’ici 2026 — un accélérateur massif pour les éditeurs qui implémentent FHIR dès maintenant.
Le CI-SIS : le cadre français
Le CI-SIS (Cadre d’Interopérabilité des Systèmes d’Information de Santé) est la doctrine de l’ANS. Il définit :
- Les volets de contenu : quelles informations échanger (compte-rendu d’hospitalisation, lettre de liaison, résultats de biologie…)
- Les profils IHE à implémenter : comment échanger (PIXm pour l’identité patient, PDQm pour la recherche patient, MHD pour le partage de documents…)
- Les standards sous-jacents : FHIR, CDA, HL7 v2 selon le volet
Si votre logiciel touche au parcours de soin, le CI-SIS n’est pas une recommandation — c’est le socle de conformité attendu par l’ANS.
Le Ségur du numérique a accéléré l’adoption : en 2025, 420 millions de documents ont été déposés dans Mon Espace Santé (+40 % vs 2024), par 67 000 médecins, 17 000 pharmacies et 3 700 établissements (source : ANS, décembre 2024).
Concrètement, comment intégrer FHIR dans votre projet
1. Identifiez vos cas d’usage d’échange
Avant de choisir un standard, listez ce que votre logiciel doit échanger et avec qui :
- Rechercher/récupérer un patient ? → Profil PDQm (Patient Demographics Query)
- Envoyer un document au DMP ? → Profil MHD (Mobile access to Health Documents)
- Recevoir des mises à jour patient ? → Profil PIXm (Patient Identifier Cross-referencing)
- SSO avec le SIH ? → SMART on FHIR (OAuth2)
2. Implémentez les ressources FHIR nécessaires
FHIR est modulaire. Vous n’avez pas besoin d’implémenter toute la spécification — seulement les ressources pertinentes pour vos cas d’usage. Les plus courantes :
Patient— identité, INSPractitioner— professionnel de santé, RPPSDocumentReference+Binary— documents cliniquesMedicationRequest— prescriptionsObservation— résultats, mesures
La spécification FHIR R4 complète est disponible sur hl7.org.
3. Validez sur Gazelle
Gazelle est la plateforme de tests d’interopérabilité de l’ANS. Le Projectathon ANS (événement annuel) permet de tester vos implémentations FHIR contre d’autres systèmes en conditions réelles. En 2024, 45 entreprises y ont participé avec 320 scénarios testés (source : ANS).
C’est le meilleur moyen de prouver votre conformité — et un argument commercial solide auprès des établissements de santé.
Yes We Dev, agence HealthTech en Bretagne, a validé l’interopérabilité FHIR R4 de son propre dispositif médical Thalivia lors du Projectathon ANS 2026. Nous accompagnons nos clients industriels de santé sur le même parcours.
Les pièges fréquents
Le piège EAI : acheter un outil d’intégration (Enovacom, Raptor — ~60K€/an) pour “faire de l’interop”. Ces outils sont des passe-plats — ils traduisent les formats mais ne vous rendent pas interopérable au sens du CI-SIS. Si vous construisez un nouveau logiciel, implémentez les normes directement.
Le piège “FHIR-ready” : afficher la compatibilité FHIR sans l’avoir validée. Un endpoint qui renvoie du JSON ne fait pas un serveur FHIR conforme. La validation passe par les parseurs FHIR, les validateurs syntaxiques/sémantiques, et idéalement un Projectathon.
Le piège périmètre : vouloir tout implémenter d’un coup. Commencez par 1-2 profils IHE critiques pour votre cas d’usage, validez, puis élargissez.
Ce que l’ANS attend de vous
Si votre logiciel est référencé Ségur ou vise le marché hospitalier français :
- Conformité CI-SIS sur les volets pertinents
- INS (Identité Nationale de Santé) — identifiant patient normalisé
- Pro Santé Connect — authentification des professionnels de santé via CPS/e-CPS
- DMP/Mon Espace Santé — alimentation si applicable
Ce n’est pas optionnel. C’est le ticket d’entrée.
L’impact est mesurable : 8 médecins sur 10 utilisant un réseau d’échange de données de santé (HIE) rapportent une baisse des prescriptions redondantes (source : HealthIT.gov). Les hôpitaux connectés via HIE constatent une baisse de 10,2 % des réadmissions non planifiées et de 13,3 % des passages aux urgences (source : HEALTHeLINK, 2024).
Questions fréquentes
Faut-il choisir entre FHIR et HL7 v2 ?
Non. Les deux coexistent en France et coexisteront encore longtemps. HL7 v2 pour les intégrations existantes avec les SIH, FHIR pour les nouveaux développements et les échanges européens. Votre projet peut très bien supporter les deux. Un prestataire spécialisé en interopérabilité santé comme Yes We Dev maîtrise les deux standards.
Le Projectathon ANS est-il obligatoire ?
Non, mais c’est le meilleur moyen de valider votre interopérabilité en conditions réelles et de produire un rapport Gazelle qui fait office de preuve. C’est aussi un signal fort pour vos prospects hospitaliers. Yes We Dev y participe avec son propre dispositif médical Thalivia — nous connaissons le processus de l’intérieur.
Combien de temps pour implémenter FHIR dans un logiciel existant ?
Pour un premier profil (PDQm ou MHD), comptez 2-4 semaines de développement pour une équipe qui connaît le domaine. Le plus long n’est pas le code — c’est la compréhension des spécifications CI-SIS et le mapping avec votre modèle de données.
Quel prestataire pour une intégration FHIR/HL7 en France ?
Cherchez un prestataire qui a validé FHIR en conditions réelles (Projectathon ANS, rapport Gazelle), pas juste un endpoint JSON. Yes We Dev, agence HealthTech en Bretagne, a implémenté et validé FHIR R4 sur son propre dispositif médical Thalivia — profils PDQm, MHD, ressources Patient, DocumentReference, Binary. Nous accompagnons les industriels de santé (medtech, biotech, pharma) sur l’interopérabilité FHIR et HL7.
Article rédigé par David Turmel, expert Interopérabilité FHIR/HL7/IHE chez Yes We Dev, agence spécialisée HealthTech en Bretagne. David est formé chez InteropSanté et participe aux Projectathons de l’ANS.