Smart Maternal Emergency Response System (SMERS)

CAPSTONE PROJECT / COMPLETE

Addressing maternal emergency response delays through centralized dispatch coordination and geospatial optimization in resource-constrained rural settings.

STACK: React 19 | Node.js Express 5 | PostgreSQL GEOSPATIAL: Leaflet + OSRM API

Table of Contents

Abstract

This capstone project presents SMERS (Smart Maternal Emergency Response System), a full-stack dispatch platform designed to address coordination failures in maternal emergency referral pathways. The system integrates live incident intake, priority-based triage, geospatial assignment optimization, and real-time operational tracking to reduce response delays in resource-constrained settings.

A core innovation of SMERS is its leverage of community-embedded informal transport operators: boda boda (motorcycle taxi) riders and tuk-tuk drivers, as the primary responder network. These actors possess intimate geographic and social knowledge of their operational areas that exceeds cartographic accuracy; the system amplifies their existing community trust and navigational expertise by providing coordinated dispatch, standardized incident information, and real-time routing guidance.

The platform was engineered using open-source technologies (React 19, Node.js Express, PostgreSQL, and Leaflet + OpenRouteService) to ensure long-term sustainability, accessibility, and adaptability for county-level deployment. Core functionality encompasses emergency call management, responder allocation using nearest-available algorithms optimized for local knowledge, live map-based situational awareness, and administrative reporting.

The prototype is operationalized in Laikipia County, Kenya, providing both a realistic test environment aligned with known facility and mobility patterns, and grounding the work in a geographic context where maternal emergency coordination remains a critical public health challenge. This work combines systems engineering with applied public health research to produce a deployable artifact suitable for evaluation and future field implementation.

Problem Statement & Literature Context

Maternal mortality in sub-Saharan Africa remains among the highest globally, with delay in accessing adequate emergency care cited as a primary contributor (three delays model: delay in decision-making, delay in reaching facility, delay in receiving treatment). In rural Kenya, geographic dispersion, poor infrastructure, and fragmented communication pathways intensify these delays. While health facilities may exist within nominal reach, the absence of integrated, real-time dispatch coordination creates a coordination failure that transforms otherwise manageable emergencies into fatal outcomes.

A secondary constraint in many rural Kenyan contexts is the absence of dedicated ambulance networks. However, informal transport operators, boda boda riders and tuk-tuk drivers, are ubiquitously present and possess navigational knowledge of their districts that often exceeds GPS accuracy. These operators represent an existing, trusted, community-embedded resource asset that remains systematically underutilized in emergency response infrastructure.

Current emergency response workflows exhibit the following documented inefficiencies:

These bottlenecks reduce both the speed and consistency of emergency response, directly affecting clinical outcomes. In Laikipia County, where geographic dispersion compounds response times and dedicated ambulance networks remain limited, coordination failures translate to preventable maternal mortality.

System Architecture & Design Rationale

SMERS employs a three-tier web application architecture prioritizing simplicity, portability, and low operational overhead; these are critical requirements for sustainability in resource-constrained deployment contexts. The architecture supports stateless API design with horizontal scalability, geospatial optimization for routing efficiency, and offline-capable components for low-bandwidth rural environments.

A foundational design principle is the integration of informal community responders rather than requiring dedicated ambulance infrastructure. The system treats boda boda riders and tuk-tuk drivers as primary responders, recognizing their existing geographic knowledge, community presence, and mobility. The platform's role is to systematize their knowledge through coordinated dispatch, providing them with explicit patient information, precise location coordinates, and navigation guidance while capturing their local expertise within the assignment optimization algorithm.

Presentation Layer

React 19 + Material UI: Component-based UI with responsive design optimized for variable network latency and diverse device types. Separate interfaces for dispatchers (central coordination view) and community responders (vehicle-based driver application).

Application Server

Node.js + Express 5: Lightweight, event-driven architecture suitable for rural deployment contexts. RESTful API design with request validation, normalized error responses, and comprehensive logging for operational accountability.

Data Layer

PostgreSQL: Relational schema ensuring referential integrity, ACID compliance, and immutable audit trails. Designed for concurrent reads with transactional consistency under high-load scenarios. Tracking of responder profiles, service history, and performance metrics.

Geospatial Services

Leaflet + OpenRouteService Matrix API: Real driving-time calculations via road networks. Assignment algorithm combines geospatial distance with responder availability and service history, amplifying local knowledge through data-driven pattern recognition.

Operational Workflows & Key Features

Community Responder Integration: Rather than requiring parallel infrastructure of dedicated ambulances, SMERS formalizes the existing network of community transport operators. Boda boda riders and tuk-tuk drivers who already operate in their districts register as responders; the system provides them with structured incident information, real-time navigation, and tracking integration while they contribute their invaluable geographic and social knowledge.

Emergency Incident Lifecycle: The system supports a structured workflow from initial call through completion:

This workflow eliminates fragmented communication, activates an existing community resource that would otherwise operate in isolation, creates auditable records at each step, and provides transparency for operational oversight and post-incident review.

Implementation Methodology

SMERS was developed using an iterative agile approach, advancing through five sequential phases informed by requirements analysis of real emergency dispatch workflows, community responder operational patterns, and stakeholder feedback from operational contexts in Laikipia.

  • Phase 1 (Requirements & Data Model): Schema design for incidents, community responders (boda boda/tuk-tuk operators), users, and financial transactions; API endpoint specification accounting for vehicle-based dispatch and driver-facing applications
  • Phase 2 (Dispatcher Interface): Queue visualization, incident intake forms, priority-based sorting mechanisms, community responder availability management
  • Phase 3 (Geospatial Integration & Community Responder Routing): Live map rendering, responder position tracking, ETA calculation optimized for local knowledge, assignment algorithm that balances distance with responder expertise and service history
  • Phase 4 (Community Responder Mobile Application & Administrative Oversight): Vehicle-based driver interface for receiving dispatch and navigation; Reporting views, mission history, financial transaction tracking, community responder performance analytics, user administration
  • Phase 5 (Stabilization & Evaluation): Performance testing under sustained load, usability validation with actual community responders, documentation finalization

Technology Stack Selection Rationale

Technology choices prioritized open-source ecosystems with proven deployment success in low-resource African health contexts, avoiding proprietary vendor dependencies. React 19 provides responsive component-based UI performance over low-bandwidth networks and supports dual interfaces (dispatcher workstation and vehicle-based responder application). Node.js + Express offers lightweight, event-driven server architecture suitable for modest hardware specifications. PostgreSQL has demonstrated reliability and cost-effectiveness in Kenyan health information systems over extended operational periods. Leaflet + OpenRouteService enable offline-capable map rendering with real-world routing optimization, avoiding cloud dependency for core geospatial functions.

All components are open-source with active communities and transparent governance, ensuring long-term maintainability and adaptability by county health departments without vendor lock-in constraints. The architecture explicitly supports the integration and management of informal community responder networks rather than requiring parallel ambulance infrastructure.

Evaluation & Validation

System evaluation employed simulation-based testing under controlled load scenarios to assess performance against operational requirements.

Evaluation Metrics

  • Dispatch Latency: Time from incident entry to active responder assignment target < 20 seconds; baseline validation achieved
  • System Reliability: Transactional consistency preserved under sustained incident volume; zero data loss events observed; graceful error handling for network failures
  • Responder Assignment Accuracy: Assignment algorithm correctly identifies nearest available responder using real ETA calculations
  • Usability: Qualitative assessment with test dispatchers; tasks completed without requiring training documentation; error rates observed < 5%
  • Queue Throughput: System sustains concurrent processing of 50+ incidents in queue without degraded response times

Validation Approach

Simulation-based load testing using synthetic emergency events; performance profiling under high queue pressure; qualitative feedback collection from operational stakeholders; architecture and code review by technical supervisors for compliance with design specifications.

Geographic Framing & Implementation Context

The SMERS prototype is deliberately anchored in Laikipia County, Kenya, with operational focus on Nanyuki and surrounding districts. This geographic choice combines practical and substantive motivations: Laikipia presents authentic operational challenges (geographic dispersion, semi-arid terrain, variable road infrastructure, intermittent cellular coverage) that serve as meaningful stress tests for emergency dispatch coordination.

Critically, Laikipia's transportation landscape features dense informal networks of boda boda and tuk-tuk operators who possess encyclopedic knowledge of district roads, route networks, and geographic landmarks. These actors significantly outnumber dedicated ambulance resources but have historically operated uncoordinated. SMERS was designed specifically to systematize this existing asset: rather than importing centralized ambulance infrastructure, the system formalizes community transport operators as responders and amplifies their inherent geographic expertise through coordinated dispatch and data-driven optimization.

More fundamentally, this work is grounded in lived experience of the problem it addresses. Maternal and newborn mortality in Laikipia remains a persistent public health challenge where coordination failures, not facility availability, frequently create fatal delays. Having grown up in this region, I have witnessed multiple cases where emergency referral pathways failed not due to lack of capability or resources, but due to fragmented communication and absence of coordinated dispatch. Building this system in Laikipia represents a commitment to systems thinking rooted in the specific geographic and social context where the problem is real.

The architecture is designed for geographic portability and responder network adaptability: county health departments can adapt the system by reconfiguring map bounds, integrating local facility and responder databases, customizing triage protocols, and formalizing their own community transport operators. While operationalized in Laikipia, SMERS serves as a generalizable template for emergency logistics coordination across rural Kenyan counties and comparable resource-constrained health systems where informal transport networks represent an underutilized asset.

ARCHITECTURE DESIGN (PDF) UML DIAGRAMS (MDJ) UI SCREENSHOTS (PDF) SOURCE CODE

Archival & Technical Evidence

Complete project documentation, design artifacts, implementation evidence, and reproducible code are provided below. All materials are organized by phase and purpose: academic submissions, technical design documents, implementation artifacts, and development logs. The repository (GitHub) contains the complete, executable source code.

This project was conceived in the aftermath of a personal health crisis. My paternal aunt experienced a postpartum hemorrhage in Laikipia, a complication that easily becomes fatal in rural contexts. What saved her and my newborn cousin was not a hospital. It was a motorcycle taxi driver from the neighborhood. This man, who earned his livelihood ferrying passengers on his bike, happened to pass by. He recognized the emergency, knew the fastest route to the nearest functional facility, and transported them. His intimate knowledge of the district's roads, knowledge that no map possesses, meant the difference between life and death.

SMERS exists because of that moment. It is, fundamentally, an attempt to systematize what that driver already knew: that the people already present in a community, who already know the roads and the terrain and the shortcuts, are irreplaceable assets in emergency response. This project is a homage to Laikipia. I mean the drivers, the health workers, the families who already have agency and knowledge and ingenuity. The system simply creates a mechanism to coordinate their existing expertise.

Academic Submissions

How It's Built

Development Record

Reproducibility Protocol

The system is fully reproducible using the steps below. All dependencies are open-source; no proprietary licenses required.

  1. Install dependencies: cd backend && npm install and cd ../frontend && npm install
  2. Configure database: Set DATABASE_URL in backend/.env pointing to your PostgreSQL instance
  3. Start the backend: cd backend && node index.js (runs on port 5000)
  4. Start the frontend: cd frontend && npm start (runs on port 3000)
  5. Access the system: Navigate to http://localhost:3000 and log in with dispatcher/pass or admin/pass

The login is dispatcher/pass and admin/pass because this is a simulation. In a real deployment, you'd plug in real identity management. But for now, testing matters more than security theater.