Les systèmes de santé nationaux reposent sur des dizaines de systèmes distincts : hôpitaux, centres de santé, programmes verticaux comme la vaccination ou la lutte contre le paludisme, régimes d’assurance, pharmacies, état civil et carte sanitaire administrative. Les relier ne constitue pas un seul projet : ce sont de nombreux projets. L’interopérabilité des systèmes de santé prend des formes différentes selon ce qui est échangé, et la pratique d’interopérabilité de Bluesquare, en plein développement, tout récemment à travers un programme national en Mauritanie, produit déjà des enseignements qui méritent d’être partagés avant même que les résultats soient complets.
Avant de choisir une architecture, un programme national doit savoir combien de systèmes distincts il relie réellement, un exercice généralement plus restreint et plus gérable qu’il n’y paraît.
Un réseau de 200 centres de santé fonctionnant avec seulement 6 logiciels différents ne crée, au fond, que 6 problèmes d’intégration. Dimensionner une architecture par site plutôt que par éditeur de logiciel surestime l’effort et masque l’endroit où la véritable négociation doit avoir lieu. Les programmes nationaux gagnent à tenir un registre des points de service qui consigne l’éditeur, le produit et la version d’API de chaque site, car c’est ce qui détermine le travail d’intégration restant.
L’interopérabilité peut être gouvernée de 2 façons : un modèle centralisé, où une couche d’intégration absorbe le format natif de chaque système, nœud par nœud, ou un modèle prescriptif, où le secteur fixe d’emblée un contrat d’API partagé ainsi que des terminologies de référence. Le modèle centralisé permet de lancer rapidement un premier échange, mais crée une dépendance durable envers ceux qui construisent les connecteurs. Le modèle prescriptif exige une véritable autorité institutionnelle pour rendre le cadre obligatoire. L’enseignement applicable jusqu’ici : décider, système par système, quelle logique convient, et inscrire une clause de sortie dans chaque connecteur centralisé pour qu’il ne devienne pas permanent.
Une grande partie de ce qui ressemble à un retard technique dans les programmes d’interopérabilité relève, en pratique, d’une question de gouvernance qui n’a jamais été explicitement distinguée.
Savoir si une formation sanitaire peut accéder aux données d’une autre dépend en réalité de 4 décisions distinctes : une vérification technique d’identité, un droit interorganisationnel défini par un accord de partage de données, une décision d’accès fine relevant uniquement de la formation sanitaire qui détient les données, et une base juridique individuelle telle que le consentement du patient. Confondre ces décisions est l’une des sources les plus fréquentes d’échanges bloqués ou, à l’inverse, d’un accès excessif non gouverné. Un accord-cadre sectoriel, signé une seule fois par tous les points de service et assorti d’une courte annexe bilatérale par connexion, transforme cette démarche en une étape reproductible plutôt qu’en une négociation à chaque fois.
Un échange délimité, comme un résumé patient minimal, repose sur un ensemble de concepts défini et vérifiable, et se gouverne simplement. La terminologie à l’échelle d’un secteur est différente : définir à l’avance tous les concepts qu’un secteur pourrait vouloir échanger n’aboutit jamais, et un périmètre déclaré complet au lancement s’avère presque toujours incomplet dès que les systèmes l’utilisent. Le principe applicable : n’ajouter un concept que lorsqu’un flux enregistré en a besoin, en s’appuyant sur des référentiels tels que CIM-11, LOINC, et ATC partout où ils conviennent déjà.
L’interopérabilité recouvre des requêtes qui n’ont plus rien de comparable dès lors que l’on tient compte du temps de réponse attendu, et cette différence détermine la plupart des décisions techniques qui suivent.
Lorsqu’un programme national de vaccination ou de lutte contre le paludisme envoie des indicateurs agrégés au système d’information de gestion de la santé du pays, généralement DHIS2, personne n’attend de réponse en ligne. Cet échange agrégé s’exécute selon un calendrier, de quelques minutes à une fois par jour, via une couche d’intégration par lots telle que OpenHEXA, qui extrait, nettoie, dédoublonne et réconcilie de gros volumes de données, conserve des copies de travail versionnées des registres et des tables de terminologie, et ne fait jamais office de source faisant autorité des données qu’elle traite.
Consulter un dossier patient pendant une consultation, valider un code de formation sanitaire ou vérifier l’éligibilité à une assurance relèvent d’une logique différente : quelqu’un attend, généralement entre 100 millisecondes et 2 secondes pour une seule recherche, et jusqu’à environ 10 secondes lorsque plusieurs appels dépendants doivent être orchestrés, par exemple pour résoudre l’identité, la formation sanitaire et la terminologie avant de transmettre un dossier. Cet échange en temps réel passe par une couche d’interopérabilité transactionnelle, qui journalise chaque transaction, applique les contrôles de consentement et garantit la livraison, contrairement aux outils par lots utilisés pour le rapportage agrégé.
Certains échanges en temps réel franchissent une limite qu’aucun pipeline par lots, ni aucune couche transactionnelle, ne peut gérer seul en toute sécurité : la frontière entre 2 entités juridiques distinctes.
Vérifier l’identité d’un patient auprès de l’état civil, contrôler des droits ou une affiliation d’assurance, notifier une naissance ou un décès, ou vérifier l’autorisation d’exercer d’un professionnel de santé impliquent tous 2 entités juridiques distinctes, chacune ayant besoin d’une preuve que l’autre partie ne pourra pas contester par la suite. Cette preuve, un message signé, un horodatage approuvé, un journal vérifiable tenu indépendamment par chaque partie, est ce qu’un bus de confiance national ajoute à une couche d’interopérabilité : une garantie différente de celle que la couche offre seule.
Un bus de confiance national ne devrait être proposé que là où il est déjà en production, ou là où une autorité mandatée s’est engagée à le construire, et jamais construit de toutes pièces au sein d’un seul programme de système d’information sanitaire. Les échanges purement internes, ou les flux analytiques de grand volume destinés aux tableaux de bord nationaux, n’ont pas besoin de cette couche, et en ajouter une malgré tout ne fait que doubler la charge de journalisation pour les équipes nationales par la suite. Recourir à la couche minimale dont un cas d’usage a réellement besoin est l’un des enseignements les plus nets de ce travail.
Bluesquare met en œuvre cette approche de l’interopérabilité à travers DIGISANTE MRT, un programme qui appuie la digitalisation du secteur de la santé en Mauritanie, et dont les premières étapes comportent déjà leurs propres enseignements.
En collaboration avec le ministère de la Santé, le ministère de la Transformation numérique et de la Modernisation de l’administration, l’autorité nationale du registre de la population et les organismes professionnels, le programme a organisé un atelier national qui a posé un socle commun : HL7 FHIR R4, un identifiant patient national et des terminologies harmonisées (CIM-11, SNOMED CT, LOINC, ATC). Il a aussi identifié plusieurs registres : un registre des patients lié à l’identifiant de la population, un registre du personnel de santé, un registre des formations sanitaires construit sur la carte sanitaire administrative, une identification des assurances, un registre pharmaceutique et une couche d’export alimentant DHIS2 pour un rapportage agrégé et anonymisé. Une unité nationale de pilotage, présidée par le Secrétaire général du ministère, a tenu sa première session en juillet 2026.
Le programme a décidé très tôt d’impliquer les éditeurs de logiciels du pays et de les guider vers les standards d’échange. Ce choix soutient la pérennité de la solution et son appropriation par les équipes du pays, y compris le personnel technique du ministère de la Santé et du ministère de la Transformation numérique et de la Modernisation de l’administration. Le programme s’insère dans un écosystème existant, avec par exemple des hôpitaux déjà digitalisés sur plusieurs solutions différentes. Son rôle est de construire un cadre d’interopérabilité auquel les acteurs du pays s’adaptent, tout en continuant à développer leur propre activité.
Une grande partie des soins de santé primaires en Mauritanie repose encore sur des registres papier, sans accès à internet et avec une électricité limitée : le programme digitalise donc d’abord et intègre les systèmes plus avancés ensuite, plutôt que de supposer une connectivité qui n’existe pas encore. Après avoir comparé 2 plateformes open source de dossier médical électronique, le programme a recommandé OpenClinic GA comme dossier de soins primaires partagé, en privilégiant une solution open source déjà alignée sur les standards nationaux. Parmi les 21 centres de santé évalués à Nouakchott, au Trarza et au Brakna, 12 ont été confirmés comme sites pilotes, avant un premier déploiement au centre de santé de Dar Naim.
Ces enseignements sur l’interopérabilité sont précoces et issus d’un travail encore en cours ; les prochains mois en Mauritanie, ainsi que dans les autres programmes nationaux de Bluesquare, les mettront davantage à l’épreuve. Pour en savoir plus sur l’approche de Bluesquare en matière de registres et de données géospatiales à l’échelle nationale, découvrez le géoregistre et les outils de microplanification.
