Malaria Risk Mapping with Google Earth Engine: An Enterprise Geospatial Solution

Introduction

Welcome to the strategic world of malaria risk mapping, powered by Google Earth Engine (GEE)—a geospatial cloud platform within the Google Cloud ecosystem purpose-built for planetary-scale geospatial analysis. GEE was fitting in this project for its unparalleled capabilities in processing vast amounts of satellite imagery and climate data. This project represents a significant leap forward in public health surveillance, offering a geospatial approach to proactive disease management.

This initiative strategically taps into GEE’s massive climate raster data stored in the Google Earth Engine Data Catalog and Google’s robust cloud computing muscles. Our goal was to accurately map where mosquito populations are most likely to thrive, influenced by critical factors such as climate change, rainfall patterns, human activities leading to land cover shifts, and elevation data. A key design principle was to leverage a cloud-native architecture, meaning everything is done in the cloud—eliminating the need to spin up your own servers or wrestle with colossal CSV files. The ultimate output? An interactive malaria risk mapping web-application designed to empower scientists, policymakers, and C-suite decision-makers to pinpoint areas at the highest malaria risk, all with a few clicks. This application acts as a critical decision support system, helping to channel resources where they are needed most effectively.

Let’s delve into the systematic process we employed to build this powerful and intuitive web-app, illustrating how Business Systems Analysis methodologies were integral to its success.

Malaria Risk Earth Engine Web-App Architecture: A Top-Down Design

To set the stage for the project architecture, it's crucial to understand that while developed primarily using the GEE Code Editor, the entire application seamlessly integrates with the broader Google Cloud Platform (GCP). You would like to refer on Creating an Earth Engine Cloud Project for technical setup details.

Our design philosophy adhered to a top-down analysis and design approach, starting from the overarching business objectives of MalariaOrg and iteratively breaking them down into granular system components. Although the application runs entirely on Google Earth Engine’s cloud-native platform, its underlying design consciously adheres to GCP's Well-Architected Framework pillars. This ensures scalable infrastructure, robust data-driven decision support, and minimal operational overhead, offering a secure, cost-effective way to monitor malaria risk at a national scale.

Before designing any technical solution, I led a Root Cause Analysis using the Fishbone Diagram (Ishikawa Diagram) technique to identify the key drivers of ineffective malaria monitoring systems:
Our journey began with a thorough root cause analysis to understand the complexities of malaria transmission and the limitations of existing surveillance methods. We utilized a Fishbone Diagram, also known as a Cause-and-Effect Diagram, to visually dissect the problem. This allowed us to categorize contributing factors into key areas such as Environment, Data, Technology, Human Factors, and Policy.

• Environment: Climatic conditions (rainfall, temperature, humidity), stagnant water bodies, vegetation.
• Data: Data scarcity, data inconsistencies, delayed reporting, lack of real-time data, unintegrated data sources.
• Technology: Limited access to advanced mapping tools, insufficient computational power, lack of expertise in geospatial analysis.
• Human Factors: Inadequate training for data collection, resistance to new technologies, limited community engagement.
• Policy: Unclear guidelines for data sharing, insufficient funding for surveillance programs.

This comprehensive analysis revealed that a lack of timely, granular, and easily accessible environmental data was a significant bottleneck in effective malaria risk prediction and intervention. This analysis helped visualize the multi-dimensional nature of the problem and formed the basis for our problem statement and business case.

Requirements Elicitation and Analysis

Stakeholder engagement was maintained through sprint reviews, biweekly check-ins, and documentation updates on Confluence. To ensure our primary stakeholders’ alignment and build a system that addresses actual needs, I employed a mix of elicitation techniques:

System Requirements Specifications (SRS) and Scalability

A comprehensive System or Software Requirements Specification (SRS) document was developed at the outset of the project and continuously updated throughout the Agile sprints. The SRS served as the single source of truth for all requirements, ensuring alignment between stakeholders and the development team. Its main elements included:
• Introduction: Purpose, scope, definitions, and references.
• Overall Description: Product perspective, product functions, user characteristics, general constraints, assumptions, and dependencies.
• Specific Requirements:
o Functional Requirements: What the system must do (e.g., "The system shall ingest daily precipitation data from CHIRPS.").
o Non-Functional Requirements: Qualities of the system (e.g., performance, security, uptime, usability, scalability).
o External Interface Requirements: How the system interacts with other systems (e.g., Python & JavaScript APIs for Google Earth Engine).
o Performance Requirements: Response times, data processing throughput.
o Security Requirements: Data access control, authentication.

Ensuring Scalability of the Malaria System

Scalability was a paramount non-functional requirement for the malaria system. We designed the system with future growth in mind, knowing that MalariaOrg would likely expand its operations to new regions and require processing larger datasets. To ensure system scalability, we leveraged the cloud-native architecture of Google Earth Engine and designed the system to dynamically update as new satellite data becomes available, enabling region-wide or even continent-wide coverage.

• Cloud-Native Architecture: Leveraging Google Earth Engine's cloud infrastructure inherently provides horizontal scaling capabilities for computation and storage.
• Modular Design: Breaking the system into independent, loosely coupled modules allowed for individual components to be scaled up or down as needed without affecting the entire system.
• Stateless Components: Designing components to be stateless minimized dependencies and facilitated easier scaling.
• Efficient Algorithms: Optimizing GEE scripts and data processing algorithms for performance and resource utilization.
• Database Design: Employing scalable database solutions (e.g., NoSQL databases for geospatial data) to handle increasing data volumes.
• This strategic focus on scalability ensures the longevity and adaptability of the malaria monitoring system as MalariaOrg's needs evolve.

Top-Down Analysis and System Design process

We wanted methodical approach which could allow us to move from high-level conceptualization to detailed technical implementation, ensuring alignment with user needs at every step. We arrived at a top-down design approach, the system was modeled from the high-level organizational goals down to detailed functional requirements. This approach ensured that the overall architecture was sound and that individual modules aligned with the overarching strategic vision. This began with identifying Business Objectives (e.g., improve disease preparedness, reduce outbreak response time) and decomposing them into functional modules such as:

1. Data Ingestion: Loading relevant environmental and demographic data directly from the Google Earth Engine Data Catalog. This also involved data validation and pre-processing to ensure data quality.
2. Data Processing & Modeling: Performing complex geospatial analysis and statistical modeling within the Earth Engine Code Editor. This is where our business logic for malaria risk prediction was codified.
3. Interactive Web Map Development: Designing an intuitive, sleek, and highly interactive web map interface. Our focus here was on usability and clear information visualization for diverse stakeholders. In the system design and development, I developed the System Architecture Diagram, using popular software tools Lucidchart, Jira and Python and JavaScript APIs in GEE to script geospatial logic and visualization layers. I also used Entity Relationship Diagrams (ERD), and Data Flow Diagrams (DFD) to communicate design specifications to developers and data scientists but in this article I’ll only show the System Architecture Diagram.

Software Development Methodology: Agile Development

We adopted an Agile development methodology, specifically Scrum, for this project. This iterative and incremental approach was highly effective given the evolving nature of geospatial data analysis and the need for continuous feedback from MalariaOrg.

• Sprints: The project was broken down into short, time-boxed iterations (sprints), typically 2-4 weeks long.
• Daily Scrums: Short daily meetings to synchronize activities and identify impediments.
• Sprint Reviews: Demonstrations of completed work to stakeholders at the end of each sprint.
• Sprint Retrospectives: Team meetings to reflect on the past sprint and identify areas for improvement.

This iterative process allowed for rapid prototyping, frequent validation with stakeholders, and the flexibility to adapt to new insights or changing priorities.

Interactive Web App: The User-Centric Interface Showing Malaria Risk Scores

This is the showstopper—the Beyoncé of the app, built with a strong focus on User Experience (UX). Through extensive requirements elicitation, including interviews with epidemiologists and public health officials, we defined clear User Stories and Acceptance Criteria for the interactive map features.

• Dynamic Risk Mapping: Once a county is selected, the system, based on complex GEE scripts, processes all the relevant environmental data and generates a dynamic malaria breeding conditions map.
• Intuitive Visualization: Areas are color-coded using a 5-level scale, making risk levels immediately understandable. This aligns with the functional requirement of clear visual communication.

Interactive Web App-Map Showing Malaria Risk Scores

This is the showstopper—the Beyoncé of the app, built with a strong focus on User Experience (UX). Through extensive requirements elicitation, including interviews with epidemiologists and public health officials, we defined clear User Stories and Acceptance Criteria for the interactive map features.

• Dynamic Risk Mapping: Once a county is selected, the system, based on complex GEE scripts, processes all the relevant environmental data and generates a dynamic malaria breeding conditions map.
• Intuitive Visualization: Areas are color-coded using a 5-level scale, making risk levels immediately understandable. This aligns with the functional requirement of clear visual communication.

• Enhanced Data Readability: You bet we added a custom swatch legend (hello, UX excellence!) and printed dynamic values for average temperature, rainfall, elevation, and land cover directly from the study area. This fulfills the non-functional requirement of providing comprehensive, context-specific information at a glance.
• Purposeful Data Display: The real gem is a dynamic malaria score legend panel, which not only tells you your county’s risk but also helps make data feel like data with purpose. This was a key Usability Requirement identified during our stakeholder workshops.

And if you love graphs (who doesn’t?), you’ll get live time series charts showing rainfall and temperature trends—no need to squint at spreadsheets anymore. This feature was developed based on the Use Case of a public health official needing to analyze historical environmental patterns.

Multi-Version Development and Population-at-Risk Module

We built this project into two versions: a JavaScript version and a Python version. This approach allowed us to prototype rapidly with JavaScript and then expand capabilities with Python, leveraging its robust data science libraries for more complex analysis.
Our choropleth map built on the Python version contains an extended module—it’s now possible to understand the population under risk of malaria infection if it strikes. Sounds cool? This feature, identified as a "Must-Have" requirement during our requirements prioritization using the MoSCoW technique integrates county-level population data.
It enables users to select a county and immediately view its malaria risk score, total population, and assigned risk level. For instance, Samburu, a specific county, shows a population of 553,419 and a moderate risk level with a score of 406.

Time series charts of rainfall and temperature further contextualize the data over time, fulfilling the functional requirement for historical trend analysis. Our MoSCow technique enebled us to consider the Cost-Benefit Analysis to prioritize features requirement that offered the highest return on investment and addressed the most critical pain points. Another priority requirement was the Risk Assessment approach to prioritizing features that mitigated high-impact risks to the project and the malaria organization.

My Approach towards Testing and Quality Assurance

Our commitment to delivering a robust and reliable system was underpinned by a comprehensive testing and quality assurance (QA) approach, integrated throughout the Agile development lifecycle.

• Unit Testing: Individual components of the GEE scripts and Python processing modules were tested to ensure their correctness.
• Integration Testing: Verifying the seamless interaction between different system components, such as data ingestion modules with the mapping interface. This involved testing system integration points.
• System Testing: End-to-end testing of the entire system to ensure it met all specified functional and non-functional requirements.
• Performance Testing: Assessing the system's responsiveness and stability under various load conditions, especially crucial for a system dealing with large geospatial datasets.
• User Acceptance Testing (UAT): The final and critical phase where end-users from MalariaOrg validated the system against their operational needs.

Successful User Acceptance Testing (UAT)

Throughout the project, we embraced an Agile development methodology, specifically Scrum, which allowed for continuous feedback loops and iterative refinement. Our approach to testing and quality assurance was integrated into every sprint:

• Unit Testing of individual GEE scripts and Python modules.
• Integration Testing to ensure seamless system integration between data processing, modeling, and the web-app.
• System Testing for end-to-end functionality.
• User Acceptance Testing (UAT)- This was the final and most crucial validation step. Successful user acceptance testing involved key end-users (e.g. epidemiologists, public health program managers) from MalariaOrg. They tested the application against real-world scenarios and their defined Acceptance Criteria, ensuring the system met their operational needs and provided the expected value. Their direct involvement confirmed the system's readiness for deployment.

In Conclusion: Business Systems Analyst as a Strategic Enabler

This project exemplifies the critical role of a Business Systems Analyst in bridging the gap between intricate business challenges and cutting-edge technological solutions. It demonstrates how Business Systems Analysis (BSA) goes beyond gathering requirements — it is about orchestrating strategy, process, data, and technology to deliver value. By aligning stakeholder needs with a flexible, scalable system built on geospatial intelligence, we enabled the MalariaOrg and its partners to shift from reactive to proactive disease management.

As a Senior Business Systems Analysis, I championed this outcome through structured analysis, effective communication, and agile execution — delivering not just a system, but a measurable improvement in public health operations.

This is part of projects we work on here at GEE DEVS Nairobi Community which I would encourage you to join. This project was also presented at GEO Health Community of Practice-AfriGEO as a series of work being done in Africa sponsored by AfriGeo and presented at Google I/O 2025 in Berlin.