Applies to: Model description v1.0.0

Type of change: New feature, for next minor revision of the software.

Summary: This RFC adds several new “triggers” for starting vaccination, and also expands the retrospective vaccination option.

Justification: Having only an option to start vaccinating after a certain number of detections is insufficiently flexible.

Change: Section Initiation of a vaccination program begins by stating how a vaccination program was triggered in the previous version of the model. This old text is removed:

A vaccination program is initiated when the user-specified number of infected units has been detected. Until or unless this number is reached, units are not marked for vaccination.

Change: The struck-out text above is replaced by a list of all the new ways in which a vaccination program can be triggered. The new text:

There are several conditions that can trigger initiation of a vaccination program. They are:

• Disease has been detected in a given number of units of certain production types. For example, we might create two triggers:

  1. Initiate a vaccination program if disease has been detected in any 5 units out of this set of production types: dairy cattle, beef cattle, mixed cattle.
  2. Initiate a vaccination program if disease has been detected in any 2 units out of this set of production types: sheep, goats.

  The modeler can create any number of triggers of this type.

  Note that this type of trigger can be used to imitate simulations created in model version 1.0. The earlier model version allowed only one type of trigger: “Initiate a vaccination program if disease has been detected in ‘n’ units.” An equivalent trigger can be created in model version 1.1 by specifying the same number of units ‘n’ and including all production types.

• The rate of new detections has exceeded a given threshold. The threshold is specified by a number of units and a number of days, for example, “3 or more units detected within 5 days.”

  As with the previous trigger type described above, this can be limited to a certain set of production types. Also as with the previous trigger type described above, the modeler can create more than one trigger of this type, so that different rates can be specified for different sets of production types.

• The Estimated Dissemination Rate has exceeded a given threshold. The threshold is specified by a number of days and a ratio, for example, “initiate a vaccination program if the number of units detected in the last 5 days is 1.5× or more than the number of units detected in the 5 days before that.”

  As with the previous trigger types described above, this can be limited to a certain set of production types. Also as with the previous trigger types described above, the modeler can create more than one trigger of this type, so that different rates can be specified for different sets of production types.

• Disease has been detected in a given number of production type groups. The intention of this trigger is to initiate a vaccination program when disease spreads beyond one industry “sector”. This kind of trigger requires the modeler to divide the production types into groups, and specify in how many groups disease must be detected to trigger a vaccination program.

• A given number of days have elapsed since the first detection. As with the previous trigger types described above, this can be limited to the first detection in a certain set of production types. Also as with the previous trigger types described above, the modeler can create more than one trigger of this type, so that different numbers of days can be specified for different sets of production types.

• Any unit that has been marked for destruction because it was detected as diseased (that is, an Infected Premise) has been awaiting destruction for a given number of days. The intention of this trigger is to initiate a vaccination program when destruction resources appear to be overwhelmed.

  As with the previous trigger types described above, this can be limited to units of a certain set of production types. Also as with the previous trigger types described above, the modeler can create more than one trigger of this type, so that different wait times can be specified for different sets of production types.

Any number of these triggers can be created by the modeler. If no triggers are created, vaccination will never begin. If more than one trigger is created, the triggers are considered to have an “or” between them: for example, “initiate a vaccination program once disease has been detected in 10 units or once disease has been detected in 2 production type groups.” Put another way, the first trigger whose conditions are satisfied will initiate a vaccination program.

The modeler can specify a different set of triggers to be used after a vaccination program is ended. (See section Ending a vaccination program). This enables the modeler to specify a less stringent set of conditions for re-initiating a vaccination program.

Change: Section Initiation of a vaccination program goes on to talk about which detected units have vaccination rings drawn around them. The old text made specific mention of a “critical number of detections” being reached; this needs to change to more generic wording now that other types of triggers are available. This text also changes to reflect the new retrospective vaccination feature.

Note that this change does not discuss the change from rings only to rings and donuts; that is discussed in a separate RFC.

Once this critical number has been reached a vaccination program has been initiated, units within the specified vaccination ring surrounding the most recently detected unit are marked for vaccination. Vaccination rings also will be created around any unit that is detected on the same simulation day that the critical number is reached the vaccination program is initiated, and “retrospectively” around any units that were detected in the previous few days (the number of days is user-specified). Similarly, vaccination rings will be created around infected units detected on subsequent simulation days. Units marked for vaccination are then treated according to the steps described below.

Change: A new global parameter is added in Section Vaccination. This new parameter is added to the bottom of the Global parameters (applied to all production types) list:

• how far back retrospective vaccination applies (days) (see section Initiation of a vaccination program)

Change: Several words are removed in Section Vaccination. Again this is because the old text made specific mention of a “number of detected units”, which needs to change to more generic wording now that other types of triggers are available.

The initiation of a vaccination program may be delayed until a certain trigger point is reached in terms of numbers of detected units (see section Initiation of a vaccination program).

Change: A new section is added:

Ending a vaccination program

The vaccination program may optionally be ended if a given number of days pass with no more than a given number of new detections, for example, if 30 days pass with no more than 3 new detections. The number of new detections can be zero to specify a time period with strictly no new detections. As with the trigger types described above, the counting can be limited to a certain set of production types. When a vaccination program is ended, all units currently on the vaccination waiting list are removed from the list.

After a vaccination program has ended, it may be re-initiated if any of the conditions set by the user for initiation of a vaccination program are met (see section Initiation of a vaccination program). When a vaccination program is re-initiated, the vaccination waiting list does not re-add units that were removed from the list when the vaccination program was ended. This is true even if retrospective vaccination is in effect: the retrospective days go back only to the point at which the vaccination program was ended.

When a vaccination program is ended, the various vaccination triggers (see section Initiation of a vaccination program) are reset in the following ways:

• The number of detections trigger has its count reset to zero.
• The rate of detections trigger, which retains detection information over the past ‘n’ days, has its count reset to zero.
• The Estimated Dissemination Rate trigger, which divides the number of new detections in the last ‘n’ days (the numerator) by the number of new detections in the ‘n’ days before that (the denominator), has its counts reset to zero.
• The number of production type groups (industry sectors) trigger has its count of groups involved in the outbreak reset to zero.
• The number of days elapsed since the first detection trigger resets and begins listening for the first detection post-ending of the vaccination program.
• The destruction wait time trigger resets and tracks only the wait time of units added to the destruction queue post-ending of the vaccination program.

Change: A new 2nd paragraph is added to section Vaccination capacity to note that different capacity charts apply the first time a vaccination program is initiated vs. later re-starts.

If a vaccination program is re-initated after being ended (see section Ending a vaccination program), a different relational chart applies. This enables the modeler to specify a faster ramp-up of resources when a vaccination program is re-initiated. This second chart is given as the number of units which can be vaccinated per day versus the number of days since the first detection post-ending of the vaccination program. If there have been no detections post-ending of the vaccination program (e.g., the vaccination program is re-initiated by the destruction wait time trigger, not by any new detection) then the second chart is treated as the number of units which can be vaccinated per day versus the number of days since the re-start of the vaccination program.

This second chart also applies to any subsequent re-starts, if the vaccination program is ended and re-initiated more than once.

End of changes

Additional notes

Note 1

The notion of initiating a vaccination program when the geographical area covered by the outbreak reaches a certain extent was discussed. Several ways to quantify this were suggested:

• Use the number of foci.
• Take the east-west spread or the north-south spread of the detected units, whichever is largest.
  
• Compute the area of the “convex hull” around the detected units. Note that there will be no area until at least 3 units are detected.
  
  An area-based measure like this could be used in a trigger either as an absolute value, or as a proportion of the entire study area.

The consensus was to defer this idea to a later version.

Note 2

The notion of initiating a vaccination program when a certain number of animals are known to be infected was discussed. The consensus was to defer this idea to a later version. This idea was raised again in a Feb. 13 2013 email from D. Styles to K. Forde-Folle.

The notion of terminating a vaccination program once all depopulation is complete was discussed. The consensus was to defer this idea to a later version.

Note 3

There is a potential conflict between retrospective vaccination and the stop trigger rule, as illustrated here:

In the RFC, we have stated that those units are not re-added to the queue; rather, retrospective vaccination only goes as far back as the day the vaccination program was deliberately stopped.