Emerging AI Technologies for Public Health

Emerging AI should be evaluated as a set of candidate capabilities, not as one wave of progress. Public health agencies need to know whether a specific system improves a defined decision or workflow in its intended population and setting, under the available privacy, infrastructure, workforce, and governance constraints. Claims should therefore be classified as demonstrated, theoretical, or beyond current capabilities before the same readiness test is applied to each.

Learning Objectives

This chapter equips readers to:

  • Classify emerging-technology claims as demonstrated, theoretical, or beyond current capabilities
  • Distinguish a component benchmark from evidence that a complete public health workflow improves
  • Evaluate multimodal foundation models against a defined task, user, comparator, and escalation path
  • Assess federated learning and edge AI against privacy, security, hardware, network, and governance constraints
  • Interpret digital-twin and quantum-computing outputs without converting assumptions or theoretical speedups into operational evidence
  • Compare an AI approach with the current non-AI baseline before investing
  • Define pilot success criteria, monitoring duties, failure modes, and stop conditions before deployment

Core rule: Select a decision before selecting a technology. An architecture can create useful options, but its name does not establish effectiveness, privacy, equity, affordability, or readiness for public health use.

Decision sequence:

  1. Define the decision, current workflow, non-AI baseline, affected population, and accountable owner.
  2. Classify the claim by evidence maturity: demonstrated on a bounded task, theoretical but plausible, or beyond current capabilities.
  3. Test the complete system in conditions similar to use, including people, data, hardware, connectivity, escalation, and downstream action.
  4. Compare benefits, harms, resource requirements, and residual uncertainty with viable alternatives.
  5. Assign monitoring and suspension authority before scaling. The NIST AI Risk Management Framework treats context, measurement, management, and governance as continuing lifecycle functions rather than a one-time checklist.

Technology readiness checks:

  • Multimodal foundation models
    • Credible opportunity: Combine text, images, audio, or other inputs for a defined task.
    • Before operational use: Require task-specific evaluation, source verification, human escalation, subgroup analysis, and monitoring. WHO guidance notes that broad general-purpose capability remains unproven.
  • Federated learning
    • Credible opportunity: Train across sites without pooling raw records in one central dataset.
    • Before operational use: Require leakage and attack testing, site-level validation, secure aggregation where appropriate, shared protocols, and legal governance (Rieke et al., 2020).
  • Edge AI
    • Credible opportunity: Run inference on local hardware with less dependence on a remote service.
    • Before operational use: Test accuracy, latency, memory, power, heat, updates, and failures on the target device. Official LiteRT guidance emphasizes device constraints and the size, speed, and accuracy tradeoff.
  • Digital twins
    • Credible opportunity: Represent a defined person, facility, or population process for conditional simulation.
    • Before operational use: Specify the represented system, calibration data, update rule, uncertainty, validation target, and decision context (Niederer et al., 2021).
  • Quantum computing
    • Credible opportunity: Investigate task-specific computational methods.
    • Before operational use: Demonstrate end-to-end advantage over a strong classical baseline on the relevant problem, including data preparation, noise, access, and operational cost (Preskill, 2018).

Critical takeaways:

  • A capability demonstration is not deployment evidence.
  • Keeping raw data local does not by itself guarantee privacy or resolve governance.
  • Local inference does not by itself establish diagnostic validity, offline reliability, or affordability.
  • Digital-twin and quantum-computing timelines should remain conditional, not procurement claims.
  • Scale only after the complete workflow meets predefined performance, equity, safety, and sustainability requirements.

1. Introduction: Evidence Before Forecast

Emerging-technology chapters are vulnerable to a recurring error: a working component becomes evidence for a much broader system claim. The World Health Organization’s guidance on large multi-modal models defines systems that accept one or more data types and generate varied outputs, while stating that broad general-purpose capability has not been proven. The same evidentiary discipline applies to every technology assessed below. A useful output on one task does not establish effectiveness in a different population, workflow, jurisdiction, or decision.

Claims fall into three evidence tiers:

  • Demonstrated: A bounded capability has credible evidence on a specified task. This tier does not imply that the complete public health intervention improves outcomes.
  • Theoretical: The proposed use is technically plausible, but end-to-end performance in the intended setting has not been demonstrated.
  • Beyond current capabilities: A required enabling capability, validated workflow, or task-relevant advantage has not been shown with current methods.

The tiers apply to claims, not permanent technology categories. A system can be demonstrated for one narrow use and theoretical for another. The practical review therefore starts with context: intended purpose, users, inputs, outputs, affected population, baseline, operating conditions, and downstream action. NIST’s AI RMF similarly places contextual mapping before measurement and a go or no-go decision, then requires continued monitoring and risk management throughout use.

For a full deployment evaluation, use the Evaluating AI Systems for Healthcare framework. Emerging technologies introduce uncertainty beyond local implementation because the underlying capability itself is still developing.

2. Foundation Models and Multimodal AI

Foundation-model scope is not evidence of public health validity. A multimodal system may accept text, images, audio, video, or sensor data and still fail on the exact combination, population, language, or workflow proposed for use. Evaluation should name the task, comparator, source of truth, error costs, human reviewer, and escalation path before any output influences an investigation or service.

Public Health Applications

1. Outbreak Investigation

The following hypothetical example demonstrates a failure mode, not a validated outbreak-investigation workflow. A model receives a meal photograph and a short symptom report, then produces a confident etiologic assessment from information that cannot support one.

Hypothetical prompt: “Review this meal photograph and a report of diarrhea and nausea six hours after eating. Identify visible food-safety concerns, possible causes, and recommended investigation steps.”

Illustrative model output (unverified):

Analyzing the image, I observe:
- Undercooked chicken (pink interior visible)
- Cross-contamination risk: raw vegetables adjacent to meat
- Improper temperature control indicated by condensation

Given 6-hour incubation:
- Most likely: Salmonella (chicken source)
- Possible: Clostridium perfringens
- Less likely: Norovirus (longer incubation)

Recommended actions:
1. Test food samples for Salmonella
2. Interview other diners with similar exposure
3. Inspect restaurant kitchen practices

Evidence check: This output overreaches. A photograph and one reported incubation interval cannot establish undercooking, cross-contamination, temperature control, the outbreak source, or the responsible pathogen. CDC’s investigation framework treats early source ideas as hypotheses and confirms an outbreak source using epidemiologic, traceback, and food or environmental evidence. A multimodal model may help organize observations or questions, but its output is a lead, not evidence.

2. Telemedicine in Low-Resource Settings

The following hypothetical sketch shows a common proposal, remote assessment that combines a patient description with a photograph, and the same failure mode as the outbreak example.

# Hypothetical sketch: photo-based dermatology assessment sent by messaging app
diagnosis = multimodal_model.analyze(
 image="skin_lesion.jpg",
 text="3-week history, itchy, spreading",
 patient_info={"age": 45, "location": "rural Kenya", "hiv_status": "unknown"}
)

# Illustrative output (unverified): suspected tinea corporis
# Illustrative recommendation: topical antifungal, HIV test if persistent

Evidence check: A single photograph and a short history cannot establish a diagnosis or justify treatment. Such output can support triage only after validation on the target population, image quality, and skin tones, with clinician review and a referral pathway.

Scientific Foundation Models

Models trained specifically on scientific data:

Galactica (Meta, 2022)

Taylor et al., 2022, arXiv

  • Trained on 48M scientific papers, textbooks, knowledge bases
  • Can summarize papers, annotate molecules, write literature reviews
  • Controversy: Public demo withdrawn after criticism that it generated plausible but false content, including fabricated citations

BioGPT (Microsoft, 2022)

Luo et al., 2022, Briefings in Bioinformatics

  • Pre-trained on 15M PubMed abstracts
  • Reported better results than prior models on most of six biomedical NLP tasks, including PubMedQA
  • Use cases: Literature search, clinical trial matching, adverse event detection

MedPaLM 2 (Google, 2023)

Singhal et al., 2023, arXiv preprint

  • Reported accuracy of up to 86.5% on MedQA (USMLE-style questions)
  • Physicians preferred its long-form answers to physician answers on eight of nine clinical axes
  • Evaluated on adversarial question sets designed to probe model limitations

The original Med-PaLM (67.6% MedQA) was reported in Singhal et al., 2023, Nature.

Implications for Public Health

Opportunities:

  • Rapid literature synthesis during emergencies (like COVID-19)
  • Multi-lingual health communication with vision context
  • Remote diagnostics combining images + patient history
  • Automated surveillance from diverse data sources (text, images, videos)

Challenges:

  • Hallucination risk - Plausible but incorrect information
  • Validation difficulty - No established method for verifying multimodal outputs
  • Computational cost - Large models expensive to run at scale
  • Bias amplification - Training data may lack diverse populations

Open-Weight Models for Resource-Limited Settings

Proprietary models such as GPT-4 and Claude have led many clinical AI benchmarks. Open-weight alternatives have been reported to perform competitively at substantially lower cost, which matters in resource-limited settings.

DeepSeek-R1, developed under hardware access limitations, achieved 0.92 accuracy on the US Medical Licensing Examination, approaching the 0.95 performance of OpenAI’s o1 model (Sandmann et al., Nature Medicine, 2025). In ophthalmology evaluations on 300 clinical cases, DeepSeek-R1 matched o1’s 82.0% accuracy while reducing inference costs by approximately 15-fold (93% cost savings) (medRxiv, 2025).

Cost implications for LMICs: A 2025 Journal of Medical Systems article documents DeepSeek deployment in 90 Chinese tertiary hospitals, showing how efficient architectures can enable local deployment without ongoing API costs (Chen et al., 2025). However, clinical impact data from these implementations remains unreported.

Trade-offs: Open-weight models offer local deployment control and cost efficiency but require:

  • Local technical capacity for implementation and maintenance
  • Infrastructure for model hosting (less intensive than training, but not trivial)
  • Ongoing model updates and safety monitoring
  • Integration complexity without vendor support

Other competitive open-weight options include Meta’s Llama 3-70B (0.83 USMLE accuracy in radiology case evaluations) and Mistral models, though comprehensive clinical validation in LMIC contexts remains limited (Yang et al., JAMA Network Open, 2024).

Guardrail concerns: Open-weight models may be more susceptible to targeted attacks since model weights are accessible, though closed-source models are not exempt from these risks. When system-level instructions to produce incorrect health responses were tested across five LLMs, four of five generated 100% disinformation responses delivered in authoritative tones (Modi et al., 2025, Annals of Internal Medicine). Deployment without adequate safety protocols, particularly in settings with limited clinical oversight and low health literacy, poses serious risks.

Best practices for deployment:

  • Implement output screening and safety protocols before deployment
  • Establish version control and update tracking mechanisms
  • Conduct regular audits against verified medical sources to detect hallucinations
  • Ensure adequate clinical oversight, especially in underserved populations
  • Monitor for adversarial attacks and model degradation over time

3. Federated Learning for Privacy-Preserving Collaboration

The Problem: Data Silos in Public Health

Current reality:

  • Hospital A has 5,000 patient records
  • Hospital B has 7,000 patient records
  • Hospital C has 3,000 patient records

Traditional approach:

  1. Create data use agreements (6–18 months)
  2. De-identify and transfer data to central location
  3. Risk of re-identification
  4. Patient privacy concerns

Federated learning approach:

  1. Train model locally at each site
  2. Share only model updates (not data)
  3. Aggregate updates centrally
  4. Raw patient records stay at each institution

How Federated Learning Works

McMahan et al., 2017, AISTATS introduced Federated Averaging (FedAvg):

┌─────────────────────────────────────────────────────────┐
│    Federated Learning Process     │
├─────────────────────────────────────────────────────────┤
│               │
│ Central Server           │
│  │             │
│  ├──── Initial Model ────▶ Hospital A    │
│  │       (Local Training)  │
│  ├──── Initial Model ────▶ Hospital B    │
│  │       (Local Training)  │
│  └──── Initial Model ────▶ Hospital C    │
│         (Local Training)  │
│  ▲             │
│  │             │
│  ├──── Model Update ◀──── Hospital A    │
│  ├──── Model Update ◀──── Hospital B    │
│  └──── Model Update ◀──── Hospital C    │
│  │             │
│ Aggregate & Update          │
│  │             │
│  └──── Repeat for N rounds ────▶     │
│               │
└─────────────────────────────────────────────────────────┘

Implementation Example

Using Flower framework:

import flwr as fl
from flwr.common import Metrics
import tensorflow as tf
from typing import List, Tuple

# Define model
def create_sepsis_model():
 model = tf.keras.Sequential([
  tf.keras.layers.Dense(64, activation='relu', input_shape=(20,)),
  tf.keras.layers.Dropout(0.2),
  tf.keras.layers.Dense(32, activation='relu'),
  tf.keras.layers.Dropout(0.2),
  tf.keras.layers.Dense(1, activation='sigmoid')
 ])
 model.compile(
  optimizer='adam',
  loss='binary_crossentropy',
  metrics=['accuracy', tf.keras.metrics.AUC(name='auc')]
 )
 return model

# Client (Hospital)
class HospitalClient(fl.client.NumPyClient):
 def __init__(self, hospital_id: str):
  self.hospital_id = hospital_id
  self.model = create_sepsis_model()
  # Load local hospital data
  self.X_train, self.y_train = load_hospital_data(hospital_id)
  self.X_val, self.y_val = load_hospital_validation_data(hospital_id)

 def get_parameters(self, config):
  """Return model parameters"""
  return self.model.get_weights()

 def fit(self, parameters, config):
  """Train model on local data"""
  # Update model with parameters from server
  self.model.set_weights(parameters)

  # Train on local data
  history = self.model.fit(
   self.X_train, self.y_train,
   epochs=5,
   batch_size=32,
   validation_data=(self.X_val, self.y_val),
   verbose=0
  )

  # Return updated model parameters and metrics
  return (
   self.model.get_weights(),
   len(self.X_train),
   {"accuracy": float(history.history['accuracy'][-1])}
  )

 def evaluate(self, parameters, config):
  """Evaluate model on local validation data"""
  self.model.set_weights(parameters)
  loss, accuracy, auc = self.model.evaluate(
   self.X_val, self.y_val,
   verbose=0
  )
  return loss, len(self.X_val), {"accuracy": accuracy, "auc": auc}

# Server: Aggregate metrics
def weighted_average(metrics: List[Tuple[int, Metrics]]) -> Metrics:
 """Weighted average of metrics from all hospitals"""
 # Multiply accuracy of each client by number of examples
 accuracies = [num_examples * m["accuracy"] for num_examples, m in metrics]
 examples = [num_examples for num_examples, _ in metrics]

 # Aggregate and return
 return {"accuracy": sum(accuracies) / sum(examples)}

# Start federated learning
def start_federated_learning():
 # Define strategy
 strategy = fl.server.strategy.FedAvg(
  fraction_fit=1.0, # Sample 100% of available clients for training
  fraction_evaluate=1.0, # Sample 100% for evaluation
  min_available_clients=3, # Wait for 3 hospitals before starting
  evaluate_metrics_aggregation_fn=weighted_average,
 )

 # Start Flower server
 fl.server.start_server(
  server_address="0.0.0.0:8080",
  config=fl.server.ServerConfig(num_rounds=10),
  strategy=strategy,
 )

# Each hospital runs this:
def hospital_participates(hospital_id: str):
 client = HospitalClient(hospital_id)
 fl.client.start_numpy_client(
  server_address="central-server.health.gov:8080",
  client=client
 )

# Usage:
# Hospital A: hospital_participates("hospital_a")
# Hospital B: hospital_participates("hospital_b")
# Hospital C: hospital_participates("hospital_c")

Real-World Applications

MELLODDY (2020-2023)

Multi-Partner Learning for drug discovery

  • Partners: 10 pharmaceutical companies
  • Goal: Predict drug-target interactions
  • Data: 10M+ compounds (kept at each company)
  • Reported result: Better models than any single company could build alone

FeTS (Federated Tumor Segmentation)

Sheller et al., 2020, Scientific Reports

  • Partners: 10 institutions
  • Task: Brain tumor segmentation from MRI
  • Finding: Federated model reached 99% of the model quality achieved with centralized data, without sharing patient data

Google’s Gboard Keyboard

McMahan & Ramage, 2017, Google AI Blog

  • Application: Next-word prediction
  • Scale: Millions of mobile devices
  • Privacy: User typing data never leaves device

Challenges and Solutions

Challenge Solution Approach
Non-IID data (hospitals have different patient populations) FedProx algorithm, personalized federated learning
Communication costs (slow networks) Compressed updates, fewer rounds
Malicious participants (poisoning attacks) Robust aggregation, Byzantine-tolerant methods
Privacy leakage (model updates leak info) Differential privacy: add noise to gradients (DP-SGD)
Heterogeneous systems (different hardware) Asynchronous federated learning

4. Edge AI: Intelligence at the Point of Care

What is Edge AI?

Definition: Running AI models directly on devices (smartphones, tablets, IoT sensors) rather than in the cloud.

Why it matters for public health:

  • Low-latency: Instant results without internet delay
  • Privacy: Raw data can remain on the device
  • Offline capability: Works in areas with poor connectivity
  • Cost: No cloud inference fees at scale
  • Bandwidth: Reduces data transmission needs

Technology Enablers

1. Model Compression

Techniques to make models smaller:

Quantization: Reduce precision (32-bit → 8-bit)

import tensorflow as tf

# Original model
model = tf.keras.models.load_model('sepsis_model.h5')

# Convert to TensorFlow Lite with quantization
converter = tf.lite.TFLiteConverter.from_keras_model(model)
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.target_spec.supported_types = [tf.int8]

tflite_quant_model = converter.convert()

# Save quantized model
with open('sepsis_model_quantized.tflite', 'wb') as f:
 f.write(tflite_quant_model)

# Check size reduction
import os
original_size = os.path.getsize('sepsis_model.h5') / (1024**2)
compressed_size = os.path.getsize('sepsis_model_quantized.tflite') / (1024**2)

print(f"Original: {original_size:.2f} MB")
print(f"Compressed: {compressed_size:.2f} MB")
print(f"Reduction: {(1 - compressed_size/original_size)*100:.1f}%")

Pruning: Remove unimportant connections

import tensorflow_model_optimization as tfmot

# Apply pruning
prune_low_magnitude = tfmot.sparsity.keras.prune_low_magnitude

# Define pruning schedule
pruning_params = {
 'pruning_schedule': tfmot.sparsity.keras.PolynomialDecay(
  initial_sparsity=0.0,
  final_sparsity=0.5, # Remove 50% of weights
  begin_step=0,
  end_step=1000
 )
}

# Apply to model
model_for_pruning = prune_low_magnitude(model, **pruning_params)

# Train with pruning
model_for_pruning.compile(
 optimizer='adam',
 loss='binary_crossentropy',
 metrics=['accuracy']
)

model_for_pruning.fit(X_train, y_train, epochs=10)

Knowledge Distillation: Train small model to mimic large model

# Large teacher model
teacher_model = tf.keras.models.load_model('large_model.h5')

# Small student model
student_model = create_small_model()

# Distillation loss
def distillation_loss(y_true, y_pred, teacher_pred, temperature=3):
 # Student matches teacher's soft predictions
 soft_loss = tf.keras.losses.KLDivergence()(
  tf.nn.softmax(teacher_pred / temperature),
  tf.nn.softmax(y_pred / temperature)
 )
 # Student also learns from ground truth
 hard_loss = tf.keras.losses.binary_crossentropy(y_true, y_pred)

 return 0.5 * soft_loss + 0.5 * hard_loss

2. Specialized Hardware

Mobile/Edge AI Chips:

  • Google Coral: 4 TOPS (trillion operations/sec), $25
  • NVIDIA Jetson Nano: 472 GFLOPS, $99
  • Apple Neural Engine: Built into iPhone/iPad
  • Qualcomm AI Engine: Built into Snapdragon chips

Public Health Applications

1. Point-of-Care Diagnostics

Example: Malaria Detection from Blood Smears

Rajaraman et al., 2018, PeerJ

# Mobile app using TensorFlow Lite
import tensorflow as tf
import numpy as np
from PIL import Image

# Load quantized model
interpreter = tf.lite.Interpreter(model_path="malaria_detector.tflite")
interpreter.allocate_tensors()

# Get input/output details
input_details = interpreter.get_input_details()
output_details = interpreter.get_output_details()

def diagnose_malaria(image_path):
 """
 Analyze blood smear image for malaria parasites
 Runs entirely on mobile device, no internet required
 """
 # Load and preprocess image
 img = Image.open(image_path).resize((224, 224))
 img_array = np.array(img).astype(np.float32) / 255.0
 img_array = np.expand_dims(img_array, axis=0)

 # Run inference
 interpreter.set_tensor(input_details[0]['index'], img_array)
 interpreter.invoke()
 prediction = interpreter.get_tensor(output_details[0]['index'])[0][0]

 # Interpret result
 result = {
  'infected': bool(prediction > 0.5),
  'confidence': float(prediction),
  'parasitemia': estimate_parasitemia(img_array) if prediction > 0.5 else 0,
  'recommendation': generate_recommendation(prediction)
 }

 return result

# Example usage (runs on smartphone)
result = diagnose_malaria("blood_smear_photo.jpg")
print(f"Malaria detected: {result['infected']}")
print(f"Confidence: {result['confidence']:.1%}")
print(f"Recommendation: {result['recommendation']}")

Illustrative assumptions (not measured outcomes):

  • Diagnosis time: 10 minutes → 30 seconds
  • Cost: $5 microscopy + technician → $0 marginal cost
  • Accessibility: Urban hospital → Rural clinic with smartphone
  • Scalability: Limited by trained technicians → Limited by smartphones

2. Wearable Disease Monitoring

Example: Fever Detection from Smartwatch

Mishra et al., 2020, Nature Biomedical Engineering

# Continuous temperature monitoring on wearable device
class FeverDetector:
 """
 Runs on smartwatch to detect fever patterns
 Sends alert only when anomaly detected (preserves battery)
 """

 def __init__(self):
  self.baseline_temp = self.calibrate_baseline()
  self.hourly_temps = []

 def process_temperature_reading(self, temp, timestamp):
  """Process each temperature reading (every 5 minutes)"""
  self.hourly_temps.append(temp)

  # Keep last 12 readings (1 hour)
  if len(self.hourly_temps) > 12:
   self.hourly_temps.pop(0)

  # Check for fever pattern
  if len(self.hourly_temps) >= 6: # At least 30 minutes of data
   fever_detected, confidence = self.detect_fever()

   if fever_detected and confidence > 0.8:
    self.send_alert(temp, confidence)
    # Log to phone app for physician review
    self.log_to_cloud_when_connected()

 def detect_fever(self):
  """Lightweight on-device fever detection"""
  # Illustrative rule: check for sustained elevation above baseline
  mean_temp = np.mean(self.hourly_temps)
  std_temp = np.std(self.hourly_temps)

  # Fever if:
  # 1. Mean temp > baseline + 1°C
  # 2. Low variance (sustained, not spike)
  fever = mean_temp > (self.baseline_temp + 1.0) and std_temp < 0.5
  confidence = min((mean_temp - self.baseline_temp) / 2.0, 1.0)

  return fever, confidence

3. Real-Time Syndromic Surveillance

Edge AI on mobile phones for symptom tracking:

  • Input: User-reported symptoms via app
  • Processing: On-device NLP to extract symptoms
  • Output: Aggregated signals (no PII sent to server)
  • Privacy: Individual records can remain on the device

4. AI Health Agents on Messaging Platforms

More than 3 billion people in over 180 countries use WhatsApp. Messaging platforms are therefore a potential channel for public health programs, particularly where they are the dominant way people communicate.

Technical architecture:

WhatsApp Business API enables programmatic messaging with AI backends:

# Simplified health agent architecture
class WhatsAppHealthAgent:
    """
    AI health agent for messaging platforms

    Use cases: medication reminders, vaccination scheduling,
    symptom triage, health education
    """

    def process_message(self, user_message: str, user_id: str):
        # 1. Intent classification
        intent = self.classify_intent(user_message)

        # 2. Entity extraction (symptoms, medications, dates)
        entities = self.extract_entities(user_message)

        # 3. Context retrieval (conversation history)
        context = self.get_user_context(user_id)

        # 4. Response generation
        if intent == "symptom_report":
            return self.triage_symptoms(entities, context)
        elif intent == "medication_query":
            return self.medication_info(entities)
        elif intent == "appointment":
            return self.schedule_appointment(entities, context)
        else:
            return self.general_health_info(user_message)

    def triage_symptoms(self, symptoms: list, context: dict):
        # Rule-based triage with escalation to human providers
        severity = self.assess_severity(symptoms)

        if severity == "emergency":
            return "Please call emergency services immediately: [local number]"
        elif severity == "urgent":
            return "Please visit a health facility within 24 hours. [Nearest clinic link]"
        else:
            return self.self_care_guidance(symptoms)

Public health applications:

  • Vaccination campaigns: Appointment reminders, side effect reporting, second dose scheduling
  • Chronic disease management: Medication adherence prompts, glucose/blood pressure logging
  • Maternal health: Antenatal visit reminders, danger sign education, postpartum check-ins
  • Outbreak response: Symptom screening, testing site directions, isolation guidance

Implementation considerations:

Aspect Recommendation
API access Use official WhatsApp Business API (unofficial clients violate ToS and risk account bans)
Data privacy The AI backend processes message content, so it must be governed as a holder of health data
Language support Must support local languages, not just English
Escalation Clear pathways to human providers for complex cases
Consent Explicit opt-in before health messaging begins

Reach vs. other channels: India has one of the largest WhatsApp user bases. Meeting users on platforms they already use can reduce adoption barriers.

Security Warning

Never use unofficial WhatsApp libraries or “grey” APIs. These violate WhatsApp’s Terms of Service, risk account termination, and may expose patient data. Use only the official WhatsApp Business Platform or WhatsApp Cloud API.

Case Study: Project Premonition (Microsoft Research)

Monitoring zoonotic disease emergence

Components:

  • Smart mosquito trap: Edge AI for species identification
  • On-device processing: Classify mosquito species from images
  • Selective sampling: Only upload images of disease vectors
  • Network: Deploy in remote areas with poor connectivity

Reported results:

  • 99% reduction in data transmission (only relevant images sent)
  • Real-time identification without expert entomologist
  • Scalable to resource-limited settings

5. Quantum Computing for Public Health

What is Quantum Computing?

Classical bit: 0 or 1

Quantum bit (qubit): Superposition of 0 and 1 simultaneously

Key principles:

  • Superposition: A register can represent many basis states at once; measurement returns one outcome
  • Entanglement: Qubits correlated in ways impossible classically
  • Quantum advantage: Proven or conjectured speedups for specific problem classes

Current Status (TRL 3-4)

Representative vendor-reported systems (2019–2022):

  • IBM Quantum: 433 qubits (Osprey, announced 2022)
  • Google: 53 qubits (Sycamore, claimed quantum supremacy 2019)
  • Rigetti: 80 qubits
  • IonQ: 32 qubits (trapped ion)

Reality check: Still noisy, error-prone, limited to small problems. Hardware is improving (50 to 400+ qubits), but error rates remain the bottleneck (Preskill, 2018). Public health applications are decades away.

Potential Applications in Public Health

1. Epidemic Simulation

Problem: Simulate disease spread through network of 1M people with 10 interactions each.

Classical approach:

  • Full joint state space: 2^1,000,000 possible configurations
  • Classical stochastic and agent-based simulations sample trajectories instead of enumerating states, and routinely model populations of this size

Quantum approach:

  • Encode population in qubits
  • Quantum gates simulate interactions
  • Measure to sample likely outcomes
  • Efficiency for epidemic models has not been demonstrated

Example (conceptual):

# Using IBM Qiskit for epidemic modeling (simplified)
from qiskit import QuantumCircuit, QuantumRegister, ClassicalRegister
from qiskit import execute, Aer
import numpy as np

def create_epidemic_circuit(n_individuals, transmission_prob):
 """
 Create quantum circuit for epidemic simulation
 Each qubit represents one individual (0=susceptible, 1=infected)
 """
 # Create quantum and classical registers
 qr = QuantumRegister(n_individuals, 'person')
 cr = ClassicalRegister(n_individuals, 'outcome')
 circuit = QuantumCircuit(qr, cr)

 # Initialize: patient zero infected
 circuit.x(qr[0])

 # Transmission gates (simplified)
 # CRY(theta) gives P(infect neighbor) = sin^2(theta/2), so theta = 2*arcsin(sqrt(p))
 theta = 2 * np.arcsin(np.sqrt(transmission_prob))

 for i in range(n_individuals - 1):
  # Controlled rotation: infected person can infect susceptible neighbor
  circuit.cry(theta, qr[i], qr[i+1])

 # Measure all individuals
 circuit.measure(qr, cr)

 return circuit

# Run simulation
circuit = create_epidemic_circuit(n_individuals=10, transmission_prob=0.3)
backend = Aer.get_backend('qasm_simulator')
job = execute(circuit, backend, shots=1000)
result = job.result()
counts = result.get_counts()

# Analyze results
print("Epidemic outcomes:")
for outcome, count in sorted(counts.items(), key=lambda x: x[1], reverse=True)[:5]:
 infected_count = outcome.count('1')
 probability = count / 1000
 print(f" {infected_count} infected: {probability:.1%}")

Note: This is a simplified illustration. Practical quantum epidemiology models do not exist yet (TRL 2–3).

2. Drug Discovery Optimization

Problem: Prioritize candidates within a chemical space too large for exhaustive laboratory evaluation.

Quantum advantage: Grover’s algorithm can search unsorted database in √N time vs N time classically.

Cao et al., 2018, Chemical Reviews - “Quantum chemistry in the age of quantum computing”

3. Optimization Problems

Vaccine distribution:

  • 1,000 clinics
  • 10,000 routes
  • Minimize cost + maximize coverage + prioritize high-risk areas

Quantum annealing: D-Wave systems already used for logistics optimization.

Conditions for Practical Use

Readiness criteria (no fixed date):

  • Advantage over a strong classical baseline on a relevant public health task
  • Error rates low enough for the problem size, including error correction overhead
  • End-to-end cost, including data preparation, access, and integration, below the classical alternative

Prepare now by:

  • Learning quantum algorithms fundamentals
  • Identifying problems with potential quantum speedup
  • Partnering with quantum computing companies
  • Training workforce in quantum programming (Qiskit, Cirq)

6. Digital Twins for Population Health

What are Digital Twins?

Definition: Virtual replica of a physical entity (person, hospital, city) that:

  • Mirrors real-time state
  • Simulates responses to interventions
  • Enables “what-if” scenario testing without risk

Origin: Aerospace (NASA, simulate spacecraft systems)

Evolution: Manufacturing → Healthcare → Population health

Types of Health Digital Twins

1. Individual Digital Twin

Virtual model of a single person’s health:

  • Inputs: EHR, genomics, wearables, imaging
  • Model: Physiological simulation + ML predictions
  • Outputs: Personalized risk scores, treatment recommendations

Niederer et al., 2021, Nature Computational Science

Example: Cardiovascular Digital Twin

class CardiovascularDigitalTwin:
 """
 Individual-level digital twin for cardiovascular health
 Integrates multiple data sources and predicts outcomes
 """

 def __init__(self, patient_id):
  self.patient_id = patient_id
  self.load_patient_data()

 def load_patient_data(self):
  """Load all available patient data"""
  self.demographics = load_ehr_demographics(self.patient_id)
  self.vitals = load_continuous_vitals(self.patient_id) # From wearables
  self.labs = load_lab_results(self.patient_id)
  self.imaging = load_cardiac_imaging(self.patient_id)
  self.genetics = load_genomic_data(self.patient_id)

 def simulate_intervention(self, intervention, duration_days=365):
  """
  Simulate effect of intervention over time

  Args:
   intervention: dict with type and parameters
   duration_days: simulation duration

  Returns:
   Predicted outcomes at checkpoints
  """
  outcomes = []

  # Initialize state
  current_state = self.get_current_state()

  for day in range(duration_days):
   # Apply intervention effect
   if intervention['type'] == 'medication':
    current_state = self.apply_medication_effect(
     current_state,
     intervention['drug'],
     intervention['dose']
    )
   elif intervention['type'] == 'lifestyle':
    current_state = self.apply_lifestyle_change(
     current_state,
     intervention['changes']
    )

   # Simulate physiological evolution
   current_state = self.advance_one_day(current_state)

   # Record outcomes at monthly checkpoints
   if day % 30 == 0:
    outcomes.append({
     'day': day,
     'blood_pressure': current_state['bp'],
     'cholesterol': current_state['ldl'],
     'cvd_risk': self.calculate_cvd_risk(current_state),
     'quality_of_life': self.estimate_qol(current_state)
    })

  return outcomes

 def compare_treatments(self, treatment_options):
  """Compare multiple treatment strategies"""
  results = {}

  for name, intervention in treatment_options.items():
   outcomes = self.simulate_intervention(intervention)
   results[name] = {
    'final_cvd_risk': outcomes[-1]['cvd_risk'],
    'risk_reduction': self.get_current_state()['cvd_risk'] - outcomes[-1]['cvd_risk'],
    'side_effects': self.estimate_side_effects(intervention),
    'cost': self.estimate_annual_cost(intervention)
   }

  return results

# Usage example
twin = CardiovascularDigitalTwin(patient_id="PAT123456")

# Define treatment options
treatments = {
 'statin_only': {
  'type': 'medication',
  'drug': 'atorvastatin',
  'dose': '40mg'
 },
 'statin_plus_lifestyle': {
  'type': 'combined',
  'medication': {'drug': 'atorvastatin', 'dose': '20mg'},
  'lifestyle': {'diet': 'mediterranean', 'exercise': '150min/week'}
 },
 'lifestyle_only': {
  'type': 'lifestyle',
  'changes': {'diet': 'mediterranean', 'exercise': '150min/week'}
 }
}

# Compare treatments
comparison = twin.compare_treatments(treatments)

# Recommend optimal treatment
for treatment, results in comparison.items():
 print(f"{treatment}:")
 print(f" CVD risk reduction: {results['risk_reduction']:.1%}")
 print(f" Annual cost: ${results['cost']:,.0f}")
 print()

2. Hospital Digital Twin

Virtual replica of hospital operations:

  • Model: Patient flow, resource utilization, staff scheduling
  • Simulate: Surge capacity, new protocols, facility changes
  • Optimize: Bed allocation, OR scheduling, supply chain

Croatti et al., 2020, Journal of Medical Systems

3. City/Population Digital Twin

Urban health system simulation:

  • Inputs: Demographics, mobility, social networks, healthcare access
  • Model: Disease transmission, healthcare demand, intervention effects
  • Applications: Pandemic preparedness, health equity, resource allocation

Example: Singapore Virtual Twin

Virtual Singapore - 3D city model with:

  • Real-time sensor data
  • Population movement patterns
  • Healthcare facility locations
  • Environmental conditions

Potential use case: Simulate dengue outbreak response strategies

Challenges and Future Directions

Technical challenges:

  • Model accuracy: Digital twins only as good as underlying models
  • Data integration: Combining EHR, genomics, wearables, imaging
  • Computational cost: Real-time simulation of complex physiological systems
  • Validation: Predictions are difficult to validate without real-world experimentation

Ethical challenges:

  • Consent: Patients may not understand that their digital twin is being used
  • Access inequality: Digital twins may be available only to wealthier patients and systems
  • Determinism: Risk of treating predictions as certain outcomes
  • Unintended consequences: Optimization for one outcome may harm another

7. AI-Accelerated Drug and Vaccine Development

Traditional Timeline vs. AI-Accelerated

Traditional drug development: approximately 10–15 years (Singh et al., 2025). A widely cited industry survey estimated $2.558 billion in capitalized pre-approval cost per approved compound in 2013 dollars, but cost estimates vary with the data, scope, and accounting assumptions (DiMasi et al., 2016).

The phase ranges below are directional planning scenarios, not validated averages or additive components. Reported reductions vary by program. The AI column is directional, not universal.

Phase Traditional With AI Improvement
Target identification 2–3 years 6–12 months 3–4x faster
Lead discovery 3–6 years 1–2 years 2–3x faster
Preclinical testing 1–2 years 6–12 months 1.5–2x faster
Clinical trials 6–7 years 4–9 years in selected programs up to ~1.5x faster

AI Techniques in Drug Discovery

1. Molecular Generation

Problem: Design molecules with desired properties (binds target, low toxicity, synthesizable)

AI approach: Generative models (VAE, GAN, Diffusion, Transformers)

Jiménez-Luna et al., 2020, Nature Machine Intelligence

Example: Using Transformer for molecule generation

# Simplified example using molecular SMILES notation
from transformers import GPT2LMHeadModel, GPT2Tokenizer
import torch

# Load pre-trained molecular language model
# (In practice: ChemBERTa, MolGPT, etc.)
tokenizer = GPT2Tokenizer.from_pretrained("gpt2")
model = GPT2LMHeadModel.from_pretrained("gpt2")

def generate_drug_candidate(target_properties):
 """
 Generate novel drug molecule with desired properties

 Args:
  target_properties: dict with keys like:
   - target_protein: "SARS-CoV-2 spike protein"
   - properties: ["high_binding_affinity", "low_toxicity", "oral_bioavailability"]

 Returns:
  SMILES string of generated molecule
 """
 prompt = f"Generate molecule that binds to {target_properties['target_protein']} with properties: {', '.join(target_properties['properties'])}. SMILES:"

 # Generate
 input_ids = tokenizer.encode(prompt, return_tensors='pt')
 output = model.generate(
  input_ids,
  max_length=100,
  num_return_sequences=10,
  temperature=0.8,
  do_sample=True
 )

 # Decode
 molecules = [tokenizer.decode(seq) for seq in output]

 # Filter for valid SMILES and desired properties
 valid_molecules = [m for m in molecules if is_valid_smiles(m) and has_desired_properties(m, target_properties)]

 return valid_molecules

# Example: Generate COVID-19 antiviral candidates
candidates = generate_drug_candidate({
 'target_protein': 'SARS-CoV-2 main protease',
 'properties': ['inhibits_protease', 'oral_bioavailable', 'low_toxicity']
})

print(f"Generated {len(candidates)} candidate molecules")
for i, smiles in enumerate(candidates[:3], 1):
 print(f"Candidate {i}: {smiles}")

2. Binding Affinity Prediction

Problem: Will drug bind to target protein strongly enough?

AI approach: Graph neural networks on 3D protein-ligand structures

Stärk et al., 2022, ICML - EquiBind; Corso et al., 2023, ICLR - DiffDock

import torch
from torch_geometric.nn import GCNConv, global_mean_pool

class ProteinLigandBindingPredictor(torch.nn.Module):
 """
 Graph neural network to predict protein-ligand binding affinity
 """

 def __init__(self, num_node_features):
  super().__init__()
  self.conv1 = GCNConv(num_node_features, 128)
  self.conv2 = GCNConv(128, 64)
  self.conv3 = GCNConv(64, 32)
  self.fc = torch.nn.Linear(32, 1)

 def forward(self, data):
  x, edge_index, batch = data.x, data.edge_index, data.batch

  # Graph convolutions
  x = self.conv1(x, edge_index)
  x = torch.relu(x)
  x = self.conv2(x, edge_index)
  x = torch.relu(x)
  x = self.conv3(x, edge_index)

  # Global pooling
  x = global_mean_pool(x, batch)

  # Predict binding affinity
  binding_affinity = self.fc(x)

  return binding_affinity

# Usage
model = ProteinLigandBindingPredictor(num_node_features=75)

# Load protein-ligand complex as graph
protein_ligand_graph = load_complex_as_graph("spike_protein_drug_complex.pdb")

# Predict binding affinity
predicted_affinity = model(protein_ligand_graph)
print(f"Predicted binding affinity: {predicted_affinity.item():.2f} kcal/mol")

3. Toxicity Prediction

Problem: Eliminate toxic compounds early (attrition is costly)

AI approach: Multi-task learning on toxicity endpoints

Mayr et al., 2016, Frontiers in Environmental Science

Toxicity endpoints:

  • Hepatotoxicity (liver damage)
  • Cardiotoxicity (heart issues)
  • Mutagenicity (DNA damage)
  • hERG inhibition (cardiac arrhythmia)

Success Stories

1. AlphaFold (DeepMind)

Jumper et al., 2021, Nature

  • Problem: Protein structure prediction from amino acid sequence
  • Traditional: X-ray crystallography (months-years, expensive)
  • AlphaFold: Computational structure prediction, often with accuracy competitive with experiment on benchmarked targets; confidence varies by residue and system
  • Impact: More than 200 million predictions are openly available in AlphaFold DB

Public health relevance:

  • Understand how viruses evolve (SARS-CoV-2 variants)
  • Design vaccines targeting conserved regions
  • Identify drug targets in neglected tropical diseases

2. Non-AI Comparator: Moderna mRNA COVID-19 Vaccine

The mRNA-1273 program used prior platform work and structure-based antigen design. Clinical material was manufactured and delivered within 45 days, and the first participant was vaccinated on March 16, 2020 (NIH, 2020; Jackson et al., 2020). This record does not isolate a causal AI contribution.

3. Insilico Medicine: INS018_055

A 2024 peer-reviewed report describes the AI-supported discovery and development program. Phase I began in 2022; Phase II first-patient dosing occurred in 2023.

  • Target: Idiopathic pulmonary fibrosis
  • Timeline: Roughly 18 months from target discovery to preclinical candidate nomination
  • Cost: A 2026 review reported an approximately US$2.6 million early-program cost; this is not an end-to-end development cost (Furukawa et al., 2026)
  • Method: Generative chemistry + reinforcement learning

Emerging Technologies: AI Lab Automation

Closed-loop discovery: AI designs experiments → robots perform → AI analyzes results → repeat

Burger et al., 2020, Nature - Mobile robot chemist

Components:

  1. AI: Bayesian optimization to select next experiment
  2. Robotics: Automated synthesis and testing
  3. Analysis: High-throughput screening, mass spec, NMR
  4. Iteration: Continuously improve based on results

Potential impact: Automated laboratories can operate outside normal working hours, but throughput gains are assay-, workflow-, and facility-specific and must be measured.

8. Causal AI: Beyond Correlation

The Limitations of Predictive AI

Current AI: Excellent at finding correlations

Problem: Correlation ≠ Causation

Example:

  • Observation: Ice cream sales correlate with drowning deaths
  • Predictive AI: “High ice cream sales → High drowning risk”
  • Causality: Both caused by hot weather (confounding)

Public health consequences:

  • Wrong intervention: Ban ice cream → Drownings continue
  • Right intervention: Increase lifeguard patrols on hot days

What is Causal AI?

Goal: Understand cause-effect relationships, enabling:

  1. Counterfactual reasoning: “What would have happened if…?”
  2. Intervention planning: “What should we do to achieve X?”
  3. Explanation: “Why did Y happen?”

Foundations: Pearl, 2009, Causality - Causal inference with directed acyclic graphs (DAGs)

The Causal Hierarchy

Pearl & Mackenzie, 2018, The Book of Why

Level Question Example AI Capability
Association What if I see X? Patients taking drug Y have better outcomes Standard ML
Intervention What if I do X? What if we mandate drug Y? Requires causal models
Counterfactual What if I had done X? Would patient survive if given drug Y instead of Z? Hardest, requires causal model + assumptions

Causal Inference Techniques

1. Randomized Controlled Trials (RCTs)

Gold standard: Randomly assign treatment → Breaks confounding

But: Expensive, slow, sometimes unethical

AI role: Design trials efficiently, predict who benefits most

2. Instrumental Variables

Method: Find variable that affects treatment but not outcome (except through treatment)

Example: Geographic distance to specialist

  • Affects likelihood of treatment
  • Does not directly affect outcome (except via treatment)
from econml.iv.dml import DMLIV
from sklearn.ensemble import RandomForestRegressor, RandomForestClassifier
import numpy as np

# Synthetic data
n = 10000
# Instrumental variable: distance to HIV specialist
distance = np.random.uniform(0, 100, n)
# Confounders: age, comorbidities
confounders = np.random.randn(n, 5)
# Treatment: receiving antiretroviral therapy
treatment = (distance < 50).astype(int) + 0.2 * confounders[:, 0] + np.random.randn(n) * 0.1
treatment = (treatment > 0.5).astype(int)
# Outcome: viral load suppression
outcome = 0.5 * treatment + 0.3 * confounders[:, 0] + np.random.randn(n) * 0.1

# Estimate causal effect using instrumental variables
est = DMLIV(
 model_y_xw=RandomForestRegressor(),
 model_t_xw=RandomForestClassifier(),
 model_t_xwz=RandomForestClassifier()
)

est.fit(Y=outcome, T=treatment, X=confounders, Z=distance.reshape(-1, 1), W=None)

# Estimate treatment effect
treatment_effect = est.effect(confounders)
print(f"Average treatment effect: {treatment_effect.mean():.3f}")

3. Propensity Score Matching

Idea: Match treated and untreated individuals with similar likelihood of treatment

from sklearn.linear_model import LogisticRegression
from sklearn.neighbors import NearestNeighbors
import pandas as pd

def propensity_score_matching(data, treatment_col, outcome_col, covariate_cols):
 """
 Estimate treatment effect using propensity score matching

 Args:
  data: DataFrame with patient data
  treatment_col: Name of treatment column (0/1)
  outcome_col: Name of outcome column
  covariate_cols: List of covariate columns

 Returns:
  Estimated average treatment effect
 """
 # Estimate propensity scores
 X = data[covariate_cols]
 treatment = data[treatment_col]

 ps_model = LogisticRegression()
 ps_model.fit(X, treatment)
 data['propensity_score'] = ps_model.predict_proba(X)[:, 1]

 # Match treated to control
 treated = data[data[treatment_col] == 1]
 control = data[data[treatment_col] == 0]

 # Find nearest neighbor matches
 nn = NearestNeighbors(n_neighbors=1, metric='euclidean')
 nn.fit(control[['propensity_score']])

 distances, indices = nn.kneighbors(treated[['propensity_score']])

 # Calculate treatment effect
 treated_outcomes = treated[outcome_col].values
 matched_control_outcomes = control.iloc[indices.flatten()][outcome_col].values

 ate = (treated_outcomes - matched_control_outcomes).mean()

 return ate

# Example: Effect of vaccination on hospitalization
ate = propensity_score_matching(
 data=patient_data,
 treatment_col='vaccinated',
 outcome_col='hospitalized',
 covariate_cols=['age', 'comorbidities', 'prior_infection']
)

print(f"Vaccination reduces hospitalization by {-ate:.1%}")

4. Causal Discovery from Data

Goal: Learn causal structure from observational data

Methods:

  • Constraint-based: PC algorithm, FCI
  • Score-based: GES, NOTEARS
  • Hybrid: Learn structure, then refine with domain knowledge

Spirtes et al., 2000, Causation, Prediction, and Search

#| eval: false
from causalnex.structure import StructureModel
from causalnex.structure.notears import from_pandas
import pandas as pd

# Learn causal structure from observational data
# Example: What causes COVID-19 severity?
covid_data = pd.DataFrame({
 'age': [...],
 'comorbidities': [...],
 'vaccination_status': [...],
 'viral_load': [...],
 'immune_response': [...],
 'severity': [...]
})

# Learn structure using NOTEARS algorithm
sm = from_pandas(covid_data)

# Visualize learned causal graph
sm.get_largest_subgraph().edges()
# Output: [('age', 'comorbidities'),
#   ('age', 'immune_response'),
#   ('comorbidities', 'severity'),
#   ('vaccination_status', 'immune_response'),
#   ('viral_load', 'severity'),
#   ('immune_response', 'severity')]

# Refine with domain knowledge
sm.add_edge('vaccination_status', 'viral_load') # Vaccine reduces viral load

# Estimate causal effects
from causalnex.inference import InferenceEngine
ie = InferenceEngine(sm)

# Query: Effect of vaccination on severity
effect = ie.query(
 {'vaccination_status': 1}, # Intervene: set vaccination = 1
 'severity'
)

Applications in Public Health

1. Policy Evaluation

Question: Did mask mandates reduce COVID-19 transmission?

Challenge: States that implemented mandates differ from those that did not (confounding)

Causal approach: Difference-in-differences, synthetic control

Abadie & Gardeazabal, 2003, American Economic Review - Synthetic control methods

2. Personalized Treatment

Question: Which patients benefit most from intervention X?

Causal ML: Heterogeneous treatment effects

from econml.dml import CausalForestDML

# Estimate individualized treatment effects
causal_forest = CausalForestDML()
causal_forest.fit(Y=outcomes, T=treatments, X=covariates)

# Predict treatment effect for new patient
new_patient = np.array([[age, sex, comorbidities, ...]])
treatment_effect = causal_forest.effect(new_patient)

if treatment_effect > threshold:
 recommend_treatment()
else:
 recommend_alternative()

3. Understanding Health Disparities

Question: Why do Black patients have worse COVID-19 outcomes?

Causal decomposition:

  • Direct effect of race (discrimination, bias)
  • Indirect effects via mediators (SES, comorbidities, healthcare access)

Method: Causal mediation analysis

Climate-Health AI: Preparing for Environmental Threats

Climate change increases heat, vector-borne, air-quality, and extreme-weather risks to health. AI is increasingly applied to predict, monitor, and respond to climate-driven health impacts.

Heat Wave Prediction and Response

Problem: Extreme heat causes preventable deaths and illness. Vulnerable populations (elderly, outdoor workers, those without AC) need advance warning.

AI applications:

  • Forecasting: Ensemble models combining weather data, urban heat island effects, and population vulnerability
  • Alert targeting: Identify high-risk individuals for proactive outreach
  • Resource allocation: Position cooling centers, emergency services

Example system:

# Simplified heat vulnerability prediction
def calculate_heat_risk(temperature, humidity, population_data):
    """
    Combine meteorological and demographic data for targeted alerts
    """
    # Heat index calculation
    heat_index = compute_heat_index(temperature, humidity)

    # Vulnerability factors
    vulnerability_score = (
        population_data['age_65_plus'] * 0.3 +
        population_data['no_ac_rate'] * 0.25 +
        population_data['outdoor_workers'] * 0.2 +
        population_data['chronic_disease_rate'] * 0.15 +
        population_data['social_isolation'] * 0.1
    )

    # Combined risk
    risk_score = heat_index * vulnerability_score

    return risk_score

Operational examples:

  • NYC Heat Vulnerability Index: Maps neighborhood-level risk
  • CDC HeatRisk: 7-day forecast combining NWS data with health factors
  • Google Flood Hub: AI-based flood forecasting in more than 80 countries

Vector-Borne Disease Modeling

Climate change expands ranges of disease-carrying mosquitoes and ticks. AI helps predict where outbreaks will emerge.

Key applications:

Disease Vector AI Application
Dengue Aedes aegypti Predict outbreaks 2–4 weeks ahead using temperature, rainfall, prior cases
Malaria Anopheles Model range expansion under climate scenarios
Lyme Ixodes Track northward tick migration, predict high-risk seasons
West Nile Culex Forecast transmission intensity from weather patterns

Data sources:

  • Satellite imagery (land use, water bodies, vegetation)
  • Weather station data (temperature, precipitation, humidity)
  • Case surveillance data (historical outbreak patterns)
  • Climate projections (CMIP6 scenarios)

Example: Dengue early warning (Singapore)

Singapore’s Environmental Health Institute uses machine learning combining weather data, Aedes trap counts, and case data to issue weekly dengue risk forecasts, enabling targeted vector control.

Example: Dengue risk mapping (Colombia)

A spatiotemporal U-Net++ framework combining satellite, census, climatic, and socioeconomic inputs generated high-resolution dengue risk maps across Colombia, reaching a test mean intersection-over-union (mIoU) of 0.66 at national scale and approximately 0.73 when restricted to five departments with high dengue incidence (Velandia et al., 2026). National-scale validation mIoU reached 0.74 against a test mIoU of 0.66, a generalization gap that operational deployment would need to absorb. Approaches built on remotely sensed and census inputs matter most where routine case reporting is sparse, though this remains research-stage work without operational validation.

A 2026 Globalization and Health comment proposes an IGAD-anchored five-layer AI Climate-Health Early Warning System (AI-CHEWS) for the Horn of Africa (Djibouti, Eritrea, Ethiopia, Kenya, Somalia, South Sudan, Sudan, and Uganda) that would fuse ICPAC earth-observation data, IDSR/DHIS2 case reporting, and displacement, nutrition, and WASH vulnerability layers, with SMS fallback in low-connectivity districts (Alasow et al., 2026). The authors state the region lacks a coordinated climate-health early warning system and note fewer than 50 dual-trained public-health and data-science professionals across the eight IGAD member states, outlining phased rollout from 3–5 border districts in Year 1 to 10–15 in Year 2 as proposed future work. The comment proposes a design; it trains no model for the Horn of Africa, analyzes no datasets, and reports no outbreak-detection performance or morbidity impact. The authors call for future CHEWS health-impact trials measuring morbidity, not only AUC.

Air Quality and Respiratory Health

Wildfire smoke, urban pollution, and allergens increasingly impact respiratory health. AI enables real-time monitoring and personalized alerts.

Applications:

  • Sensor fusion: Combine satellite data (MODIS, TROPOMI) with ground sensors for high-resolution air quality maps
  • Exposure modeling: Estimate individual exposure based on location history
  • Health impact prediction: Forecast emergency department visits from air quality forecasts
  • Vulnerable population alerts: Target warnings to those with asthma, COPD

Tools:

Climate-Health AI Challenges

Limitations and Uncertainties

Model uncertainty:

  • Climate projections have wide confidence intervals
  • Cascade of uncertainty: climate model → exposure model → health model
  • Behavioral adaptation (AC adoption, migration) hard to predict

Data gaps:

  • Historical health data often lacks climate-relevant variables
  • Vulnerable populations underrepresented in research
  • Real-time environmental monitoring sparse in many regions

Equity concerns:

  • Climate impacts disproportionately affect marginalized communities
  • AI systems may not account for differential vulnerability
  • Alert systems require connectivity and language accessibility

Resources

9. Preparing for Emerging Technologies

Technology Readiness Assessment

Questions to ask:

  1. What problem does this solve?
    • Is it a real problem for public health?
    • Do we have other solutions?
    • What’s the value add?
  2. What’s the current maturity? (TRL)
    • Proof of concept or production-ready?
    • Who else is using it?
    • What’s the timeline to practical deployment?
  3. What are the requirements?
    • Data infrastructure
    • Computational resources
    • Expertise and training
    • Budget and sustainability
  4. What are the risks?
    • Technical risks (does not work as expected)
    • Ethical risks (bias, privacy, equity)
    • Organizational risks (workforce, change management)
    • Financial risks (cost overruns, vendor lock-in)

Building Organizational Capacity

1. Workforce Development

Roles needed:

  • AI-literate public health practitioners - Understand capabilities/limitations
  • Technical specialists - Implement and maintain systems
  • Translators - Bridge public health and AI communities
  • Ethicists - Assess ethical risks and trade-offs

Training approaches:

  • Upskill existing workforce (courses, workshops)
  • Hire AI talent into public health agencies
  • Partner with academic institutions
  • Engage AI consultants for specific projects

2. Infrastructure Investment

Computational infrastructure:

  • Cloud computing accounts (AWS, GCP, Azure)
  • High-performance computing clusters
  • Data storage and management systems
  • MLOps platforms

Data infrastructure:

  • Electronic disease surveillance systems
  • EHR integration capabilities
  • Data quality monitoring
  • Privacy-preserving data sharing

3. Partnerships and Collaborations

Internal:

  • IT departments
  • Legal and compliance teams
  • Leadership and decision-makers

External:

  • Academic research institutions
  • AI companies and vendors
  • Other public health agencies
  • Community stakeholders

Pilot Project Framework

Start small, learn fast, scale what works

Phase 1: Proof of Concept (3–6 months)

  • Select well-defined, limited-scope problem
  • Use existing data and tools where possible
  • Measure baseline performance
  • Set success criteria upfront

Phase 2: Pilot Implementation (6–12 months)

  • Deploy in controlled setting (1–2 sites)
  • Monitor performance closely
  • Collect user feedback
  • Iterate based on learnings

Phase 3: Scale and Sustain (12+ months)

  • Expand to additional sites
  • Integrate into workflows
  • Establish maintenance procedures
  • Plan for long-term sustainability

10. Risks and Ethical Considerations

Emerging Risks

1. Autonomous AI Systems

Concern: AI making decisions without human oversight

Example: Automated triage system that denies care

Mitigation: Human-in-the-loop, override mechanisms, audit trails

2. Synthetic Data and Deepfakes

Concern: Generated images/videos indistinguishable from real

Public health impact:

  • Fake health information going viral
  • Undermining trust in public health messaging
  • Fraudulent research data

Detection: AI-generated content detectors, watermarking, provenance tracking

3. Dual-Use Technologies

Concern: Technologies with beneficial and harmful applications

Example: AI-designed pathogens (gain-of-function concerns)

Governance: Oversight, publication guidelines, biosecurity measures

4. Concentration of Power

Concern: Few tech companies control critical AI infrastructure

Risks:

  • Vendor lock-in
  • Lack of transparency
  • Profit-driven rather than health-driven
  • Geopolitical dependencies

Mitigation: Open-source alternatives, public AI infrastructure, regulation

5. Environmental and Resource Costs

Concern: Training and deploying large AI models consume vast computational resources, contributing to carbon emissions and environmental impact.

Energy consumption dimensions:

  • Training costs: Large language models require substantial electricity for initial training (though this is a one-time cost per model)
  • Inference costs: Cumulative energy from billions of queries adds up significantly
  • Water consumption: Data centers require cooling, with large models consuming thousands of liters during training
  • Hardware lifecycle: GPU manufacturing, rare-earth mining, and electronic waste contribute additional environmental burden

Scale in healthcare contexts:

At the level of individual queries, energy and water consumption may appear minimal. However, cumulative use in healthcare settings grows with volume:

  • Daily clinical use: Ambient scribing, documentation assistance, electronic health record queries across thousands of facilities
  • Triage and decision support: Millions of patient interactions daily
  • Research and analysis: Large-scale data processing for epidemiological studies

For context on scale, ChatGPT’s daily CO2 emissions have been estimated to equal those of 400–800 U.S. households, and healthcare deployments may carry an even larger footprint per query because of model size and local hosting requirements (Kleinig et al., 2024, Internal Medicine Journal).

LMIC considerations:

Environmental costs disproportionately affect resource-limited settings:

  • Many LMICs lack renewable energy infrastructure, making AI deployment more carbon-intensive
  • Cloud-dependent models require continuous connectivity and energy-intensive data transmission
  • Edge AI and locally deployed models can reduce but not eliminate environmental impact
  • Trade-off: Environmental costs vs. health benefits must be evaluated contextually

Mitigation strategies:

  • Model efficiency: Quantization, pruning, and distillation reduce computational requirements without major performance loss (see Edge AI section)
  • Renewable energy: Prioritize data centers powered by renewable sources
  • Selective deployment: Reserve computationally expensive models for high-value use cases
  • Transparency: Report carbon footprint and resource consumption for AI deployments
  • Open-weight models: DeepSeek and similar efficient architectures have been reported to achieve competitive performance with substantially lower computational requirements

Under-reported impacts:

Current environmental reporting typically focuses on electricity use during model operation, while underemphasizing:

  • Hardware manufacturing emissions (GPU production, rare-earth mining)
  • Water consumption for cooling (particularly problematic in water-scarce regions)
  • Full lifecycle analysis from development through deployment to retirement

Best practice: Conduct environmental impact assessments for large-scale AI deployments, particularly when deploying in resource-limited settings where trade-offs between health benefits and environmental costs require explicit evaluation.

Responsible Innovation Principles

Stilgoe et al., 2013, Research Policy - Responsible innovation framework

Four dimensions:

  1. Anticipation - Foresee potential impacts (intended and unintended)
  2. Reflexivity - Question assumptions and framings
  3. Inclusion - Engage diverse stakeholders
  4. Responsiveness - Adapt based on evidence and values

Applied to emerging AI:

  • Anticipate: What could go wrong? Who might be harmed?
  • Reflect: Are we solving the right problem? Whose interests are prioritized?
  • Include: Are affected communities involved in design?
  • Respond: Are we monitoring impacts and adjusting course?

11. Key Takeaways

Essential Points

Technology Landscape:

  • AI capabilities and compute availability are changing rapidly, but no single doubling interval describes all capabilities or systems
  • Several technologies are moving from research toward bounded operational use
  • Public health can shape development by engaging early

Closest to Bounded Use (task-specific evaluation still required):

  1. Multimodal foundation models - Candidate uses in clinical documentation, literature synthesis, and multilingual health communication, with source verification and human review
  2. Federated learning - Multi-site model training without pooling raw records, with leakage testing and governance
  3. Edge AI - Offline inference on local devices, validated on the target hardware and population

Promising but Largely Theoretical for Public Health Decisions:

  1. Digital twins - Conditional simulation of defined individuals, facilities, or populations
  2. AI drug discovery - Early-stage design and prioritization; clinical development still required
  3. Causal AI - Methods for estimating intervention effects under stated assumptions

Research Stage, No Fixed Date:

  1. Quantum computing - Advantage over classical methods not yet shown for public health tasks

Key Preparation Steps:

  • Assess organizational readiness (infrastructure, workforce, partnerships)
  • Start with pilot projects on well-defined problems
  • Build partnerships with AI researchers and companies
  • Invest in workforce training and data infrastructure
  • Engage in responsible innovation (anticipate, reflect, include, respond)

Guiding Philosophy: > “The best way to predict the future is to invent it.” - Alan Kay

Public health should not be a passive recipient of AI technologies developed elsewhere. Agencies that engage early can shape development toward public health needs.

Hands-On Exercise

Exercise: Assess an Emerging Technology for Your Organization

Objective: Evaluate the readiness and potential impact of an emerging technology for a specific public health application.

Time: 60–90 minutes

Part 1: Technology Selection (15 min)

Choose one emerging technology from this chapter:

  • Multimodal foundation models
  • Federated learning
  • Edge AI
  • Digital twins
  • Causal AI

And one public health application:

  • Disease surveillance
  • Health equity intervention
  • Emergency response
  • Chronic disease management
  • Maternal/child health

Deliverable: One-paragraph description of your chosen technology-application pair.

Part 2: Readiness Assessment (30 min)

Evaluate organizational readiness across dimensions:

Technical Readiness:

  • What data infrastructure exists?
  • What computational resources are available?
  • What technical expertise does the team have?

Workforce Readiness:

  • Who would need training?
  • What skills are missing?
  • How long would training take?

Organizational Readiness:

  • Do stakeholders understand the technology?
  • Is leadership supportive?
  • Are there change management processes?

Financial Readiness:

  • What’s the estimated budget?
  • Are there funding sources?
  • What’s the expected ROI?

Deliverable: Readiness assessment table with scores (1–5) and justifications for each dimension.

Part 3: Pilot Project Design (30 min)

Design a 6-month pilot project to test the technology:

Problem Statement:

  • What specific problem will you address?
  • What are current limitations?
  • What’s the expected improvement?

Approach:

  • What’s the technical implementation plan?
  • What data will you use?
  • What metrics will you track?

Success Criteria:

  • What outcomes indicate success?
  • What’s the minimum viable result?
  • How will you measure impact?

Risks and Mitigations:

  • What could go wrong?
  • How will you mitigate risks?
  • What’s the contingency plan?

Deliverable: 2-page pilot project proposal.

Part 4: Ethical Analysis (15 min)

Apply responsible innovation framework:

Anticipate:

  • What unintended consequences might occur?
  • Who might be harmed?
  • What’s the worst-case scenario?

Reflect:

  • Are you solving the right problem?
  • Whose interests are prioritized?
  • What assumptions are you making?

Include:

  • Which stakeholders should be involved?
  • How will you incorporate community input?
  • Are affected populations represented?

Respond:

  • How will you monitor for problems?
  • What triggers would cause you to pause/stop?
  • How will you adapt based on feedback?

Deliverable: 1-page ethical analysis with mitigation strategies.

Bonus Challenge

Create a 5-minute presentation pitching your pilot project to leadership. Include:

  • Problem statement
  • Technology overview (accessible to non-technical audience)
  • Expected benefits
  • Resource requirements
  • Timeline
  • Risk mitigation

Check Your Understanding

Test your knowledge of emerging AI technologies and their applications in public health. Each question builds on the key concepts from this chapter.

Question 1

A public health agency is considering three emerging AI technologies for investment: (A) Multimodal foundation models for clinical documentation (TRL 7–8, commercially available), (B) Federated learning for multi-state surveillance collaboration (TRL 5–6, requires infrastructure development), or (C) Quantum computing for epidemic simulation (TRL 2–3, mostly research stage). With limited budget and 18-month timeline, which should be prioritized and why?

  1. Quantum computing, because it has the highest potential payoff and will position the agency as a technology leader
  2. Multimodal foundation models, because they’re production-ready, address immediate needs, and have proven value
  3. Federated learning, because it balances innovation with feasibility and solves a real collaborative challenge
  4. All three equally, using a diversified portfolio approach to hedge risk

Correct Answer: b) Multimodal foundation models, because they’re production-ready, address immediate needs, and have proven value

This question tests understanding of technology readiness levels (TRL) and practical decision-making for technology adoption, key themes emphasized in the chapter’s preparation section.

TRL Framework Application:

Technology readiness levels (TRL) run from 1 (basic principles) to 9 (proven in operation). The chapter’s readiness assessment asks about current maturity before any investment. Each option is analyzed below:

Option A: Quantum Computing (TRL 2–3)

  • Status: Basic research, proof-of-concept stage
  • Timeline: The chapter’s FAQ states that no fixed date for public health use is defensible
  • Reality check: “Still noisy, error-prone, limited to small problems”
  • Risk: 18 months is far too short for research-stage technology to become operational
  • Chapter guidance: Prepare by learning quantum algorithm fundamentals and identifying problems with potential speedup, not by deploying

Option B: Multimodal Foundation Models (TRL 7–8)

  • Status: Production-ready, commercially available (GPT-4 Vision, Med-PaLM 2)
  • Timeline: Deployable immediately, mature within 18 months
  • Candidate uses: The chapter lists clinical documentation, literature synthesis, and multilingual health communication, each requiring task-specific evaluation
  • Immediate benefit: Addresses current needs (documentation burden, communication challenges)
  • Deployment: Commercially available, though local evaluation and human review are still required

Option C: Federated Learning (TRL 5–6)

  • Status: Lab validation, prototype testing stage
  • Timeline: Feasible in 18 months with infrastructure investment
  • Real applications: Chapter cites MELLODDY, federated brain tumor segmentation, and Google Gboard
  • Challenge: “Requires infrastructure development”, significant setup cost
  • Value: Solves real problem (multi-site collaboration) but needs substantial groundwork

The Decision Framework:

The chapter’s “Technology Readiness Assessment” section provides clear guidance:

  1. What problem does this solve?
    • A (Quantum): Hypothetical future problems (complex simulation)
    • B (Multimodal): Current problems (documentation, communication, multilingual outreach)
    • C (Federated): Real problem (multi-site collaboration) but requires stakeholder alignment
  2. What’s the current maturity?
    • A: Research stage, not deployment-ready
    • B: Production-ready, commercially available
    • C: Prototype stage, needs development
  3. What’s the timeline to practical deployment?
    • A: 10–15+ years
    • B: Immediate to 6 months
    • C: 12–24 months with infrastructure
  4. What are the requirements?
    • A: Specialized quantum expertise, quantum hardware access, research partnerships
    • B: API access, integration work, user training (manageable)
    • C: Multi-site coordination, infrastructure build-out, data governance agreements

Given limited budget and 18-month timeline, Option B is the clear choice.

Why other options are wrong:

Option (a) commits the “shiny object” fallacy, prioritizing futuristic technology over practical needs. The chapter warns against this through its readiness assessment. Quantum computing’s “highest potential payoff” is speculative and has no defensible date. “Technology leadership” means being effective with current technology, not gambling on research that may never materialize for your use case. The chapter’s quantum section explicitly positions this as long-term preparation, not near-term deployment.

Option (c) is more defensible than (a) but misweights timeline constraints. Federated learning could be valuable but requires:

  • Infrastructure development at each site
  • Data governance agreements across multiple jurisdictions
  • Technical expertise for implementation
  • Stakeholder buy-in from all participating sites

While feasible in 18 months with sufficient resources, the “limited budget” constraint makes this challenging. The chapter positions federated learning as “emerging” (not yet mainstream) for good reason: implementation overhead is substantial.

Option (d) violates the principle of focused resource allocation. “Diversified portfolio” makes sense for large R&D operations, not resource-limited public health agencies with 18-month timelines. The chapter’s “Start small, learn fast, scale what works” philosophy argues for focused pilots, not scattered investments. Spreading limited budget across three technologies (especially including one that’s pure research) means none get sufficient resources.

The chapter’s evidence tiers:

The Essential Points place multimodal foundation models among the technologies closest to bounded use, for candidate uses in clinical documentation, literature synthesis, and multilingual health communication with source verification and human review.

This supports Option B.

Practical implementation path:

Months 1–3:

  • Pilot multimodal AI for clinical documentation (reduce burden)
  • Test multilingual health communication (COVID-19 vaccine messaging in multiple languages)
  • Demonstrate value with quick wins

Months 4–9:

  • Scale successful pilots
  • Integrate into workflows
  • Train staff

Months 10–18:

  • Full deployment
  • Measure outcomes
  • Iterate based on feedback

Meanwhile:

  • Monitor federated learning maturity for future adoption
  • Learn quantum fundamentals through training, not deployment

Real-world precedents:

Commercial multimodal models are available now, but the chapter’s TL;DR still requires task-specific evaluation, source verification, human escalation, and monitoring before operational use.

For practitioners:

The chapter’s message is clear: match technology selection to organizational capacity and timeline. Emerging technologies are promising, but deployment decisions should prioritize:

  1. Evidence of value on the specific task
  2. Maturity (production-ready)
  3. Timeline fit (achievable in your window)
  4. Resource requirements (manageable with your budget)

Multimodal foundation models satisfy all four criteria; quantum computing satisfies none; federated learning is borderline depending on resources and stakeholder readiness.

The key lesson: match the technology to the decision. The chapter’s responsible innovation framework emphasizes solving real problems with appropriate tools, not adopting the newest technology for its own sake. Option B embodies this pragmatic approach.

Question 2

A research consortium wants to train a tuberculosis prediction model using patient data from 20 hospitals across 5 countries. Privacy regulations prohibit data sharing, and several countries require that data never leave national borders. Which technical approach would BEST enable this collaboration while respecting data sovereignty?

  1. Have all hospitals de-identify data using k-anonymity (k=10) and share to a central cloud server for training
  2. Use federated learning where models train locally at each hospital and only aggregated model updates are shared internationally
  3. Create synthetic data at each hospital using GANs, share the synthetic datasets, and train centrally
  4. Build separate models at each hospital and manually combine predictions using ensemble methods

Correct Answer: b) Use federated learning where models train locally at each hospital and only aggregated model updates are shared internationally

This question tests understanding of federated learning’s core value proposition and when it’s the appropriate solution, a major theme in the chapter’s federated learning section.

The Scenario’s Constraints:

  1. Privacy regulations prohibit data sharing - Hard legal constraint
  2. Data sovereignty requirements - Data cannot leave national borders
  3. Multi-site collaboration needed - 20 hospitals across 5 countries
  4. Goal: Train a single, collaborative model

Federated Learning as the Solution:

The chapter presents federated learning explicitly for this scenario: “The Problem: Data Silos in Public Health.” The McMahan et al. (2017) FedAvg algorithm is designed precisely for this use case.

How Federated Learning Addresses Each Constraint:

Privacy regulations: Raw patient data are not shared; only model parameters (gradients/weights) are transmitted. The chapter states: “Raw patient records stay at each institution.”

Data sovereignty: Training happens locally within each country’s borders. The central server (which could be in any country or neutral territory) only receives mathematical model updates, not patient data. This satisfies regulations requiring data stay in-country.

Multi-site collaboration: The chapter’s algorithm walkthrough shows exactly how this works:

  1. Central server initializes model
  2. Each hospital trains on local data
  3. Hospitals send model updates (not data)
  4. Server aggregates using FedAvg
  5. Repeat

Scale: The chapter cites Google Gboard with “millions of mobile devices”; 20 hospitals is feasible.

Real-World Validation:

The chapter cites relevant precedents:

Federated brain tumor segmentation:

  • 10 institutions
  • Brain tumor segmentation
  • Finding: the federated model reached 99% of the model quality achieved with centralized data

This is a comparable scenario: multi-institutional collaboration on sensitive medical data.

MELLODDY:

  • 10 pharmaceutical companies
  • Drug discovery collaboration
  • 10M+ compounds kept at each company
  • Result: Better models than any single company alone

Why other options fail:

Option (a), K-anonymity + central sharing:

Multiple problems:

  1. Still violates data sovereignty: Even de-identified data leaving national borders may violate regulations. Many data protection laws (GDPR, local regulations) restrict data transfer regardless of de-identification.

  2. K-anonymity insufficient: K-anonymity reduces but does not eliminate re-identification risk. For 20 hospitals across diverse populations, achieving k=10 while preserving utility is challenging. Small hospitals or rare TB subtypes might not have sufficient patients.

  3. Data quality loss: K-anonymity requires generalization (exact ages → age ranges, precise locations → regions) which degrades predictive power for medical models.

  4. Trust issues: Hospitals/countries may not trust “de-identified” data, especially given documented re-identification risks.

Option (c), Synthetic data:

Problems:

  1. Quality concerns: Synthetic data may not capture rare events or complex relationships critical for medical prediction

  2. Validation challenge: How do you validate synthetic data quality without comparing to real data (creating a chicken-and-egg problem)?

  3. Privacy leakage risk: GANs can leak training data if not properly implemented with differential privacy.

  4. Does not solve sovereignty: Synthetic data still represents aggregated information from real patients. Some regulations may still restrict its transfer. And you need to share the synthetic data, which still crosses borders.

  5. Complexity: Each hospital generates synthetic data (requires expertise), shares internationally, then trains centrally. This is more complex than federated learning while providing weaker privacy guarantees.

Option (d), Separate models + manual ensembling:

This does not solve the collaboration problem:

  1. No knowledge transfer: Each hospital trains only on local data, missing the benefit of multi-site learning that motivated collaboration.

  2. Manual ensembling: “Manually combine predictions” does not provide principled aggregation. How do you weight hospitals? How do you handle distribution shift?

  3. No collaborative improvement: Unlike federated learning where all sites benefit from collective training, this approach means small hospitals with limited data get worse models.

The chapter positions federated learning as a response to this problem: “Federated learning approach: 1. Train model locally at each site, 2. Share only model updates (not data), 3. Aggregate updates centrally, 4. Raw patient records stay at each institution.”

Additional Considerations:

Enhanced Privacy:

Common extensions include:

  • Secure aggregation: Central server cannot see individual hospital updates
  • Differential privacy: Add noise to updates for formal privacy guarantees
  • Encrypted aggregation: Homomorphic encryption for extra security

For sensitive TB data, combining federated learning with differential privacy (DP-FL) provides formal privacy guarantees, at some cost to model accuracy.

Challenges and Mitigations:

The chapter’s challenges table shows federated learning is not without issues:

  • Non-IID data: Different patient populations across countries → Use FedProx
  • Communication costs: International data transfer can be expensive → Compress updates
  • Malicious participants: Potential for poisoning → Robust aggregation methods

But these are solvable technical problems, not fundamental blockers like sovereignty violations.

Practical Implementation:

Using the chapter’s Flower framework example, implementation follows these steps:

  1. Each hospital runs HospitalClient code locally
  2. Central coordinating server runs FedAvg strategy
  3. HTTPS communication for model updates (lightweight, KB to MB, not GB)
  4. After 10–20 rounds, collaborative model complete

The chapter’s evidence tiers:

The Essential Points place federated learning among the technologies closest to bounded use: multi-site model training without pooling raw records, with leakage testing and governance.

For practitioners:

International health collaborations increasingly face data sovereignty challenges. Federated learning is specifically designed for this:

  • Respects local data governance
  • Enables genuine collaboration (not just separate analyses)
  • Scales to many sites
  • Works with existing ML frameworks (TensorFlow, PyTorch)
  • Has successful healthcare precedents

The TB prediction scenario in the question is the kind of use case federated learning was designed for.

Question 3

A rural health clinic in sub-Saharan Africa wants to implement AI-based malaria diagnosis from smartphone photos of blood smears. Internet connectivity is intermittent (available 2–3 hours/day), and cloud API costs are prohibitive at scale. Which approach would be MOST appropriate?

  1. Wait until reliable internet infrastructure is available, then deploy cloud-based AI via API calls
  2. Deploy edge AI with TensorFlow Lite models running entirely on smartphones, enabling offline diagnosis with no internet required
  3. Use SMS-based system to send images to central server during connectivity windows for batch processing
  4. Provide tablets with pre-downloaded training data so clinicians can train models locally as needed

Correct Answer: b) Deploy edge AI with TensorFlow Lite models running entirely on smartphones, enabling offline diagnosis with no internet required

This question tests understanding of edge AI’s value proposition and context-appropriate technology design, critical themes in the chapter’s Edge AI section and the Looking Ahead discussion of global health equity.

The Scenario’s Constraints:

  1. Rural, resource-limited setting
  2. Intermittent connectivity (2–3 hours/day available)
  3. Cost sensitivity (cloud APIs “prohibitive at scale”)
  4. Critical healthcare need (malaria diagnosis)
  5. Existing infrastructure (smartphones available)

Edge AI as the Solution:

The chapter dedicates an entire section to edge AI, defining it as: “Running AI models directly on devices (smartphones, tablets, IoT sensors) rather than in the cloud.”

Why Edge AI Matters for This Scenario:

The chapter lists exactly these benefits:

  • Offline capability: “Works in areas with poor connectivity”
  • Cost: “No cloud inference fees at scale”
  • Low-latency: “Instant results without internet delay”
  • Privacy: “Raw data can remain on the device” (additional benefit)

Related Example in the Chapter:

The chapter provides a closely related use case:

“Example: Malaria Detection from Blood Smears” with an illustrative TensorFlow Lite sketch:

def diagnose_malaria(image_path):
 """
 Analyze blood smear image for malaria parasites
 Runs entirely on mobile device, no internet required
 """

Illustrative assumptions from the chapter (not measured outcomes):

  • Diagnosis time: 10 minutes → 30 seconds
  • Cost: $5 microscopy + technician → $0 marginal cost
  • Accessibility: Urban hospital → Rural clinic with smartphone
  • Scalability: Limited by trained technicians → Limited by smartphones

This is precisely the rural clinic scenario in the question.

Technical Feasibility:

The chapter demonstrates model compression techniques:

1. Quantization: Reduce model from 32-bit to 8-bit

  • Storing each weight in 1 byte instead of 4 reduces weight storage by about 75% (illustrative arithmetic)
  • Feasible for smartphone storage and processing

2. Example code provided:

converter = tf.lite.TFLiteConverter.from_keras_model(model)
converter.optimizations = [tf.lite.Optimize.DEFAULT]
tflite_model = converter.convert()

3. Hardware availability:

  • “Google Coral: 4 TOPS, $25”
  • “Apple Neural Engine: Built into iPhone/iPad”
  • Modern smartphones can run these models

Real-World Precedent:

The chapter cites Project Premonition (Microsoft Research) using edge AI for mosquito species identification in remote areas, a similar context (rural, limited connectivity, disease surveillance).

Why Other Options Fail:

Option (a), Wait for infrastructure:

This is the opposite of context-appropriate design, a theme the Looking Ahead section carries into the next chapter.

Waiting for infrastructure means:

  • Delayed healthcare delivery (people die from untreated malaria)
  • No agency over solution (dependent on external infrastructure investment that may never come)
  • Missed opportunity to use available technology (smartphones are already there)

Waiting for ideal infrastructure leaves the populations with the greatest need without service.

Option (c), SMS batch processing:

Multiple problems:

  1. Latency: Batch processing during 2–3 hour connectivity windows means multi-hour delays for diagnosis. Malaria diagnosis needs to be rapid for treatment decisions.

  2. Still requires connectivity: Depends on the intermittent internet, defeating the purpose. If internet is down, no diagnoses happen.

  3. Cost: SMS with image attachments (MMS) can be expensive, and still requires server-side processing (cloud costs).

  4. Scalability: Central server becomes bottleneck. If 100 clinics queue images during connectivity window, server overload.

  5. Privacy: Images transmitted off-device, creating privacy risks.

The chapter’s edge AI section lists offline capability and no cloud inference fees as advantages over this client-server model.

Option (d), Local training:

This fundamentally misunderstands machine learning deployment:

  1. Training vs. inference: Inference (making predictions) is lightweight and suitable for smartphones. Training (learning from data) is computationally intensive and requires GPUs, large datasets, and expertise.

  2. Impractical: Clinicians are not ML engineers. “Train models locally as needed” is not feasible without extensive technical expertise, computational resources, and training data.

  3. Quality control: Locally trained models without validation could produce dangerous errors.

  4. Unnecessary: A well-trained malaria detection model deployed once works for all cases. No need for site-specific training.

The chapter’s edge AI section discusses deploying pre-trained models to devices, not local training.

Implementation Path (illustrative):

Model Development (Centralized):

  1. Train malaria detection model on large labeled dataset (hospitals/research institutions with connectivity)
  2. Validate on diverse blood smear types
  3. Compress using quantization for mobile deployment
  4. Package as TensorFlow Lite model

Deployment (Edge):

  1. Distribute .tflite model file to smartphones (one-time download or via SD card)
  2. Install simple app that loads model and processes images
  3. Clinicians photograph blood smears with smartphone camera
  4. App provides instant diagnosis on-device
  5. Results saved locally, uploaded to central database when connectivity available (optional, for surveillance)

Sustainability:

  • No ongoing connectivity costs
  • No cloud inference fees (device, maintenance, and validation costs remain)
  • Minimal maintenance (update model annually via occasional connectivity or physical media)
  • Scales without per-query fees (marginal inference cost near zero)

The Chapter’s Evidence Tiers:

The Essential Points place edge AI among the technologies closest to bounded use: offline inference on local devices, validated on the target hardware and population.

Equity and Access:

The chapter’s Looking Ahead section points to context-appropriate AI design for resource-limited settings, the subject of AI in Global Health and Equity.

Edge AI fits this principle. Waiting for infrastructure or depending on connectivity excludes those most in need.

For practitioners:

Rural health technology must be:

  1. Offline-capable: Cannot depend on connectivity
  2. Low-cost: Marginal costs must approach zero for sustainability
  3. Simple: Works with available infrastructure (smartphones, not specialized equipment)
  4. Robust: Functions in challenging environments (heat, dust, humidity)

Edge AI satisfies all four. Cloud-dependent solutions (options a, c) fail criteria 1–2. Local training (option d) fails criteria 2–3.

The chapter’s malaria example is an illustrative sketch that calls undefined helper functions. Any real deployment requires local diagnostic validation against microscopy or another reference standard before use.

Question 4

A public health researcher wants to understand whether a new community health worker program actually caused improved maternal health outcomes, or whether the correlation is due to confounding (e.g., wealthier communities got the program AND had better baseline health infrastructure). Standard predictive AI shows strong correlation between the program and outcomes. What approach would provide the STRONGEST causal evidence?

  1. Train a more sophisticated deep learning model with additional confounders to improve predictive accuracy
  2. Use causal inference methods like propensity score matching or instrumental variables to estimate treatment effect
  3. Increase sample size to make the correlation more statistically significant (p < 0.001)
  4. Run the predictive model on held-out test data to verify the correlation generalizes

Correct Answer: b) Use causal inference methods like propensity score matching or instrumental variables to estimate treatment effect

This question tests understanding of the fundamental distinction between correlation and causation, the central theme of the chapter’s Causal AI section, and when causal inference methods are necessary.

The Core Problem:

The chapter emphasizes: “Current AI: Excellent at finding correlations. Problem: Correlation ≠ Causation.”

The ice cream/drowning example illustrates this perfectly: predictive AI would identify the correlation and might recommend “ban ice cream to prevent drowning,” but causal understanding reveals hot weather as the common cause, leading to the correct intervention (increase lifeguards on hot days).

The Scenario’s Challenge:

The researcher faces classic confounding: communities that received the program may differ systematically from those that did not. Wealthy communities might:

  • Have better baseline health infrastructure
  • More educated population
  • Better nutrition and housing
  • More likely to advocate for and receive the program

A simple correlation between program and outcomes could reflect these pre-existing differences rather than program effectiveness.

Why Option B is Correct:

The chapter’s Causal AI section covers methods for this problem. Two specific techniques mentioned:

1. Propensity Score Matching (the chapter provides an implementation sketch):

The chapter shows matching treated and untreated communities with similar likelihood of receiving treatment:

def propensity_score_matching(data, treatment_col, outcome_col, covariate_cols):
 # Estimate propensity scores
 ps_model = LogisticRegression()
 ps_model.fit(X, treatment)

 # Match treated to control based on propensity
 # Calculate treatment effect

This creates “apples-to-apples” comparisons by matching communities that were equally likely to get the program but some did and some did not (quasi-randomization).

2. Instrumental Variables (also in chapter):

The chapter explains finding a variable that affects treatment but not outcome (except through treatment). For example:

  • Instrument: Geographic proximity to NGO headquarters
  • Affects treatment: Closer communities more likely to receive program (logistics)
  • Does not directly affect outcomes: Except via the program itself

The chapter provides code using EconML’s DMLIV for exactly this estimation.

Pearl’s Causal Hierarchy (from the chapter):

Level Question AI Capability
Association What if I see X? Standard ML
Intervention What if I do X? Requires causal models
Counterfactual What if I had done X? Hardest

The researcher needs intervention-level reasoning (“What if we deploy the program?”), not association (“Communities with program have better outcomes”). Standard ML only provides association.

Why Other Options Fail:

Option (a), More sophisticated predictive model:

This is the “more data, more features, better model” fallacy. The chapter explicitly warns against this:

“Predictive AI: ‘High ice cream sales → High drowning risk’”

A deep learning model with more confounders will find better correlations but still cannot distinguish causation from confounding. You could add 1000 features and achieve 99% accuracy, but still not know if the program causes improvements.

The chapter’s Limitations of Predictive AI subsection states the point directly: Correlation ≠ Causation. No amount of predictive sophistication solves this.

Option (c), Increase sample size for significance:

Statistical significance (p < 0.001) only means “the correlation is unlikely due to random chance.” It does NOT address confounding.

With larger sample size, you’ll be very confident there’s a correlation, but still will not know if it’s causal. The chapter’s discussion of policy evaluation emphasizes you need causal methods, not just stronger correlations.

Example: With 1 million communities, you might have p < 10^-50 for the program-outcome correlation, but it could still be entirely due to wealth confounding.

Option (d), Test set validation:

Held-out test data validates that the correlation generalizes (model is not overfitting). But it still only shows the pattern holds across different samples, not that the relationship is causal.

If wealthy communities in both training and test sets got the program, the correlation will generalize perfectly while still being confounded.

Real-World Application:

The chapter’s policy evaluation section addresses exactly this scenario:

“Question: Did mask mandates reduce COVID-19 transmission? Challenge: States that implemented mandates differ from those that did not (confounding) Causal approach: Difference-in-differences, synthetic control”

Replace “mask mandates” with “community health worker program” and “COVID transmission” with “maternal health outcomes”, same structure, same need for causal methods.

Implementation Path:

Propensity Score Matching:

  1. Identify covariates that predict program assignment (wealth, education, baseline health)
  2. Estimate propensity scores for each community
  3. Match program communities to similar non-program communities
  4. Compare outcomes between matched pairs
  5. Estimate average treatment effect

Instrumental Variable:

  1. Find valid instrument (e.g., distance to NGO office)
  2. Use two-stage approach:
    • First stage: Instrument predicts program assignment
    • Second stage: Predicted assignment predicts outcomes
  3. Estimate causal effect from second stage

The Chapter’s Key Message:

“Goal: Understand cause-effect relationships, enabling:

  1. Counterfactual reasoning: ‘What would have happened if…?’
  2. Intervention planning: ‘What should we do to achieve X?’
  3. Explanation: ‘Why did Y happen?’”

For policy decisions (should we scale the program?), you need intervention-level reasoning. Predictive AI cannot provide this, causal inference can.

For practitioners:

When evaluating program effectiveness for policy decisions:

  • Association sufficient: Simple monitoring (is correlation still present?)
  • Causation required: Deciding to scale, modify, or terminate programs

The chapter’s ice cream example contrasts the wrong intervention (ban ice cream) with the right one (lifeguard patrols on hot days).

Deploying community health workers requires significant resources. The decision to scale nationwide needs causal evidence, not just predictive correlation. Option B provides that evidence through rigorous causal inference methods explicitly designed for this purpose.

Question 5

A pharmaceutical research consortium wants to accelerate drug discovery for a neglected tropical disease. They have identified a protein target and need to generate novel drug candidates, predict binding affinity, and assess toxicity. Which AI-accelerated approach would provide the most complete drug discovery pipeline?

  1. Use molecular generation models (VAE/GAN) to create candidates, then test all of them in wet lab experiments for binding and toxicity
  2. Use AlphaFold to predict target protein structure, then manually design candidates using traditional medicinal chemistry principles
  3. Deploy an integrated AI pipeline: generative models for candidate design, graph neural networks for binding prediction, and multi-task models for toxicity screening, then validate top candidates experimentally
  4. Use large language models to search PubMed for existing compounds that might bind the target, then repurpose them

Correct Answer: c) Deploy an integrated AI pipeline: generative models for candidate design, graph neural networks for binding prediction, and multi-task models for toxicity screening, then validate top candidates experimentally

This question tests understanding of the AI drug discovery ecosystem presented in the chapter and how different AI techniques work together in a modern discovery pipeline.

The Chapter’s AI Drug Discovery Framework:

The AI-Accelerated Drug and Vaccine Development section presents directional planning scenarios for each phase:

Phase Traditional With AI Improvement
Target identification 2–3 years 6–12 months 3–4x faster
Lead discovery 3–6 years 1–2 years 2–3x faster
Preclinical testing 1–2 years 6–12 months 1.5–2x faster

The chapter presents three specific AI techniques for the drug discovery process:

1. Molecular Generation (for candidate design):

The chapter shows transformer-based and GAN-based models generating novel molecules with desired properties:

def generate_drug_candidate(target_properties):
 # Generate novel molecules with:
 # - High binding affinity
 # - Low toxicity
 # - Oral bioavailability

This creates the candidate pool (thousands of potential molecules).

2. Binding Affinity Prediction (for filtering):

The chapter demonstrates graph neural networks for protein-ligand binding:

class ProteinLigandBindingPredictor(torch.nn.Module):
 # Predicts binding affinity in silico
 # Eliminates weak binders before synthesis

This filters candidates from thousands to hundreds based on predicted binding strength.

3. Toxicity Prediction (for safety screening):

The chapter discusses multi-task learning for toxicity endpoints:

  • Hepatotoxicity (liver damage)
  • Cardiotoxicity (heart issues)
  • Mutagenicity (DNA damage)
  • hERG inhibition (cardiac arrhythmia)

This eliminates toxic compounds before animal testing, reducing attrition.

Why Option C is Correct:

Integrated Pipeline Workflow:

An illustrative integrated workflow might proceed as follows:

Stage 1: Generative Design

  • Generate 10,000 candidate molecules using VAE/GAN/Transformer
  • Constrain generation to target properties (binds specified protein, drug-like properties)

Stage 2: Binding Prediction

  • Use graph neural networks to predict binding affinity for all 10,000 candidates
  • Filter to top 500 with predicted strong binding

Stage 3: Toxicity Screening

  • Run multi-task toxicity models on 500 candidates
  • Eliminate compounds with predicted toxicity
  • Narrow to top 50–100 candidates

Stage 4: Experimental Validation

  • Synthesize top 50–100 candidates
  • Wet lab testing for binding (biochemical assay)
  • Toxicity testing (cell cultures, animal models)
  • Advance top 5–10 to further development

Efficiency Gains:

This illustrative funnel shows how computational prioritization can reduce the number of compounds advanced to laboratory testing. The reduction is a planning assumption, not a measured universal effect.

Real-World Validation:

The chapter cites Insilico Medicine’s INS018_055, an AI-supported candidate evaluated in Phase II trials. The reported timeline was roughly 18 months from target discovery to preclinical candidate nomination; Phase I began in 2022. A 2026 review reported an approximately US$2.6 million early-program cost, not end-to-end development cost (Furukawa et al., 2026).

The program combined several AI-supported steps, not a single technique.

Why Other Options Fail:

Option (a), Generative models only, then full wet lab:

This uses AI for only one stage (generation) but then tests everything experimentally. Problems:

  1. Experimental burden: AI filtering can reduce the number of candidates advanced to laboratory testing, but useful throughput is program-specific.

  2. Cost: Realized savings depend on program design, assay burden, attrition, and development stage.

The chapter’s approach is generate → AI-filter → validate top candidates experimentally, not generate → test everything.

Option (b), AlphaFold only, then manual design:

This misunderstands how different AI tools fit together:

  1. AlphaFold provides structure, not candidates: The chapter presents AlphaFold for protein structure prediction. This is useful for understanding the target, but does not generate drug molecules.

  2. Design throughput: Computational generation can expand the candidate set, but useful throughput depends on filtering, synthesizability, assays, and medicinal-chemistry review.

  3. Search scale: AI can search a chemical space too large for exhaustive human or laboratory exploration.

While AlphaFold is valuable (chapter mentions it for understanding targets in neglected diseases), it’s only one piece. You still need generative models for candidates and predictive models for screening.

Option (d), LLM literature search for repurposing:

Drug repurposing is valuable but does not address the scenario’s need for novel candidates:

  1. Limited scope: Repurposing searches existing drugs. For neglected tropical diseases, few or no existing drugs may act on the chosen target.

  2. Not generative: LLMs searching literature do not create new molecules, they find existing ones. The chapter’s generative models (VAE, GAN, Transformers) create novel chemical structures.

  3. Missed AI capabilities: The question asks for “accelerate drug discovery,” implying novel compound development. The chapter’s AI drug discovery section focuses on de novo design, not just repurposing.

PubMed search is useful for background research, but the chapter’s drug discovery pipeline is about AI-designed molecules, not literature mining.

Pipeline boundary: A hypothetical pipeline may combine structure prediction, generative design, predictive screening, and experimental validation. The cited examples illustrate different roles and do not constitute one validated end-to-end workflow. The INS018_055 report used available TNIK crystal structures with Chemistry42, not AlphaFold as part of that candidate’s reported pipeline.

Practical Implementation:

AI may improve early-discovery feasibility for underfunded diseases, but evidence remains program-specific.

The reported early-program cost cannot be compared directly with capitalized end-to-end drug-development estimates. AI may reduce early discovery burden, but clinical development costs remain.

But this requires the full pipeline (option C), not just one AI technique.

For practitioners:

The chapter’s message is clear: AI drug discovery is not a single tool. It’s an integrated ecosystem. Each stage uses the appropriate AI technique:

  • Generation: Transformers, GANs, VAEs
  • Binding: Graph neural networks, molecular docking
  • Toxicity: Multi-task learning, QSAR models
  • Optimization: Reinforcement learning, active learning

The Insilico Medicine case illustrates an integrated AI-supported workflow. It does not establish a controlled causal estimate of time or cost savings.

Question 6

A public health agency wants to prepare for emerging AI technologies over the next 5 years. They have limited budget and need to prioritize investments. According to the chapter’s responsible innovation framework, which preparation strategy would be MOST effective?

  1. Purchase expensive quantum computing access now to gain first-mover advantage before competitors
  2. Invest heavily in one breakthrough technology (e.g., digital twins) with all resources to achieve deep expertise
  3. Start small pilot projects on mature technologies (TRL 6–7), build workforce capacity, and establish partnerships with AI researchers while monitoring emerging technologies
  4. Wait until all emerging technologies are fully mature (TRL 9) and standards are established before investing

Correct Answer: c) Start small pilot projects on mature technologies (TRL 6–7), build workforce capacity, and establish partnerships with AI researchers while monitoring emerging technologies

This question tests understanding of the chapter’s technology readiness assessment framework, responsible innovation principles, and practical preparation strategies for public health agencies.

The Chapter’s Preparation Framework:

The “Preparing for Emerging Technologies” and “Risks and Ethical Considerations” sections provide explicit guidance on how public health agencies should approach emerging AI.

Key Principles from the Chapter:

1. Technology Readiness Assessment:

Technology readiness levels (TRL) describe maturity:

  • TRL 1–3: Research (quantum computing for epidemiology)
  • TRL 4–6: Development (federated learning prototypes)
  • TRL 7–9: Deployment (GPT-4 for clinical documentation)

The chapter’s readiness assessment asks about current maturity, and its TL;DR classifies each claim as demonstrated, theoretical, or beyond current capabilities before investment.

2. Pilot Project Framework:

The chapter explicitly outlines “Start small, learn fast, scale what works”:

Phase 1: Proof of Concept (3–6 months)

  • Select well-defined, limited-scope problem
  • Use existing data and tools where possible
  • Set success criteria upfront

Phase 2: Pilot Implementation (6–12 months)

  • Deploy in controlled setting (1–2 sites)
  • Monitor performance closely
  • Iterate based on learnings

Phase 3: Scale and Sustain (12+ months)

  • Expand to additional sites
  • Integrate into workflows
  • Establish maintenance procedures

3. Workforce Development:

The chapter emphasizes building organizational capacity:

Roles needed:

  • AI-literate public health practitioners
  • Technical specialists
  • Translators (bridge public health and AI)
  • Ethicists

Training approaches:

  • Upskill existing workforce
  • Partner with academic institutions
  • Engage consultants for specific projects

4. Responsible Innovation Framework:

Stilgoe et al.’s four dimensions (Risks and Ethical Considerations section):

  1. Anticipation - Foresee potential impacts
  2. Reflexivity - Question assumptions
  3. Inclusion - Engage diverse stakeholders
  4. Responsiveness - Adapt based on evidence

Why Option C is Correct:

Option C embodies ALL of these principles in a balanced, practical strategy:

“Start small pilot projects on mature technologies (TRL 6–7)”

  • Aligned with the chapter’s readiness assessment
  • Near-term value (mature technologies work now)
  • Low risk (proven technologies)
  • Learning opportunity (gain hands-on experience)

“Build workforce capacity”

  • Addresses chapter’s emphasis on workforce as limiting factor
  • Sustainable (builds internal capability, not just vendor dependence)
  • Enables future technology adoption (trained staff can evaluate new technologies)

“Establish partnerships with AI researchers”

  • The chapter lists academic research institutions and AI companies and vendors as external partners
  • Access to expertise without full-time hiring costs
  • Influence technology development toward public health needs
  • Early awareness of emerging technologies

“While monitoring emerging technologies”

  • Responsible innovation’s “anticipation” dimension
  • Preparation without premature commitment
  • Example from chapter: prepare for quantum computing by learning fundamentals and identifying problems with potential speedup (not deploying)

This is the chapter’s recommended balanced approach.

Real-World Validation:

The chapter’s federated-learning examples (federated brain tumor segmentation and MELLODDY) show multi-institution collaboration built on shared protocols and partnerships. Both applied a method in development, neither research-stage (TRL 1–3) nor fully mature (TRL 9), to a bounded task. The chapter does not document how either consortium staged its adoption.

Why Other Options Fail:

Option (a), Quantum computing first-mover advantage:

This violates multiple chapter principles:

  1. Wrong TRL: Quantum computing is TRL 2–3 (basic research). The chapter’s FAQ states that no fixed date for public health use is defensible. With a 5-year timeframe, this is too early.

  2. Expensive with no near-term ROI: “Purchase expensive quantum computing access” wastes limited budget on technology that will not deliver value in 5 years.

  3. “First-mover advantage” fallacy: The chapter emphasizes public health should engage to shape development, not compete with tech companies. “First mover” makes sense for commercial products, not public health research.

  4. Neglects fundamentals: Chapter states quantum preparation should be “learning quantum algorithms fundamentals, identifying problems with potential quantum speedup”, not purchasing access.

Option (b), All resources on one technology:

This is high-risk, inflexible strategy that violates responsible innovation:

  1. Lack of diversification: What if digital twins do not pan out for your use case? All resources wasted.

  2. Ignores technology evolution: Five years is a long planning horizon for AI. Locking into one technology can prevent adoption of better-supported alternatives as evidence and systems change.

  3. Violates “reflexivity”: Responsible innovation requires questioning assumptions and adapting. All-in commitment prevents adaptation.

  4. Organizational risk: The chapter warns about vendor lock-in and concentration of power. Going all-in on one technology (especially from one vendor) creates dependency.

The chapter never recommends this approach, instead showing how different technologies serve different needs (federated learning for privacy, edge AI for resource-limited settings, causal AI for policy evaluation).

Option (d), Wait for TRL 9 maturity:

This is the opposite extreme, too conservative:

  1. Missed opportunity: By waiting for TRL 9 (full operational deployment), you miss the chance to shape technology development. The chapter’s Essential Points state that public health can shape development by engaging early.

  2. Always behind: By the time technology reaches TRL 9, it’s mature and commoditized. New technologies are already emerging. This creates perpetual catch-up.

  3. No workforce development: If you wait until technology is fully mature to start learning, your workforce is always behind. The chapter emphasizes upskilling existing workforce takes time.

  4. Contradicts chapter’s message: “Public health should not be a passive recipient of AI technologies developed elsewhere. Agencies that engage early can shape development toward public health needs.”

The Chapter’s Evidence Tiers:

The Essential Points place three technologies closest to bounded use, each still requiring task-specific evaluation:

  1. Multimodal foundation models (TRL 7–8)
  2. Federated learning (TRL 5–6)
  3. Edge AI (TRL 6–7)

All fall between research-stage technology (TRL 1–3) and fully mature standards (TRL 9).

Practical 5-Year Plan (illustrative):

Years 1–2:

  • Pilot multimodal AI for documentation (TRL 7–8, immediate value)
  • Start federated learning pilot with 2–3 partner institutions (build expertise)
  • Train workforce on AI fundamentals and ethics
  • Establish partnerships with universities and AI companies

Years 3–4:

  • Scale successful pilots
  • Evaluate emerging technologies (digital twins, causal AI, edge AI)
  • Start pilots on newly mature technologies
  • Deepen workforce expertise

Years 5+:

  • Mature capabilities in proven technologies
  • Monitor quantum computing, neuromorphic computing (still research stage)
  • Continuous learning and adaptation

This balanced approach delivers near-term value (years 1–2) while building capacity for future adoption (years 3–5).

For practitioners:

The chapter’s preparation philosophy is:

  • Not too early: Do not invest in TRL 1–3 technologies that will not deliver in your timeframe
  • Not too late: Do not wait for TRL 9 perfection; engage during development (TRL 4–7)
  • Develop skills: Technology is less limiting than workforce and organizational readiness
  • Diversify: Different technologies for different problems
  • Learn by doing: Pilots provide hands-on experience
  • Partner: Use external expertise while building internal capability

Option C embodies this balanced, practical, sustainable approach that the chapter explicitly recommends for public health agencies with limited budgets preparing for AI’s future.

What is federated learning, and why does it matter for public health?

Federated learning trains or updates a model across distributed sites without centralizing raw records. It can support collaborations where hospitals, laboratories, or jurisdictions cannot pool data, but it does not guarantee privacy, fairness, or compliance. Model updates may leak information, sites may contribute uneven data, and heterogeneous systems can destabilize training. Secure aggregation, privacy controls, shared protocols, and governance remain necessary.

What is edge AI in health settings?

Edge AI runs inference on a local device rather than relying on continuous cloud access. It can reduce latency, preserve operation during connectivity failures, and limit some data transfers. Its value depends on measured performance on the target hardware, including memory, power, heat, battery, update procedures, and failure behavior. A smaller or quantized model should be revalidated because compression can alter overall and subgroup performance.

Are digital twins ready for population-health decisions?

Digital twins range from mechanistic simulations to data-driven representations of individuals, facilities, or populations. Some component models are useful for planning, but a high-fidelity, continuously updated population twin is not a general-purpose reality. A credible use should define the represented system, causal assumptions, calibration data, update mechanism, validation target, and decision. Scenario output should be presented as conditional on those assumptions, not as a forecast of what will happen.

When will quantum computing affect public health practice?

No fixed date is defensible. Current systems remain limited by noise, scale, access, and the need to demonstrate advantage over strong classical methods on a relevant task. Public health organizations should monitor validated computational advances and post-quantum security requirements, but should not procure a quantum solution because of a theoretical speedup. The comparison must include the complete workflow and classical baseline.

How should claims that AI accelerated drug or vaccine development be evaluated?

Identify the exact stage affected. AI may support target identification, sequence selection, molecule prioritization, trial operations, or manufacturing optimization, but it does not replace experimental validation, clinical trials, or regulatory review. A shortened design step should not be described as a shortened end-to-end development timeline unless the source measured that complete interval and attributed the change with an appropriate comparator.

Discussion Questions

  1. Technology assessment: Which emerging technology do you think will have the biggest impact on public health in the next 5 years? Why? What would need to happen to realize that impact?

  2. Equity concerns: How can we ensure that emerging AI technologies benefit all populations, not just wealthy countries/communities? What governance mechanisms are needed?

  3. Workforce implications: How should public health agencies prepare their workforce for rapid AI advancement? What skills will be most important? How do we avoid widening the gap between “AI-enabled” and traditional public health practice?

  4. Responsible innovation: What oversight mechanisms should govern development of powerful AI systems for public health? Who should be involved in decision-making? How do we balance innovation with precaution?

  5. Causal vs. predictive: When is understanding causality essential for public health decision-making? When is prediction sufficient? Give examples of each.

  6. Federated learning adoption: What are the biggest barriers to adopting federated learning for multi-site public health research? How can these be overcome?

  7. Quantum hype: Is quantum computing overhyped for public health applications? How should agencies balance preparation for quantum computing with more immediate needs?

  8. Digital twin ethics: What are the ethical implications of creating digital twins of individuals or populations? How should consent work? What safeguards are needed?

Further Resources

Books

Emerging Technologies:

Causal Inference:

Key Papers

Foundation Models:

Federated Learning:

AI Drug Discovery:

Causal AI:

Tools & Tutorials

Multimodal AI:

Federated Learning:

Edge AI:

Causal Inference:

  • DoWhy - Microsoft causal inference library
  • EconML - Heterogeneous treatment effects
  • CausalNex - Causal reasoning with Bayesian networks

Online Courses

Emerging Technologies:

Causal Inference:

Communities & Forums

AI for Health:

Federated Learning:

Looking Ahead

The next chapter, AI in Global Health and Equity, examines:

  • Global health AI equity and addressing the digital divide
  • Context-appropriate AI design for resource-limited settings
  • Algorithmic fairness across diverse populations
  • Capacity building strategies in low- and middle-income countries
  • Data governance in international health collaborations

The emerging technologies covered in this chapter can benefit public health. Those benefits depend on equitable deployment across populations. For the regulatory and governance frameworks shaping how these technologies can be adopted, see AI Policy and Governance in Healthcare.

The Public Health AI Handbook is free to read and cite, with no advertising. If this chapter informed your work, you can support the handbook.