FHIR, c’est quoi ? Le guide simple pour les médecins au Sénégal

Awa sort du cabinet de cardiologie du Dr Moussa Ndiaye, au Plateau, avec une ordonnance manuscrite, une demande d’analyse de sang et une date de contrôle notée dans l’agenda papier de la secrétaire. À la pharmacie, à la Médina, le pharmacien déchiffre l’écriture. Au laboratoire, quelqu’un saisit son nom une nouvelle fois. L’an prochain, un autre médecin reprendra son histoire de zéro.

Le problème n’est pas le manque de logiciels. C’est que ces logiciels ne parlent pas la même langue. Ce guide présente FHIR, le standard international conçu pour donner aux données de santé cette langue commune : ce qu’il est, ses quatre briques, qui l’utilise déjà et ce qu’il changerait pour un cabinet à Dakar. Aucune connaissance informatique n’est nécessaire ; une courte partie, à la fin, s’adresse aux lecteurs techniques.

Ce qu’est FHIR

FHIR signifie Fast Healthcare Interoperability Resources et se prononce comme le mot anglais « fire ». C’est un standard d’échange d’informations de santé entre systèmes informatiques, créé par HL7 International, l’organisation qui élabore des standards pour les données de santé. La spécification est libre d’utilisation, sans restriction : une clinique, une start-up ou un programme public peut s’en servir sans payer de licence.

Le mot savant du milieu, interopérabilité, veut simplement dire que deux systèmes peuvent échanger des informations et les comprendre de la même façon. Pensez aux formulaires administratifs : comme chacun remplit les mêmes cases dans le même ordre, n’importe quel bureau peut lire un formulaire rempli ailleurs. FHIR fait de même pour les données de santé, avec les technologies ordinaires du web (HTTP, JSON, XML).

Plusieurs versions existent. Celle sur laquelle s’appuient aujourd’hui les régulateurs et les programmes nationaux est la R4 : c’est la version exigée par les règles de certification américaines et la base du guide national indien.

Les quatre briques

Les ressources : des fiches standard

Chaque type d’information de santé a une structure convenue, appelée ressource. Il existe une ressource Patient (nom, sexe, date de naissance, coordonnées), une ressource Appointment (le rendez-vous), une ressource Encounter (la consultation elle-même), une ressource Observation (une tension artérielle ou un résultat d’analyse) et une ressource MedicationRequest (l’ordonnance). La version R4 définit plus de 140 types de ressources, de la prise de rendez-vous à la facturation.

Les ressources se répondent. L’ordonnance d’Awa renvoie à sa fiche Patient et à la fiche Practitioner du Dr Ndiaye : l’ordonnance sait toujours à qui elle appartient et qui l’a signée. Quand un pays a besoin d’un élément que le standard de base ne prévoit pas, FHIR lui permet d’adapter les ressources grâce aux profils (des règles locales appliquées à une ressource) et aux extensions (des champs supplémentaires documentés), publiés pour que les autres puissent les lire.

Les codes : un seul sens partout

Une fiche n’est utile que si les cases sont remplies de la même façon. FHIR s’appuie donc sur des listes de codes internationales : la CIM-11 pour les diagnostics, LOINC pour les analyses de laboratoire, ATC pour les médicaments et SNOMED CT pour les termes cliniques détaillés. Qu’un médecin écrive paludisme, malaria ou palu, le dossier porte le même code CIM-11, et chaque système le lit de la même manière. Notre guide de la CIM-11, de LOINC et d’ATC présente chacune de ces listes.

L’API : une même façon de demander

Une API (interface de programmation) est la porte par laquelle un logiciel demande des informations à un autre. FHIR définit une seule API, de type REST, pour toutes ses ressources : elle utilise le même genre de requête web qu’un navigateur qui ouvre une page. « Donne-moi les ordonnances en cours d’Awa » s’écrit de la même façon quel que soit le logiciel, et la réponse revient dans le même format. Un logiciel de pharmacie capable de dialoguer avec un serveur FHIR peut donc, en principe, dialoguer avec tous, sans connexion sur mesure pour chaque clinique.

SMART on FHIR : le patient garde la clé

Partager ne doit pas vouloir dire exposer. SMART App Launch, qu’on appelle couramment SMART on FHIR, est un guide HL7 qui ajoute la connexion et les autorisations à FHIR. Il repose sur OAuth 2.0, un standard du web pour déléguer un accès, et utilise des « scopes » qui définissent précisément ce qu’une application peut lire ou écrire. Pensez à la carte d’un hôtel : elle ouvre une chambre, pour une durée limitée, pas tout le bâtiment.

FHIR prévoit aussi des ressources pour les règles elles-mêmes. Consent garde la trace de ce que le patient a accepté, et AuditEvent enregistre qui a consulté quel dossier, et quand. Le fonctionnement concret fait l’objet de notre article sur qui peut voir votre dossier médical.

À retenir

FHIR n’est pas une application. C’est une grammaire commune : des fiches standard (les ressources), un vocabulaire partagé (les codes), une seule façon de demander (l’API) et un seul jeu de clés (SMART on FHIR).

Qui parle déjà FHIR

FHIR est inscrit dans la réglementation, intégré à des logiciels très répandus et adopté par des programmes de santé mondiaux.

Les recommandations SMART de l’OMS et SMART on FHIR n’ont en commun qu’un mot : les premières traduisent des recommandations médicales en règles numériques, le second contrôle ce à quoi les applications peuvent accéder.

L’Union africaine va dans le même sens. En 2023, l’Africa CDC a publié des lignes directrices et standards pour l’échange d’informations de santé sur le continent, préparés par un groupe de travail de 24 experts. Sa recommandation est sans ambiguïté :

« […] [le groupe de travail] recommande que toutes les nouvelles mises en œuvre et améliorations des systèmes de santé numérique utilisent FHIR comme principal mécanisme d’échange de données. » (traduction)

— Africa CDC, African Union Health Information Exchange Guidelines and Standards (2023)

Ce que FHIR change pour un cabinet à Dakar

Le Sénégal a numérisé sa santé par morceaux. Le DHIS2, la plateforme open source du système national d’information sanitaire, est utilisé depuis plus de dix ans, du niveau central jusqu’aux postes de santé communautaires. Cliniques privées, pharmacies, laboratoires et start-up, eux, gardent chacun leurs dossiers dans leur propre format.

Concrètement, voici ce qu’un standard commun change :

• Écrit une fois, lu là où c’est autorisé. L’ordonnance du Dr Ndiaye arrive à la pharmacie de la Médina sous forme de données structurées, pas d’écriture à déchiffrer. Le résultat d’analyse d’Awa revient dans son logiciel sans être ressaisi.
• Changer de logiciel sans perdre ses patients. Des dossiers tenus au format FHIR peuvent passer d’un système FHIR à un autre. La clinique n’est plus prisonnière du format propriétaire d’un éditeur.
• Les nouveaux partenaires se branchent une seule fois. Un assureur, une mutuelle de santé ou un laboratoire se connecte au standard, et non à chaque clinique au prix d’un projet sur mesure.
• Le reporting national sans double saisie. Les consultations peuvent alimenter les indicateurs anonymisés qu’attend le système national, grâce à une couche de traduction (un intergiciel, ou middleware). Dans l’enquête DHIS2, cette correspondance se fait le plus souvent dans l’intergiciel, comme nous l’expliquons dans DHIS2 et FHIR.

Pour la patiente, le changement est simple : son historique la suit, au lieu de rester dans la clinique où il a été écrit.

Ce que FHIR ne fait pas

Un standard est une fondation, pas une maison finie.

• Ce n’est pas un logiciel. FHIR est une spécification que des logiciels mettent en œuvre. Une clinique a toujours besoin d’une application agréable à utiliser et qui fonctionne sur une connexion faible.
• Il ne corrige pas les mauvaises données. Un diagnostic erroné, parfaitement codé, reste erroné. Les codes doivent être choisis avec soin, et les écrans doivent rendre le bon code facile à choisir.
• Il ne décide pas qui voit quoi. FHIR fournit les outils (Consent, scopes SMART, journaux d’accès). Les règles viennent des choix du patient, de la loi et de la gouvernance de chaque structure.
• Il demande des accords nationaux. Chaque pays doit encore fixer les détails : quel identifiant patient, quelles listes de codes, quels profils. L’Inde l’a fait en publiant son propre guide FHIR. Le Sénégal aura besoin du même type de référentiel commun.

Pour le lecteur technique

Voici une ressource Patient minimale pour Awa, en JSON (un format de données en texte brut), conforme à FHIR R4 :

{
  "resourceType": "Patient",
  "id": "awa-diop",
  "name": [{ "family": "Diop", "given": ["Awa"] }],
  "gender": "female",
  "birthDate": "1990-04-12",
  "telecom": [{ "system": "phone", "value": "+221 77 000 00 00", "use": "mobile" }],
  "address": [{ "city": "Dakar", "country": "SN" }],
  "communication": [{
    "language": {
      "coding": [{ "system": "urn:ietf:bcp:47", "code": "wo", "display": "Wolof" }]
    },
    "preferred": true
  }]
}

Le champ resourceType indique de quelle fiche il s’agit, et l’élément communication enregistre le wolof (code BCP 47 « wo ») comme langue préférée d’Awa. Rien dans la structure n’est propre au Sénégal : seules les valeurs le sont.

Toutes les ressources suivent le même schéma REST. GET [base]/Patient/awa-diop renvoie cette fiche, et GET [base]/MedicationRequest?patient=awa-diop renvoie ses ordonnances. Avec SMART on FHIR, l’application obtient d’abord un jeton d’accès OAuth 2.0 dont les scopes limitent ce que le serveur renverra. En production, un profil national viendrait aussi encadrer chaque ressource, et les serveurs devraient valider les données par rapport à ce profil.

Ce que fait Quralys

Quralys est une plateforme de santé nativement FHIR, en cours de construction à Dakar, avant son lancement. Son premier produit est volontairement ordinaire : une appli patient pour trouver un médecin, réserver et payer par mobile money, et une suite pour les médecins avec agenda, notes de consultation, ordonnances numériques pré-remplies et téléconsultation construite sur Jitsi. Un pilote avec trois à cinq médecins libéraux de Dakar est prévu.

La différence se trouve en dessous. Chaque action écrit une ressource FHIR R4 standard (Appointment, Encounter, MedicationRequest et d’autres) : une pharmacie, un laboratoire, un assureur ou le système national pourra ensuite lire le même dossier, avec l’accord du patient. Les applications sénégalaises existantes sont invitées à se brancher sur ce dossier via une API partenaires sécurisée par SMART on FHIR, plutôt qu’à lui faire concurrence. La page plateforme montre comment s’articule cette première version.

Sources

1. HL7 International : résumé de FHIR R4
2. Healthcare IT News : 5 things to know about HL7 FHIR
3. HL7 International : index des ressources FHIR R4
4. HL7 International : guide d’implémentation SMART App Launch
5. ONC (HealthIT.gov) : Standardized API for patient and population services
6. Epic : Epic on FHIR
7. Apple Newsroom : annonce des dossiers médicaux sur iPhone (2018)
8. NRCeS : guide d’implémentation FHIR pour l’ABDM
9. OMS : recommandations SMART
10. DHIS2 : enquête sur l’intégration DME–DHIS2 (juin 2026)
11. Africa CDC : African Union Health Information Exchange Guidelines and Standards (2023)
12. HISP Rwanda : la santé numérique au Sénégal, plus de dix ans de DHIS2