Dengue and Diarrhoea Cluster Detection from Daily Clinic Case Reports

The problem: outbreaks noticed after they peak

Dengue returns to Lahore, Rawalpindi, Karachi and many other cities every year after the monsoon. Diarrhoea outbreaks follow contaminated water supply. Clinics and labs report suspected cases, but the reports often arrive as paper forms or spreadsheets, and district teams look at totals by week. A cluster of cases in one neighbourhood can grow for days before anyone sees it in the numbers, and by then larvae control or water testing is late.

District teams are not short of data; they are short of time to analyse it. A health officer covering a whole district cannot inspect every neighbourhood's daily counts by hand, and simple weekly thresholds either miss small local clusters or fire constantly in peak season. What they need is a short, ranked list each morning of places where the pattern of cases is genuinely unusual, with enough detail to decide whether to send a team, and a record of what was done about each alert.

Spotting an unusual cluster early, in a specific place, is the job of space-time surveillance methods. They are well established in research and public health agencies with statisticians, and rarely used in day-to-day district work.

What already exists and the gap

• The Punjab Information Technology Board's Dengue Activity Tracking System records anti-dengue field activities such as larvae surveillance, with geo-tagged photos from field staff across districts.
• DHIS2 is widely used for health information reporting and dashboards.
• SaTScan is free desktop software for scan statistics, used by epidemiologists who prepare data and interpret output by hand.

The gap is the daily, automatic link between case reports and a cluster detection method, with address cleaning and an alert workflow a district health officer can use without a statistician.

Inspiration

A Space-Time Permutation Scan Statistic for Disease Outbreak Detection (Kulldorff, Heffernan, Hartman, Assunção and Mostashari, PLoS Medicine, 2005) introduced a prospective method that needs only case counts by place and time, with no population data, and tested it on daily emergency department visits in New York City, where it flagged clusters that heralded citywide gastrointestinal outbreaks. That property, needing only cases, makes it a good fit where reliable population figures per neighbourhood are hard to find.

What you build

• Clinics and labs (or a data clerk) upload a daily line list: date of onset or visit, rough address, age band and suspected diagnosis.
• The pipeline validates and geocodes each case to a neighbourhood, then runs the scan each morning.
• Health officers open a map showing any significant clusters, with the number of cases observed and expected, and mark each alert after follow-up.

The technically interesting part

• Geocoding messy addresses. Addresses such as "near Jamia Masjid, Block C" need a gazetteer of neighbourhoods, landmarks and fuzzy matching. Report a confidence score and keep low-confidence cases out of the scan or at a coarser level.
• Implementing the scan. Build cylinders in space and time over neighbourhood centroids, compute the likelihood ratio under the permutation model, and assess significance with Monte Carlo replications. Make it fast enough to run daily.
• Handling reporting delays. Cases arrive late. Decide how many recent days to include and measure how delays affect alerts.
• Validation without ground truth. Use historical data if a health department shares it under agreement, or simulate outbreaks into realistic background data and measure detection delay and false alarms.

How to evaluate it

• Detection delay: days between a simulated outbreak's start and its first alert.
• False alarms: alerts per month on background data with no injected outbreak.
• Agreement: on a test dataset, compare your implementation's clusters with SaTScan's output on the same input.
• Usability: walk a public health professional or community medicine teacher through a week of alerts and record their judgement.

Suggested plan

• Weeks 1 to 4: read the Kulldorff paper and SaTScan documentation; talk to a community medicine department.
• Weeks 5 to 10: synthetic data generator, ingestion and validation.
• Weeks 11 to 15: geocoder and gazetteer for one city.
• Semester 2, weeks 1 to 6: scan implementation and comparison with SaTScan.
• Semester 2, weeks 7 to 12: alert workflow, map and evaluation.
• Semester 2, weeks 13 to 15: report and demo.

Path to a product

District health offices, public health programmes and NGOs running clinics need early warning, and tools that work with existing reporting systems are easier to adopt. An open source module that plugs into existing data flows, with support contracts, is realistic. The project is strong evidence for health data and analytics roles.

Scope warning

Never use identifiable patient data without formal approval; build and test on synthetic data first. Do not predict outbreaks from weather or social media; detect clusters in reported cases. An alert is a prompt to investigate, not a diagnosis, and the interface must say so.

Learn what you need on Sefism

• Data science roadmap: statistics, hypothesis testing and simulation.
• Data engineering roadmap: the daily ingestion pipeline.
• OpenIntro Statistics: the statistical foundations for likelihood and significance.
• pandas User Guide: cleaning and reshaping line lists.
• PostgreSQL Documentation: storing cases and neighbourhood boundaries.

Get help with this idea

The hard parts are realistic test data, a correct scan implementation and alerts that do not cry wolf. Tauseef can help you plan the simulation, find a public health partner and structure the evaluation. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session