Interoperability, not competition: connecting Senegal's health apps

Awa found her cardiologist, Dr Moussa Ndiaye in Plateau, through a booking app. Last year she used a women's health teleconsultation service, and when she needs a medicine she checks a pharmacy finder on her phone. Each service did its job well. None of them knows what the others know.

The usual reflex is to ask which app will win. This article argues that the more useful question is how they can work together. It explains what interoperability means in plain words, how a shared standard layer lets existing apps plug into the same record, and how consent keeps the patient in control.

Senegal already has useful health apps

Senegalese teams have built practical digital health services, often starting from a gap they saw around them. A few examples, described only from public sources:

• Freedocteurs was presented by Financial Afrik in 2020 as a Senegalese e-health platform that aims to bring doctors and patients closer together.
• Njureel, launched at the end of 2019, offers online consultations and reproductive health advice for women and girls. A voice service added at the end of 2020 lets women without internet access talk to health professionals, as Gavi reported in 2023.
• Wergu, created in 2019 by students of the École polytechnique de Dakar, helps people find a medicine by suggesting the three nearest pharmacies (Gavi, 2023). Its team was clear that the aim is not to replace pharmacists, who decide the dosage.
• Telewer, launched in June 2022 by the start-up Senvitale, offers remote consultations and tele-expertise, with a solar-powered telemedicine kit that lets a nurse carry out checks such as an electrocardiogram (Gavi, 2023).
• Wawdocteur, released in 2025, describes itself in its App Store listing as a booking tool with automatic reminders and agenda management for facilities, with data hosted in Senegal.

Each of these teams knows its users and its niche better than any newcomer could. That knowledge is worth keeping, not replacing.

The gap is between the apps, not inside them

Each app stores what it needs in its own format. That is a sensible choice when you build alone. The problem appears when the patient moves: the booking app does not know what the teleconsultation prescribed, the pharmacy finder cannot tell which ordonnance is valid, and the doctor's own software knows neither.

Connecting apps one by one does not scale. If every system needs a custom link to every other system, 5 systems need 10 links and 10 systems need 45, because the count grows as n × (n − 1) ÷ 2. Each link is a separate project to build, test and maintain. With one shared standard, each system builds a single connection to the common format, and every new partner adds one link instead of dozens.

Senegal does not have that shared layer yet. A 2025 country brief published by PATH described the national interoperability framework as still "in draft form", and a 2024 landscape analysis for the Transform Health coalition, citing the Global Digital Health Monitor, scored "architecture and interoperability of existing platforms" at 1 out of 5. We look at the causes in why health data is fragmented in Senegal.

Interoperability in plain words

Interoperability means that two systems can exchange information and both understand it the same way, without anyone retyping it. Picture a prescription written by Dr Ndiaye that a pharmacy in Medina can read, check and mark as dispensed, whatever software each of them uses.

The international standard built for this is HL7 FHIR (Fast Healthcare Interoperability Resources, pronounced "fire"). It defines standard building blocks called resources: Patient, Appointment, Encounter (a consultation), MedicationRequest (a prescription), Observation (a measurement or a lab result). The specification is free to use: HL7 publishes it under a Creative Commons "No Rights Reserved" (CC0) licence. Our plain-language guide to FHIR covers the basics.

Interoperability does not mean one app absorbing the others. It means agreeing on the shape of the data, so that each app can stay itself.

One record, many doors

Think of a shared standard layer as one record with several doors. Each app is a door. It keeps its own design, its own users and its own business model, but what it writes goes into the same standard format, and what it reads comes from it, when the patient allows.

For Awa, this means her teleconsultation prescription and her cardiology follow-up can sit in the same history. For Dr Ndiaye, it means seeing what other authorised services recorded, without asking Awa to recite it. For app teams, it means reaching doctors and patients who use other tools, without building and maintaining a link with each one.

This way of working matches the Principles for Digital Development, whose 2024 version opens with "Understand the existing ecosystem" and "Share, reuse, and improve".

"Build on what works, improve what works, and share so that others can do the same."

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

SMART on FHIR and consent: who sees what

A shared record raises an obvious question: who can read it? Three mechanisms answer it.

SMART on FHIR sets the rules for how an app signs in and asks permission before it reads or writes FHIR data. The SMART App Launch specification is built on OAuth 2.0, a common standard for giving an app limited access without sharing a password. The SMART team, based at Boston Children's Hospital, describes the goal as letting a developer build an app once and use it across health settings. In the United States, certified health software had to offer a standardised FHIR API with SMART support to its customers by 31 December 2022, according to an ONC fact sheet.

Consent is recorded as data, not assumed. FHIR's Consent resource is defined as a record of a healthcare consumer's choices, which permits or denies identified recipients to perform actions. Nothing is shared by default. Our article on consent and access to the health record goes further.

Audit closes the loop. Every access is written to a log, which FHIR represents with the AuditEvent resource, "a record of an event made for purposes of maintaining a security log". If the pharmacy finder read Awa's prescription, there is a trace.

For the technical reader

• SMART v2 scopes combine a context and permissions: patient/Observation.rs allows reading and searching observations for the current patient, user/Encounter.rs covers what the signed-in user can access, and system/ scopes serve back-end services. The letters stand for create, read, update, delete and search.
• launch/patient asks for a patient to be selected at launch, so a partner app works inside one patient's record rather than the whole database.
• In FHIR R4, the Consent resource is at trial-use status and models the privacy use case; access decisions should check it before data leaves the server, and each read should produce an AuditEvent.

What existing apps keep, and what they gain

A partner app on a shared layer keeps what makes it valuable: its users, its brand, its pricing and its roadmap. Nothing obliges it to change the experience its users know.

What it gains is reach and context. With the patient's consent, it can read a fuller history, and what it writes becomes useful to the next doctor. It can specialise: a women's health service does not have to build a pharmacy network, and a pharmacy finder does not have to build an agenda.

A shared standard does not remove competition between apps. It moves it from who holds the data to who serves patients best. The SMART team itself argues that "one app should be readily substitutable for another", and that this pushes quality up. For patients like Awa, that is the competition that matters.

How Quralys approaches this

Quralys starts from the view that Senegal's existing health apps are potential partners, not rivals. Its core writes every action as a standard FHIR R4 resource, and a partner API based on SMART on FHIR, with the patient's consent, is planned so that other apps can read and write the same record instead of copying it. A sandbox for partner developers is part of the free tier.

Quralys is pre-launch: the first modules are being built and a pilot with 3 to 5 private doctors in Dakar is planned, with the partner API to follow. You can see how the pieces are meant to connect on our ecosystem page.

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: App Store listing (via MWM)
4. PATH: VPD surveillance systems in Senegal, country brief (July 2025)
5. Transform Health coalition: Landscape analysis, digitisation and health data governance in Senegal (January 2024)
6. HL7: FHIR R4 licence (CC0)
7. Principles for Digital Development (2024)
8. HL7: SMART App Launch implementation guide
9. SMART Health IT: About SMART
10. ONC: Cures Update certification criteria, 31 December 2022 deadline (fact sheet)
11. HL7: FHIR R4 Consent resource
12. HL7: FHIR R4 AuditEvent resource