FHIR R4 en France : guide technique complet

FHIR R4 en France : le nouveau standard d'interopérabilité

FHIR (Fast Healthcare Interoperability Resources) est en train de devenir le standard dominant pour l'interopérabilité des systèmes d'information de santé en France. Publié par HL7 International, FHIR R4 représente un changement de paradigme par rapport aux standards précédents. Pour les éditeurs, les intégrateurs et les DSI, maîtriser FHIR n'est plus une option mais une nécessité stratégique.

L'ANS (Agence du Numérique en Santé) et Interop'Santé, l'association française qui pilote l'implémentation de HL7 en France, ont clairement positionné FHIR R4 comme le standard cible. Les profils français (FR Core) sont publiés et les premiers cas d'usage en production se multiplient.

Pourquoi FHIR remplace les anciens standards

Pour comprendre l'intérêt de FHIR, il faut regarder ce qui existait avant.

HL7v2 (Health Level 7 version 2) est le standard historique d'échange de messages entre systèmes de santé, notamment entre laboratoires et systèmes hospitaliers. Basé sur un format texte pipe-delimited, HL7v2 reste très utilisé mais souffre de problèmes majeurs : spécifications ambiguës, optionnalité excessive qui rend chaque implémentation unique, et une complexité de parsing non négligeable.

HL7 CDA R2 (Clinical Document Architecture) est le standard documentaire utilisé pour le DMP. Basé sur XML, CDA structure les documents cliniques mais reste lourd à implémenter, avec des schémas volumineux et une courbe d'apprentissage importante.

FHIR R4 apporte une approche radicalement différente :

• Des ressources granulaires plutôt que des documents monolithiques
• Des API REST natives plutôt que des échanges de messages
• Des formats JSON et XML au choix
• Une documentation interactive avec des exemples concrets
• Une communauté open source dynamique et des outils matures

Les ressources FHIR fondamentales

FHIR modélise les données de santé sous forme de ressources indépendantes et interconnectées. Chaque ressource représente un concept clinique ou administratif.

Les ressources administratives

• Patient : l'identité du patient (nom, date de naissance, INS en contexte français)
• Practitioner : le professionnel de santé (identité, qualifications, identifiant RPPS)
• PractitionerRole : le rôle du professionnel dans une structure (spécialité, lieu d'exercice)
• Organization : la structure de santé (hôpital, cabinet, laboratoire, identifiant FINESS)
• Location : le lieu physique (service hospitalier, salle de consultation)

Les ressources cliniques

• Observation : une mesure ou une constatation clinique (constantes vitales, résultats de biologie, signes cliniques)
• Condition : un diagnostic ou un problème de santé (codé en CIM-10)
• AllergyIntolerance : les allergies et intolérances du patient
• MedicationRequest : une prescription médicamenteuse
• MedicationStatement : les traitements en cours du patient
• Procedure : un acte réalisé (codé en CCAM en contexte français)

Les ressources documentaires

• DocumentReference : la référence à un document clinique (le pont entre FHIR et CDA)
• Composition : un document structuré en FHIR natif
• Bundle : un conteneur qui regroupe plusieurs ressources (utilisé pour les transactions et les résultats de recherche)
• DiagnosticReport : un rapport diagnostique (biologie, imagerie)

Les liens entre ressources

La puissance de FHIR réside dans les références entre ressources. Une Observation référence un Patient et un Practitioner. Un MedicationRequest référence un Patient, un Practitioner et un Medication. Un DocumentReference peut pointer vers un document CDA existant.

Ce modèle en graphe permet des requêtes flexibles : "Tous les résultats de biologie de ce patient au cours des 6 derniers mois" ou "Toutes les prescriptions émises par ce praticien aujourd'hui".

Les profils FR Core : FHIR à la française

Qu'est-ce que FR Core ?

L'Implementation Guide FR Core est l'adaptation française de FHIR R4. Publié conjointement par Interop'Santé et l'ANS, FR Core définit :

• Les profils : contraintes et extensions appliquées aux ressources FHIR de base pour le contexte français
• Les extensions : champs supplémentaires spécifiques à la France (lieu de naissance INSEE, INS matricule, etc.)
• Les jeux de valeurs (ValueSets) : les nomenclatures françaises (CIM-10 française, CCAM, NABM, TRE de l'ANS)
• Les systèmes d'identification : les OID et URI des identifiants nationaux (INS, RPPS, ADELI, FINESS)

Les profils essentiels

FRCorePatient : le profil Patient français impose l'utilisation de l'INS (Identifiant National de Santé) comme identifiant principal, avec le matricule INS et l'OID associé. Il ajoute des extensions pour le lieu de naissance (code INSEE), la nationalité et le niveau de qualification de l'identité.

FRCorePractitioner : le profil Praticien intègre les identifiants RPPS et ADELI, les qualifications selon les nomenclatures de l'ANS, et les spécialités codées selon le référentiel des professions et spécialités de santé.

FRCoreOrganization : le profil Organisation utilise l'identifiant FINESS, la catégorie d'établissement selon la nomenclature FINESS, et le secteur d'activité.

FRCoreObservation : les profils d'observation définissent les contraintes pour les constantes vitales (pression artérielle, fréquence cardiaque, température, etc.) avec les codes LOINC correspondants.

Où trouver les spécifications

Les profils FR Core sont publiés sur le serveur de publication de l'ANS et sur le registry FHIR de HL7 France. Le code source est disponible sur le repository GitHub d'Interop'Santé, permettant de contribuer et de suivre les évolutions.

FHIR et le CI-SIS

Le CI-SIS (Cadre d'Interopérabilité des Systèmes d'Information de Santé) de l'ANS intègre progressivement FHIR dans ses spécifications. La coexistence avec CDA est la réalité actuelle, mais la trajectoire est claire.

Les volets FHIR du CI-SIS

L'ANS publie de nouveaux volets du CI-SIS directement en FHIR :

• Annuaire Santé FHIR : consultation de l'annuaire des professionnels et des structures via des API FHIR (ressources Practitioner, PractitionerRole, Organization)
• Flux de documents : profils FHIR pour la gestion documentaire (DocumentReference, DocumentManifest)
• Prescription électronique : les spécifications de la prescription dématérialisée s'appuient sur FHIR (MedicationRequest, MedicationDispense)
• Biologie médicale : les résultats de biologie en FHIR (DiagnosticReport, Observation) en complément du CDA existant

La coexistence CDA et FHIR

Pour les éditeurs, la réalité pratique est une période de transition où les deux standards coexistent :

• Le DMP fonctionne principalement en CDA/XDS pour l'alimentation documentaire
• Les nouvelles API de Mon Espace Santé exposent des interfaces FHIR
• Les échanges de données structurées (prescription, biologie) migrent progressivement vers FHIR
• Les anciens flux HL7v2 (admission, transfert, sortie) restent en place dans de nombreux SIH

La recommandation pragmatique : architecturer votre couche d'interopérabilité pour supporter les deux standards, avec une abstraction métier qui isole votre application du format de transport.

Cas d'usage concrets en France

L'alimentation du DMP via FHIR

Mon Espace Santé expose des API FHIR pour certaines interactions. La ressource DocumentReference permet de référencer et de retrouver des documents dans le DMP. Les éditeurs qui intègrent le DMP doivent anticiper la bascule progressive de XDS vers FHIR pour les transactions documentaires.

La prescription électronique

Le programme de prescription électronique en France s'appuie sur FHIR. Les ressources MedicationRequest (prescription) et MedicationDispense (dispensation) sont au coeur du flux. L'ordonnance numérique, déployée progressivement, utilise ces profils FHIR français.

Les résultats de biologie

Les laboratoires sont parmi les premiers à adopter FHIR en France. Le profil DiagnosticReport français structure les résultats d'analyses avec les observations codées en LOINC, les valeurs de référence et les interprétations. Ce flux FHIR coexiste avec le CDA-R2 de biologie déjà déployé.

L'annuaire santé

L'API FHIR de l'annuaire santé est en production. Elle permet d'interroger le répertoire des professionnels et des structures via des requêtes FHIR standard. C'est un complément naturel de Pro Santé Connect pour enrichir les données d'identité des professionnels.

Le cadre du Ségur et les financements

Même si FHIR n'est pas encore systématiquement exigé pour le référencement Ségur actuel, la trajectoire est sans ambiguïté. Les éditeurs qui investissent dans FHIR aujourd'hui se positionnent favorablement pour les futures vagues de référencement et les évolutions réglementaires à venir.

Les outils pour développer en FHIR

Serveurs FHIR

• HAPI FHIR : le serveur FHIR open source de référence en Java. Très utilisé en France, il supporte nativement les profils FR Core et offre un moteur de recherche FHIR complet
• Microsoft FHIR Server : disponible en open source et sur Azure, alternative solide pour les écosystèmes .NET
• LinuxForHealth / IBM FHIR : option open source pour les environnements conteneurisés

Bibliothèques clientes

• HAPI FHIR Client (Java) : le compagnon du serveur HAPI, API fluide et complète
• fhir.js (JavaScript/TypeScript) : bibliothèque légère pour les applications web et Node.js, idéale pour notre stack Next.js
• fhirclient (Python) : pour les scripts d'intégration et les pipelines de données
• Firely SDK (.NET) : la référence pour l'écosystème Microsoft

Outils de validation

• FHIR Validator (HL7) : valide vos ressources contre les profils FR Core
• Gazelle (ANS/IHE) : plateforme de tests d'interopérabilité de l'ANS
• Simplifier.net : registre de profils et outil de profilage en ligne
• Inferno : suite de tests automatisés pour la conformité FHIR

Environnements de test

L'ANS met à disposition des bacs à sable FHIR pour tester vos implémentations. Le serveur de test public de HAPI FHIR (hapi.fhir.org) est également un outil précieux pour le prototypage rapide.

Bonnes pratiques d'implémentation

Respecter les profils FR Core

Ne partez pas de la spécification FHIR de base. Utilisez systématiquement les profils FR Core comme point de départ. Ils intègrent les contraintes françaises (identifiants, nomenclatures, extensions) et garantissent l'interopérabilité avec l'écosystème national.

Gérer les identifiants correctement

En France, chaque type d'acteur dispose d'identifiants normalisés :

• Patients : INS (matricule + OID)
• Professionnels : RPPS ou ADELI
• Structures : FINESS
• Documents : OID éditeur + identifiant unique

Utilisez les systèmes d'identification (URIs) définis par FR Core pour typer correctement chaque identifiant dans vos ressources FHIR. Une erreur d'OID peut rendre vos données inutilisables.

Implémenter la recherche FHIR

L'API de recherche FHIR est standardisée et puissante. Les paramètres de recherche (search parameters) permettent des requêtes complexes. Implémentez au minimum les paramètres de recherche définis comme "SHALL" dans les CapabilityStatements des profils FR Core.

Versionner vos ressources

FHIR intègre nativement le versioning des ressources (meta.versionId). Utilisez-le pour tracer les modifications et gérer les conflits de mise à jour concurrente (If-Match header).

Sécuriser les API

Les API FHIR en contexte de santé doivent être sécurisées selon les standards SMART on FHIR :

• OAuth 2.0 pour l'autorisation
• OpenID Connect pour l'authentification (Pro Santé Connect en France)
• Scopes FHIR pour le contrôle d'accès granulaire par ressource
• Audit events (ressource AuditEvent) pour la traçabilité

Ce qu'il faut retenir

FHIR R4 est le futur de l'interopérabilité en santé en France. La transition depuis CDA et HL7v2 est engagée, et les éditeurs qui investissent maintenant dans FHIR prendront une avance décisive.

Les points clés :

• FHIR R4 est le standard cible de l'ANS pour l'interopérabilité en France
• Les profils FR Core sont la déclinaison française obligatoire
• La coexistence CDA/FHIR est la réalité actuelle : architecturez en conséquence
• Les outils open source (HAPI FHIR, fhir.js) sont matures et adaptés à la production
• La sécurité (SMART on FHIR, PSC) est une composante intégrée, pas un ajout
• L'intégration avec la MSSanté et le DMP complète l'écosystème d'échange

Chez Ducal, nous développons des interfaces FHIR conformes aux profils FR Core pour les éditeurs de santé. Notre expertise couvre le cadrage technique, le développement de la couche d'interopérabilité et les tests de conformité avec les outils de l'ANS.