Introduction à FHIR pour les développeurs non-santé

FHIR — Fast Healthcare Interoperability Resources — est l'API REST de la santé. Si vous avez déjà écrit un GET/POST/PUT sur un endpoint et lu un JSON, vous savez déjà 80 % de FHIR. Cette page couvre les 20 % restants.

Pourquoi FHIR existe

Avant FHIR, l'interopérabilité santé reposait sur deux standards principaux, incompatibles entre eux. HL7 v2.5.1 (1989, 2007 pour la mineure) est un protocole pipe-delimited extrêmement déployé dans les hôpitaux, mais peu adapté aux API modernes. HL7 v3 (2005) est un standard XML rigoureux mais lourd, qui n'a jamais convaincu cliniquement : trop verbeux, trop académique, courbe d'apprentissage trop pentue.

En 2011, Grahame Grieve démarre FHIR comme un projet expérimental à HL7 : prendre le meilleur de v2 (pragmatique, modulaire) et de v3 (modèle structuré, terminologies), et l'exposer en API REST avec JSON ou XML comme représentation. La version DSTU sort en 2014, STU3 en 2017, R4 en 2019, R4B en 2022, et la version R5 est devenue normative en mars 2023. FHIR est aujourd'hui le standard de fait pour toute nouvelle interface santé externe.

La Resource, bloc de base

Dans FHIR, tout est Resource. Une Resource est une unité métier autonome — un patient, une observation, une prescription, un rendez-vous, un diagnostic — avec son propre identifiant et son propre URL. FHIR R5 définit environ 160 types de Resources, organisés en familles. Quelques exemples incontournables :

• Patient — démographie d'un patient ;
• Practitioner — un professionnel de santé ;
• Encounter — un séjour ou une consultation ;
• Observation — une mesure clinique (tension, glycémie, etc.) ;
• Condition — un diagnostic ;
• MedicationRequest — une prescription ;
• DiagnosticReport — un rapport d'examen (biologie, imagerie) ;
• Appointment — un rendez-vous.

Chaque Resource a un schéma JSON et XML défini par HL7. Une Patient minimale en JSON :

{ "resourceType":"Patient", "id":"example", "name":[{"family":"Dupont","given":["Marie"]}], "gender":"female", "birthDate":"1985-12-10" }

Le champ resourceType est obligatoire au sommet : il dit au parseur de quelle Resource il s'agit. Le champ id est le permalink local (sur le serveur FHIR donné), distinct des identifiants métier qui se trouvent dans identifier.

Le Bundle, conteneur de Resources

Un Bundle est une Resource d'un genre particulier : elle contient d'autres Resources. C'est l'équivalent FHIR de l'enveloppe SBDH côté PEPPOL ou du segment UNG en EDIFACT : un conteneur pour transmettre plusieurs documents en une fois. Les Bundles servent à plusieurs usages : résultat de recherche (type: searchset), transaction atomique (type: transaction), document clinique complet (type: document), ou message FHIR (type: message).

Un Bundle transaction permet de créer plusieurs Resources liées en une seule requête HTTP : par exemple, un Patient + un Encounter + une Observation, avec garantie atomique sur l'ensemble. Si l'une échoue, aucune n'est créée. C'est l'équivalent santé de la saga PO/ASN/INVOIC côté commerce.

L'API REST FHIR en pratique

L'interaction standard FHIR est l'API REST. Quelques verbes typiques :

• GET /Patient/example — récupérer une Resource par id ;
• POST /Patient avec body Patient JSON — créer une nouvelle Resource ;
• PUT /Patient/example avec body Patient JSON — remplacer (idempotent) ;
• DELETE /Patient/example — supprimer (souvent logique, soft delete) ;
• GET /Patient?name=Dupont&birthdate=1985-12-10 — recherche avec paramètres standardisés.

Au-delà des verbes REST classiques, FHIR ajoute des opérations spéciales préfixées par $ : $everything renvoie toutes les Resources liées à un Patient (résumé complet) ; $expand sur un ValueSet déplie une liste de codes ; $validate vérifie qu'une Resource respecte un profil donné.

Le serveur FHIR expose aussi un CapabilityStatement à la racine (GET /metadata) qui décrit toutes les Resources supportées, les opérations disponibles, et les paramètres de recherche acceptés. C'est l'équivalent FHIR d'un OpenAPI : introspection automatique des capacités.

Les Implementation Guides (IG)

FHIR R5 publie des Resources génériques qui ne peuvent pas couvrir, en l'état, les besoins de chaque pays, secteur ou cas d'usage. Pour combler cet écart, HL7 et les communautés nationales publient des Implementation Guides (IG) : des packages qui contraignent les Resources, fixent des valeurs obligatoires, ajoutent des contraintes spécifiques.

Quelques IG centraux en 2026 :

• US Core — IG américain qui sert de base à tous les EHR US ;
• IPS (International Patient Summary) — IG international pour les résumés patient transfrontaliers (utilisé par EHDS) ;
• Interopérabilité Santé France — IG publié par l'Agence du Numérique en Santé (ANS) pour l'écosystème français (DMP, Mon Espace Santé) ;
• CARIN BB — IG américain pour le partage de données d'assurance santé entre payeurs et patients ;
• SMART on FHIR App Launch — IG technique pour le lancement d'applications tierces.

Un IG est techniquement un ensemble de profiles (StructureDefinition), de ValueSets (listes de codes autorisés), de CapabilityStatements et de pages de documentation. Le tout est packagé en format NPM-like et téléchargeable depuis HL7.org. Les serveurs FHIR savent valider une Resource contre un IG en utilisant l'opération $validate.

SMART on FHIR — authentification standardisée

Une question fondamentale : comment une application tierce s'authentifie-t-elle auprès d'un serveur FHIR ? SMART on FHIR répond. C'est un standard publié en 2014 qui utilise OAuth 2.0 + OpenID Connect pour l'authentification, avec des scopes spécifiques santé : patient/*.read autorise la lecture de toutes les Resources liées à un patient, user/Patient.read autorise la lecture de tous les patients, etc.

Le flux SMART « App Launch » permet à un EHR (Electronic Health Record) de lancer une application tierce — par exemple un outil de gestion du diabète — dans le contexte d'un patient donné, avec un token d'accès limité dans le temps et en portée. Plus de 700 applications certifiées SMART existent en 2026, et tous les grands EHR américains (Epic, Cerner, Allscripts) supportent le flux.

Pièges fréquents d'un premier contact

Quelques erreurs typiques quand on découvre FHIR en venant d'autres horizons :

• Confondre id et identifier. id est le permalink local sur le serveur FHIR (souvent un UUID) ; identifier est l'identifiant métier (numéro de sécurité sociale, GLN, RPPS, etc.). Confondre les deux dans un mapping est l'erreur n°1 des nouveaux venus.
• Oublier le champ system. Tout identifiant et tout code FHIR sont qualifiés par un system URI : urn:oid:1.2.250.1.213.1.4.8 pour le RPPS français, http://loinc.org pour LOINC, etc. Sans system, le code est ambigu et invalide.
• Ignorer les versions. Beaucoup d'EHR américains exposent encore du R4, pas du R5. La rétrocompatibilité entre R4 et R5 est partielle (R4B est un palier de stabilisation des Resources cliniques). Toujours vérifier la version FHIR du serveur via CapabilityStatement avant de coder.
• Sous-estimer les terminologies. FHIR pointe vers des terminologies externes — LOINC, SNOMED CT, ICD-10, RxNorm — qui ont leurs propres règles d'usage, leurs propres licences (SNOMED CT est payant dans certains pays), et leurs propres mises à jour annuelles. Un projet FHIR sérieux a toujours un volet terminologies.

Pour aller plus loin

• FHIR R5 chez ediverse — la page de référence sur les Resources, opérations et IGs.
• HL7 v2.x — pour le contraste avec le standard legacy encore très déployé.
• FHIR R5 vs HL7 v2.5.1 en 2026 — l'analyse comparée des cas d'usage.
• Tester ses pipelines — patterns de test transférables vers les API FHIR.