Technical Documentation
Methodology
“From lag-aware dengue forecasting to operational preparedness intelligence.”
DengueOps AI does not claim a novel forecasting algorithm. Its contribution is the operational decision-support layer that converts outbreak forecasts into supply depletion timelines, bed pressure estimates, uncertainty scenarios, and zone-level preparedness priorities.
Audience note
RMSE values, MAE comparisons, and model evidence are included for technical evaluators and IEEE reviewers. Operational users — public health officials and hospital administrators — receive translated preparedness recommendations through the dashboard's role-based views, not raw model metrics.
Core positioning: The operational decision-support layer is the primary contribution — not proof that the selected Random Forest is superior on real Dhaka data.
Pipeline Overview
Methodology Pipeline Overview
Eight sequential stages convert raw surveillance and climate inputs into facility-level operational directives.
Data Inputs
Weekly dengue cases, climate variables, zone exposure proxies, facility readiness data, and inventory assumptions.
→ dengue_cases.csv · climate_data.csv · zones.json · facilities.json · inventory.json
Feature Engineering
Creates lagged climate features, autoregressive case trends, rolling means, growth rates, and seasonality signals.
→ data/model_features.csv — 29 engineered features per epi week
Temporal Backtesting
Runs the governed 68-fold rolling-origin comparison across seven frozen candidates. The legacy 80/20 split remains diagnostic-only.
→ data/validation_metrics.json · data/model_comparison.json
Forecasting
The adopted RandomForestRegressor is refitted on all labelled rows for the 14-day demonstration forecast.
→ data/forecast_output.json — forecast_cases, growth_factor, risk_level, risk_score
Uncertainty Scenarios
Evaluates a prior-only expanding absolute-residual empirical range and keeps legacy planning scenarios separate.
→ forecast_uncertainty.json + compact forecast reference + preparedness_scenarios
Spatial Exposure Allocation
Allocates city-level forecast cases to zones using a composite spatial exposure heuristic weighted by density, vulnerability, facility pressure, and mobility.
→ Zone-level case allocations and priority scores for each scenario
Facility Readiness Modelling
Computes SDH for each consumable per facility under forecast-adjusted demand. Projects bed load using LOS logic. Calculates bed gap.
→ Per-facility SDH (NS1/RDT, IV Fluid), bed_gap_expected/worst
Operational Directives
Translates risk and readiness outputs into facility-level preparedness directives: reorder supplies, activate beds, prepare referral protocols, prioritise vector-control response.
→ data/directives.json — 11 facility directives with inventory alerts and recommendations
Data Input Layer
Input Datasets
Five structured data files feed the analytics pipeline. No patient-level records are used at any stage.
dengue_cases.csv
Weekly dengue case counts for time-series forecasting
Fields: epi_year, epi_week, city, total_cases
climate_data.csv
Climate variables for lag-feature engineering
Fields: epi_year, epi_week, city, rainfall_mm, temp_mean_c, humidity_pct
zones.json
Spatial exposure proxy parameters for zone-level allocation
Fields: zone_id, population_share, density_weight, vulnerability_weight, exposure_index
facilities.json
Facility configuration for readiness and bed pressure modelling
Fields: facility_id, zone_id, facility_name, general_bed_capacity, dengue_bed_capacity_demo, avg_length_of_stay
inventory.json
Supply stock and consumption for SDH simulation
Fields: facility_id, item_name, current_stock, baseline_daily_consumption, reorder_threshold_days
Data Status: Prototype vs Real Deployment
| Dataset | Purpose | Current Prototype Status | Future Deployment Source |
|---|---|---|---|
| Dengue cases | Forecasting | Synthetic/demo aggregate data | Official aggregated DGHS/IEDCR surveillance reports |
| Climate data | Lagged environmental predictors | Synthetic/demo climate-style data | BMD / Open-Meteo / NASA POWER or approved meteorological source |
| Zones | Spatial exposure allocation | Proxy exposure weight values | Ward-level population, mobility, vector surveillance data |
| Facilities | Readiness modelling | Real public anchors + synthetic readiness values | Hospital/facility MIS — actual bed capacity and occupancy |
| Inventory | SDH simulation | Synthetic inventory values | Facility stock management or pharmacy system |
Feature Engineering
Lag-Aware Feature Engineering
The model uses prior observations to avoid future-data leakage. The 14- and 28-day climate lookbacks are governed candidate inputs; they are not established Dhaka epidemiological relationships and require local temporal backtesting.
Governance of the current lag candidates
Candidate feature configuration — locally unvalidated
Candidate 2-week lag
A provisional lookback used for research comparison; not proven optimal or causal for Dhaka.
Candidate 4-week lag
A second provisional lookback that requires local temporal backtesting.
Evidence status
No current lag is registered as a validated Dhaka epidemiological coefficient.
Deployment status
These features remain candidate model inputs and must be selected using local data.
rainfall_lag_2wRainfall 14 days prior — provisional candidaterainfall_lag_4wRainfall 28 days prior — provisional candidatetemp_lag_2wMean temperature 14 days priortemp_lag_4wMean temperature 28 days priorhumidity_lag_2wHumidity 14 days priorhumidity_lag_4wHumidity 28 days prior
cases_lag_1wCases last week — most recent signalcases_lag_2wCases 2 weeks agocases_lag_4wCases 4 weeks agocases_rolling_3wRolling 3-week mean — short-term trendcases_rolling_4wRolling 4-week mean — reference baselinecases_rolling_8wRolling 8-week mean — medium-term contextgrowth_rate_1wWeek-over-week proportional changegrowth_rate_2w2-week proportional change
epi_week_sinSine encoding of epi week (captures cyclical pattern)epi_week_cosCosine encoding of epi week (captures cyclical phase)monsoon_flagProvisional configured calendar flagpost_monsoon_flagProvisional configured calendar flag
Leakage prevention
Rolling features are calculated using past values only — .shift(1) is applied before all rolling windows. Target columns (target_cases_next_2w) are excluded from FEATURE_COLUMNS to prevent future data leakage. Train/test split is strictly chronological.
Temporal Backtesting
Temporal Backtesting & Baseline Comparison
A chronological (time-based) train/test split is used to evaluate model performance under realistic conditions — each test prediction uses only data that would have been available at that point in time.
❌ Random split (not used)
Random row shuffling creates future data leakage — test rows may contain data from earlier in the series than training rows.
✓ Chronological split (used)
Train on early epi weeks, test on the final 20%. Every test prediction uses only historically available data.
✓ Baseline comparison (used)
A model that cannot beat naive last-week repeat provides no operational signal. Baselines establish the minimum useful bar.
Validation Design
One chronological holdout (final 20%)
Train Rows
96 epi weeks
Test Rows
25 epi weeks
Forecast Target
Cases +14 days
Model Comparison — Chronological Test Period
| Model | Role | MAE | RMSE | MAPE (%) | |
|---|---|---|---|---|---|
| Gradient Boosting Regressor (scikit-learn) | Primary ML | 33.5 | 51.2 | 34.8% | Best |
| Naive Baseline | Baseline | 42.4 | 71.3 | 38.4% | |
| Moving Average Baseline (4-week) | Baseline | 48.8 | 77.0 | 42.4% |
Model selection rationale
Random Forest was selected under the declared MAE-first rule after completing all 68 rolling-origin folds without failure, then adopted under P1.2B. The displayed GBR holdout remains historical compatibility evidence (-46% lower MAE than its naive baseline), not active-model performance. No real-world Dhaka superiority is claimed.
Validation methodology notes — research candidate only
- Rolling-origin validation repeatedly evaluates unseen future periods, but current results are based on deterministic synthetic benchmark data and do not establish real-world Dhaka performance.
- Real reporting publication delays and revision vintages are not modeled yet.
- Permutation importance was not calculated per fold because each rolling-origin fold contains one validation row, making permutation diagnostics statistically degenerate and unsuitable for temporal-stability claims.
- Leakage prevention: A one-row label-availability embargo excludes the row whose target is unavailable at each origin.
Forecasting Layer
Forecasting & Experimental Growth Scoring
The governed RandomForestRegressor takes the engineered feature matrix and outputs a 14-day ahead case count forecast. The operational engine then derives a growth factor, an experimental growth score, and a provisional forecast-growth category.
Growth Factor
Variable Definitions
Forecast CasesML model 14-day ahead predictioncases_rolling_4w4-week rolling mean of recent observed cases
Growth factor > 1.0 indicates surge above recent baseline. Used for risk classification and supply demand adjustment.
Experimental Growth Score (0–100)
Unsupported provisional score used only in benchmark/research presentation. It is not risk or probability.
Provisional forecast-growth categories
Low forecast growth
growth_factor < 1.1
Moderate forecast growth
1.1 ≤ growth_factor < 1.5
High forecast growth
1.5 ≤ growth_factor < 2
Very high forecast growth
growth_factor ≥ 2
Uncertainty Engine
Planning Sensitivity Scenarios
Single-point forecasts are insufficient for preparedness planning. Three legacy RF RMSE values remain for operational compatibility. They are separate from the empirical forecast range.
Lower sensitivity scenario
Optimistic lower bound. Assumes model performs better than validation RMSE.
Point forecast
Central estimate from the adopted RandomForestRegressor.
Upper sensitivity scenario
Pessimistic upper bound. Assumes model error in the adverse direction.
Lower sensitivity scenario
87
GF 1.246× · Moderate · 44/100
Point forecast
120
GF 1.719× · High · 71/100
Upper sensitivity scenario
153
GF 2.192× · Critical · 87/100
These uncalibrated planning values are based on holdout RMSE. They are separate from the active empirical forecast range and are retained only for operational compatibility. Future real-data calibration must select and evaluate an appropriate governed method.
Spatial Allocation
Spatial Exposure Allocation
City-level dengue forecasts cannot be directly treated as ward-level forecasts. In the absence of validated zone-level case counts — a common constraint in data-scarce urban health settings — a transparent spatial exposure heuristic is used.
Exposure Index
Weights are transparent, domain-informed heuristics — not learned from spatial data.
Zone Case Allocation
Ensures zone case counts sum to city-level forecast. Each zone receives a proportional allocation.
This is a spatial disaggregation heuristic under city-level data constraints, not a learned ward-level spatial model. Zone-level allocations are advisory approximations for preparedness planning, not epidemiologically validated zone estimates.
Supply Depletion Horizon
Supply Depletion Horizon (SDH)
SDH estimates how many days a consumable resource may last under forecast-adjusted demand. It answers: “If surge demand rises by the forecast growth factor, when does stock run out?”
Dynamic Daily Demand
Variable Definitions
Baseline Daily ConsumptionHistorical average daily consumption at the facility (synthetic demo value)Forecast Growth FactorSurge multiplier from forecast engine
Applied per supply item per facility. Demand rises proportionally with growth factor.
Stock Depletion Horizon (SDH)
Variable Definitions
Current StockUnits of supply held at facility (synthetic demo value)
Prototype only: critical ≤ 3d; NS1 warning ≤ 7d; IV-fluid warning ≤ 5d. Not institution-approved.
✓ SDH applies to:
- · NS1/RDT diagnostic kits
- · IV fluids (500 ml)
✗ SDH does not apply to:
- · Hospital beds (modelled separately via LOS logic)
Bed Pressure
LOS-Based Bed Pressure
Hospital beds are not consumables. A patient admitted today occupies a bed for their entire length of stay. Projecting bed pressure requires modelling concurrent occupancy — not just new admissions per day.
Projected Bed Load
Variable Definitions
Occupied Dengue BedsCurrent dengue bed occupancy (synthetic demo value)Allocated Daily Surge CasesZone-allocated new cases per day under forecastAvg LOSAverage length of dengue inpatient stay (days)
Models cumulative concurrent bed demand, not a simple daily admission count.
Bed Gap
Positive bed gap = deficit (beds required exceed available). Bed values are synthetic demo values — not actual clinical capacity claims.
All bed capacity values (dengue_bed_capacity_demo) are synthetic operational readiness values used to illustrate the LOS modelling logic. Real deployment would require actual facility bed counts, occupancy data, and validated average LOS from clinical records.
Priority Scoring
Experimental Planning-Priority Score
This synthetic prototype uses the governed executable structural-plus-growth heuristic. Its coefficients are unsupported, locally unvalidated, and not an official resource-allocation rule.
Experimental Planning-Priority Score
Variable Definitions
Risk ScoreNormalised 0–100 risk score from the forecast engineVulnerability WeightZone composite vulnerability index (0–1)
Benchmark-only heuristic. Coefficients and tiers are not validated or institution-approved.
Priority Categories
Directive Engine
Simulated Planning Suggestions
Prototype trigger conditions translate synthetic indicators into simulated planning suggestions. They are deterministic, not approved operational recommendations.
Trigger Condition
SDH ≤ threshold days
Directive
Reorder supplies (NS1/RDT kits or IV fluids)
Critical / WarningTrigger Condition
Bed gap > 0
Directive
Activate additional beds / prepare referral protocol
WarningTrigger Condition
Priority score ≥ 51 (High/Critical)
Directive
Prioritise vector-control response
High / CriticalTrigger Condition
Worst-case bed gap > expected gap
Directive
Contingency planning for worst-case surge
AdvisoryExample Directive Card
Highest Simulated Planning Tier
Kamrangirchar
Example public anchor facility
Expected Bed Gap
12 beds
NS1 SDH
7.4 days
Advisory output — human review required before any operational action.
Human-in-the-Loop
Human-in-the-Loop Design
All DengueOps AI outputs are advisory. No operational actions are triggered automatically. Final decisions remain with qualified public health and hospital authorities.
Outputs are advisory, not diagnostic
The system does not diagnose dengue. It generates preparedness signals for human review by qualified health professionals.
No autonomous decision-making
No directives trigger automatic orders, procurement, or operational actions. All recommendations require explicit human approval.
Technical/MIS staff maintain the pipeline
Pipeline execution, data validation, and configuration are responsibilities of technical or MIS staff — not operational users.
Operational users receive translated outputs
Public health officials and hospital administrators receive plain-language recommendations — not RMSE values or raw JSON.
“Operational users are not expected to code, clean CSV files, or run scripts during an outbreak. The analytics pipeline is maintained by technical/MIS staff, while hospital and public health users receive translated action recommendations.”
Limitations
Known Limitations
These limitations are disclosed explicitly as part of the prototype's transparency design. They are not deficiencies to be minimised but constraints to be clearly communicated to evaluators and users.
Synthetic / demo data throughout
All case counts, climate values, inventory levels, and bed occupancy figures are synthetically generated. Results demonstrate pipeline behaviour, not real-world epidemiological accuracy.
No patient-level data
Only aggregated weekly case totals are used. Individual-level clinical or epidemiological data are not available, collected, or processed in this prototype.
Facility readiness and inventory values are simulated
Dengue-specific bed allocations, occupancy figures, NS1/RDT stock, and IV fluid stock are synthetic demonstration values. Real public hospital names are used as spatial anchors only.
Zone allocation is a heuristic
Spatial case disaggregation uses a weighted exposure index, not a validated spatial epidemiology model. Zone case counts are advisory approximations, not precision estimates.
Uncertainty band is not fully probabilistic
The empirical range uses prior-only synthetic RF residuals. Historical coverage is not a probability guarantee; legacy RMSE scenarios remain planning compatibility only.
Real deployment requires validated official data and integration
Operational use would require validated DGHS/IEDCR surveillance data, actual facility MIS integration, institutional governance, and deployment infrastructure beyond this prototype scope.
This prototype demonstrates simulation-based decision-support pipeline design and forecast-to-preparedness translation logic. It is not a deployment-ready system and does not claim clinical or epidemiological validation on real data.
Future Roadmap
Future Extension Pathways
The modular Python analytics pipeline is designed to accommodate progressive data and capability upgrades without full redesign.
Real surveillance data connection
DGHS/IEDCR validated case feed
Scheduled data ingestion
Automated weekly pipeline execution
Calibrated probabilistic forecasting
Conformal prediction or bootstrapped ensemble
Ward-level spatial modelling
Validated geospatial population and mobility data
Facility MIS integration
Live bed occupancy and stock system
Public advisory layer
Simplified risk communication for citizens
Dashboard deployment with access control
Role-based auth for hospital / PH staff
Document scope
This methodology documentation is produced for the IEEE ICADHI 2026 Project Showcase, Track 06: Health Data Analytics & Predictive Systems. All values referenced are from synthetic demonstration data. This prototype is not a deployment-ready system. Human review is required before any operational action based on these outputs.