Global Health AI Exercises

Applied exercises for context, equity, capacity, data governance, and One Health AI decisions. The material is maintained separately so each operational question has a stable, focused reference.

Learning Objectives
  • Identify the evidence and controls relevant to this decision area
  • Distinguish technical performance from operational and population impact
  • Apply the included framework without extending claims beyond the cited evidence

Use explicit targets, populations, thresholds, and decision consequences. Require external evidence and local monitoring where deployment can affect people or programs. Preserve uncertainty and document limits.

Introduction

This focused reference is part of the broader Global Health AI Exercises overview. It preserves the detailed methods, examples, and exercises while reducing page size and improving direct navigation.

Check Your Understanding

Test your knowledge of global health AI equity and how to design AI systems that work for all populations. Each question addresses critical concepts from this chapter.

Question 1

A health NGO wants to deploy an AI diagnostic system in rural sub-Saharan Africa where electricity is available only 6 hours per day, internet connectivity is intermittent (2-3 hours daily), and there are no trained data scientists locally. Which deployment approach would be MOST sustainable and effective?

  1. Cloud-based AI requiring continuous internet, with remote technical support from the NGO’s headquarters in a high-income country
  2. Edge AI with offline-capable models on battery-powered tablets, local SQLite database, opportunistic syncing, and training local health workers to operate the system
  3. Paper-based system with periodic data entry and batch cloud processing when connectivity is available
  4. Wait to deploy until infrastructure improves (reliable electricity and internet) to ensure optimal system performance

Correct Answer: b) Edge AI with offline-capable models on battery-powered tablets, local SQLite database, opportunistic syncing, and training local health workers to operate the system

This question tests understanding of context-appropriate AI design for resource-limited settings, a central theme throughout the chapter’s discussion of the global digital divide and successful implementations.

The Chapter’s Context-Appropriate Design Principles:

Section “Context-Appropriate AI Design” establishes clear principles for resource-limited settings:

1. Offline-First Design: The chapter provides a complete OfflineAISystem implementation showing exactly this approach: - Local model inference (no internet required) - SQLite database for local storage - Opportunistic sync when connectivity available - Graceful failure handling

2. Low-Power Design: The chapter’s LowPowerOptimizer demonstrates: - Quantized models (4x smaller, 3-4x faster, minimal accuracy loss) - Battery-powered operation - Minimal power consumption

3. Human Capacity: The chapter emphasizes building local capacity rather than external dependence.

Why Option B is Correct:

Addresses all infrastructure constraints:

Electricity (6 hours/day): - Battery-powered tablets can operate during non-electricity hours - Charging during 6-hour electricity window sufficient for 18+ hours operation - Low-power quantized models extend battery life

Internet (intermittent 2-3 hours/day): - Edge AI runs entirely offline, no internet needed for diagnosis - Opportunistic sync uploads results when connectivity available - System continues functioning if sync fails (will retry later)

No local data scientists: - Training local health workers to operate (not develop) the system is feasible - Chapter’s case studies show nurses operating AI diagnostics after 1-day training - No ongoing technical expertise required for daily operation

Real-World Validation:

The chapter provides three case studies demonstrating exactly this approach:

Case Study 1: Diabetic Retinopathy Screening (India): - Offline operation - Low-cost portable hardware - Nurses operate after 1-day training - Immediate results (30 seconds) - Result: 300,000+ patients screened, 10x cost reduction

Case Study 2: TB Screening (Sub-Saharan Africa): - Portable X-ray + tablet - Battery-powered (8 hours) - Quantized model (25 MB) - Result: 250,000+ X-rays, 120 sites, 5 countries

Case Study 3: Malaria Detection (Southeast Asia): - Smartphone-based microscopy - Offline AI analysis - $50 microscope attachment - Result: 95% accuracy matching expert microscopists

All three successfully deployed in settings with exactly the constraints described (intermittent electricity/connectivity, limited local expertise).

Why Other Options Fail:

Option (a), Cloud-based system:

This violates the chapter’s core principles and would fail in the described setting:

  1. Continuous internet requirement: With only 2-3 hours daily connectivity, the system is non-functional 21-22 hours per day. Patients arriving when internet is down cannot be diagnosed.

  2. Power dependency: Cloud systems require powered internet infrastructure (routers, modems). With 6 hours electricity, internet may only work during that window, reducing already limited 2-3 hour availability.

  3. External dependence: “Remote technical support from headquarters” creates unsustainable dependency. The chapter warns against this in the “Paradox of Need” callout: “Dependence on external solutions → Not context-appropriate → Poor outcomes → Distrust.”

  4. Latency: Even when internet is available, cloud API calls in low-bandwidth settings may take 10-30 seconds per diagnosis vs. <1 second for edge AI.

  5. Cost: Cloud API fees accumulate with scale. Chapter emphasizes $0 marginal cost after edge AI deployment vs. ongoing cloud costs.

Option (c), Paper + batch processing:

This is a half-measure that misses AI’s value proposition:

  1. Delays: Batch processing means results only available after next connectivity window, potentially 24-48 hour delays. For acute conditions, this defeats the purpose.

  2. Data entry bottleneck: Manual paper→digital transcription is labor-intensive and error-prone. Chapter emphasizes this challenge in the “Data Infrastructure Divide” section.

  3. Limited benefit: If you’re doing paper anyway, the AI adds minimal value compared to standard clinical protocols. The chapter emphasizes AI’s value is real-time decision support at point of care.

  4. Scalability: Paper systems don’t scale. The chapter’s case studies succeeded because they eliminated paper bottlenecks.

Option (d), Wait for infrastructure:

This is explicitly rejected throughout the chapter:

The chapter’s introduction states: “AI could have the greatest impact in precisely these settings” (resource-limited LMICs). Waiting means:

  1. Opportunity cost: Patients who could benefit from AI diagnostics today continue suffering or dying while waiting for infrastructure that may never arrive (or take decades).

  2. No agency: Waiting for external infrastructure improvements means no local control over timeline.

  3. Contradicts chapter’s message: The entire chapter is about designing AI that works despite infrastructure limitations, not waiting for ideal conditions.

  4. Perpetuates inequity: The “wait for infrastructure” mentality ensures AI benefits only wealthy, connected populations, precisely the inequity the chapter aims to prevent.

The chapter’s conclusion emphasizes: “Infrastructure is foundational - No amount of sophisticated AI can overcome lack of electricity, internet, or digital health systems.” But this means design for constraints, not wait for ideal infrastructure.

The Design for Constraints Philosophy:

The chapter’s key message (appearing multiple times):

“Context-appropriateness beats sophistication” - Simple offline system with local ownership outperforms sophisticated cloud system requiring continuous connectivity.

Option B embodies this philosophy. Option A pursues sophistication at the expense of context-appropriateness. Options C and D don’t fully use AI’s potential.

Implementation Path for Option B:

Phase 1: Setup (Weeks 1-4) - Procure battery-powered tablets ($200-500 each) - Load quantized diagnostic models (pre-trained, validated) - Set up local SQLite databases - Establish sync endpoint (when connectivity available)

Phase 2: Training (Week 5) - 1-week training for local health workers - Focus on: image capture, quality assessment, result interpretation - No advanced technical skills required

Phase 3: Deployment (Week 6+) - Begin seeing patients - Models run offline, store results locally - Periodic syncing uploads to central database for surveillance

Sustainability: - No ongoing internet costs - No ongoing technical support dependency (basic troubleshooting trainable) - Local ownership and operation

The Chapter’s Framework:

This aligns with the chapter’s preparation checklist: - Offline-first design - Low-power operation - Local capacity building - Sustainability planning - Context-appropriate technology

For practitioners:

The chapter’s “Paradox of Need” explains why settings with greatest potential AI impact often have least capacity. Breaking this cycle requires: 1. Designing for constraints (not ideal conditions) 2. Building local capacity (not external dependency) 3. Prioritizing sustainability (not short-term pilots)

Option B achieves all three. It’s proven at scale (case studies), technically feasible (chapter provides implementation), and sustainable (local ownership, minimal ongoing costs).

The global health AI equity challenge isn’t primarily technical. It’s about appropriate design for context. Option B represents context-appropriate AI; the alternatives don’t.

Question 2

An AI sepsis prediction model trained primarily on data from US and European hospitals is being considered for deployment in a low-income country. Initial testing reveals 91% accuracy on US patients but only 78% accuracy on the local population. What is the MOST likely primary cause of this performance disparity, and what’s the appropriate response?

  1. The local population has genetic differences requiring a completely separate model from scratch
  2. The model suffers from dataset shift, training data doesn’t represent local patient characteristics (disease prevalence, comorbidities, healthcare practices), requiring diverse training data and possibly local fine-tuning
  3. The local healthcare workers are less skilled at data entry, creating noisy input data
  4. The 78% accuracy is actually acceptable given resource constraints; deploy as-is since some AI is better than no AI

Correct Answer: b) The model suffers from dataset shift, training data doesn’t represent local patient characteristics (disease prevalence, comorbidities, healthcare practices), requiring diverse training data and possibly local fine-tuning

This question tests understanding of algorithmic fairness, the importance of diverse training data, and how to address performance disparities across populations, key themes in the chapter’s “Algorithmic Fairness Across Populations” section.

The Chapter’s Evidence:

Performance Disparity Example (from chapter):

The chapter provides a nearly identical scenario in the FairnessAuditor example:

Overall Accuracy: 87.3%
--- Performance by COUNTRY ---
[OK] USA: 91.2% (disparity: +3.9%)
[WARNING] Kenya: 78.5% (disparity: -8.8%)
[WARNING] India: 80.1% (disparity: -7.2%)

[WARNING] Large performance disparity detected (>10%)

This is exactly the scenario in the question: high-income country model (91%) vs. LMIC performance (78%), with a 13-point disparity.

Root Cause: Dataset Shift

The chapter explicitly addresses this in “Strategies to Improve Fairness”:

Problem: “Models trained only on high-income country data perform poorly elsewhere.”

Why this happens:

1. Different disease prevalence: - High-income countries: More chronic diseases (diabetes, heart disease) - LMICs: More infectious diseases (TB, malaria, HIV) as comorbidities - Sepsis presentation differs with underlying conditions

2. Different patient populations: - Age distributions differ (LMICs have younger populations) - Nutritional status affects immune response and sepsis progression - Genetic diversity not captured in US/European datasets

3. Different healthcare practices: - US/Europe: Early ICU admission, aggressive interventions - LMICs: Later presentation (patients seek care later), fewer ICU beds - Different baseline vital signs cutoffs may apply

4. Different data characteristics: - US/Europe: Complete EHR data, frequent lab tests - LMICs: Sparse data, paper records, missing values common - Features available for prediction differ

5. Measurement differences: - Equipment calibration variations - Different lab reference ranges - Environmental factors (altitude affects oxygen saturation, temperature norms vary)

The Solution (from chapter):

The chapter provides three specific strategies:

Strategy 1: Diverse Training Data (Section “Diverse Training Data”):

The DiverseDatasetBuilder class shows: - Assess dataset diversity across dimensions (country, income level, ethnicity) - Balance dataset to ensure fair representation - Create stratified splits preserving diversity

The chapter emphasizes: “Include diverse training data from multiple populations.”

Strategy 2: Fairness-Aware Training (Section “Fairness-Aware Training”):

The FairML class demonstrates: - Training with fairness constraints (demographic parity, equalized odds) - Ensures model performs equitably across populations - Uses Fairlearn library for constrained optimization

Strategy 3: Local Fine-Tuning (Section “Local Fine-Tuning”):

The LocalFineTuner class shows: - Start with global model (retains general knowledge) - Fine-tune on local data (adapts to local context) - Transfer learning approach

Why this is correct:

The 13-point accuracy gap (91% vs. 78%) indicates the model learned patterns specific to US/European populations that don’t generalize. This is dataset shift, the classic machine learning problem when training and deployment distributions differ.

Why Other Options Are Wrong:

Option (a), Genetic differences requiring separate model:

This is scientifically incorrect and potentially harmful:

  1. Overstates genetic differences: While genetic variation exists, population genetic differences are typically small and continuous, not categorical. Sepsis is primarily driven by infection and immune response, not population genetics.

  2. Ignores environmental/social factors: The chapter emphasizes healthcare access, disease prevalence, and treatment practices vary more than genetics. Option B captures these factors; option A doesn’t.

  3. Inefficient: Starting from scratch discards valuable learned patterns (sepsis presentation, organ dysfunction progression). Transfer learning (option B’s fine-tuning) is more data-efficient.

  4. Data requirements: Training from scratch requires massive labeled datasets (thousands to tens of thousands of cases). The chapter emphasizes LMICs often lack this data volume. Fine-tuning needs far less local data (hundreds to thousands).

  5. Perpetuates bias: Treating populations as fundamentally different can reinforce biological essentialism and excuse algorithmic bias rather than addressing its root causes (training data limitations).

Option (c), Data entry quality:

This victim-blames local healthcare workers and misdiagnoses the problem:

  1. Assumption unfounded: The question provides no evidence of data quality issues. This option assumes without justification that LMIC healthcare workers are less competent.

  2. Misses root cause: Even with perfect data entry, a model trained on US patterns won’t generalize to different disease prevalence, patient populations, and healthcare contexts.

  3. Offensive and incorrect: The chapter’s case studies show successful AI deployments with local healthcare workers operating systems. The chapter emphasizes capacity building, not capability deficits.

  4. Technical flaw: Modern ML models (especially deep learning) are generally robust to moderate noise. A 13-point accuracy drop is far too large to attribute to data entry noise alone.

If data quality were the issue, the solution would be data validation and cleaning, not what the chapter recommends (diverse training data, fairness-aware training, local fine-tuning).

Option (d), Deploy despite poor performance:

This is ethically and practically unacceptable:

  1. Violates equity principle: The chapter’s core message is AI should work for all populations, not just the privileged. Accepting lower performance for LMICs perpetuates health inequities.

  2. Patient safety: 78% accuracy means 22% error rate. For sepsis (high mortality, time-sensitive), errors cost lives. “Some AI is better than no AI” is false when AI provides incorrect guidance.

  3. Erodes trust: Deploying underperforming AI damages trust in technology and healthcare system. The chapter’s “Paradox of Need” warns poor outcomes lead to distrust, reducing future technology adoption.

  4. Violates responsible AI: The chapter references WHO’s “Ethics and Governance of AI for Health” framework, which requires AI to be “effective for intended use.” 78% vs. 91% fails this standard.

  5. Contradicts chapter’s framework: The chapter’s fairness auditing section explicitly flags >10% disparities as unacceptable, requiring intervention.

The “acceptable given resource constraints” reasoning is precisely the inequity the chapter argues against.

The Appropriate Response (from Chapter):

Step 1: Fairness Audit

auditor = FairnessAuditor()
results = auditor.audit_model_fairness(model, local_test_data, ['country'])

Step 2: Root Cause Analysis - Examine where model fails (which patient subgroups, which features) - Identify dataset shift characteristics - Quantify disparity magnitude

Step 3: Mitigation - Collect local data: Even 500-1000 local cases can enable effective fine-tuning - Fine-tune model: Transfer learning retains general knowledge while adapting to local context - Retrain with diverse data: Include local data in global model training for future versions - Adjust thresholds: Post-processing fairness methods can equalize performance across populations

Step 4: Validation - Test fine-tuned model on held-out local data - Ensure performance gap narrows (ideally <5%) - Validate with local clinicians before deployment

Real-World Precedent:

The chapter’s Case Study 1 (Diabetic Retinopathy Screening) and Case Study 2 (TB Screening) both involved local adaptation: - Models developed with diverse international data - Fine-tuned for specific deployment contexts - Validated locally before rollout - Result: Performance comparable to expert human interpretation

The Chapter’s Framework for Fairness:

From the conclusion: “Algorithmic fairness requires active work: - Diverse training data from multiple populations - Fairness-aware training with constraints - Regular auditing across demographic groups - Local fine-tuning for specific contexts”

Option B embodies this framework. Options A, C, and D don’t.

For practitioners:

Performance disparities across populations are a warning sign of algorithmic unfairness, not an inevitability. The chapter provides the technical tools (fairness auditing, diverse datasets, fairness-aware training, local fine-tuning) to address these disparities.

The global health AI equity imperative requires rejecting “good enough for poor countries” mentality. AI should work equitably for all populations, and the chapter shows how to achieve this.

Question 3

A research team from a high-income country wants to collect health data from multiple hospitals in a low-income country to train an AI model. They propose collecting de-identified data, training the model at their university, publishing in high-impact journals, and potentially commercializing the technology. How should this collaboration be structured to avoid data colonialism and ensure equity?

  1. Proceed as proposed, de-identification protects privacy and publication advances science for everyone’s benefit
  2. Establish a partnership with data sovereignty (local institution retains data control), co-authorship, IP sharing, capacity building (training local researchers), and benefit sharing arrangements
  3. Pay a one-time fee to the hospitals for data access to compensate them for their contribution
  4. Have local researchers sign consent forms acknowledging the high-income institution’s ownership of resulting IP

Correct Answer: b) Establish a partnership with data sovereignty (local institution retains data control), co-authorship, IP sharing, capacity building (training local researchers), and benefit sharing arrangements

This question tests understanding of equitable data governance, avoiding data colonialism, and building genuine partnerships, critical themes in the chapter’s “Data Governance for Equity” and “Building Local Capacity” sections.

The Chapter’s Data Governance Framework:

The chapter dedicates an entire section to “Data Governance for Equity” with clear principles:

1. Data Sovereignty: “Data sovereignty ensures that the institution or country where data originates retains control over how it’s used, shared, and governed.”

Key quote: “Data stays at source location, external researchers access via federated learning or approved analysis pipelines.”

2. Benefit Sharing: The chapter outlines specific mechanisms: - Research benefit sharing: Co-authorship on publications, joint grant applications - Intellectual property sharing: Shared patents, licensing agreements - Revenue sharing: Percentage of commercialization revenue returned to data-providing countries - Capacity building: Training, infrastructure investment, knowledge transfer

3. Equitable Partnerships: The chapter contrasts exploitative vs. equitable models:

Extractive (Data Colonialism): - External researchers collect data - Analysis happens externally - Publications list external authors only - IP owned by external institution - No benefit to data source

Equitable: - Local partners involved from design stage - Shared governance - Co-authorship - IP sharing - Capacity building - Long-term commitment

Why Option B is Correct:

Option B implements ALL of the chapter’s recommended principles:

Data Sovereignty: - “Local institution retains data control” ensures data stays under local governance - Can use federated learning (covered in Emerging Technologies) to train collaboratively without data leaving the country - Local IRB oversight and approval required - Locals decide what research questions are priorities

Co-Authorship: - Recognizes local contribution to research - Ensures local researchers gain publication track record - Builds local academic capacity - Chapter explicitly lists this under “Research Benefit Sharing”

IP Sharing: - Local institution has ownership stake in resulting technology - Ensures commercialization benefits local populations - Can negotiate licensing terms favorable to low-income country access - Chapter lists “Shared patents, licensing agreements” as equitable practice

Capacity Building: - “Training local researchers” breaks the dependency cycle - Chapter’s capacity building section describes training progression: - Awareness → Literacy → Application → Development → Research - Creates sustainable local AI capability - Aligns with chapter’s emphasis on “Build sustainable local capacity”

Benefit Sharing: - Ensures local population benefits from their data contribution - Can include revenue sharing from commercialization - Addresses the chapter’s concern about “Data extraction without benefit”

Real-World Validation:

The chapter cites the H3Africa (Human Heredity and Health in Africa) initiative as a model: - African scientists as co-PIs - Data governance by African institutions - Genomic data stays in Africa - Capacity building (training, infrastructure) - Benefit sharing agreements

Why Other Options Are Wrong:

Option (a), Proceed as proposed (extractive model):

This is textbook data colonialism that the chapter explicitly warns against:

Problems:

  1. No data sovereignty: Data collected and removed to high-income country. Local institution loses control over how their population’s data is used.

  2. No recognition: Publications listing only high-income researchers ignores local contribution. This perpetuates global health research inequities.

  3. No benefit sharing: Technology commercialized abroad, profits accrue to high-income institution. Local population whose data enabled the technology receives no benefit.

  4. No capacity building: No knowledge transfer to local researchers. Perpetuates dependence and “brain drain” (local researchers must go abroad to do cutting-edge work).

  5. Violates ethics: The chapter references WHO’s ethics framework, which requires “fair distribution of benefits and burdens.”

  6. De-identification insufficient: The chapter (and the Privacy chapter) explain de-identification doesn’t address exploitation, only privacy. Data colonialism can occur even with de-identified data.

The chapter explicitly states: “Avoid extractive research models that collect data from LMICs for analysis in high-income countries without benefit sharing or capacity building.”

Option A is precisely this extractive model.

Option (c), One-time fee:

This treats data as a commodity for purchase rather than a partnership:

Problems:

  1. Transactional, not collaborative: One-time payment doesn’t create ongoing partnership. Chapter emphasizes “long-term relationships, not one-off projects.”

  2. No capacity building: Money doesn’t build local AI capability. The chapter’s framework prioritizes knowledge transfer, not financial transactions.

  3. Undervalues data: Health data enables potentially valuable technology (diagnostics, drugs). One-time fee is typically far less than commercialization value. This is exploitation.

  4. No data sovereignty: Payment doesn’t ensure local control over data use. External researchers still take data and use however they want.

  5. Perpetuates inequity: Wealthy institutions can afford to buy data from poor countries, concentrating AI capabilities in high-income settings. This widens the AI divide the chapter aims to close.

  6. Ethical concerns: Paying hospitals for patient data raises questions about patient consent and whether hospitals should profit from patient information.

The chapter never suggests financial compensation as an equitable solution. It emphasizes partnership, not purchase.

Option (d), Consent to external IP ownership:

This is exploitative with a veneer of consent:

Problems:

  1. Coercive: Local researchers may feel pressured to sign to access collaboration opportunities. This isn’t genuine consent in unequal power dynamics.

  2. Violates benefit sharing: Explicitly gives all IP to external institution, ensuring locals receive no commercialization benefits.

  3. No true partnership: Treating locals as data providers who must “consent” to external ownership is hierarchical, not collaborative.

  4. Perpetuates inequity: Ensures technology and profits flow to already-wealthy institutions. The chapter’s equity framework rejects this.

  5. Unethical: The chapter’s framework requires “fair distribution of benefits.” Consenting to unfair distribution doesn’t make it fair.

The chapter states: “Avoid extractive agreements where LMIC partners provide data but receive limited benefits.”

Option D is an extractive agreement with legal cover.

The Chapter’s Recommended Approach:

Partnership Checklist (from chapter):

Joint problem definition: What health challenges do local partners prioritize? Shared governance: Decision-making authority for both parties Data sovereignty: Data stays under local control Co-authorship: Local researchers as co-authors, not just acknowledged IP sharing: Shared ownership of resulting technology Capacity building: Training, infrastructure investment, knowledge transfer Benefit sharing: Revenue sharing if commercialized Long-term commitment: Ongoing relationship, not one-off project Local deployment: Ensure resulting technology is accessible to data-providing community

Implementation Example:

Phase 1: Partnership Formation - Joint research proposal with local institution as co-PI - Data governance agreement (data stays local or federated learning) - MOU specifying co-authorship, IP sharing, benefit sharing - IRB approval from both institutions

Phase 2: Capacity Building - Train local researchers in AI/ML methods - Provide access to computational resources - Joint supervision of graduate students

Phase 3: Research Execution - Collaborative model development (federated learning if data can’t leave country) - Local researchers involved in all analysis stages - Regular joint meetings and knowledge exchange

Phase 4: Dissemination - Co-authored publications (local researchers as co-first/co-senior authors) - Joint conference presentations - IP jointly owned by both institutions

Phase 5: Deployment and Benefit Sharing - Technology deployed first in data-providing country - If commercialized: revenue sharing agreement (e.g., 50/50 split) - Licensing terms ensure affordable access in LMICs - Continued capacity building and support

The Chapter’s Broader Context:

This aligns with the chapter’s conclusion: “Data governance prevents exploitation: - Data sovereignty - Source retains control - Benefit sharing - Co-authorship, IP sharing, revenue sharing - Equitable partnerships - Avoid data colonialism - Capacity building - Knowledge transfer, not extraction”

For practitioners:

International health data collaborations must be genuinely equitable, not extractive. The chapter provides a clear framework distinguishing the two.

Key principles: - If only the high-income partner benefits → Exploitation - If both partners share governance, credit, IP, and benefits → Equity

Option B embodies equity; the alternatives are varying degrees of exploitation.

The global health AI divide will only be bridged through equitable partnerships that build local capacity and ensure fair benefit sharing. Data colonialism, even when legal and technically sophisticated, perpetuates the inequities the chapter aims to address.

Question 4

A mobile health app using AI is being deployed in a multilingual low-income country with diverse ethnic groups, varying health literacy levels, and strong cultural norms around family decision-making (especially for women’s health). What is the MOST important design consideration to ensure the app is culturally appropriate and effective?

  1. Translate the English interface to the dominant local language and deploy uniformly across the country
  2. Design with cultural localization: support multiple languages, use local disease terminology, respect cultural norms (family involvement, traditional medicine integration), and adjust health communication to local literacy levels
  3. Use only visual icons and images to bypass language barriers entirely
  4. Deploy in English since it’s widely understood by educated populations who are most likely to use mobile apps

Correct Answer: b) Design with cultural localization: support multiple languages, use local disease terminology, respect cultural norms (family involvement, traditional medicine integration), and adjust health communication to local literacy levels

This question tests understanding of cultural localization, linguistic diversity, and human-centered design for global health AI, key themes in the chapter’s “Cultural and Linguistic Considerations” section.

The Chapter’s Localization Framework:

The chapter provides a complete LocalizedHealthAI implementation demonstrating exactly this approach.

The “Localization Checklist” (from chapter):

Language: Support local languages, not just English Terminology: Use local disease names and terms Cultural norms: Respect gender roles, family decision-making Traditional medicine: Acknowledge and integrate where appropriate Religious considerations: Respect dietary restrictions, prayer times Health literacy: Adjust communication complexity to education level

Why Option B is Correct:

Option B implements ALL elements of the chapter’s localization checklist:

1. Multiple Language Support:

The chapter’s example shows: - Different regions use different languages (Swahili in East Africa, French in West Africa, etc.) - Multilingual models (XLM-RoBERTa, mBERT, IndicBERT) - Translation to/from English for processing, with local language interface

Example from chapter:

system = LocalizedHealthAI(language='sw', region='east-africa')
# User reports symptoms in Swahili
symptoms_swahili = "Nina homa kali na kichwa kinaniuma"
# System processes and responds in Swahili

Why this matters: The chapter’s digital divide data shows language barriers affect healthcare access. English-only systems exclude non-English speakers.

2. Local Disease Terminology:

The chapter provides specific examples: - “Malaria” → “Homa” (Swahili), “Paludisme” (French), “Malária” (Portuguese) - “Tuberculosis” → “Kifua kikuu” (Swahili), “TB” (Global)

Why this matters: Patients describe symptoms using local terms. AI must understand these to function effectively.

3. Cultural Norms (Family Decision-Making):

The chapter’s cultural guidelines explicitly address this:

cultural_guidelines = {
 'south-asia': {
  'gender_sensitivity': 'high', # May need male family member involvement
 }
}

The generated recommendation includes: “Please discuss this with your family before making treatment decisions.”

Why this matters: In many cultures, health decisions (especially for women) involve family members. An app that ignores this is culturally inappropriate and ineffective. Users won’t follow recommendations that violate cultural norms.

4. Traditional Medicine Integration:

The chapter’s example shows:

if cultural_guidance['traditional_medicine'] == 'integrate':
 recommendation += "This recommendation can complement traditional treatments. Consult both your healthcare provider and traditional healer."

Why this matters: Many populations use both traditional and modern medicine. Acknowledging this builds trust and adherence. Dismissing traditional medicine alienates users.

5. Health Literacy Adjustment:

The checklist includes: “Adjust communication complexity to education level.”

Why this matters: Technical medical language excludes low-literacy populations. The app must communicate in accessible terms.

Real-World Validation:

Case Study 1: Retinopathy Screening (India) - Recommendations in Hindi/English bilingual format - Visual severity scale for low-literacy users - Result: Accessible to diverse populations

Case Study 2: TB Screening (Africa) - Multiple language support across deployment sites - Culturally appropriate explanations - Result: High acceptance across diverse communities

Why Other Options Are Wrong:

Option (a), Single dominant language:

This assumes linguistic homogeneity that doesn’t exist:

Problems:

  1. Ignores multilingualism: Most low-income countries have multiple languages. India has 22 official languages, Nigeria has 500+, Kenya has 68. A “dominant language” may be spoken by only 30-40% of population.

  2. Excludes minorities: Minority language speakers (often marginalized populations) are excluded. This perpetuates health inequities.

  3. Misses cultural nuances: Translation alone doesn’t address cultural norms, disease terminology, traditional medicine integration, or literacy levels. The chapter shows these are equally important.

  4. Uniform deployment fails: The chapter emphasizes context-appropriate design. Different regions have different needs; uniform deployment ignores this.

Option (c), Icons/images only:

This oversimplifies and has serious limitations:

Problems:

  1. Limited expressiveness: Medical concepts (symptoms, diagnoses, recommendations) are complex. Icons can’t convey nuanced information like “take medication with food” or “seek care if symptoms worsen.”

  2. Cultural interpretation varies: Symbols have different meanings across cultures. A thumbs-up or checkmark may not be universally understood as positive. Color symbolism varies (white is mourning in some cultures, purity in others).

  3. Patronizing: Assuming users can’t handle text (with appropriate literacy-level adjustment) is condescending and disempowering.

  4. Medical accuracy: Icons are imprecise. “Fever” might be represented by a thermometer, but doesn’t convey severity. Misinterpretation can lead to clinical errors.

  5. Ignores cultural norms: Icons don’t address family decision-making norms, traditional medicine, religious considerations. These require text explanations.

The chapter never suggests icon-only approaches. All case studies use text (in local languages) with icons as supplements, not replacements.

Option (d), English for educated users:

This is elitist and excludes most of the target population:

Problems:

  1. Excludes majority: Even in countries where English is an official language, fluency is often limited to urban, educated elites. Rural and low-income populations (who need healthcare AI most) typically speak local languages.

  2. Contradicts equity mission: The chapter emphasizes AI should serve those most in need, not just the privileged. English-only systems serve those with education access, perpetuating inequities.

  3. Reduces effectiveness: Even for English speakers, health communication is more effective in first language. Stress and illness reduce ability to process second language.

  4. Cultural inappropriateness: English explanations may not align with local cultural norms, disease concepts, or traditional medicine.

  5. Violates accessibility principles: The chapter’s framework requires AI to “work for all populations.” English-only fails this standard.

  6. Empirically wrong: The chapter’s case studies succeeded precisely because they didn’t assume English. The malaria app worked in rural Southeast Asia, TB screening in rural Africa, populations with limited English.

The Chapter’s Broader Framework:

This question aligns with multiple chapter themes:

1. Context-Appropriate Design: “Effective AI in LMICs requires designing for constraints, not assuming ideal conditions.”

English-only, single-language, or icon-only approaches assume ideal conditions (linguistic homogeneity or universal icon comprehension). Option B designs for real-world constraints (multilingual, multicultural populations).

2. Equity: “Global health AI should benefit those who need it most. If AI only works for the wealthy and connected, we have failed.”

English-only and single dominant language approaches work for urban, educated populations. Option B works for everyone, including marginalized language minorities.

3. Local Ownership: Cultural localization requires local input, what terminology do locals use? What cultural norms matter? This builds local ownership and sustainability.

Implementation Considerations:

Full Localization (Option B):

Languages: - Identify languages spoken in deployment area (survey or census data) - Prioritize by speaker population - Use multilingual models (XLM-RoBERTa) or translation services

Terminology: - Work with local health workers to map local disease terms - Build terminology dictionaries - Validate with community input

Cultural Norms: - Consult local cultural experts and community leaders - Identify relevant norms (gender, family, religion, traditional medicine) - Incorporate into system logic and recommendations

Literacy: - Assess target population literacy levels - Adjust language complexity (Flesch-Kincaid grade level) - Use audio for very low literacy - Supplement text with images (not replace)

Testing: - Usability testing with diverse user groups (languages, cultures, literacy levels) - Iterate based on feedback - Validate cultural appropriateness

The Chapter’s Key Message:

From the conclusion: “Context-appropriateness beats sophistication - Simple SMS-based system with local ownership often outperforms sophisticated cloud system requiring continuous connectivity.”

Applied to this question: Culturally localized system with appropriate language/cultural support outperforms technically sophisticated English-only system.

For practitioners:

Global health AI cannot be “one size fits all.” The chapter demonstrates that effective, equitable AI requires deep cultural localization: - Multiple languages (not just English or dominant language) - Local terminology (not just translation) - Cultural respect (family norms, traditional medicine, religion) - Appropriate literacy level (accessible to target population)

Option B embodies this complete approach. The alternatives take shortcuts that reduce accessibility and effectiveness.

The global health AI divide is partly technical, but also cultural and linguistic. Option B addresses all three dimensions; the alternatives address at most one.

Question 5

A health ministry in a low-middle income country wants to build local AI capacity rather than depending on external consultants indefinitely. According to the chapter’s capacity building framework, what is the MOST effective long-term strategy?

  1. Send a few promising individuals abroad for PhD training, expecting them to return and lead AI development
  2. Implement a complete multi-year program with staged training (awareness → literacy → application → development → research), infrastructure investment, partnerships with universities, retention strategies, and knowledge sharing networks
  3. Hire expensive international consultants to run AI projects, with local staff observing to learn on the job
  4. Purchase commercial AI software with vendor support rather than building in-house capacity

Correct Answer: b) Implement a complete multi-year program with staged training (awareness → literacy → application → development → research), infrastructure investment, partnerships with universities, retention strategies, and knowledge sharing networks

This question tests understanding of sustainable capacity building for AI in resource-limited settings, a critical theme in the chapter’s “Building Local Capacity” section and central to breaking the “Paradox of Need” cycle.

The Chapter’s Capacity Building Framework:

The chapter dedicates an entire section to “Building Local Capacity” with a specific, staged training progression:

The Training Progression (from chapter):

  1. Awareness (Weeks): Understanding AI capabilities, limitations, applications
  2. Literacy (Months): Reading research papers, using existing tools
  3. Application (6-12 months): Deploying pre-built models, adapting to local context
  4. Development (1-2 years): Building custom models, fine-tuning, integration
  5. Research (2-5 years): Novel methods, publishing, advancing the field

Why Option B is Correct:

Option B implements ALL elements of the chapter’s complete capacity building framework:

1. Staged Training Progression:

The chapter explicitly outlines the awareness → literacy → application → development → research pathway.

Why this matters: - Sustainable: Builds capability layer by layer - Retention-friendly: Provides career progression locally - Scalable: Each stage creates teachers for the next cohort - Context-appropriate: Focuses initially on application (deploying AI) before research (creating new methods)

Rushing to research (option A) skips critical foundational stages.

2. Infrastructure Investment:

The chapter emphasizes infrastructure as foundational: - “Infrastructure is foundational - No amount of sophisticated AI can overcome lack of electricity, internet, or digital health systems.”

What’s needed: - Computational resources (cloud accounts or local GPUs) - Data infrastructure (EHRs, data quality systems) - Collaboration tools - Internet bandwidth for training/access to resources

Why this matters: Trained people without infrastructure can’t deploy AI. The chapter shows capacity = people + infrastructure + partnerships.

3. Partnerships with Universities:

The chapter recommends: - “Partner with academic institutions” - “Joint supervision of graduate students” - “Collaborative research projects”

Why this matters: - Access to expertise: University partners provide training and mentorship - Sustainability: Local universities can continue training after initial program - Research capacity: Enables local research, not just application - Legitimacy: Academic credentials and publications build credibility

4. Retention Strategies:

The chapter acknowledges the “brain drain” challenge: - “Risk: Trained individuals leave for better opportunities elsewhere”

Mitigation strategies (from chapter): - Competitive salaries and career advancement - Interesting, impactful work - Recognition (publications, presentations) - Community and collaboration - Clear career pathways

Why this matters: Training without retention wastes investment. Option A (send abroad for PhD) has high brain drain risk.

5. Knowledge Sharing Networks:

The chapter emphasizes: - “Peer-to-peer learning networks” - “Communities of practice” - “Open source contributions”

Why this matters: Isolated individuals struggle. Networks provide support, problem-solving, and continuous learning.

Real-World Validation:

The H3Africa Initiative (cited in chapter): - Multi-year program - Staged training (workshops → degree programs → independent research) - Infrastructure investment (genomics facilities) - University partnerships - Knowledge sharing (annual conferences) - Result: >100 trained scientists, multiple publications, sustained local genomics research capacity

Why Other Options Fail:

Option (a), Send individuals abroad for PhD:

This is the classic “brain drain” approach that has failed repeatedly:

Problems:

  1. High brain drain risk: The chapter acknowledges many trainees don’t return after PhDs abroad. They find better salaries, resources, and career opportunities in high-income countries.

Statistics: Studies show 30-70% of LMIC-born PhDs remain abroad. Even those who return often leave again within 5 years if local conditions don’t support their work.

  1. Isolated individuals: Sending “a few” creates isolated experts without peer support. The chapter emphasizes community and networks.

  2. No infrastructure: Returnees find no computational resources, data, or institutional support to apply their training. Frustration leads to departure.

  3. Doesn’t scale: Training a few individuals (even if retained) doesn’t build national capacity. The chapter’s staged approach trains cohorts who then train others.

  4. Mismatch: PhD training abroad focuses on research (stage 5) before application/development (stages 3-4). This doesn’t meet immediate needs (deploying AI for local health challenges).

  5. Expensive: International PhDs cost $100k-$300k per person. For the same investment, option B could train 50-100 people through application stage.

  6. Long timeline: PhDs take 4-6 years. The chapter’s approach delivers application-level capability in 6-12 months.

The chapter explicitly warns: “Challenge: Brain drain - Trained individuals may leave for opportunities in high-income countries.”

Option (b) addresses this through retention strategies. Option (a) exacerbates it.

Option (c), Observe international consultants:

This creates permanent dependency, not capacity:

Problems:

  1. Passive learning: Observation without hands-on practice doesn’t build competency. The chapter’s staged approach requires active doing at each level.

  2. No knowledge transfer: Consultants often don’t share methodological details (proprietary knowledge). Locals learn what to do, not why or how to do it themselves.

  3. Expensive: International consultants cost $200-$500/day. For multi-year projects, this is millions of dollars, far more than training local staff.

  4. Unsustainable: When consultants leave, projects often collapse. No local capacity remains.

  5. Wrong incentives: Consultants benefit from dependency (more contracts). They lack incentive to transfer knowledge that makes them unnecessary.

  6. Cultural mismatch: External consultants may not understand local context, leading to context-inappropriate solutions (the chapter’s major theme).

The chapter explicitly warns: “Paradox of Need: Limited resources → Limited AI capacity → Dependence on external solutions → Not context-appropriate → Poor outcomes”

Option C perpetuates this dependency cycle. Option B breaks it.

Option (d), Purchase commercial software:

This is outsourcing, not capacity building:

Problems:

  1. No capacity built: Purchasing software doesn’t create local expertise in AI development, adaptation, or deployment.

  2. Vendor lock-in: The chapter warns about “concentration of power” and “vendor lock-in” as risks.

  3. Limited customization: Commercial software is generic, not adapted to local diseases, populations, or workflows. The chapter emphasizes context-appropriateness requires customization.

  4. Ongoing costs: Licensing fees, support contracts, updates. Sustainable capacity requires local ownership, not perpetual payments.

  5. No research capability: Purchasing software doesn’t build research capacity to advance the field or address local challenges.

  6. Black box: Commercial systems are often proprietary black boxes. Locals can’t inspect, validate, or adapt algorithms.

  7. Dependency: If vendor discontinues product or changes pricing, locals are stranded.

The chapter’s framework prioritizes: “Build sustainable local capacity” and “Plan for long-term local ownership.”

Option D achieves neither. It’s appropriate for specific tools but not a capacity building strategy.

The Chapter’s Complete Framework:

Capacity Building Components (from chapter):

1. Training Pipeline: - Awareness workshops (health workers) - Literacy courses (public health practitioners) - Application bootcamps (data analysts) - Development programs (engineers) - Research training (scientists)

2. Infrastructure: - Cloud computing accounts - GPU access (local or cloud) - Data infrastructure (EHRs, quality systems) - Collaboration tools

3. Partnerships: - Local universities (curriculum, degrees) - International universities (mentorship, exchange) - Industry partners (internships, applied projects) - Government support (funding, policy)

4. Retention: - Competitive salaries - Career pathways - Impactful work opportunities - Recognition mechanisms - Community building

5. Knowledge Sharing: - Communities of practice - Regular workshops/conferences - Open source contributions - Internal knowledge bases

6. Sustainability: - Train trainers (stage N teachers stage N-1) - Institutional commitment - Long-term funding - Local leadership

Implementation Timeline:

Year 1: - Awareness training for health ministry (100 people) - Literacy training for data analysts (20 people) - Infrastructure setup (cloud accounts, data systems) - University partnerships established

Year 2: - Application training for first cohort (ready to deploy AI) - Literacy training for second cohort - First AI deployments (using trained cohort) - Development training for advanced learners

Year 3: - Development training for first cohort (building custom models) - Application training for second cohort - Literacy training for third cohort - Research training for most advanced

Year 4-5: - Research capacity online (publishing, innovating) - First cohort trains new cohorts (sustainability) - Local centers of excellence established - Reduced external dependence

The Chapter’s Key Message:

From the conclusion: “Build sustainable local capacity: - Train local data scientists (awareness → literacy → application → development → research) - Invest in local infrastructure - Share code, models, and knowledge - Plan for long-term local ownership”

Option B embodies this complete vision. Options A, C, and D are partial measures that don’t achieve sustainable local capacity.

For practitioners:

The chapter’s message is clear: Capacity building is a marathon, not a sprint. Quick fixes (international consultants, commercial software, sending a few individuals abroad) don’t create sustainable local capability.

Effective capacity building requires: - Multi-year commitment (not one-off workshops) - Staged progression (don’t skip foundational stages) - Infrastructure investment (people need tools) - Retention focus (training without retention wastes resources) - Local leadership (locals design and lead programs)

The global health AI divide won’t be bridged by sending LMIC researchers abroad or hiring consultants. It requires sustained investment in complete local capacity building.

Option B represents this sustainable approach. It’s harder and slower than alternatives, but it’s the only path to genuine, lasting local AI capability.

Question 6

A foundation wants to fund AI for global health projects in LMICs. When evaluating proposals, which project characteristic would be the STRONGEST indicator of likely long-term success and sustainable impact according to the chapter’s framework?

  1. The project uses the most advanced, state-of-the-art AI techniques (deep learning, transformers, etc.)
  2. The project is led by prestigious universities from high-income countries with strong track records
  3. The project has local leadership, addresses a locally-prioritized health problem, includes capacity building and knowledge transfer, and has a sustainability plan for local ownership after external funding ends
  4. The project promises to screen the largest number of patients in the shortest time

Correct Answer: c) The project has local leadership, addresses a locally-prioritized health problem, includes capacity building and knowledge transfer, and has a sustainability plan for local ownership after external funding ends

This question tests understanding of what makes AI projects succeed sustainably in global health contexts, synthesizing themes from throughout the chapter about equity, context-appropriateness, local ownership, and sustainability.

The Chapter’s Success Framework:

The chapter provides multiple case studies and explicit criteria for successful, equitable global health AI. Let’s examine what Option C gets right and why the alternatives fail.

Why Option C Indicates Success:

1. Local Leadership:

The chapter emphasizes throughout that local leadership is critical for success:

From the Data Governance section: “Equitable partnerships require: Local partners involved from design stage, Shared governance, Co-authorship, IP sharing.”

From case studies: - Retinopathy screening (India): “Developed with Aravind Eye Hospitals (local expertise)” - TB screening (Africa): Local health workers operate and maintain

Why this matters: - Context understanding: Local leaders understand local health priorities, cultural context, and implementation realities - Sustainability: Locals have long-term commitment; external partners may leave - Trust: Communities trust local-led initiatives more than external impositions - Capacity building: Local leadership develops local capability

Absence of local leadership is a red flag for: - Potential data colonialism - Context-inappropriate design - Unsustainable external dependency - Limited local buy-in

2. Locally-Prioritized Health Problem:

The chapter warns against external priorities imposed on LMICs:

Partnership checklist includes: “Joint problem definition: What health challenges do local partners prioritize?”

Why this matters: - Relevance: Addresses real needs, not what external funders think is important - Adoption: Healthcare workers prioritize solutions to their pressing problems - Impact: Solves problems locals face daily - Respect: Recognizes local expertise in identifying their own priorities

External-imposed priorities often lead to: - Solutions for problems that aren’t priorities - Low adoption (not addressing urgent needs) - Abandoned after funding ends (no local investment)

3. Capacity Building and Knowledge Transfer:

The chapter makes capacity building central to sustainable impact:

From the conclusion: “Build sustainable local capacity: - Train local data scientists - Invest in local infrastructure - Share code, models, and knowledge - Plan for long-term local ownership”

Why this matters: - Sustainability: Locals can maintain, adapt, and improve after external partners leave - Scalability: Trained locals can lead new projects - Equity: Builds local capability, not dependency - Innovation: Empowered locals can address other health challenges

Absence of capacity building indicates: - Extractive model (use local data, provide no local benefit) - Dependency (requires perpetual external support) - Unsustainability (collapses when funding ends)

4. Sustainability Plan for Local Ownership:

The chapter emphasizes thinking beyond the funding period:

Sustainability questions (from chapter): - Who maintains the system after project ends? - How is it funded long-term? - Are local institutions committed to continuation? - Is infrastructure sustainable (electricity, internet, hardware)?

Why this matters: - Long-term impact: Many pilots succeed then disappear when funding ends - Resource stewardship: Donor funds shouldn’t create temporary solutions - Realistic planning: Forces consideration of long-term costs and feasibility

The chapter critiques “pilot projects that don’t scale” and emphasizes “long-term commitment, not one-off projects.”

The Chapter’s Case Study Success Factors:

All three successful case studies share Option C’s characteristics:

Case Study 1: Retinopathy Screening (India) - Local leadership: Developed with Aravind Eye Hospitals - Local priority: Blindness prevention in diabetic population - Capacity building: Nurses trained to operate - Sustainability: Integrated into existing clinics, scalable business model

Case Study 2: TB Screening (Sub-Saharan Africa) - Local leadership: Deployment led by local health authorities - Local priority: TB is leading cause of death - Capacity building: Health workers trained - Sustainability: Portable equipment, offline operation, low ongoing costs

Case Study 3: Malaria Detection (Southeast Asia) - Local leadership: Local clinics and health workers - Local priority: Malaria is major health burden - Capacity building: Smartphone operation trainable - Sustainability: Low-cost equipment ($50), offline, scalable

Why Other Options Don’t Indicate Success:

Option (a), Most advanced AI techniques:

This confuses technical sophistication with impact:

Problems:

  1. Context-appropriateness matters more: The chapter’s key message: “Context-appropriateness beats sophistication - Simple SMS-based system with local ownership often outperforms sophisticated cloud system.”

  2. Advanced ≠ deployable: State-of-the-art models often require:

  • Large computational resources (expensive, unavailable in LMICs)
  • Extensive training data (may not exist for local populations)
  • Specialized expertise to maintain (brain drain risk)

  1. Overfitting to research: Cutting-edge techniques are often research prototypes, not production-ready systems. The chapter’s successful deployments used proven, reliable methods.

  2. Wrong incentives: Focus on technical novelty incentivizes publishable research over practical impact. The chapter distinguishes research contributions from implementation success.

  3. Missing key factors: Doesn’t address local leadership, capacity building, sustainability, all more important for long-term success than technical sophistication.

The chapter’s case studies used relatively simple techniques (CNNs for image classification, basic ML) but succeeded because they addressed the other factors in Option C.

Option (b), Prestigious high-income country universities:

This is the traditional extractive model the chapter warns against:

Problems:

  1. Not necessarily equitable: Prestige doesn’t ensure equitable partnership. The chapter warns about data colonialism from high-income institutions.

  2. May lack local context understanding: External researchers, even prestigious ones, often don’t understand local health systems, cultural context, or implementation realities.

  3. Brain drain risk: Prestigious external universities may attract local talent away (fellowships, positions).

  4. Doesn’t ensure sustainability: “Strong track record” in high-income settings doesn’t predict success in resource-limited settings with different constraints.

  5. Missing critical factors: Prestige doesn’t indicate local leadership, capacity building, or sustainability planning.

The chapter’s partnership framework emphasizes equity over prestige: Shared governance, co-authorship, IP sharing, capacity building. A prestigious external university CAN be a good partner, but only if the partnership is equitable (local co-leadership, capacity building, sustainability planning, Option C’s elements).

Option (d), Screen largest number of patients fastest:

This prioritizes scale over sustainability:

Problems:

  1. Vanity metrics: Large numbers look good for reports but don’t ensure quality, sustainability, or long-term impact.

  2. Pilot fatigue: Many LMICs have experienced large-scale pilots that disappear when funding ends, leaving no lasting impact. The chapter warns against “pilot projects that don’t scale.”

  3. Doesn’t ensure quality: Screening many patients poorly is worse than screening fewer patients well.

  4. Unsustainable: Massive short-term campaigns often aren’t sustainable after funding ends.

  5. Missing key factors: Says nothing about local leadership, capacity building, or sustainability, all critical for long-term success.

The chapter emphasizes: “Measure what matters: - Not just performance, but also sustainability - Not just deployment, but also equity and local ownership”

Option D measures deployment scale, not sustainability or equity.

The Foundation’s Evaluation Rubric (Based on Chapter):

To evaluate proposals, assess:

1. Partnership Equity (30%): - Local co-leadership (not just “collaboration”) - Shared governance - Co-authorship and IP sharing - Benefit sharing plans

2. Context-Appropriateness (25%): - Addresses locally-prioritized problem - Designed for local infrastructure constraints - Culturally appropriate - Aligns with local health system workflows

3. Capacity Building (25%): - Specific training plans (not just “workshops”) - Staged progression (awareness → research) - Knowledge transfer mechanisms - Retention strategies

4. Sustainability (20%): - Long-term funding plan - Local ownership structure - Maintenance and support plan - Scalability pathway

Option C addresses all four dimensions. Options A, B, and D address at most one.

Red Flags (Reject These Proposals):

Based on the chapter’s framework:

  • External leadership only (no local co-PIs)
  • Data extraction without benefit sharing
  • No capacity building component
  • No sustainability plan
  • Addresses external-imposed priorities (not local)
  • Requires infrastructure unavailable locally
  • Perpetuates dependency on external partners
  • Short timeline (6-12 months) with no continuation plan

Green Flags (Fund These Proposals):

Based on the chapter’s framework:

  • Local co-leadership from design stage
  • Addresses locally-identified priority
  • Context-appropriate design (offline, low-power, culturally adapted)
  • Complete capacity building plan
  • Sustainability plan with local ownership
  • Equitable benefit sharing
  • Realistic timeline (multi-year commitment)
  • Partnership with local institutions
  • Knowledge sharing and open source

Option C exhibits all the green flags.

The Chapter’s Broader Message:

From the conclusion: “Global health AI should benefit those who need it most. If AI only works for the wealthy and connected, we have failed.”

Implications for funding decisions:

Don’t fund: - Technically impressive but context-inappropriate projects - Extractive research from prestigious institutions without local partnership - Large-scale deployments without sustainability plans

Do fund: - Locally-led, equitable partnerships - Context-appropriate solutions to local priorities - Complete capacity building - Sustainable, locally-owned implementations

For practitioners (funders):

The chapter provides clear guidance for funders wanting to support equitable global health AI:

Evaluation criteria should prioritize: 1. Equity: Local leadership, shared governance, benefit sharing 2. Relevance: Locally-prioritized problems, context-appropriate design 3. Sustainability: Capacity building, local ownership, long-term planning 4. Impact: Addresses real health needs, scalable, sustainable

Not: 1. Technical sophistication 2. Prestige of external partners 3. Scale of deployment 4. Publishability in high-impact journals

Option C embodies the first set of criteria, the ones that predict long-term success and sustainable impact. The alternatives prioritize factors that don’t ensure sustainable, equitable impact.

The global health AI divide won’t be bridged by funding the most technically sophisticated projects from the most prestigious institutions. It requires funding equitable, locally-led, sustainable partnerships that build local capacity.

Option C represents this approach.