Skip to main content
Program Design2026-02-248 min read

Building a Consistent Multi-Site Surveillance Program

Consistency across locations is an organizational problem before it is a technical one, and it is usually solved by narrowing scope rather than adding process.

INTERNATIONAL MOSQUITO AND VECTOR CONTROL

A single well-run monitoring site is straightforward. Twenty sites across several jurisdictions, serviced by different crews on different schedules, is a different problem entirely. The failure mode is predictable: each location develops its own local practice, and after two seasons the organization cannot compare any of them.

The instinct is to respond with more process. In practice, multi-site consistency comes from defining a small mandatory core precisely and being deliberately permissive about everything else.

01

Define the minimum comparable record

Decide which fields must be identical everywhere, and keep that set small. Typically: site identifier, date and time, equipment type and identifier, servicing interval, count or observation result, a controlled set of condition descriptors, and inspector identity. That is the layer the whole program depends on.

Everything beyond that core can vary by location. A site with an unusual habitat feature may need extra fields; a site with access complications may need transport notes. Local additions are fine as long as the core is untouched, because comparability only requires the core.

02

Use controlled vocabulary for anything descriptive

Free-text condition fields do not aggregate. If one inspector writes "heavy vegetation," another "overgrown," and a third "veg dense," the program has three unrelated values. Providing a fixed list of terms with definitions, and a separate open notes field for anything the list does not cover, resolves this at the point of entry.

Keep the list short enough to be memorized and specific enough to be meaningful. Long taxonomies get used inconsistently, which reproduces the original problem in a more official-looking form.

03

Give every site a documented reason to exist

Each monitoring location should carry a written rationale: what it is meant to detect, why the placement was chosen, what habitat it represents, and what would justify moving or retiring it. Sites without a stated purpose are the first to be dropped when staffing is short, and their historical records become uninterpretable once the person who chose them has left.

This also creates a mechanism for reducing network size honestly. A site whose stated purpose is now served by a neighboring location can be retired with a documented reason rather than quietly skipped.

04

Design the schedule around actual staffing

Programs routinely design monitoring intervals against ideal capacity and then run at partial compliance. Partial compliance is worse than a longer interval, because the gaps are unrecorded and irregular, which makes the whole series harder to interpret.

Plan the interval you can maintain in your worst staffing month, and treat additional visits as documented extras. A fourteen-day interval consistently met produces a more usable dataset than a seven-day interval met sixty percent of the time.

05

Standardize the kit, not just the form

Consistency in records depends on consistency in equipment. If sites use different trap models, different collection containers, or different power arrangements, results are not comparable even with identical forms.

Define kit configurations by contents list and assign a configuration to each site type. Where equipment must differ, record the difference as a site attribute so it can be accounted for during analysis rather than discovered as an anomaly.

06

Build in a supervisory review step

Consistency degrades gradually and invisibly. A periodic review comparing recent records across crews, checking completeness, and looking for drift catches it while correction is still cheap. This does not require re-doing fieldwork; it requires someone looking at the records as records.

Make the review a defined responsibility with a schedule. Reviews that depend on someone noticing a problem happen only after the problem has been present for a season.

07

Onboard new staff from documentation, not shadowing

In programs with seasonal hiring, practice is transmitted by shadowing experienced staff. Each transmission introduces variation, and after several cycles different crews are effectively running different protocols descended from a common ancestor.

Written checklists, forms with embedded guidance, and a short reference manual let each new crew start from the same source. Shadowing remains valuable, but as reinforcement rather than as the primary channel.

08

Accept that some history will not be comparable

When standardizing an existing multi-site program, resist the temptation to retroactively normalize everything. Some historical records cannot be mapped to the new structure without assumptions that will later be mistaken for data.

Mark the boundary explicitly. Records before a stated date are available for context but excluded from comparison. This is a more honest position than a continuous series that quietly changes meaning partway through, and it means the new structure starts clean.

TakeawaysSUMMARY
  • 01Define a small mandatory core record and allow local additions around it.
  • 02Use controlled vocabulary with a separate open notes field.
  • 03Document why each site exists and what would justify retiring it.
  • 04Set intervals against worst-case staffing, not ideal capacity.
  • 05Standardize kit configurations, not only forms.
  • 06Schedule supervisory consistency reviews as a defined duty.
  • 07Mark the boundary where comparable history begins.
Scope Notice

Website information is provided for general informational purposes and does not constitute medical, public-health, regulatory, environmental, scientific, or legal advice. Services and technology are intended to support qualified human decision-making. Results depend on local conditions, program implementation, available data, and other factors.

Engagement RequestAPPT ONLY

Apply this to your own program

If this describes a problem you recognize, the next step is a conversation about your actual records rather than a general one about method.