FHIR pour l’interopérabilité santé en Afrique : tutoriel 2026

📍 Article principal : Santé numérique conforme CEDEAO 2026

Introduction

Une clinique privée à Dakar fournissait jusqu’en 2024 ses statistiques de santé publique au ministère via des fichiers Excel envoyés mensuellement par email. Format hétérogène, données à ressaisir manuellement côté ministère, retards et erreurs fréquentes. Le passage à un échange via FHIR avec le système national d’information sanitaire (basé sur DHIS2) a transformé l’opération : les données circulent automatiquement chaque nuit sans intervention humaine, le format est standardisé, et la clinique reçoit en retour des analyses agrégées sur sa zone d’intervention. Cette interopérabilité ouvre aussi des partenariats avec les laboratoires d’analyses qui transmettent leurs résultats directement dans le dossier patient. Ce tutoriel détaille l’implémentation FHIR : ressources de base, serveur HAPI FHIR auto-hébergé, intégration avec une plateforme OpenMRS existante, et patterns d’interopérabilité ouest-africains.

Prérequis

• Plateforme santé numérique fonctionnelle (OpenMRS ou autre)
• VPS Hetzner Cloud pour héberger HAPI FHIR si serveur dédié
• Connaissance de base REST API et JSON
• Connaissance des principes d’interopérabilité en santé (utile)
• Niveau : intermédiaire avancé — Temps : 3 heures

Étape 1 — Comprendre FHIR en 5 minutes

HL7 FHIR (Fast Healthcare Interoperability Resources) est un standard d’échange de données médicales conçu pour le web moderne. Il s’appuie sur trois principes simples : ressources REST identifiées par URI, format JSON ou XML, vocabulaire standardisé pour les concepts médicaux. Une donnée médicale est représentée par une ressource (Patient, Observation, Condition, Encounter, MedicationRequest, etc.) avec un identifiant unique et des relations entre ressources.

Concrètement, un patient en FHIR ressemble à un objet JSON avec son nom, sa date de naissance, son sexe, ses identifiants (numéro de dossier, CNI, sécurité sociale), et ses adresses. Une consultation est une ressource Encounter qui référence un Patient et un Practitioner, contient les diagnostics (Condition), prescriptions (MedicationRequest), et observations cliniques (Observation pour température, tension, poids). Cette modélisation reflète la réalité médicale et facilite l’échange entre systèmes hétérogènes.

Étape 2 — Déployer HAPI FHIR Server

HAPI FHIR est l’implémentation open-source de référence d’un serveur FHIR. Maintenue activement, elle implémente toute la spécification R4 et propose une image Docker prête à l’emploi. Pour les structures qui veulent un serveur FHIR autonome (par exemple comme proxy entre OpenMRS et le système national), HAPI tient sur un VPS Hetzner CX22.

cd /home/fhir
cat > docker-compose.yml <<EOF
services:
  hapi-fhir:
    image: hapiproject/hapi:latest
    ports:
      - "8090:8080"
    environment:
      SPRING_DATASOURCE_URL: jdbc:postgresql://db:5432/fhir
      SPRING_DATASOURCE_USERNAME: fhir
      SPRING_DATASOURCE_PASSWORD: ${DB_PASSWORD}
      SPRING_DATASOURCE_DRIVERCLASSNAME: org.postgresql.Driver
      HAPI_FHIR_FHIR_VERSION: R4
    depends_on:
      - db
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: fhir
      POSTGRES_USER: fhir
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - ./pgdata:/var/lib/postgresql/data
EOF

docker compose up -d

Une fois démarré, HAPI expose son endpoint FHIR sur http://localhost:8090/fhir. Tester avec un appel simple : curl http://localhost:8090/fhir/metadata retourne le manifest des ressources supportées. Configurer ensuite Caddy comme reverse proxy avec HTTPS pour exposer publiquement avec authentification.

Étape 3 — Sécurité et authentification

FHIR exige une protection forte : les données échangées sont sensibles. Trois couches de protection. Premièrement, le réseau : HAPI ne doit pas être exposé directement sur Internet. Caddy en frontal avec authentification API key obligatoire. Deuxièmement, OAuth 2 SMART on FHIR pour les applications tierces qui ont besoin d’accéder en lecture aux données patients — le standard officiel pour les apps santé. Troisièmement, audit log de chaque requête FHIR avec qui, quand, quoi — nécessaire pour la conformité réglementaire.

# Caddyfile avec auth basic + IP restriction
fhir.example.sn {
    @api_clients remote_ip 5.6.7.8/32 9.10.11.12/32
    handle @api_clients {
        basic_auth {
            api-client-1 $2a$14$hashed_password_1
            api-client-2 $2a$14$hashed_password_2
        }
        reverse_proxy localhost:8090
    }
    handle {
        respond "Forbidden" 403
    }
}

Pour la production, préférer OAuth 2 sur HTTP Basic. La complexité initiale (deux semaines pour configurer un serveur OAuth 2 type Keycloak en frontal) se rentabilise dès qu’on a plusieurs applications consommatrices et qu’on doit gérer la rotation des credentials.

Étape 4 — Ressources FHIR essentielles

Pour un cabinet médical typique, six ressources couvrent 90 % des cas d’usage. Patient pour l’identité du patient. Practitioner pour les médecins et soignants. Encounter pour chaque consultation ou hospitalisation. Observation pour les mesures cliniques (poids, taille, tension, température, glycémie). Condition pour les diagnostics et antécédents médicaux. MedicationRequest pour les prescriptions de médicaments. Ces six ressources structurent l’essentiel des informations médicales et facilitent l’export vers systèmes nationaux.

// Exemple de Patient FHIR R4
{
  "resourceType": "Patient",
  "identifier": [
    { "system": "urn:oid:cabinet.example.sn:patients", "value": "P-12345" },
    { "system": "urn:oid:senegal:cni", "value": "1980034567" }
  ],
  "name": [{ "use": "official", "family": "Diop", "given": ["Aïssatou"] }],
  "gender": "female",
  "birthDate": "1985-03-15",
  "address": [{ "line": ["Liberté 6"], "city": "Dakar", "country": "SN" }],
  "telecom": [{ "system": "phone", "value": "+221771234567", "use": "mobile" }]
}

Pour chaque consultation, créer un Encounter qui référence le Patient et le Practitioner, et lier les Observations et MedicationRequests à cet Encounter. Cette structure relationnelle facilite ensuite les requêtes complexes type « donner-moi toutes les consultations de cette patiente avec leurs diagnostics et prescriptions ».

Étape 5 — Intégrer OpenMRS et HAPI

OpenMRS 3 expose nativement une API FHIR R4 via le module FHIR officiel. Pour synchroniser avec un serveur HAPI externe (par exemple celui du ministère de la santé), on configure un job qui appelle l’API OpenMRS, récupère les ressources FHIR récentes, et les envoie au serveur cible via POST FHIR. Cette synchronisation tourne typiquement nuitée et transmet les nouvelles consultations du jour.

// Pseudo-code Hono pour synchronisation
app.post('/api/sync/fhir-vers-ministere', async (c) => {
  const debutHier = dateDebutHier();
  const finHier = dateFinHier();

  // Récupérer les Encounters d'hier depuis OpenMRS
  const encounters = await fetchOpenMrs(`/fhir/Encounter?date=ge${debutHier}&date=le${finHier}`);

  // Pour chaque Encounter, exporter vers le serveur ministère
  for (const enc of encounters.entry) {
    await fetch(MINISTERE_FHIR_URL + '/Encounter', {
      method: 'POST',
      headers: { 'Authorization': 'Bearer ' + MINISTERE_TOKEN, 'Content-Type': 'application/fhir+json' },
      body: JSON.stringify(enc.resource)
    });
  }

  return c.json({ exported: encounters.entry.length });
});

Pour les structures qui n’ont pas encore d’OpenMRS et veulent un système plus simple, on peut utiliser HAPI FHIR directement comme moteur métier avec un frontend React ou SvelteKit. Cette approche est plus légère qu’OpenMRS mais demande de redévelopper les fonctionnalités cliniques. Pour la majorité des cas, OpenMRS plus FHIR proxy reste le meilleur compromis.

Étape 6 — Trois cas d’usage concrets

Premier cas : envoi automatique au système national. Chaque nuit, le serveur synchronise les consultations vers le ministère via FHIR. Données reçues : statistiques anonymisées sur les pathologies par zone, indicateurs de santé publique, alertes maladies à déclaration obligatoire. La clinique gagne en conformité administrative et reçoit en retour des analyses utiles.

Deuxième cas : intégration avec laboratoire d’analyses. Le laboratoire partenaire expose un endpoint FHIR pour publier les résultats d’examens. La clinique souscrit aux notifications, et chaque résultat arrive automatiquement dans le dossier patient. Plus besoin de scanner les rapports papier ni de ressaisir les valeurs.

Troisième cas : portabilité du dossier patient entre cliniques. Avec consentement explicite du patient, deux cliniques peuvent échanger un dossier complet via FHIR Bundle (collection de ressources). Le patient qui change de cabinet ou consulte un spécialiste apporte son dossier digital plutôt que de tout ressaisir. Cette portabilité améliore la qualité de soins et réduit les examens redondants.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Trois aspects pratiques. Premièrement, les systèmes nationaux d’information sanitaire en Afrique de l’Ouest convergent vers DHIS2 plus FHIR. Sénégal, Côte d’Ivoire, et Burkina Faso annoncent leurs feuilles de route 2027-2029 dans cette direction. Les structures privées qui adoptent FHIR dès 2026 seront naturellement compatibles avec ces écosystèmes. Deuxièmement, le réseau africain HL7 FHIR Africa organise des sessions techniques régionales et des sandbox de test interopérabilité — une ressource précieuse pour valider ses implémentations face à des homologues régionaux. Troisièmement, pour les zones rurales avec connectivité limitée, prévoir une synchronisation FHIR incrémentale avec retry exponentiel et résolution de conflits — une consultation effectuée hors-ligne peut arriver avec retard et doit être correctement gérée.

Pour les coûts, HAPI FHIR sur Hetzner CX22 plus PostgreSQL revient à environ 8 euros par mois, négligeable face aux bénéfices d’interopérabilité. Pour les structures publiques qui ont besoin d’une infrastructure plus dimensionnée, monter à CX32 à 8 euros par mois reste très accessible.

Tutoriels frères

• Déployer OpenMRS sur Hetzner
• Audit trail et conformité
• App patient mobile

Pour aller plus loin

• 🔝 Pilier : Santé numérique CEDEAO
• Doc : HAPI FHIR · HL7 FHIR

FAQ

FHIR R4 ou R5 en 2026 ?
R4 reste la version stable et largement déployée. R5 publié en 2023 mais adoption progressive. Pour les nouveaux projets, R4 reste le choix par défaut.

HAPI FHIR ou Microsoft FHIR Server ?
Microsoft FHIR Server est aussi excellent et open-source, écrit en C# .NET. HAPI Java est plus mature en Afrique. Choisir selon les compétences de l’équipe.

Comment tester sans serveur réel ?
HAPI offre un serveur de test public à http://hapi.fhir.org/baseR4. Pour développer et tester sans risque sur de vraies données.

Quel volume de données HAPI peut-il gérer ?
Plusieurs millions de ressources avec un PostgreSQL bien tuné. Pour les très gros volumes (10M+), envisager une architecture distribuée.

Profils nationaux et adaptations

FHIR définit un noyau de ressources mais permet à chaque pays ou réseau de créer des « profils » qui restreignent ou étendent le standard pour ses besoins spécifiques. Plusieurs profils nationaux émergent en Afrique de l’Ouest. Le profil sénégalais, en cours d’élaboration par le ministère de la santé et des partenaires techniques, précise les identifiants nationaux acceptés (CNI sénégalaise), les codes diagnostiques selon la classification CIM-10 utilisée localement, et les vaccins du calendrier PEV adapté. Le profil ivoirien suit une logique similaire avec ses spécificités. Pour les structures privées qui anticipent l’interopérabilité avec ces systèmes nationaux, suivre les profils en cours de définition et participer aux consultations publiques aide à influencer leur conception et facilite l’adoption ultérieure.

Pour la mise en œuvre pratique, on configure son serveur FHIR avec les profils cibles, et on valide chaque ressource sortante contre ces profils avant envoi. HAPI FHIR offre cette validation native via les fichiers de profil au format StructureDefinition. Le surcoût technique est modéré (quelques jours d’intégration) mais évite les rejets côté système national qui demanderaient ensuite des corrections rétroactives.

Bundles et transactions FHIR

Pour transmettre plusieurs ressources liées en une seule opération atomique, FHIR définit le concept de Bundle. Un Bundle de type « transaction » garantit que toutes les ressources sont créées ensemble ou aucune ne l’est — utile pour transmettre un dossier patient complet sans risque d’incohérence partielle. Pour les exports nocturnes vers le ministère, on regroupe typiquement les Encounters, Observations, et Conditions du jour dans un seul Bundle, transmis en une requête HTTP. Cette atomicité simplifie la gestion d’erreurs et améliore les performances.

Les Bundles supportent aussi le mode « batch » qui exécute les opérations indépendamment — utile quand on accepte des échecs partiels. Pour les synchronisations critiques, préférer le mode transaction. Pour les imports massifs de données historiques, le mode batch peut être plus tolérant aux problèmes ponctuels.

Évolution FHIR 2026-2028

FHIR R5 publié en 2023 introduit des évolutions intéressantes : meilleur support des données génomiques, ressources pour la santé publique enrichies, intégration native avec les standards d’imagerie médicale. L’adoption R5 reste progressive et la majorité des écosystèmes nationaux ouest-africains restent sur R4 jusqu’en 2027-2028. Pour 2026, R4 est le choix sûr et compatible avec l’écosystème existant. La migration vers R5 se fera ensuite naturellement quand l’écosystème aura migré.

Côté outillage, l’écosystème FHIR mûrit rapidement avec des bibliothèques clientes dans tous les langages, des outils de validation, des générateurs de code à partir des profils. Cette maturité réduit progressivement la barrière d’entrée et rend FHIR accessible à des équipes techniques de taille modeste. Pour les agences ouest-africaines qui se positionnent sur le segment santé numérique, investir dans une expertise FHIR dès maintenant prépare aux opportunités futures de partenariats avec les acteurs publics et internationaux.

Bénéfices économiques mesurés

L’investissement dans FHIR rapporte concrètement. Pour une clinique typique, on observe trois sources de gains. Le temps administratif lié au reporting santé publique baisse de 60 à 70 % grâce à la transmission automatique remplaçant les rapports manuels. Les examens redondants entre cabinets baissent de 25 à 40 % grâce au partage des résultats récents via FHIR Bundle. Les revenus issus de partenariats avec laboratoires et ONG augmentent grâce à la facilité d’intégration permettant de nouvelles collaborations. Cumulés, ces gains représentent typiquement 5 à 15 % du chiffre d’affaires d’une clinique moderne après 18 mois d’utilisation, ce qui rentabilise largement les coûts d’implémentation initiaux.