Afiya — Bringing Digital Healthcare to Africa via WhatsApp

What Inspired Us

In Cameroon and across Sub-Saharan Africa, the healthcare system is facing a structural crisis:

1 doctor for every 5,697 patients (WHO recommends 1:1,000)
80% of emergency room admissions are minor cases that could be handled remotely
3 to 5 hours of waiting time for a 5-minute consultation
Paper registers everywhere — zero digital patient records

We built Afiya because we live this reality every day. Clinics in Yaoundé still write patient names in notebooks. Doctors have no access to a patient's medical history. Families travel hours to see a doctor for a fever.

The infrastructure was never built. We decided to build it — using the tools people already have in their hands.

What We Built

Afiya is a WhatsApp-native telemedicine platform that digitizes the entire patient journey — from booking to medical record — without requiring any new app.

The patient journey:

Patient receives a WhatsApp message and opens the Afiya Flow
Selects a partner clinic and available doctor (real-time availability)
Completes a pre-consultation form (personal info, symptoms, metrics)
Pays via Mobile Money (MTN or Orange) — directly in WhatsApp
Consults with the doctor via WhatsApp conversation
AI automatically generates a structured medical record from the conversation
Doctor reviews, validates, and adds diagnosis + prescription on the dashboard

The doctor's dashboard (deployed on Vercel):

Real-time patient queue
Full patient profile with pre-consultation data
AI-generated consultation summary
Editable medical record (diagnosis, treatment, prescription, orientation)
Consultation history per patient
Availability toggle (visible to patients in real-time)
Analytics: consultations per day, top symptoms, revenue, doctor performance

How We Built It

Stack

Layer	Technology
Patient interface	WhatsApp Flows (Meta)
Backend	FastAPI (Python)
Database	AWS DynamoDB
Frontend dashboard	Next.js deployed on Vercel
Payment	MTN Mobile Money + Orange Money
AI Summary	LLM API for conversation analysis

Why AWS DynamoDB

We chose DynamoDB as our primary database for three specific reasons:

1. Flexible schema for medical data Each patient consultation contains different data — symptoms vary, conversation lengths differ, some patients have rich medical histories while others are first-time users. DynamoDB's document model lets us store all of this — chat logs, AI summaries, medical records, consultation history — as nested objects in a single item, without complex JOINs or schema migrations.

2. Partition key design for real-time queues We use clinique_id as the partition key and consultation_id as the sort key. This means querying "all patients at Clinique Centrale today" is a single, instantaneous DynamoDB query — no table scans, no aggregations.

3. Scale without configuration If Afiya grows from 10 clinics to 500 clinics, DynamoDB scales automatically. No re-architecture needed.

Data Model

Each consultation is stored as a single DynamoDB item:

{
  "clinique_id": "clinique_1",        // Partition Key
  "consultation_id": "AF-2026-001",   // Sort Key
  "nom": "KAMGA Jean",
  "motif": "Fièvre depuis 3 jours",
  "statut_consultation": "terminee",
  "chat_log": [...],                  // Full conversation
  "ai_summary": {                     // AI-generated
    "symptoms": [...],
    "risk_level": "MEDIUM"
  },
  "dossier_medical": {                // Doctor-filled
    "diagnostic": "Paludisme suspecté",
    "traitement": "...",
    "orientation": "hopital"
  },
  "historique": [...]                 // Past consultations
}

WhatsApp Flows

We built a 4-screen WhatsApp Flow:

Screen 1: Partner clinic selection
Screen 2: Doctor selection with real-time availability
Screen 3: Personal info + symptom description + biometrics
Screen 4: Recap + Mobile Money payment

When the patient submits, Meta sends the complete payload to our FastAPI webhook, which creates the DynamoDB record and triggers the Mobile Money payment request.

Challenges We Faced

WhatsApp Business verification Meta requires business verification to publish WhatsApp Flows to real users. Without legal registration documents, we couldn't complete verification in time. We worked around this using the Meta Developer sandbox with test numbers for our demo.

DynamoDB schema design Choosing between multiple tables vs. single-table design was a key architectural decision. We opted for a single-table approach with nested objects to minimize read operations and keep the patient record self-contained.

Real-time dashboard updates Getting the doctor's dashboard to reflect new patients instantly required implementing polling on the /patients/today/{clinique_id} endpoint every 30 seconds, with optimistic UI updates when the doctor changes their availability status.

AI summary generation Structuring the prompt for the LLM to extract medical information reliably from informal WhatsApp conversations required multiple iterations to get consistent, structured JSON output.

What We Learned

WhatsApp Flows are incredibly powerful for markets where app adoption is low but WhatsApp penetration is near-universal
DynamoDB's single-table design requires upfront thinking but pays off in query simplicity and cost
Vercel's deployment pipeline made frontend iteration extremely fast — pushing updates took seconds
The real challenge in African healthtech is not the technology — it's distribution and trust