FHIR R5 — Fast Healthcare Interoperability Resources

La couche REST/JSON moderne de HL7. Conçue en 2012 pour rendre la santé aussi accessible que les API web : ressources atomiques, schémas ouverts, profils nationaux.

Qu'est-ce que FHIR ?

FHIR — prononcé « fire » — est un standard d'interopérabilité publié par HL7 International qui remplace la philosophie messagerie de HL7 v2 et l'approche document de HL7 CDA par une philosophie ressources : chaque concept du domaine santé (Patient, Observation, Encounter, MedicationRequest…) est représenté par une structure typée, sérialisable en JSON ou XML, et exposée via une API REST standardisée.

L'objectif : rendre l'écriture d'un client santé aussi simple que celle d'un client GitHub ou Stripe. Un développeur qui connaît HTTP, JSON et OAuth 2 peut consommer un serveur FHIR sans formation HL7. Cette accessibilité explique l'adoption rapide : en 2026, Epic, Cerner / Oracle Health, Athenahealth, Allscripts, Apple Health, Google Cloud Healthcare API, AWS HealthLake et la quasi-totalité des EHR américains exposent une couche FHIR R4 ou R5.

FHIR cohabite avec HL7 v2 plutôt qu'il ne le remplace : les flux temps réel (ADT, ORU) continuent souvent en v2, tandis que les API patient, les portails interopérables et les apps mobiles consomment du FHIR.

Anatomie d'une ressource FHIR

Une ressource FHIR est un objet JSON (ou XML) avec un type explicite, un identifiant technique id, des champs typés selon la StructureDefinition publiée par HL7, et — optionnellement — des extensions. Voici l'exemple canonique Patient publié par HL7 sur la page de référence :

{
  "resourceType": "Patient",
  "id": "example",
  "identifier": [{
    "system": "urn:oid:1.2.36.146.595.217.0.1",
    "value": "12345"
  }],
  "active": true,
  "name": [{
    "use": "official",
    "family": "Chalmers",
    "given": ["Peter", "James"]
  }],
  "telecom": [{
    "system": "phone",
    "value": "(03) 5555 6473",
    "use": "work"
  }],
  "gender": "male",
  "birthDate": "1974-12-25",
  "address": [{
    "use": "home",
    "line": ["534 Erewhon St"],
    "city": "PleasantVille",
    "state": "Vic",
    "postalCode": "3999"
  }]
}

Trois principes structurants :

• resourceType en première position — c'est le discriminateur qui permet à un client générique de dispatcher correctement.
• Types de données — chaque champ obéit à un type FHIR (string, boolean, code, HumanName, Address, Identifier, Reference, Coding, CodeableConcept, Period…). Les codages sémantiques (LOINC, SNOMED CT, ICD-10, RxNorm) sont portés via Coding / CodeableConcept.
• Extensions — pour les besoins locaux, FHIR permet d'ajouter des extension[] typées par URL. Les profils nationaux (US Core, FR Core, NL Core…) définissent leurs propres extensions.

Versions

HL7 International publie FHIR depuis 2012. Chaque release majeure remplace la précédente après une période d'overlap, et les serveurs production peuvent exposer plusieurs versions simultanément.

Familles de ressources

FHIR R5 publie environ 157 ressources, regroupées par grandes thématiques cliniques et techniques. Les plus importantes :

L'API REST

Le cœur de FHIR est sa spécification d'API REST. Quelques exemples d'endpoints typiques sur un serveur conforme :

• GET /Patient/{id} — lire une ressource Patient par son identifiant technique.
• POST /Patient — créer une ressource Patient (l'id est attribué par le serveur).
• PUT /Patient/{id} — mettre à jour une ressource Patient.
• GET /Patient?identifier=urn:oid:1.2.3|MRN12345 — rechercher une ressource par identifiant métier.
• GET /Patient/{id}/$everything — opération composite qui retourne toutes les ressources liées.
• GET /metadata — exposer la CapabilityStatement du serveur (ce qu'il sait faire).

Les réponses sont systématiquement des ressources FHIR. Quand on cherche, le serveur retourne un Bundle typé searchset qui agrège les résultats. Quand on opère sur plusieurs ressources d'un coup (transaction, batch), on poste un Bundle typé transaction à la racine du serveur.

La sécurité passe quasi-systématiquement par OAuth 2 + OpenID Connect, encadrée par SMART on FHIR pour les apps tierces qui se branchent dans un EHR.

Implementation Guides

FHIR à l'état brut n'est pas immédiatement déployable : il faut le contraindre. Les Implementation Guides (IG) le font, en publiant des profils (un StructureDefinition qui restreint une ressource), des ValueSets et des extensions propres à un cas d'usage ou à un pays.

Comparaison avec HL7 v2

Pour aller plus loin

Pages détaillées des ressources FHIR sur ediverse :

• Patient — la ressource démographique fondamentale
• Bundle — le conteneur de transaction et de search

Standards apparentés :

• HL7 v2.x — le pilier des messages cliniques
• X12 transactions 270/271/278/834/835/837 — la couche administrative HIPAA

Spécifications officielles à consulter :

• FHIR R5 — Specification (release du 26 mars 2023, copyright HL7 International, license CC-BY 4.0 sur les ressources).
• FHIR R5 — Resource List pour parcourir les 157 ressources publiées.
• International Patient Summary (IPS) — IG transfrontalier.
• US Core Implementation Guide — profil obligatoire ONC.
• SMART App Launch Framework — couche d'autorisation OAuth 2 / OpenID Connect pour FHIR.
• FHIR Management Group — organe de gouvernance HL7.