Transparency
Assumptions & Limitations
“Transparent boundaries for interpreting the DengueOps AI prototype.”
This page documents the assumptions behind the prototype. DengueOps AI is designed to demonstrate decision-support logic under data-scarce conditions, not to claim validated real-world deployment accuracy.
For evaluators: All assumptions are made explicit so reviewers can assess the prototype design without misinterpreting it as a validated live system.
Core Assumptions
Core Assumptions Table
Seven core assumptions underpin the prototype, each with an explicit rationale, known limitation, and future improvement path.
| Assumption | Why It Was Used | Limitation | Future Improvement |
|---|---|---|---|
| Synthetic / demo dengue data | Used to demonstrate full analytics pipeline safely without real surveillance data. | Does not represent official dengue surveillance records. | Replace with official aggregated dengue surveillance from DGDA/IEDCR. |
| Synthetic facility readiness | Real-time bed occupancy and inventory are not publicly available. | Cannot validate actual hospital shortages or real supply levels. | Connect to hospital MIS or authorised facility reporting system. |
| Public hospital name anchors | Improves geographic realism without fabricating institutional identities. | Only names and general anchors are real; all readiness values are synthetic. | Use validated facility profiles and official capacity data. |
| Spatial exposure heuristic | City-level forecasts need zone-level allocation; ward-level data unavailable in prototype. | Not a learned ward-level spatial model; allocation weights are assumed. | Use ward-level case data, population density, mobility, and vector indices. |
| Prequential absolute-residual empirical range | Provides a simple, transparent planning range tied directly to validation error. | Synthetic, temporally dependent, post-selection evidence; not a probability guarantee or prediction interval. | Use quantile regression, bootstrap, or Bayesian forecasting methods. |
| LOS-based bed pressure | Beds are cumulative resources; dengue admissions accumulate over average stay length. | Average length of stay is simplified and not validated against real admissions. | Use actual diagnosis, admission, and discharge data from facility records. |
| Vulnerability-gated priority score | Combines forecast risk and structural vulnerability to rank zone response urgency. | Weights are prototype assumptions, not calibrated with expert consensus. | Calibrate with expert input and historical outbreak response outcomes. |
Data Boundaries
What Is Real vs Synthetic?
A clear breakdown of each data element used in the prototype.
| Data Element | Prototype Status | Details |
|---|---|---|
| Facility names | Public Anchor | Real public anchors where available + synthetic local units |
| General bed capacity | Public Anchor | Public reference anchor where available / synthetic where unavailable |
| Dengue-specific bed allocation | Synthetic | Synthetic demonstration values only |
| Current dengue occupancy | Synthetic | Synthetic demonstration values only |
| NS1 / RDT stock | Synthetic | Synthetic demonstration values only |
| IV fluid stock | Synthetic | Synthetic demonstration values only |
| Baseline daily consumption | Synthetic | Synthetic demonstration values only |
| Dengue case trends | Demo / Aggregate | Synthetic/demo aggregate — not official surveillance |
| Climate values | Demo / Aggregate | Synthetic/demo or public-style aggregate values |
| Patient-level records | Not Used | Not collected, processed, or stored |
Spatial Exposure Heuristic
The prototype forecasts dengue at city level and allocates expected cases to zones using a spatial exposure heuristic — not a learned spatial epidemiological model.
Exposure Index Formula
Exposure Index =
Population Share × 0.40
+ Density Weight × 0.30
+ Facility Pressure Weight × 0.20
+ Mobility Corridor Weight × 0.10
This is not a learned spatial epidemiological model. It is a transparent allocation mechanism used because ward-level dengue surveillance data may not be available in the prototype context.
Operational Design
Operational Workflow Assumption
The prototype is designed so that operational users are never required to touch code, scripts, or data files.
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.
Current Prototype
CSV / JSON data files
synthetic demo data
Python analytics pipeline
manual / scheduled run
Static dashboard outputs
JSON → Next.js frontend
Future Production
Scheduled ingestion
automated data feed
API / database feeds
real-time or daily batch
Automatic pipeline runs
triggered by new data
Access-controlled dashboard
role-based login
Audit logs
traceability & governance
MIS / Data Officer
Runs pipeline updates
Public Health / Hospital Users
Review translated outputs
Decision-Makers
Act with human judgment
Modelling Limitations
Modelling Limitations
Random Forest was selected and adopted using deterministic synthetic rolling-origin evidence — not claimed as superior on real Dhaka data.
Validation uses demo/synthetic aggregate data, not official surveillance records.
The model cannot prove causal effects of rainfall or humidity on dengue transmission.
Feature importance, if shown, is interpretability only — not causal attribution.
Real deployment would require external validation on real epidemiological data.
Lag structure (14d, 28d) is based on biological reasoning; it is not statistically optimised for Dhaka South specifically.
Decision-Support Scope
Decision-Support Limitations
The System Helps Answer
- Where risk may rise across epi weeks
- Where supply pressure may emerge based on SDH
- Where bed pressure may appear based on LOS modelling
- Which zones may need vector-control attention
The System Does Not Decide
- Exact procurement orders or quantities
- Official emergency declaration triggers
- Clinical treatment decisions
- Public warning issuance
- Final resource deployment decisions
Risk Mitigation
Risk of Misuse and Mitigation
| Risk | Mitigation |
|---|---|
| Overinterpreting synthetic data as real | Data mode banners, assumption page, and explicit status labels |
| Treating forecast as certain | Uncertainty scenarios (best / expected / worst) shown prominently |
| Ignoring human judgment | Human-in-the-loop language throughout all outputs |
| Using outputs for clinical diagnosis | Explicit no-diagnosis statement in ethics and UI |
| Static vulnerability permanently biasing zones | Vulnerability-gated priority score design |
| False confidence in synthetic facility values | Synthetic readiness labels and notes on all facility outputs |
Future Work
Future Validation Roadmap
Eight prioritised steps required to move from prototype towards real operational deployment.
Replace demo data with official surveillance
Use official aggregated dengue surveillance data from DGDA, IEDCR, or city corporation epidemiology unit.
Validate climate lags against historical outcomes
Test whether 14-day and 28-day lag assumptions hold against real dengue outbreak timelines in Dhaka.
Validate uncertainty on untouched real data
Re-evaluate the frozen temporal range policy on post-selection Dhaka observations before any deployment claim.
Validate facility readiness logic
Use authorised hospital data to validate dengue bed capacity, occupancy, and inventory estimates.
Test zone prioritisation against historical response
Assess whether the spatial exposure heuristic aligns with documented outbreak zones and vector-control deployments.
Add secure scheduled ingestion pipeline
Automate data ingestion from authorised sources with error handling, logging, and data freshness checks.
Add access control and audit logs
Implement role-based access, session management, and immutable audit logs for all data and model actions.
Develop simplified public advisory layer
Create a public-facing output layer that presents risk levels in plain language without exposing facility or model details.
The value of DengueOps AI is not that it already represents a live city-wide deployment. Its value is that it demonstrates a transparent, auditable, and extensible decision-support architecture for converting outbreak forecasts into preparedness intelligence.
Assumptions Summary — DengueOps AI · IEEE ICADHI 2025
DengueOps AI — Simulation-Based Dengue Surge Preparedness Decision Support for Dhaka South. Prototype only. Not for clinical or official public health use.