Un patient passe par son médecin traitant, un laboratoire, un spécialiste, une pharmacie, parfois un hôpital. Chacun utilise un logiciel différent. L'interopérabilité, c'est la capacité de ces logiciels à échanger des informations et à les comprendre de la même façon. Le standard HL7 FHIR est devenu la référence mondiale pour y parvenir. Voici ce qu'il faut en comprendre, même sans être développeur.
En bref
- FHIR (prononcé « fire ») est un standard d'échange de données de santé, publié par l'organisation HL7.
- Il découpe l'information en ressources (Patient, Rendez-vous, Observation…) échangées via des API web modernes.
- Pour un éditeur, parler FHIR, c'est faciliter les connexions avec les hôpitaux, les laboratoires et les services publics de santé.
Les trois niveaux d'interopérabilité
| Niveau | Question | Exemple |
|---|---|---|
| Technique | Les systèmes peuvent-ils communiquer ? | Une API sécurisée accessible en HTTPS |
| Syntaxique | Parlent-ils le même format ? | Des données structurées en JSON selon FHIR |
| Sémantique | Se comprennent-ils ? | Le même code (LOINC, SNOMED CT…) pour « glycémie à jeun » |
FHIR en une image : les ressources
FHIR découpe le monde de la santé en briques appelées ressources. Chaque ressource a une structure définie, et elles se référencent entre elles.
| Ressource | Ce qu'elle représente |
|---|---|
| Patient | Identité, coordonnées, identifiants |
| Practitioner | Un professionnel de santé |
| Organization | Un cabinet, une clinique, un laboratoire |
| Appointment | Un rendez-vous |
| Encounter | Une consultation, un séjour |
| Observation | Une mesure ou un résultat (tension, glycémie…) |
| MedicationRequest | Une prescription de médicament |
| DocumentReference | Un document (compte rendu, PDF) |
- Patient
- Appointment
- Encounter
- Observation / MedicationRequest
- DocumentReference
Comment ça marche techniquement
FHIR repose sur les technologies du web : des API REST, des échanges en JSON (ou XML), et des opérations simples. Lire un patient, rechercher ses rendez-vous, créer une observation : chaque action correspond à une requête web standard. C'est ce qui le rend beaucoup plus simple à adopter que les anciens standards hospitaliers.
| Action | Requête type |
|---|---|
| Lire un patient | GET /Patient/123 |
| Chercher ses rendez-vous | GET /Appointment?patient=123 |
| Enregistrer une mesure | POST /Observation |
Les profils : adapter FHIR à chaque pays
FHIR est volontairement générique. Chaque pays ou chaque usage le précise avec des profils : quels champs sont obligatoires, quels identifiants utiliser, quelles terminologies. En France, l'Agence du numérique en santé publie un cadre d'interopérabilité (CI-SIS) et des profils FHIR adaptés au système de santé français, par exemple pour l'identité nationale de santé (INS).
Pourquoi c'est important pour votre projet
Sans standard
- Une connexion sur mesure par partenaire
- Des données recopiées à la main
- Des projets d'intégration longs et coûteux
- Un produit difficile à vendre aux établissements
Avec FHIR
- Un langage commun avec les autres systèmes
- Des intégrations plus rapides
- Une architecture prête pour les services nationaux
- Un argument de vente auprès des hôpitaux
Par où commencer ?
- Identifier les échanges utiles
Avec qui votre logiciel doit-il échanger, et quelles informations ?
- Choisir les ressources et profils
Repérer les ressources FHIR et les profils nationaux correspondants.
- Concevoir votre modèle de données en conséquence
Même si vous n'exposez pas d'API FHIR tout de suite, un modèle compatible évite une refonte.
- Tester avec des serveurs de test
Des serveurs FHIR publics et des outils de validation permettent de vérifier vos échanges.
26 août 2025 · 3 min de lecture
11 février 2025 · 3 min de lecture
15 octobre 2024 · 3 min de lecture