DengueRadar: Forecasting Dengue Risk 2-4 Weeks Ahead

Inspiration

Dengue in Singapore is not a slow-moving problem — it is a violently unstable one. Pulling the full national series from MOH's Weekly Infectious Disease Bulletin, the numbers are stark: across 574 epidemiological weeks from 2012 to 2022, weekly caseloads range from 24 to 1,791, and annual totals swing 12.8× — from 2,759 cases in 2017 to 35,261 in 2020.

That volatility is exactly why the current approach struggles. NEA designates a dengue cluster only after two cases occur within 14 days and 150 m of each other — by which point transmission is already established. Fogging crews and inspection officers are a finite resource, and the decision they make every fortnight is simply where to go next. Today they make that decision looking backwards.

The insight we wanted to test is that mosquitoes respond to weather on a biological schedule. Rainfall creates breeding habitat roughly 4–10 weeks before cases appear; temperature and humidity drive larval development and viral replication on a 2–6 week lag. If that signal is real and strong enough, it buys the two to four weeks of lead time that turns reactive fogging into pre-emptive targeting.

What it does

DengueRadar is a decision-support tool for the people who allocate vector control capacity. It has three layers, and we are deliberate about which are predictions and which are not:

Layer 1 — a national 2–4 week case forecast. A gradient-boosted model over 574 weekly observations, using weather lags chosen from Aedes biology rather than by blind search, plus harmonic seasonality and autoregressive terms. Validated walk-forward against seasonal-naive and trailing-average baselines.

Layer 2 — a ranked planning-area inspection list. Live clusters, 99 Gravitrap high-Aedes sectors, 88 rainfall stations and resident population joined onto Master Plan 2025 planning areas. This is a transparent weighted composite, not a trained model — and we say so plainly, because no historical area-level case panel exists to train one on.

Layer 3 — cluster growth dynamics. Tracking CASE_SIZE per cluster over time to model which clusters grow and which decay.

The output a user actually touches is a dashboard: a live cluster map, a forecast curve with uncertainty intervals, a ranked list of planning areas with the evidence behind each rank, and a Genie space for asking questions in plain English.

How we built it

Round 1 is an idea submission, so what exists today is a verified data foundation rather than a running pipeline. Every dataset below was probed directly against the live data.gov.sg API — row counts, column names, coverage windows and actual payloads — so the architecture rests on what the data demonstrably contains, not on what its documentation claims.

The planned build is a medallion lakehouse on Databricks Free Edition: Lakeflow jobs appending real-time weather and cluster snapshots into Bronze Delta tables, spatial joins and quality expectations in Silver, a weekly feature table in Gold, MLflow tracking the model against logged baselines, Unity Catalog carrying source lineage back to each agency, and an AI/BI dashboard plus Genie space on top.

Challenges we ran into

We can forecast when, but not where — and the brief asks for where. Singapore's dengue history is national and weekly. Spatially, the open feeds are live snapshots that overwrite daily and keep no history, so there is no area-level panel to train on. A single model producing a trained risk forecast per planning area simply cannot be built honestly from this data. Rather than blur that, we split the system and label each layer by what it actually is: a trained national forecast, and an explicitly untrained, fully inspectable spatial ranking. The alternative would have demoed better and been worse.

The spatial layer has no ground truth. A ranked list of planning areas is easy to generate and hard to justify — nothing in the live data tells you whether your weighting is sensible. We use an independent frozen NEA snapshot, 167 cases across 150 block-level polygons, as an out-of-sample spatial check. It is imperfect and we will say so, but it is a real test rather than an assertion that our weights look reasonable.

The baseline is genuinely strong. Dengue is seasonal, so a seasonal-naive forecast is already decent, and beating it is the real bar — not beating zero. We log the seasonal-naive and trailing-average baselines as first-class MLflow runs alongside the model, so the comparison is reproducible rather than claimed.

Weather has a hard ceiling. Transmission also depends on circulating serotype and population immunity, and neither is exposed in any open dataset. No weather-driven model can fully explain a year like 2020. We would rather quantify that ceiling and report honest uncertainty intervals than tune the model until it looks confident.

What we learned

That the binding constraint on a public-data project is rarely the modelling — it is working out what the data can legitimately support, and then having the discipline to build only that. The temptation here was to produce one impressive-sounding "AI dengue risk forecast per planning area." The data supports a rigorous national forecast and a transparent spatial prioritisation, which is less dramatic and considerably more useful to someone who has to act on it.

What's next

The question we most want to answer is one nobody has been able to test: do Gravitrap high-Aedes sectors lead cluster formation, and by how many weeks? Both feeds are snapshot-only, so it cannot be answered retrospectively — but by archiving both from day one of the build sprint, it becomes answerable by Demo Day using nothing but open data. A positive result would turn mosquito surveillance into an early warning signal weeks ahead of the first human case.

Beyond that: the archive compounds in value every week it runs, and the same lagged-weather method transfers directly to other vector-borne disease surveillance across the region.

Built With

• data.gov.sg
• databricks
• databricks-sql
• delta-lake
• genie
• geojson
• geopandas
• geospatial
• gradient-boosting
• lakeflow
• mlflow
• pandas
• pyspark
• python
• rest-api
• scikit-learn
• time-series-forecasting
• unity-catalog