Many comparisons create many opportunities to flag
If a system monitors many locations, conditions, and time windows, some unusual-looking results can occur by chance. A threshold that seems rare for one comparison may generate frequent alerts across the whole system.
The alert process needs to account for that monitoring context.
An alert is not an outbreak declaration
The next step may be checking data quality, reviewing cases, or seeking corroborating evidence. The workflow should say who does that and how quickly.
| Design question | Why it matters |
|---|---|
| What change matters? | Defines the detection target |
| What false-alert burden is manageable? | Connects statistics to staffing |
| What follow-up is available? | Makes the signal actionable |
| What is missed? | Keeps sensitivity limits visible |
Evaluate in realistic conditions
Historical testing can help assess detection timing and false signals, but the data should resemble the deployed reporting process, including delays and revisions. Testing only on cleaned final data can overstate real-time performance.
The best threshold is not simply the one producing the most alarms or the fewest. It is part of a system that can identify meaningful changes and respond appropriately without exhausting its capacity on signals it cannot interpret.
