HL7 FHIR en France : guide pratique pour les développeurs

Q: Comment valider une ressource contre les profils français ?

Avec le validateur HL7, en lui indiquant le paquet hl7.fhir.fr.core et le profil visé, ou avec les services de validation de l'espace de tests de l'ANS. Le validateur applique aussi les profils internationaux obligatoires, comme celui des signes vitaux.

Si vous développez une application de santé en France et que vous devez échanger des données avec un système d'information hospitalier (SIH), vous allez tomber sur FHIR. C'est le standard que l'ANS (Agence du Numérique en Santé) retient pour les nouvelles API, et celui sur lequel se construit le format européen d'échange. Il ne remplace pas tout pour autant : les documents médicaux restent en CDA, et les flux internes de l'hôpital en HL7 v2.

Le problème : la documentation FHIR est massive, en anglais, et très abstraite. Les spécificités françaises sont dispersées entre le site de l'ANS, les guides d'implémentation du CI-SIS, ceux d'Interop'Santé et les retours d'expérience des éditeurs. Ce guide rassemble ce qu'un développeur a besoin de savoir pour implémenter FHIR dans un contexte français.

Qu'est-ce que FHIR ?

FHIR (Fast Healthcare Interoperability Resources, prononcé "fire") est un standard développé par HL7 International pour l'échange de données de santé entre systèmes informatiques. Il succède aux versions précédentes du standard HL7 (v2, v3, CDA) en adoptant une approche moderne : API REST, JSON/XML, et une granularité fine basée sur des "ressources".

HL7 v2, CDA, FHIR : les différences

Standard	Époque	Format	Transport	Usage en France
HL7 v2	Fin des années 1980	Segments délimités par `\|`	TCP/IP (MLLP)	Flux internes des SIH : identités, mouvements, résultats
CDA R2	2005	XML	Partage par le DMP, envoi par MSSanté	Format de tous les documents médicaux
FHIR R4	2019	JSON ou XML	API REST	Version retenue pour les nouveaux cas d'usage

En France, beaucoup de SIH utilisent encore HL7 v2 pour les flux internes (admissions, résultats de labo, mouvements patient). Les documents médicaux, eux, sont en CDA : c'est le format du DMP. FHIR sert aux nouveaux cas d'usage, mais vous devrez souvent gérer la coexistence des trois dans un même projet.

Quelle version de FHIR ?

FHIR R4, dans sa version 4.0.1. C'est un choix national, arrêté par un groupe de travail d'Interop'Santé et de l'ANS en 2023 et 2024 : R4 pour l'ensemble des projets, pas de guide d'implémentation en R5, et une transition à préparer vers R6, annoncée comme la version stable finale. Si un éditeur vous propose une API en R5, vérifiez qu'elle reste compatible avec les profils français, tous publiés en R4.

Pourquoi FHIR change la donne

Avant FHIR, intégrer deux systèmes de santé demandait des mois de travail sur des formats propriétaires ou des messages HL7 v2 dont la structure variait d'un éditeur à l'autre. FHIR standardise les échanges autour de ressources bien définies, accessibles via des API REST classiques. Un développeur web habitué à consommer des API JSON peut commencer à travailler avec FHIR sans formation lourde.

Le standard est aussi extensible : chaque pays peut définir des profils qui adaptent les ressources de base à son contexte réglementaire. En France, ce travail est porté par Interop'Santé et l'ANS.

Les ressources FHIR essentielles

FHIR est organisé autour de "ressources" : des objets JSON/XML qui représentent chacun un concept médical ou administratif. La version R4 en définit 146, mais en pratique, une poignée couvre 80% des cas d'usage.

Les trois exemples qui suivent sont conformes aux profils français FR Core 2.2.0 : ils passent le validateur officiel HL7 sans erreur.

Patient

La ressource la plus fondamentale. Représente une personne qui reçoit des soins.

{
  "resourceType": "Patient",
  "id": "exemple-patient",
  "meta": {
    "profile": [
      "https://hl7.fr/ig/fhir/core/StructureDefinition/fr-core-patient-ins"
    ]
  },
  "extension": [
    {
      "url": "http://hl7.org/fhir/StructureDefinition/patient-birthPlace",
      "valueAddress": {
        "extension": [
          {
            "url": "https://hl7.fr/ig/fhir/core/StructureDefinition/fr-core-address-insee-code",
            "valueCoding": {
              "system": "https://mos.esante.gouv.fr/NOS/TRE_R13-CommuneOM/FHIR/TRE-R13-CommuneOM",
              "code": "63113"
            }
          }
        ]
      }
    }
  ],
  "identifier": [
    {
      "use": "official",
      "type": {
        "coding": [
          {
            "system": "https://hl7.fr/ig/fhir/core/CodeSystem/fr-core-cs-v2-0203",
            "code": "INS-NIR"
          }
        ]
      },
      "system": "urn:oid:1.2.250.1.213.1.4.8",
      "value": "285076311304523"
    }
  ],
  "name": [
    {
      "extension": [
        {
          "url": "https://hl7.fr/ig/fhir/core/StructureDefinition/fr-core-patient-birth-list-given-name",
          "valueString": "Marie Claire"
        }
      ],
      "use": "official",
      "family": "Dupont",
      "given": [
        "Marie"
      ]
    }
  ],
  "gender": "female",
  "birthDate": "1985-07-15"
}

Spécificité française : le matricule INS (Identité Nationale de Santé) identifie le patient dans les échanges, et il ne se transmet que pour une identité qualifiée. FR Core distingue donc deux profils. FRCorePatientProfile décrit un patient sans INS, avec ses identifiants locaux comme l'IPP. FRCorePatientINSProfile porte le matricule, sous l'OID 1.2.250.1.213.1.4.8 pour l'INS-NIR, et rend obligatoires le nom de naissance, la liste des prénoms de naissance, le sexe, la date et le lieu de naissance.

Le matricule compte 15 caractères, clé comprise. Pour vos tests, des OID distincts existent : 1.2.250.1.213.1.4.10 pour les INS de test et 1.2.250.1.213.1.4.11 pour les INS de démonstration.

Encounter

Représente une interaction entre un patient et un établissement de santé : consultation, hospitalisation, passage aux urgences.

{
  "resourceType": "Encounter",
  "id": "exemple-sejour",
  "meta": {
    "profile": [
      "https://hl7.fr/ig/fhir/core/StructureDefinition/fr-core-encounter"
    ]
  },
  "identifier": [
    {
      "type": {
        "coding": [
          {
            "system": "https://hl7.fr/ig/fhir/core/CodeSystem/fr-core-cs-identifier-type",
            "code": "VN"
          }
        ]
      },
      "system": "https://hopital-exemple.fr/venues",
      "value": "2026-0031547"
    }
  ],
  "status": "in-progress",
  "class": {
    "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
    "code": "IMP",
    "display": "inpatient encounter"
  },
  "subject": {
    "reference": "Patient/exemple-patient"
  },
  "period": {
    "start": "2026-03-10T08:00:00+01:00"
  },
  "serviceProvider": {
    "reference": "Organization/hopital-exemple"
  }
}

Les classes principales : AMB (ambulatoire), IMP (hospitalisation), EMER (urgences). Le profil FR Core exige un identifiant de venue, la classe et la période. En France, le mouvement patient (entrée, transfert, sortie) est historiquement géré en HL7 v2 via les messages ADT. FHIR reprend ces concepts dans Encounter avec un modèle plus riche.

Observation

Ressource générique pour tout résultat de mesure ou d'observation clinique : constantes vitales, résultats de laboratoire, scores cliniques.

{
  "resourceType": "Observation",
  "id": "exemple-frequence-cardiaque",
  "meta": {
    "profile": [
      "https://hl7.fr/ig/fhir/core/StructureDefinition/fr-core-observation-heartrate"
    ]
  },
  "status": "final",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/observation-category",
          "code": "vital-signs"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "8867-4",
        "display": "Heart rate"
      }
    ]
  },
  "subject": {
    "reference": "Patient/exemple-patient"
  },
  "effectiveDateTime": "2026-03-10T08:30:00+01:00",
  "valueQuantity": {
    "value": 72,
    "unit": "battements/minute",
    "system": "http://unitsofmeasure.org",
    "code": "/min"
  }
}

Point important : pour les signes vitaux, FHIR impose un profil. La catégorie vital-signs et la date de la mesure sont obligatoires, et le validateur rejette une fréquence cardiaque qui n'a ni l'une ni l'autre.

Les codes de Observation.code suivent des nomenclatures standardisées : LOINC pour les signes vitaux et les examens de biologie, SNOMED CT pour d'autres observations cliniques. La France a adopté SNOMED CT en 2023 et l'ANS la diffuse depuis. La NABM (Nomenclature des Actes de Biologie Médicale) reste utilisée en parallèle de LOINC, pour la facturation.

Autres ressources courantes

Ressource	Usage	Exemple concret
Practitioner	Professionnel de santé	Médecin, infirmier, sage-femme
Organization	Établissement	Hôpital, clinique, cabinet
Condition	Diagnostic / pathologie	Diabète type 2, fracture du col
MedicationRequest	Prescription	Ordonnance de médicament
DocumentReference	Document médical	Compte rendu opératoire, lettre de sortie
Bundle	Conteneur de ressources	Transaction groupée, résultat de recherche
Appointment	Rendez-vous	Consultation programmée

Les profils français : FR Core et les guides de l'ANS

Deux acteurs publient les spécifications françaises. Interop'Santé, l'affilié français de HL7 et d'IHE, maintient le socle commun. L'ANS publie les guides d'implémentation par cas d'usage, dans le cadre du CI-SIS (Cadre d'Interopérabilité des Systèmes d'Information de Santé).

FR Core, le socle

FR Core est le guide d'implémentation qui sert de fondation à FHIR en France. Sa version courante est la 2.2.0, publiée le 25 mars 2026 et basée sur FHIR R4. La règle est simple : toute implémentation FHIR française doit s'appuyer sur FR Core, et les guides de l'ANS héritent de ses profils.

Profil FR Core	Ce qu'il apporte
`FRCorePatientProfile`	Identifiants français du patient : IPP, numéro de sécurité sociale, identifiant régional
`FRCorePatientINSProfile`	Patient à l'identité qualifiée, avec le matricule INS
`FRCorePractitionerProfile`	Professionnel identifié par son identifiant national (OID `1.2.250.1.71.4.2.1`) et son numéro RPPS
`FRCorePractitionerRoleProfile`	Situation d'exercice du professionnel dans une structure
`FRCoreOrganizationProfile`	Structure, avec des variantes pour l'établissement, l'unité fonctionnelle (UF) et l'unité d'activité (UAC)
`FRCoreEncounterProfile`	Venue dans l'établissement et mouvements du séjour
Profils de signes vitaux	Fréquence cardiaque, pression artérielle, poids, taille, température, saturation

S'y ajoutent des profils pour les lieux, les services, les agendas et les rendez-vous.

Si vous lisez une documentation qui parle de FrPatient, FrPractitioner ou FrOrganization, elle date. Ce sont les noms des profils de FR Core 1, remplacés depuis la version 2.0.0 de mars 2024.

Les guides de l'ANS

L'ANS tient un catalogue de ses guides d'implémentation FHIR. On y trouve notamment :

Annuaire Santé : l'API ouverte des professionnels et des structures (notre tutoriel)
Partage de documents de santé en mobilité (PDSm), Mesures de santé, Gestion d'agendas partagés
Cercle de soins, Cahier de liaison, Notifications d'événements, Traçabilité des événements
ePrescription, Répertoire de l'offre et des ressources (ROR), Service d'accès aux soins (SAS), API MSSanté
deux volets médico-sociaux, dont le transfert de données entre logiciels de dossier usager

FR Core ne traite volontairement aucun cas d'usage. Avant de concevoir vos propres profils, cherchez dans ce catalogue le guide qui couvre le vôtre.

Où trouver les spécifications

hl7.fr/ig/fhir/core : le guide FR Core
interop.esante.gouv.fr/ig : les catalogues de guides FHIR, CDA et HL7 v2 de l'ANS, et la doctrine du CI-SIS
smt.esante.gouv.fr : le Serveur Multi-Terminologies, pour les terminologies et jeux de valeurs, avec une API FHIR
GitHub : les sources des guides sont ouvertes, chez ansforge pour l'ANS et Interop-Sante pour FR Core

Le Ségur du Numérique et FHIR

Contrairement à une idée répandue, le Ségur n'impose pas FHIR aux éditeurs de dossiers patients. Les référentiels DPI et PFI de la Vague 2 ne mentionnent pas le standard : ils reposent sur des documents CDA, déposés au DMP et envoyés par MSSanté. FHIR n'y apparaît que parmi les formats possibles pour l'export des données. Le détail est dans notre guide Ségur Vague 2.

FHIR entre dans les projets par d'autres portes :

Les API nationales. L'Annuaire Santé est une API FHIR, et Mon espace santé en expose trois : mesures de santé, agenda et documents.
L'Europe. Le règlement sur l'Espace européen des données de santé impose un format européen d'échange, que les travaux en cours fondent sur FHIR. Il s'applique à partir du 26 mars 2029 aux résumés patients et aux prescriptions, puis du 26 mars 2031 à l'imagerie, aux résultats d'examens et aux comptes rendus de sortie.
La trajectoire du CI-SIS. L'ANS prévoit qu'à terme tous les volets du cadre d'interopérabilité soient fondés sur FHIR. Pour les documents, elle retient un usage concomitant de CDA et de FHIR pendant la transition, pas une bascule.

Intégration avec les SIH français

C'est là que la théorie rencontre le terrain. Les SIH français (DxCare, Hopital Manager, Orbis, Mediboard, Easily, etc.) ont des niveaux de maturité FHIR très variables.

Ce que vous allez rencontrer en pratique

Scénario 1 : le SIH expose une API FHIR. C'est le cas idéal. Certains SIH récents exposent des endpoints FHIR R4. Vous consommez l'API comme n'importe quelle API REST. Attention : les endpoints sont souvent limités à certaines ressources et certaines opérations (lecture seule dans beaucoup de cas).

Scénario 2 : le SIH parle HL7 v2. Encore très fréquent. Vous devez mettre en place un moteur d'intégration (Mirth Connect ou son dérivé ouvert Open Integration Engine, Rhapsody, ou un développement sur mesure) qui traduit les messages HL7 v2 en ressources FHIR. C'est un travail de mapping qui prend du temps, parce que chaque établissement a ses propres variantes de HL7 v2.

Scénario 3 : le SIH utilise des web services propriétaires. Certains éditeurs exposent leurs propres API. Pas de standard, pas de documentation publique. Il faut négocier l'accès avec l'éditeur et développer un connecteur sur mesure.

Les pièges courants

Le calendrier DSI. Les DSI hospitalières ont leurs propres contraintes de validation, de sécurité et de planning. Une intégration qui devrait prendre 3 semaines peut en prendre 12 si la DSI impose ses propres phases de test et de recette. Intégrez ce risque dans vos plannings dès le départ.

Les variantes HL7 v2. Le standard HL7 v2 est tellement flexible que chaque établissement l'implémente différemment. Le champ PID-3 (identifiant patient) peut contenir l'IPP, le NIR, l'INS ou un identifiant interne selon l'établissement. Ne partez jamais du principe qu'un message HL7 v2 d'un hôpital A sera identique à celui d'un hôpital B. La référence pour ces flux est le guide d'interopérabilité hospitalier d'Interop'Santé.

L'authentification. Les API FHIR des SIH utilisent souvent des mécanismes d'authentification spécifiques : certificats clients, Pro Santé Connect (le fournisseur d'identité de l'ANS), ou des systèmes propriétaires. Renseignez-vous tôt sur les modalités d'accès.

Les environnements de test. Obtenir un accès à l'environnement de test d'un SIH hospitalier peut prendre des semaines. Les données de test sont souvent incomplètes ou non représentatives. Prévoyez un serveur FHIR local (HAPI FHIR est le plus utilisé en open source) pour développer et tester avant d'accéder à l'environnement réel.

Stack technique recommandée

Serveur FHIR

HAPI FHIR (Java) est le serveur de référence open source. Il implémente la spécification FHIR R4 de manière complète et est utilisé par de nombreux éditeurs et établissements en France. Si votre stack est en Java ou si vous avez besoin d'un serveur FHIR complet, c'est le choix par défaut.

Pour les stacks Node.js/TypeScript (ce que nous utilisons chez Bob le développeur), plusieurs options :

Outil	Usage	Remarque
Medplum	Serveur et SDK FHIR en TypeScript	Open source, développement très actif
fhirclient	Client FHIR JavaScript	Le client SMART on FHIR, pour consommer des API existantes
fhir-kit-client	Client FHIR JavaScript	Alternative légère, maintenue
fhirpath	Évaluation de FHIRPath	La librairie de HL7, pour naviguer dans les ressources
@types/fhir	Types TypeScript	Les types des ressources R4
HAPI FHIR (via Docker)	Serveur de test local	Utilisable quelle que soit votre stack applicative

Deux librairies souvent citées sont à écarter pour un nouveau projet : fhir.js, dont le dépôt est archivé et la dernière version date de 2019, et node-fhir-server-core, sans nouvelle version depuis février 2023.

Validation

Validez systématiquement vos ressources FHIR avant de les envoyer à un SIH. Les outils :

Le validateur HL7 (validator_cli.jar) : validation locale, qui charge les profils français à la demande
L'espace de tests de l'ANS (interop.esante.gouv.fr) : services de validation en ligne pour FHIR, CDA et HL7 v2
IG Publisher (HL7) : pour publier vos propres guides d'implémentation si nécessaire

La commande pour valider un patient contre le profil INS de FR Core :

java -jar validator_cli.jar Patient.json \
  -version 4.0.1 \
  -ig hl7.fhir.fr.core#2.2.0 \
  -profile https://hl7.fr/ig/fhir/core/StructureDefinition/fr-core-patient-ins

Le premier lancement télécharge les paquets et prend une bonne minute. Attendez-vous à quelques avertissements même sur une ressource correcte, par exemple sur les codes des nomenclatures françaises que le serveur de terminologie international ne connaît pas. Ce sont les erreurs qui comptent.

Terminologies

Les terminologies médicales françaises sont accessibles via le SMT (Serveur Multi-Terminologies) de l'ANS. Il centralise les terminologies gérées par l'agence et les jeux de valeurs (ValueSets) utilisés par les profils français, dont SNOMED CT depuis novembre 2023. En pratique, vous croiserez surtout CIM-10 pour les diagnostics, CCAM pour les actes, LOINC et NABM pour la biologie.

Checklist d'implémentation FHIR en France

FHIR et les obligations réglementaires

L'implémentation de FHIR ne vous dispense pas des autres obligations réglementaires. Les données qui transitent via FHIR sont des données de santé à caractère personnel, soumises à :

L'hébergement HDS : votre serveur FHIR et votre base de données doivent être hébergés chez un prestataire certifié. Consultez notre guide HDS pour startups pour les détails.
Le RGPD renforcé santé : consentement, traçabilité des accès, AIPD. Les logs d'accès aux API FHIR doivent être conservés et auditables.
La certification MDR si votre application est qualifiée de dispositif médical logiciel.

Le parcours patient digital que vous construisez avec FHIR doit intégrer ces contraintes dès la conception.

Questions fréquentes sur FHIR en France

Quelle version de FHIR utiliser en France ?

FHIR R4 (4.0.1). C'est la version retenue au niveau national par Interop'Santé et l'ANS pour tous les projets, et celle de tous les profils français. La consigne est de ne pas créer de guide en R5 et de préparer la transition vers R6.

FHIR est-il obligatoire pour être référencé Ségur ?

Non pour un dossier patient hospitalier. Les référentiels DPI et PFI de la Vague 2 ne mentionnent pas FHIR : ils reposent sur des documents CDA, le DMP et MSSanté. FHIR n'y figure que comme format possible pour l'export des données.

FHIR va-t-il remplacer CDA ?

À terme, pour les documents. Aujourd'hui, tous les documents médicaux sont stockés en CDA, à commencer par ceux du DMP. Le format européen d'échange repose sur des documents FHIR, et l'ANS prévoit que les futurs volets de contenu du CI-SIS soient conçus dans ce format. La transition retenue fait coexister CDA et FHIR, les documents historiques restant en CDA.

Qu'est-ce que FR Core ?

Le guide d'implémentation qui sert de socle à FHIR en France, publié par Interop'Santé. Il définit les profils, extensions et jeux de valeurs communs : patient, professionnel, structure, venue, signes vitaux. Sa version courante est la 2.2.0, de mars 2026. Les guides de l'ANS s'appuient dessus.

Peut-on mettre le matricule INS dans une ressource Patient ?

Oui, à condition que l'identité soit qualifiée, et en utilisant le profil FRCorePatientINSProfile. Le matricule se place dans un identifiant dont le système est l'OID 1.2.250.1.213.1.4.8. Pour un patient dont l'identité n'est pas qualifiée, on utilise le profil patient de base, sans INS.

Comment valider une ressource contre les profils français ?

Avec le validateur HL7, en lui indiquant le paquet hl7.fhir.fr.core et le profil visé, ou avec les services de validation de l'espace de tests de l'ANS. Le validateur applique aussi les profils internationaux obligatoires, comme celui des signes vitaux.

Ce que nous faisons chez Bob le développeur

Chez Bob le développeur, nous avons intégré des systèmes d'information hospitaliers dans le cadre de notre collaboration avec l'AP-HP. On sait ce que ça implique en pratique : les délais DSI, les variantes de messages, les contraintes de sécurité, les environnements de test incomplets.

Si vous développez une application qui doit communiquer avec un SIH français, ou si vous devez implémenter FHIR pour un projet de santé, on peut vous accompagner sur la partie technique : architecture, choix de stack, mapping des ressources, et intégration terrain.

Sources

Faits relevés le 13 octobre 2026.

Guide d'implémentation FR Core 2.2.0, Interop'Santé : profils, stratégie de version, exemples
Catalogue des guides d'implémentation FHIR de l'ANS et doctrine du CI-SIS, ANS
Trajectoire d'interopérabilité du CI-SIS, ANS : FHIR R4, documents CDA et FHIR, terminologies
Spécification FHIR R4 et historique des versions, HL7 International
Validateur FHIR, HL7
Référentiels DPI et PFI du Ségur Vague 2, ANS, et règlement (UE) 2025/327 sur l'Espace européen des données de santé