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

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 d'interopérabilité qui est en train de remplacer tous les autres dans le secteur santé, et l'ANS (Agence du Numérique en Santé) en a fait la pierre angulaire de sa stratégie d'interopérabilité nationale.

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, 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, v3, CDA, FHIR : les différences

Standard	Époque	Format	Transport	Adoption en France
HL7 v2	1987	Pipe-delimited (`\|`)	TCP/IP (MLLP)	Très répandu dans les SIH anciens
HL7 v3 / CDA	2005	XML complexe	SOAP/HTTP	Utilisé pour les documents (CR, ordonnances)
FHIR R4	2019	JSON ou XML	REST API	Standard cible ANS, adoption croissante

En France, beaucoup de SIH utilisent encore HL7 v2 pour les flux internes (admissions, résultats de labo, mouvements patient). FHIR est le standard cible pour tous les nouveaux développements, mais vous devrez souvent gérer la coexistence des deux dans un même projet.

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. C'est ce que fait la France via 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. Il en existe plus de 150, mais en pratique, une poignée couvre 80% des cas d'usage.

Patient

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

{
  "resourceType": "Patient",
  "id": "exemple-patient",
  "identifier": [{
    "system": "urn:oid:1.2.250.1.213.1.4.8",
    "value": "1850575012345"
  }],
  "name": [{
    "family": "Dupont",
    "given": ["Marie"]
  }],
  "gender": "female",
  "birthDate": "1985-07-15"
}

Spécificité française : l'identifiant national de santé (INS) est obligatoire pour identifier un patient dans les échanges inter-établissements. Le système d'identification utilise l'OID 1.2.250.1.213.1.4.8 pour le matricule INS. L'ANS publie un profil français FrPatient qui rend ce champ obligatoire.

Encounter

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

{
  "resourceType": "Encounter",
  "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). 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",
  "status": "final",
  "code": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "8867-4",
      "display": "Heart rate"
    }]
  },
  "subject": {
    "reference": "Patient/exemple-patient"
  },
  "valueQuantity": {
    "value": 72,
    "unit": "beats/minute",
    "system": "http://unitsofmeasure.org",
    "code": "/min"
  }
}

Point important : les codes utilisés dans Observation.code doivent suivre des nomenclatures standardisées. LOINC pour les examens de laboratoire, SNOMED CT pour les observations cliniques. En France, la NABM (Nomenclature des Actes de Biologie Médicale) est encore très utilisée en parallèle de LOINC.

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 de l'ANS

L'ANS publie des profils FHIR français dans le cadre du CI-SIS (Cadre d'Interopérabilité des Systèmes d'Information de Santé). Ces profils adaptent les ressources FHIR de base au contexte réglementaire et technique français.

Où trouver les profils

Site principal : interop.esante.gouv.fr — le portail d'interopérabilité de l'ANS
Serveur de terminologie : SMT (Serveur Multi-Terminologies) pour les jeux de valeurs français
GitHub ANS : les guides d'implémentation sont publiés en open source

Profils à connaître

FrPatient : profil Patient français. Rend obligatoire l'INS (Identité Nationale de Santé), ajoute le lieu de naissance, le matricule INSEE.

FrPractitioner / FrPractitionerRoleExercice : profil praticien français. Intègre le numéro RPPS (Répertoire Partagé des Professionnels de Santé) comme identifiant principal.

FrOrganization : profil organisation. Utilise le FINESS (Fichier National des Établissements Sanitaires et Sociaux) comme identifiant.

FrEncounter : profil de séjour/venue. Adapté au modèle français de gestion des mouvements patients.

Le Ségur du Numérique et FHIR

Le programme Ségur du Numérique en Santé a accéléré l'adoption de FHIR en France. Les éditeurs de logiciels qui veulent être référencés Ségur doivent implémenter des interfaces FHIR conformes aux spécifications de l'ANS. Les deux couloirs principaux :

Couloir DPI : échange de documents médicaux (compte rendu, lettre de sortie) via DocumentReference
Couloir LGC (Logiciels de Gestion de Cabinet) : partage du volet de synthèse médicale

Si vous développez un logiciel qui doit s'interfacer avec des établissements participant au Ségur, l'implémentation FHIR n'est pas optionnelle.

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. Les SIH récents ou mis à jour dans le cadre du Ségur 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, 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.

L'authentification. Les API FHIR des SIH utilisent souvent des mécanismes d'authentification spécifiques : certificats clients, ProSanté 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
node-fhir-server-core	Serveur FHIR Node.js	Moins complet que HAPI mais suffisant pour beaucoup de cas
fhir.js	Client FHIR JavaScript	Pour consommer des API FHIR existantes
fhirpath.js	Évaluation de FHIRPath	Pour naviguer dans les ressources FHIR
HAPI FHIR (via Docker)	Serveur de test local	Utilisable quelle que soit votre stack applicative

Validation

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

HAPI FHIR Validator : validation locale, supporte les profils français
Simplifier.net : validation en ligne avec support des profils ANS
IG Publisher (HL7) : pour publier vos propres guides d'implémentation si nécessaire

Terminologies

Les terminologies médicales françaises sont accessibles via le SMT (Serveur Multi-Terminologies) de l'ANS. Vous y trouverez les jeux de valeurs (ValueSets) référencés dans les profils français : LOINC, SNOMED CT, CIM-10 (pour les diagnostics), CCAM (pour les actes), 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.

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 être référencé Ségur, on peut vous accompagner sur la partie technique : architecture, choix de stack, mapping des ressources, et intégration terrain.

L'agence d'experts pour votre tech

Accélérez dès maintenant votre innovation grâce à votre équipe de développeurs dédiée !