Interopérabilité plutôt que concurrence : relier les applis de santé

Awa a trouvé son cardiologue, le Dr Moussa Ndiaye au Plateau, grâce à une application de prise de rendez-vous. L’an dernier, elle a utilisé un service de téléconsultation consacré à la santé des femmes, et quand elle cherche un médicament, elle consulte un outil de recherche de pharmacie sur son téléphone. Chaque service a bien fait son travail. Aucun ne sait ce que savent les autres.

Le réflexe habituel consiste à se demander quelle application l’emportera. Cet article pose une autre question, plus utile : comment peuvent-elles travailler ensemble ? Il explique ce qu’est l’interopérabilité en termes simples, comment une couche commune fondée sur un standard permet aux applications existantes de se brancher sur le même dossier, et comment le consentement laisse la main au patient.

Le Sénégal a déjà des applications de santé utiles

Des équipes sénégalaises ont bâti des services de santé numérique concrets, souvent à partir d’un manque constaté autour d’elles. Quelques exemples, décrits uniquement à partir de sources publiques :

• Freedocteurs a été présentée par Financial Afrik en 2020 comme une plateforme sénégalaise d’e-santé qui veut rapprocher médecins et patients.
• Njureel, lancée fin 2019, propose des consultations en ligne et des conseils en santé reproductive aux femmes et aux jeunes filles. Un serveur vocal, ajouté fin 2020, permet aux femmes sans accès à internet d’échanger avec des professionnels de santé, rapportait Gavi en 2023.
• Wergu, créée en 2019 par des étudiants de l’École polytechnique de Dakar, aide à trouver un médicament en indiquant les trois pharmacies les plus proches (Gavi, 2023). Son équipe le dit clairement : « Le but n’est pas de se substituer aux pharmaciens car ce sont eux qui déterminent la posologie des médicaments, bien sûr. »
• Telewer, lancée en juin 2022 par la start-up Senvitale, propose des consultations à distance et de la téléexpertise, avec une mallette de télémédecine fonctionnant à l’énergie solaire qui permet à un infirmier de réaliser des examens comme un électrocardiogramme (Gavi, 2023).
• Wawdocteur, publiée en 2025, se présente dans sa fiche App Store comme un outil de prise de rendez-vous avec rappels automatiques et gestion d’agenda pour les structures de santé, avec des données hébergées au Sénégal.

Chacune de ces équipes connaît ses utilisateurs et son domaine mieux que n’importe quel nouvel arrivant. Ce savoir mérite d’être préservé, pas remplacé.

Le problème se situe entre les applications, pas en elles

Chaque application stocke ce dont elle a besoin dans son propre format. C’est un choix raisonnable quand on construit seul. Le problème surgit quand le patient circule : l’application de rendez-vous ignore ce que la téléconsultation a prescrit, l’outil de recherche de pharmacie ne sait pas quelle ordonnance est valide, et le logiciel du médecin ne connaît ni l’un ni l’autre.

Relier les applications une à une ne tient pas la distance. Si chaque système doit construire un lien sur mesure avec chacun des autres, 5 systèmes demandent 10 liens et 10 systèmes en demandent 45, car le nombre croît selon n × (n − 1) ÷ 2. Chaque lien est un projet à construire, tester et maintenir. Avec un standard commun, chaque système construit une seule connexion vers le format partagé, et chaque nouveau partenaire ajoute un lien, pas des dizaines.

Le Sénégal ne dispose pas encore de cette couche commune. Une note pays publiée par PATH en 2025 indiquait que le cadre national d’interopérabilité était toujours à l’état de projet, et une analyse de situation réalisée en 2024 pour la coalition Transform Health, citant le Global Digital Health Monitor, attribuait la note de 1 sur 5 à « l’architecture et l’interopérabilité des plateformes existantes » (traduction). Nous revenons sur les causes dans pourquoi les données de santé sont morcelées au Sénégal.

L’interopérabilité, en termes simples

L’interopérabilité, c’est la capacité de deux systèmes à échanger une information et à la comprendre de la même façon, sans que personne ne la ressaisisse. Prenons une ordonnance rédigée par le Dr Ndiaye : une pharmacie de la Médina doit pouvoir la lire, la vérifier et la marquer comme délivrée, quel que soit le logiciel de chacun.

Le standard international conçu pour cela s’appelle HL7 FHIR (Fast Healthcare Interoperability Resources, prononcé comme l’anglais « fire »). Il définit des briques standard appelées ressources : Patient, Appointment (le rendez-vous), Encounter (la consultation), MedicationRequest (l’ordonnance), Observation (une mesure ou un résultat d’analyse). La spécification est libre d’utilisation : HL7 la publie sous licence Creative Commons « No Rights Reserved » (CC0). Notre guide de FHIR expliqué simplement en présente les bases.

L’interopérabilité ne signifie pas qu’une application absorbe les autres. Elle signifie s’accorder sur la forme des données, pour que chaque application puisse rester elle-même.

Un dossier, plusieurs portes d’entrée

Une couche commune fonctionne comme un dossier unique doté de plusieurs portes. Chaque application est une porte. Elle garde son design, ses utilisateurs et son modèle économique, mais ce qu’elle écrit va dans le même format standard, et ce qu’elle lit en provient, lorsque le patient l’autorise.

Pour Awa, cela veut dire que l’ordonnance de sa téléconsultation et son suivi en cardiologie peuvent figurer dans le même historique. Pour le Dr Ndiaye, cela veut dire voir ce que d’autres services autorisés ont enregistré, sans demander à Awa de le réciter. Pour les équipes des applications, cela veut dire toucher des médecins et des patients qui utilisent d’autres outils, sans construire et entretenir un lien avec chacun.

Cette démarche rejoint les Principes pour le développement numérique, dont la version de 2024 s’ouvre sur deux principes : « comprendre l’écosystème existant » et « partager, réutiliser et améliorer » (traduction).

« Bâtir sur ce qui fonctionne, améliorer ce qui fonctionne, et partager pour que d’autres puissent en faire autant. »

— Principles for Digital Development, Share, reuse, and improve (2024, traduction)

SMART on FHIR et consentement : qui voit quoi

Un dossier partagé soulève une question évidente : qui peut le lire ? Trois mécanismes y répondent.

SMART on FHIR fixe les règles selon lesquelles une application se connecte et demande une autorisation avant de lire ou d’écrire des données FHIR. La spécification SMART App Launch repose sur OAuth 2.0, un standard courant qui permet d’accorder à une application un accès limité sans partager de mot de passe. L’équipe SMART, basée au Boston Children’s Hospital, résume l’objectif : permettre à un développeur de construire une application une seule fois et de l’utiliser dans différents contextes de soins. Aux États-Unis, les logiciels de santé certifiés devaient fournir à leurs clients une API FHIR standardisée compatible SMART au plus tard le 31 décembre 2022, selon une fiche de l’ONC, l’autorité fédérale américaine chargée des technologies de l’information en santé.

Le consentement est enregistré comme une donnée, jamais présumé. La ressource Consent de FHIR est définie comme l’enregistrement des choix d’une personne soignée, qui autorise ou refuse à des destinataires identifiés certaines actions. Rien n’est partagé par défaut. Notre article sur le consentement et l’accès au dossier médical va plus loin.

La traçabilité ferme la boucle. Chaque accès est inscrit dans un journal, que FHIR représente avec la ressource AuditEvent, définie comme l’enregistrement d’un événement destiné à tenir un journal de sécurité. Si l’outil de recherche de pharmacie a lu l’ordonnance d’Awa, il en reste une trace.

Pour le lecteur technique

• Les scopes SMART v2 combinent un contexte et des permissions : patient/Observation.rs autorise la lecture et la recherche des observations du patient courant, user/Encounter.rs couvre ce à quoi l’utilisateur connecté a accès, et les scopes system/ servent aux services back-end. Les lettres signifient create, read, update, delete et search.
• launch/patient demande la sélection d’un patient au lancement : l’application partenaire travaille dans le dossier d’un seul patient, pas dans toute la base.
• Dans FHIR R4, la ressource Consent a le statut « trial use » et modélise le cas d’usage de la confidentialité ; les décisions d’accès doivent la vérifier avant que la donnée ne quitte le serveur, et chaque lecture doit produire un AuditEvent.

Ce que les applications existantes gardent, et ce qu’elles gagnent

Une application partenaire branchée sur une couche commune garde ce qui fait sa valeur : ses utilisateurs, sa marque, ses tarifs et sa feuille de route. Rien ne l’oblige à changer l’expérience que connaissent ses utilisateurs.

Elle gagne en portée et en contexte. Avec le consentement du patient, elle peut lire un historique plus complet, et ce qu’elle écrit devient utile au médecin suivant. Elle peut se spécialiser : un service de santé des femmes n’a pas à bâtir un réseau de pharmacies, et un outil de recherche de pharmacie n’a pas à développer un agenda.

Un standard commun ne supprime pas la concurrence entre applications. Il la déplace : on ne se dispute plus la détention des données, on rivalise sur la qualité du service rendu aux patients. L’équipe SMART défend elle-même l’idée qu’une application doit pouvoir être facilement remplacée par une autre, ce qui tire la qualité vers le haut. Pour des patientes comme Awa, c’est la seule concurrence qui compte.

Ce que fait Quralys

Quralys part d’un principe : les applications de santé sénégalaises existantes sont des partenaires potentiels, pas des rivales. Son socle enregistre chaque action sous forme de ressource FHIR R4 standard, et une API partenaires fondée sur SMART on FHIR, avec le consentement du patient, est prévue pour que d’autres applications lisent et écrivent le même dossier au lieu de le copier. Un bac à sable pour les développeurs partenaires fait partie de l’offre gratuite.

Quralys n’est pas encore lancé : les premiers modules sont en construction et un pilote avec 3 à 5 médecins libéraux à Dakar est prévu, l’API partenaires venant ensuite. Pour voir comment les pièces doivent s’articuler, consultez notre page écosystème.

Sources

1. Gavi VaccinesWork : Trois innovations made in Sénégal pour améliorer l’accès à la santé (2023)
2. Financial Afrik : Freedocteurs, une réelle solution pour les patients ? (2020)
3. Wawdocteur : fiche App Store (via MWM)
4. PATH : VPD surveillance systems in Senegal, note pays (juillet 2025)
5. Coalition Transform Health : Landscape analysis, digitisation and health data governance in Senegal (janvier 2024)
6. HL7 : licence de la spécification FHIR R4 (CC0)
7. Principles for Digital Development (2024)
8. HL7 : SMART App Launch, guide d’implémentation
9. SMART Health IT : About SMART
10. ONC : Cures Update, critères de certification et échéance du 31 décembre 2022 (fiche)
11. HL7 : ressource Consent de FHIR R4
12. HL7 : ressource AuditEvent de FHIR R4