ModelInterventions
OpenMalaria can simulate a comprehensive set of existing and hypothetical interventions against malaria. Interventions may be either preventive or curative (though curative interventions also have a preventive effect by reducing onward transmission).
This page describes how to implement simulations of preventive interventions. Curative interventions (case management) are described separately.
Preventive interventions include:
- Interventions targeting malaria in humans (mass drug deployment (MDA/MSAT), vaccines (PEV/BSV/TBV))
- Vector control interventions (insecticidal nets (ITN/LLIN), indoor spraying (IRS), larviciding, zoo-prophylaxis, odour-baited traps (OBTs) etc.)
Preventive interventions are simulated by including sub-elements in the <interventions> element of the XML.
Up to and including version 32, each intervention was separately specified within the <interventions> element.
From Version 33 onwards, the primary distinction in the description of interventions is between
-
interventions allocated to individual humans which are specified within the
<human>sub-element of the<interventions>element. (Other assignments to simulated humans, e.g. sub-population membership are also specified within the<human>sub-element). -
vector control interventions that are allocated at the population level which are specified within the
<vectorPop>sub-element of<interventions>. - other interventions and utilities or pseudo-interventions (e.g. clearing immunity), which retain their own sub-elements within
<interventions>are change the health system, change EIR (non-vector model), uninfect vectors, import infections, special R_0 intervention.
From version 43.0 onwards, it is possible to add new non human hosts, or to modify existing non human hosts using either <addNonHumanHosts> or <nonHumanHostsModifications> intervention blocks. See Non-human hosts interventions.
<interventions name="example of intervention descriptions">
<human>
...
</human>
<vectorPop>
...
</vectorPop>
...
<changeHS ... />
<changeEIR ... />
<importedInfections ... />
<insertR_0Case ... />
<uninfectVectors ... />
<addNonHumanHosts .../>
<nonHumanHostsModifications... />
</interventions>where each sub-element is optional and the sub-elements can be in any order.
The following table lists interventions which have been implemented in OpenMalaria, the different ways in which deployment may be simulated and where to find the XML for doing this. In addition to version-dependence, in some cases there is more than one way of simulating the intervention. For further details follow the links under software version you are using:
| Intervention | XML element | v33+ sub-elements | XML element (earlier versions | Timed deployment | Age-based deployment | Compatible with vector | Compatible with non-vector |
|---|---|---|---|---|---|---|---|
| Case Management | see healthSystem | healthSystem | yes | no | yes | yes | |
| Change case management | changeHS | see healthSystem | changeHS | yes | no | yes | yes |
| Vaccination | <human> |
<vaccine> |
<vaccine> |
yes | yes | yes | yes |
| Mass drug administration | <human> |
<treatSimple ... />``<treatPKPD ... />``<treatment> |
MDA, MDA1D | yes | from version 32 | yes | yes |
| Intermittent Preventive Treatment | <human> |
<treatSimple ... />``<treatPKPD ... />``<treatment> |
IPT | yes | yes | yes | yes |
| Test and Treat | <human> |
<treatSimple ... />``<treatPKPD ... />``<treatment> <screen> <diagnostic> |
MDA, MDA1D | yes | yes | yes | yes |
| Insecticide Treated Nets (ITNs) | <human> |
<ITN>, <GVI>
|
ITN | yes | from version 32 | yes | no |
| Long-Lasting Insecticide Treated Nets (LLINs) | <human> |
<ITN>, <GVI>
|
ITN | yes | from version 32 | yes | no |
| Indoor Residual Spraying (IRS) | <human> |
<IRS>, <GVI> <IRS>, <GVI>
|
<IRS> |
yes | from version 32 | yes | no |
| Deterrents | <human> |
GVI | yes | no | yes | no | |
| Repellents | <human> |
GVI | yes | no | yes | no | |
| Ivermectin treatment of humans | <human> |
GVI | yes | no | yes | no | |
| Zoo-prophylaxis | <vectorPop> |
see host independent vector control | yes | no | yes | no | |
| Insecticidal baits | <vectorPop> |
<seekingDeathRateIncrease> |
yes | no | yes | no | |
| Source reduction | <vectorPop> |
<changeEIR> <emergenceReduction>
|
yes | no | no | yes | |
| Larviciding | <vectorPop> |
<changeEIR> <emergenceReduction>
|
yes | no | no | yes |
An intervention is a method used to bring about a change in the state of the simulation (e.g. to reduce transmission). Some are designed to simulate a real-world malaria control device (e.g. a bed net) but there are also several with no real-world equivalent (e.g. "uninfect vectors").
The initial case-management system functions during the warm-up period of the simulation and therefore does not bring about a change in this sense, however, a change to the health system is considered to be an intervention.
Some models can be used to simulate established strategies (e.g. mass drug administration), while some have effects that do not correspond to any currently known intervention (e.g. "uninfect vectors"). Some do not directly affect malaria dynamics, but instead change the status of the simulated hosts in some other way (e.g. sub-population recruitment).
From schema 32, human-targeting interventions are described in terms of "components" and "deployment programmes".
-
A "component" is defined either as an intervention (e.g. LLIN), an effect of Intervention (that might be achieved in any of several ways, e.g. the blood-stage effect of a vaccine), or a pseudo-intervention (e.g. recruitment into a cohort). The
<component>XML element specifies the effect of the intervention, the decay of the effect over time, and meta-data such as the sub-population name and coverage status, -
A "deployment programme" describes how one or more components are deployed; each
<deployment>element specifies one or more components that are deployed simultaneously, for instance as a package of interventions that might be given to children at a specific age, or to some proportion of the population at a timed household visit. Mass treatment, test and treat, and intermittent preventive therapy are thus simulated by assembling components comprising distinct treating and if necessary screening interventions. -
From schema 35, conditions of deployment may be specified. This allows reactive interventions, e.g. mass screen and treat when a certain number of cases are detected, as well as any other type of conditional deployment. (The reactive deployment actually works by conditionally deploying very frequently.)
Multiple <component> elements corresponding to the same intervention (e.g. multiple vaccines of the same type) can be specified by using different id values, and the same <component> (e.g. a specific vaccine) can be deployed to different population groups (e.g. via continuous distribution with catch-up visits).
The XML description is as follows, (where all component elements must come before deployment elements):
<human>
<component id="effect1">...</component>
<component id="effect2">...</component>
<component id="effect3">...</component>
...
<deployment name="some deployment programme">
<!-- deploy these components: -->
<component id="effect1"/>
<component id="effect3"/>
<!-- via these deployment lists: -->
<continuous>...</continuous>
<timed>...</timed>
</deployment>
...
</human>Each <component> element contains one of the following sub-elements (mostly representing specific interventions):
| Intervention | XML element |
|---|---|
| screening | <screen ... /> |
| treatment | <treatSimple ... /> |
| treatment | <treatPKPD ... /> |
| enrol in decision tree | <decisionTree ... /> |
| pre-erythrocytic vaccine | <PEV ... /> |
| blood stage vaccine | <BSV ... /> |
| Transmission-blocking vaccine | <TBV ... /> |
| Insecticide-treated net | <ITN ... /> |
| Indoor residual spraying | <IRS ... /> |
| Generalised vector intervention | <GVI ... /> |
| Recruitment to cohort | <recruitmentOnly ... /> |
| Removal from cohort | <subPopRemoval ... /> |
| Set acquired immunity to zero | <clearImmunity ... /> |
and specifies the consequences that will arise each time it is deployed. The same intervention model, e.g. GVI, can be used in different components with different parameters. Each <component> element contains an id attribute (a textual identifier), and may contain a name (for documentation purposes), e.g.:
<component id="imm-suppress" name="Model complete loss of immunity">
<clearImmunity/>
</component>deployment elements describe the deployment of a set of intervention components. Deployment happens by selecting a set of humans on age criteria or at a certain time, then deploying components to all selected humans. The elements look something like:
<deployment name="example intervention">
<component id="effect1"/>
<component id="effect3"/>
<continuous>...</continuous>
<timed>...</timed>
</deployment>where:
-
componentelements list the components which are deployed when a deployment happens; theidreferences a component described above -
continuouselements control the selection of humans for deployment by potentially recruiting humans who reach a certain exact age -
timedelements control the selection of humans for deployment by potentially recruiting humans at a certain time during the simulation -
componentelements must come beforecontinuouselements which must come beforetimedelements
Deployment times and coverage details are described by the continuous and timed elements. Multiple continuous and timed elements may be used (useful if not all deployments should use the same sub-population or cumulative coverage rules), but all continuous elements must come first. These elements take the following form:
<continuous>
<restrictToSubPop id="subpop1"/> <!-- optional -->
<deploy targetAgeYrs="0.833" coverage="0.8"/>
<deploy targetAgeYrs="0.166" coverage="0.7"/>
<deploy targetAgeYrs="0.25" coverage="0.7"/>
</continuous>
<timed>
<restrictToSubPop id="subpop2"/> <!-- optional -->
<cumulativeCoverage .../> <!-- optional -->
<deploy time="0" coverage="0.6"/>
<deploy time="1y" coverage="0.6"/>
</timed>Timed (mass-deployment) campaigns: at each time given (days, steps or dates; see link), humans are selected from the target population with probability coverage. Age-based continuous deployment: from the start of the intervention period, humans are selected from the target population at exact age targetAgeYrs (years, converted to timesteps, rounding down (i.e. 0.5 years becomes 36 timesteps)) with probability coverage. Selected humans are then deployed all effects listed (with one exception: vaccine schedules may block deployment of vaccines, though not of other effects deployed by the intervention). Note that at each time step timed deployments happen before continuous deployments, and that it is technically possible for a single human to be selected and receive deployments two or more times in a single timestep.
Regular deployments (from schema 35) allow many evenly-spaced deployments to be specified more easily. Example:
<timed>
<deploy coverage="0.8" time="19t" repeatStep="1y" repeatEnd="20.027y"/>
<deploy coverage="0.8" time="37t" repeatStep="1y" repeatEnd="20.027y"/>
</timed>The target population is normally the entire simulated population, but attributes of the deploy elements and the restrictToSubPop element can change this. restrictToSubPop allows deployment to be restricted to a previously specified sub-population. cumulativeDeployment is used to target individuals who do not already have the intervention. Note that both apply to all deploy times/ages within the continuous/timed list in which they appear, but that multiple continuous and timed lists may be used. Further attributes allowed in deploy elements are:
| attribute | unit (type) | description | applicability |
|---|---|---|---|
begin |
timestep (integer) | Time from the beginning of the intervention period at which deployment starts | continuous |
end |
timestep (integer) | Time from the beginning of the intervention period at which deployment stops, plus 1 (previous timestep is the last on which deployment occurs) | continuous |
| minAge | years (floating-point) | Minimum age (inclusive) at which humans are considered eligible in years | timed |
| maxAge | years (floating-point) | Maximum age (exclusive) at which humans are considered eligible in years | timed |
| vaccMinPrevDoses | doses (integer) | See vaccine schedules; only affects vaccines | both |
| vaccMaxCumDoses | doses (integer) | See vaccine schedules; only affects vaccines | both |
cumulativeCoverage can be used with timed deployment to bring the overall coverage of some intervention up to some target level; normally coverage specifies the portion of the target population selected randomly at each deployment, but with this option coverage instead specifies a target coverage level. If coverage is already above the target level, nothing is done; if coverage is below, the necessary increase in coverage is calculated and this is used to randomly select unprotected humans. The element has one attribute: component, which should be the id of a sub-population (respectively an intervenvion component) for which membership is tested.
<component id="LLIN">
<ITN>...</ITN>
<subPopRemoval afterYears="3"/><!-- membership expires 3 years after deployment -->
</component>
<deployment name="LLIN programme">
<component id="LLIN"/>
<timed>
<cumulativeCoverage component="LLIN"/><!-- calculate coverage by membership in the LLIN sub-pop -->
<deploy time="0" coverage="0.8"/>
<deploy time="1y" coverage="0.8"/>
<deploy time="2y" coverage="0.8"/>
<deploy time="3y" coverage="0.8"/>
</timed>
</deployment>In most cases where multiple interventions are deployed at the same time, the exact order in which they are deployed does not matter, but in some cases it does, e.g. where intervention deployment is restricted to members of a sub-population who are recruited on the same timestep.
Timed intervention deployments always happen before continuous intervention deployments. Within each of these sets, deployments happen in the order the <deploy> elements occur in the XML. Each deployment ("campaign" or ...) may include multiple intervention components (e.g. ITN, vaccine). The order in which these components are deployed is fixed, but note that selection happens before any effects are deployed.
These are human-targeting interventions.
Three vaccine types are simulated. From version 32, multiple descriptions for each vaccine type are allowed and each vaccine description may be administered independently. Types of vaccine:
- Pre-erythrocytic vaccine (vaccineType
PEV): prevents a proportion of infections from commencing. - Blood-stage vaccine (vaccineType
BSV): acts as a killing factor on blood-stage parasites - Transmission-blocking vaccine (vaccineType
TBV): one minus this scales the probability of transmission to mosquitoes
Vaccine efficacy is calculated as initialEff * decayFactor, where initialEff is sampled from a Beta distribution, and decayFactor is described by the decay element and time since last deployment (see DecayFunction configuration).
The Beta distribution takes two parameters: β, set by efficacyB, and α, set as "β × μ / (1 - μ)". μ is set to one of the given initialEfficacy values: the first value the first time this vaccine component is administered, the second the second time, etc. (repeating the last value if necessary). Any number of initialEfficacy values can be given.
Note: the mean initial efficacy is μ (initialEfficacy), and the variance is "m × (1 - m)^2 / (1 - m + β)" (thus a large β=efficacyB can be used to minimise variance).
Since version 44.0, it is possible to specify per-genotype vaccine efficacy:
The VACCINE_GENOTYPE model option must be set:
<ModelOptions>
<option name="VACCINE_GENOTYPE" value="true"/>
</ModelOptions>
When the VACCINE_GENOTYPE option is set, the user MUST provide a phenotype description including initialEfficay values for each locus and allele defined in the parasiteGenetics section of the xml.
...
<PEV> <!--assuming csp (from RTS.S-A01), anti-circumsporozoit -->
<decay L="7.32" k="0.69" function="weibull"/>
<efficacyB value="10.0"/> <!-- efficacyB is used in beta distribution to assign efficacy of vaccine to an individual, allows heterogeneity-->
<phenotype name="sensitive">
<restriction onLocus="x" toAllele="sensitive"/>
<initialEfficacy value="0.91"/>
<initialEfficacy value="0.49"/>
</phenotype>
<phenotype name="resistant">
<restriction onLocus="x" toAllele="resistant"/>
<initialEfficacy value="0.91"/>
<initialEfficacy value="0.49"/>
</phenotype>
</PEV>
...
<parasiteGenetics samplingMode="tracking">
<!-- Define name/freq/fitness of the locus/alleles defined in the drugPD code -->
<locus name="x">
<allele fitness="1" initialFrequency="0.5" name="sensitive"/>
<allele fitness="1" initialFrequency="0.5" name="resistant"/>
</locus>
</parasiteGenetics>
...
When VACCINE_GENOTYPE is set, nExpected is no longer affected by the PEV vaccine. Only the reporting is affected, and the simulation will work as expected.
Use standard continuous and mass deployment descriptions.
Prior to schema 32, mass deployments select a different portion of the population each time according to the coverage given, as with any other intervention. Continuous deployments work in the same way, except that after selecting individuals according to the coverage described, any individuals who either missed a previous continuous dose (unless receiving a campaign dose to catch up) or have already received this scheduled dose (through campaign) will not receive their dose. (Thus true coverage may be less than the coverage requested.)
From schema 32, both mass and continuous deployments act, by default, like any other intervention: select the target population randomly according to coverage, then deliver. This behaviour can be changed via options within the element (e.g. to simulate the old behaviour) by specifying vaccMaxCumDoses and/or vaccMinPrevDoses. These attributes are specified per deployment. After selecting an individual, the vaccine is administered only if the total number of doses will not exceed vaccMaxCumDoses and the number of doses prior to this administration is at least vaccMinPrevDoses. If not specified, vaccMinPrevDoses defaults to 0 and vaccMaxCumDoses to a very large number (> 10^9), and thus have no effect. Use of these attributes can cause fewer doses to be deployed than the number implied by the specified coverage.
For each of these vaccine types, any positive number of doses can be simulated. Vaccine efficacy is assigned to the host depending on how many previous vaccinations they have received and the time since the last of these vaccinations (with efficacy decaying as described in ModelDecayFunctions). The '' element(s) specify the simulated efficacy immediately after receipt of each dose (i.e. the first such element corresponds to 1st dose, the 2nd to 2nd dose etc...).
Vaccines need to be configured per-scenario. From schema 32, each vaccine effect is described separately, then deployed within one or more interventions:
<interventions name="...">
<human>
...
<component id="my_TBV_effect">
<TBV>
<decay L="10.0" function="exponential"/>
<efficacyB value="10"/>
<initialEfficacy value="0.512"/>
<initialEfficacy value="0.64"/>
<initialEfficacy value="0.8"/>
</TBV>
</component>
<component id="some_PEV">
<PEV>
<decay L="10.0" function="exponential" CV="0.2"/>
<efficacyB value="10"/>
<initialEfficacy value="0.512"/>
<initialEfficacy value="0.64"/>
<initialEfficacy value="0.8"/>
</PEV>
</component>
...
<deployment>
<component id="my_TBV_effect"/>
<component id="some_PEV"/>
<continuous>
<deploy coverage="0.95" targetAgeYrs="0.0833" vaccMaxCumDoses="1" vaccMinPrevDoses="0"/>
<deploy coverage="0.95" targetAgeYrs="0.17" vaccMaxCumDoses="2" vaccMinPrevDoses="1"/>
<deploy coverage="0.95" targetAgeYrs="0.25" vaccMaxCumDoses="3" vaccMinPrevDoses="2"/>
</continuous>
<timed>
<deploy coverage="0.95" time="1t" vaccMaxCumDoses="3"/>
<deploy coverage="0.95" time="7t" vaccMaxCumDoses="3"/>
<deploy coverage="0.95" time="13t" vaccMaxCumDoses="3"/>
<deploy coverage="0.95" time="366t" vaccMaxCumDoses="3"/>
<deploy coverage="0.95" time="731t" vaccMaxCumDoses="3"/>
<deploy coverage="0.95" time="1096t" vaccMaxCumDoses="3"/>
</timed>
</deployment>
...
</human>
</interventions>Add the possibility to deploy interventions with a minimum and / or maximum host availability. This is only useful when heterogeneity is used. This may be used for example to simulate the deployment of interventions to remote areas where hosts are more exposed to bites.
Heterogeneity in human-to-mosquito availability can be enabled in the vector model by specifying a distribution and coefficient of variation (or variance) for each species. For example:
<availability distr="lognormal" CV="2"/>
or
<availability distr="gamma" variance="2"/>
OpenMalaria will pre-compute percentiles by sampling the distribution made of the sum of the availability distribution for each species. Only the raw availability will be considered here, this excludes reduction in availability due to age or interventions.
The deployment of human interventions (timed, cumulative or continuous) now allows a minimum and / or a maximum availability percentile, as follows:
<interventions name="GVI example">
<human>
<component id="GVI_example">
<GVI>
<decay function="exponential" L="3y"/>
<anophelesParams mosquito="gambiae_ss">
<deterrency value="0.7696"/>
<postprandialKillingEffect value="0.0544"/>
</anophelesParams>
<anophelesParams mosquito="funestus">
<deterrency value="0.7696"/>
<postprandialKillingEffect value="0.0544"/>
</anophelesParams>
<anophelesParams mosquito="arabiensis">
<deterrency value="0.7696"/>
<postprandialKillingEffect value="0.0544"/>
</anophelesParams>
</GVI>
</component>
<deployment name="GVI_example">
<component id="GVI_example"/>
<timed>
<deploy coverage="0.8" maxAge="95" minAge="0" minAvailability="50" maxAvailability="100" time="2005-01-01"/>
</timed>
</deployment>
</human>
</interventions>Only hosts within the availability percentile range will be considered. If not specified, the range will be 0-100%. Note that 100% is equivalent for infinity.
From Version 32, Mass Drug Administration, Intermittent Preventive Treatment and Mass Screen and Treat and other Test-and-Treat strategies are all simulated as human-targeting intervention, requiring specification of population deployment of drugs, (with or without Screening) via <component> sub-elements of the <human> element of the XML.
There are several ways of simulating mass drug administration regimens;
- treatSimple elements: this is the most straightforward approach.
- treatPKPD elements. These should be used for analysis of pharmacodynamics and or selection of drug resistance. This is compatible only with specific within-host models.
- (from schema 32) configurable treatment, making use of either of the above.
<treatSimple> This component uses a simple treatment model to clear infections from humans to whom it is deployed. Example:
<component id="MDA">
<treatSimple durationBlood="1t" durationLiver="0"/>
</component>The duration parameters are described here (note that the syntax is slightly different). In addition, transmission blocking vaccine TBV elements can be used to simulate gametocytocidal effects, preventing onward transmission to mosquitoes (note that humans can harbour gametocytes up to 20 days following "parasite clearance"), and PEV elements can be used to simulate the prophylactic effects of drugs, preventing acquisition of new infections. Example:
<component id="AQ-SP-PEV">
<PEV>
<decay L="0.175496011811728" function="weibull" k="3.30019114668797"/>
<efficacyB value="1"/>
<initialEfficacy value="1.0"/>
</PEV>
</component>This component uses PK & PD modeling of treatment (only available on a 1-day time step) and requires specification of the PKPD model corresponding to the chosen drug schedule and dosage, which are specified in the pharmacology elements.
Example:
<component id="MDA">
<treatPKPD schedule="MQ1" dosage="MQ1"/>
</component>From schema 32, treatment is configurable. This allows the same actions as health system treatment, but adding stochastic selection from multiple options. A simple example:
<component id="mda" name="example with screening">
<MDA>
<!-- optional diagnostic here (see above) -->
<effects>
<option pSelection="1">
<clearInfections timesteps="1" stage="blood"/>
</option>
</effects>
</MDA>
</component>Stage should be one of:
-
blood: clear infections which are at least one 5-day timestep old (this may include pre-patent infections, since the latent period as set by
latentpis usually 15 days) - liver: clear infections during their first 5-day timestep
-
both: clear all infections
Note: it remains to be determined how blood or liver stage clearance applies when the timestep is not 5 days.
The
timestepsattribute can be: - -1: retrospectively clear infections (see here)
- 1: clear infections on the next update (recommended over -1)
-
n: clear infections on the next n updates (where n ≥ 1)
Prior to schema 32 this configuration was not available, and treatment acted as if
timesteps="-1" stage="both"was used.
As the pSelection parameter hints, multiple options can be used with different probabilities, e.g. to have a chance of no action. A (silly) example (showing what's possible):
<component id="mda" name="example with screening">
<MDA>
<!-- optional diagnostic here (to convert this to an MSAT simulation) -->
<effects>
<option pSelection="0.2">
<clearInfections timesteps="1" stage="blood"/>
<clearInfections timesteps="3" stage="liver"/>
</option>
<option pSelection="0.3">
</option>
<option pSelection="0.5">
<clearInfections timesteps="10" stage="both"/>
</option>
</effects>
</MDA>
</component>Mass screen and treat, requires deployment of diagnostics as well as treatments. The diagnostic used for screening is declared as part of the <diagnostics> element.
Deployment of interventions conditional on the results of the tests can be specified using either <screen> or <decisionTree> sub-elements:
This component does not directly affect humans, but simulates usage of a diagnostic then deploys one or more other components dependent on the outcome.
Example:
<component id="treat">
<!-- legacy effect -->
<treatSimple durationLiver="-1t" durationBlood="-1t"/>
</component>
<component id="MSAT">
<screen diagnostic="deterministic">
<positive id="treat"/>
</screen>
</component>To deploy more than one component, or deploy on negative outcome:
<screen ...>
<positive id="componentA"/>
<positive id="componentB"/>
<negative id="componentC"/>
<negative id="componentD"/>
</screen>Example:
<component id="MSAT">
<decisionTree>
<diagnostic diagnostic="RDT">
<positive>
<treatPKPD schedule="AL_treat" dosage="AL_dosages"/>
</positive>
<negative>
<noTreatment/>
</negative>
</diagnostic>
</decisionTree>
</component>Note that this example is no more complex than that done with a screen component above, but that many more decisions are available. TODO: link to description of trees.
The decision tree or screening require separate specification of the diagnostic and optionally triggers deployment of one or more other components on positive and/or negative outcomes, in particular, the different specifications of Treatment, namely "treatSimple" or "treatPKPD".
Each component has a corresponding 'deployment' element, so that overall, the specification for MSAT might read:
<human>
<component id="AS MSAT">
<decisionTree>
<diagnostic diagnostic="RDT">
<positive>
<treatPKPD schedule="AS" dosage="AS"/>
</positive>
<negative>
<noTreatment/>
</negative>
</diagnostic>
</decisionTree>
</component>
<deployment>
<component id="AS MSAT"/>
<timed>
<deploy coverage="0.85" time="1484"/>
<deploy coverage="0.85" time="1849"/>
<!-- enable if extending the time span:
<deploy coverage="0.85" time="2214"/>
<deploy coverage="0.85" time="2579"/>
<deploy coverage="0.85" time="2944"/>
<deploy coverage="0.85" time="3309"/>
<deploy coverage="0.85" time="3674"/>
<deploy coverage="0.85" time="4039"/> -->
</timed>
</deployment>
</human>Similarly to the <diagnostic> node, this one has two possible outcomes <positive></positive> and <negative></negative>. Note that a memory parameter can be provided. The memory parameter the number of days to look back for fevers. This must be less than or equal to the healthsystem memory parameter. In general, this should be less than or equal to the repeatStep in an MSAT intervention.
Example of a mass test and treat intervention (MSAT) that will treat every symptomatic hosts during one year.
<component id="MSAT">
<decisionTree>
<!-- fevers (counted with healthsystem memory) -->
<uncomplicated memory="5d">
<positive>
<treatSimple durationLiver="0" durationBlood="1t"/>
</positive>
<negative>
<noTreatment/>
</negative>
</uncomplicated>
</decisionTree>
</component>
<deployment>
<component id="MSAT"/>
<timed>
<deploy coverage="1.0" time="1992-06-30" repeatStep="5d" repeatEnd="1993-06-30"/>
</timed>
</deployment>This one allows the user to report custom events in the DecisionTree through the healthsystem, interventions, or both. The new measure is available by declaring the following survey option:
<option name="nCMDTReport" outputNumber="90" value="true" byAge="true"/> <!-- nHostsVisited -->Example of an intervention that will report clinical cases only if the host has fever and tests positive to the RDT diagnostic.
<component id="MSAT">
<decisionTree>
<uncomplicated memory="5d">
<positive>
<diagnostic diagnostic="RDT">
<positive>
<report outputNumber="90"/>
</positive>
<negative>
<noTreatment/>
</negative>
</diagnostic>
</positive>
<negative>
<noTreatment/>
</negative>
</uncomplicated>
</decisionTree>
</component>
<deployment>
<component id="MSAT"/>
<timed>
<deploy coverage="1.0" time="1992-06-30" repeatStep="5d" repeatEnd="1993-06-30"/>
</timed>
</deployment>
</human>Note that the report node has an additional parameter: outputNumber="X" where X must be an integer. By default, the "nCMDTReport" corresponds to the output number 80. However, it is possible (like with other measures), to declare it multiple times with different outputNumbers. This can be useful to track different categories (by age groups, by cohort, ...), but here we can also use this feature to control the reporting from the <report> node by specifying the output number directly (see example below).
Note that Any positive integer can be used as the outputNumber, but the user will get an error if a measure with the same number has already been declared in the SurveyOptions. If the outputNumber parameter specified in the <report> node does not exist, there will be no error and the report will have no effect. For this reason, it is important to double check that the outputNumbers declared in the SurveyOptions match the outputNumbers declared with <report>.
In addition, note that this will only work for the nCMDTReport measure. If an outputNumber corresponding to another measure is used in <report>, this will have no effect.
Example where the DecisionTree is used to compute nPatent and nUncomp.
SurveyOptions:
<option name="nCMDTReport" outputNumber="3" value="true" byAge="true"/> <!-- replaces npatent -->
<option name="nCMDTReport" outputNumber="14" value="true" byAge="true"/> <!-- replaces nUncomp -->
<option name="nCMDTReport" outputNumber="80" value="true" byAge="true"/> <!-- nHostsVisited -->Intervention:
<component id="MSAT">
<decisionTree>
<multiple>
<report outputNumber="80"/> <!-- nVisited -->
<diagnostic diagnostic="standard">
<positive>
<report outputNumber="3"/> <!-- replaces nPatent -->
</positive>
<negative>
<noTreatment/>
</negative>
</diagnostic>
<uncomplicated memory="5d">
<positive>
<multiple>
<treatSimple durationLiver="0" durationBlood="1t"/>
<report outputNumber="14"/> <!-- replaces nUncomp -->
</multiple>
</positive>
<negative>
<noTreatment/>
</negative>
</uncomplicated>
</multiple>
</decisionTree>
</component>
<deployment>
<component id="MSAT"/>
<timed>
<deploy coverage="1.0" time="1993-06-30" repeatStep="5d" repeatEnd="1994-06-30"/>
</timed>
</deployment>Example with a random outcome:
<interventions name="triggered MSAT">
<human>
<component id="MSAT">
<decisionTree>
<diagnostic diagnostic="RDT">
<positive>
<random>
<outcome p="0.9">
<treatSimple durationLiver="0" durationBlood="20d"/>
</outcome>
<outcome p="0.1">
<treatFailure/>
</outcome>
</random>
</positive>
<negative>
<noTreatment/>
</negative>
</diagnostic>
</decisionTree>
</component>
<deployment>
<component id="MSAT"/>
<timed>
<deploy coverage="0.8" time="19t" repeatStep="1y" repeatEnd="20y"/>
<deploy coverage="0.8" time="37t" repeatStep="1y" repeatEnd="20y"/>
</timed>
</deployment>
</human>
</interventions>A special intervention which instantly uninfects all mosquitoes of malarial parasites (though doesn't prevent reinfection). If combining with mass drug administration to eliminate malaria from a scenario, note that humans can harbour gametocytes up to 20 days following "parasite clearance", hence vectors will need to be uninfected multiple times.
Example, clearing vector infections multiple times in line with above note about eliminating malaria:
<interventions name="uninfect population">
<human>
<component id="clearInfections">
<MDA>
<effects>
<option pSelection="1">
<clearInfections timesteps="5" stage="both"/>
</option>
</effects>
</MDA>
</component>
<deployment name="clear human infections">
<component id="clearInfections"/>
<timed>
<deploy coverage="1" time="73"/>
</timed>
</deployment>
</human>
<uninfectVectors name="clear mosquito infections">
<timedDeployment time="73"/>
<timedDeployment time="74"/>
<timedDeployment time="75"/>
<timedDeployment time="76"/>
<timedDeployment time="77"/>
<timedDeployment time="78"/>
</uninfectVectors>
</interventions>From Version 33 onwards, those vector control interventions that are allocated to individual humans are specified within the <human> element of the XML using <component> and <deployment> sub-elements as with chemotherapeutic interventions and vaccines.
The following interventions all work by multiplying vector model parameters affecting individual humans. There are two ways of specifying net or indoor spraying interventions, namely via Generic vector intervention (GVI) or dedicated ITN and IRS models. These interact with the vector transmission model in the same places as GVI but include more detailed models of decay of effects. Suggested values for the parameters of these models for the main African vectors can be found here
The outcome of these interventions will depend on the parameterisation of the mosquito life cycle. Inclusion of the life-cycle vector models is needed to capture cumulative effects over time on vector populations. However, simulations that do include larval dynamics depend on very uncertain calibration and parameterisations.
This model can simulate the effects bed nets, IRS, deterrents, and ivermectin can have on mosquitoes. GVI effects are described like this:
<GVI name="DDT test" id="DDTtest">
<decay L="0.5" function="exponential"/>
<anophelesParams mosquito="gambiae_ss" propActive="1">
<deterrency value="0.56"/>
<preprandialKillingEffect value="0"/>
<postprandialKillingEffect value="0.24"/>
</anophelesParams>
</GVI>where:
-
deterrencydescribes a parameter x such that the availability of a protected host to mosquitoes becomes (1 - x) × preInterventionAvailability -
preprandialKillingEffectdescribes a parameter y such that the probability of a mosquito successfully biting a chosen protected host (instead of dying) becomes (1 - y) × preInterventionProbability -
postprandialKillingEffectdescribes a parameter z such that the probability of a mosquito successfully escaping from a protected human after feeding (instead of dying) becomes (1 - z) × preInterventionProbability
The interventions use the generic decay functions framework to describe decays — see configuration (DecayFunctionValue elements).
All effects decay to zero as described by the decay function described (in the first case, exponential decay with a half-life of 0.5 years).
From schema 30 onwards, the <propActive> option indicates the proportion of bites for which the intervention has any action whatsoever on the mosquito. This is helpful for accounting for preferential biting times and location (indoors vs outdoors) (see also under ITNs). However, recent testing (Schema 37) revealed that intervention effects do not behave as expected. Therefore, it best to set the <propActive > value to "1", and to factor in any reduction in the proportion of mosquito-human contacts potentially affected by the intervention directly into the effect parameterizations.
From schema 43 onwards, the option can only be set to either 0 or 1.
Since Schema 38, it is possible to model effect of GVI on fecundity of mosquitoes. See Effects on fecundity of bloodmeal source and insecticide.
ITNs act via the three factors described above, and can therefore be specified as a generic vector intervention (GVI). Alternatively, there is a dedicated ITN specification available within the <human> element from schema v32 onwards.
From schema 29 onwards, the ITN physical state (measured through a hole index) and chemical state (measured through insecticide concentration) decay with time. The hole index does this through formation of holes, the insecticide concentration through wear and aging. The effects of the net, depending on its state, are calculated using functions describing the relationship between effect and state.
The XML description looks like:
<component id="ITN" name="Extended ITNs">
<ITN>
<usage value="0.8"/>
<holeRate mean="0.9" CV="0.95" distr="lognormal"/>
<ripRate mean="0.7" CV="0.95" distr="lognormal"/>
<ripFactor value="0.4"/>
<initialInsecticide mean="70" SD="20" distr="normal"/>
<insecticideDecay L="2.2y" function="exponential" CV="0.95"/>
<attritionOfNets L="12" function="smooth-compact" k="2"/>
<anophelesParams mosquito="gambiae_ss" propActive="1">
<deterrency holeFactor="0.5" holeScalingFactor="0.1" insecticideFactor="0.67" insecticideScalingFactor="0.1" interactionFactor="1.492537"/>
<preprandialKillingEffect baseFactor="0.09" holeFactor="0.57" holeScalingFactor="0.1" insecticideFactor="0.604" insecticideScalingFactor="1" interactionFactor="-0.424"/>
<postprandialKillingEffect baseFactor="0.10" holeFactor="0" holeScalingFactor="0.1" insecticideFactor="0.55" insecticideScalingFactor="0.1" interactionFactor="0"/>
</anophelesParams>
<anophelesParams mosquito="funestus" ...
</ITN>
</component>Description of parameters:
| Parameter | Unit/type | description |
|---|---|---|
| usage: value | A proportion between 0 and 1 | Usage represents the proportion of time during the night that a net is used by the person. Because in the current model all mosquito species bite homogeneously throughout the night, usage value can also be seen as the πi value, the proportion of encounters out of all encounters with mosquitoes that an unprotected subject has during the time they would be under an ITN if they used one. If this value differs between mosquito species because of different preferential biting times and location (indoors vs outdoors), instead of through the usage value the πi has to be specified through the propActive for each species (available from schema 30 onwards, see below). However, recent testing (Schema 37) revealed that intervention effects do not behave as expected. Therefore, it best to set the <usage > value to "1" (and also set the <propActive > value to "1"), and to factor in any reduction in the proportion of mosquito-human contacts potentially affected by the intervention directly into the effect parameterizations. From scema 42 onwards, the option is obsolete and will be ignored (set to 1).
|
| holeRate: mean | Holes per annum; min: 0; no max | Each new net is assigned a rate of new hole formation. This parameter specifies the mean rate (see also CV and distr parameters). Holes are formed according to a Poisson process with this rate as (only) parameter. |
| holeRate: CV | Type: real; min: 0; no max | If the rate is varied among nets by a log-normally distributed factor (see distr), this parameter specifies the coefficient of variance of samples. |
| holeRate: distr | name | This parameter may be specified as "const", "lognormal", or omitted (equivalent to specifying "const"). If distr="const", the rate parameter is fixed at the given mean parameter, and the CV parameter must be 0 or omitted. If distr="lognormal", the rate parameter is sampled from the log-normal distribution with the specified mean and CV parameters. |
| ripRate: mean | Units: rips per existing hole per annum; min: 0; no max | Each existing hole has a probability of being ripped larger according to a Poisson process. This parameter specifies the mean rate (see also CV and distr parameters). |
| ripRate: CV | Type: real; min: 0; no max | If the rate is varied among nets by a log-normally distributed factor (see distr), this parameter specifies the coefficient of variance of samples. |
| ripRate: distr | name | This parameter may be specified as "const", "lognormal", or omitted (equivalent to specifying "const"). If distr="const", the rate parameter is fixed at the given mean parameter, and the CV parameter must be 0 or omitted. If distr="lognormal", the rate parameter is sampled from the log-normal distribution with the specified mean and CV parameters. |
| ripFactor: value | Type: real; min: 0; no max | This factor expresses how important rips are in increasing the hole. The hole index of a net is the count of holes plus the "ripFactor" multiplied with the cumulative number of rips. |
| initialInsecticide: mean, SD, distr | Units: mg/m²; min: 0 | |
The insecticide concentration of new nets is fixed (distr="const") or Gaussian distributed (distr="normal") according to this mean and SD (standard deviation). Negative sampled values are set to 0. The insecticideScalingFactor under anophelesParams should be adjusted depending on the size of mu. The deltamethrin declared content is 1.8 g/kg corresponding to 68.4 mg/msq for long-lasting (incorporated into filaments) insecticidal nets according to WHO interim specification 333/LN/3 (August 2010)
|
||
| insecticideDecay | Units: years | A decay function describing the decay of insecticide. "exponential" is suggested as a decay function. |
| attritionOfNets | Units: years | A decay function describing how nets are discarded by users. Note also that humans who are "outmigrated" by the demography model and humans who die also remove nets from the population since there is no redistribution or sharing of nets in the model. Currently, this is independent of net state, and the time until disappearance is predefined according to the decay function when a net is first distributed. |
Parameters described per anopheles species/subspecies:
| Parameter | Unit/type | description |
|---|---|---|
| propActive | Proportion between 0 and 1 | This indicates the proportion of bites, when the intervention is in use, for which the intervention has any action whatsoever on the mosquito. This is intended to be helpful for accounting for preferential biting times and location (indoors vs outdoors) and factoring in the πi value for different species (see under 'usage value' above and under deterrency described below). However, recent testing (Schema 37) revealed that intervention effects do not behave as expected. Therefore, it best to set the <propActive > value to "1", and to factor in any reduction in the proportion of mosquito-human contacts potentially affected by the intervention directly into the effect parameterizations. From scema 42 onwards, the option is obsolete and will be ignored (set to 1).
|
<deterrency holeFactor="0.5" holeScalingFactor="0.10" insecticideFactor="0.67" insecticideScalingFactor="0.10" interactionFactor="1.492537"/>RelativeAttractiveness=exp(log(holeFactor)*exp(-HoleIndex*holeScalingFactor)+log(insecticideFactor)*(1-exp(-InsecticideConcentration*insecticideScalingFactor)))+log(interactionFactor)*exp(-HoleIndex*holeScalingFactor)*(1-exp(-InsecticideConcentration*insecticideScalingFactor))))
NOTE: The exponential function prevents the RelativeAttractiveness from becoming negative. The interactionFactor can be calculated from experimental hut data: observed RelativeAttractiveness value for intact treated divided by the product of the observed RelativeAttractiveness values for intact untreated (holeFactor) and holed treated (insecticideFactor). If the holeFactor=1 insecticideFactor=1 and interactionFactor=1, the RelativeAttractiveness=1 and there is 0 effect of the net.
If the experimental hut data had subjects under ITNs during the whole biting period, and if the the πi value is to be factored in for each mosquito species (thus not via the usage value), the factors for deterrency change as follows:
holeFactor=1-πi * (1-RelativeAttractiveness values for intact untreated nets)
insecticideFactor=1-πi * (1-RelativeAttractiveness values for holed treated nets)
interactionFactor=(1-πi * (1-RelativeAttractiveness values for intact treated nets))/holeFactor * insecticideFactor
<preprandialKillingEffect baseFactor="0.09" holeFactor="0.57" holeScalingFactor="0.10" insecticideFactor="0.604" insecticideScalingFactor="0.10" interactionFactor="-0.424"/>Relative pre-prandial survival=(1-(baseFactor+insecticideFactor * (1-exp(-InsecticideConcentration * insecticideScalingFactor)) +holeFactor * exp(-HoleIndex.holeScalingFactor)+interactionFactor * exp(-HoleIndex * holeScalingFactor) * (1-exp(-InsecticideConcentration * insecticideScalingFactor))))/(1-baseFactor)
Note: The factors can be calculated from data as follows:
baseFactor = proportion killed by a badly holed untreated net
holeFactor = proportion killed by an intact untreated net - baseFactor
insecticideFactor = proportion killed by a badly holed treated net - baseFactor
interactionFactor = proportion killed by an intact treated net - baseFactor - holeFactor - insecticideFactor
If the holeFactor=0 insecticideFactor=0 and interactionFactor=0, the relative pre-prandial survival=1 and there is 0 effect of the net.
If the experimental hut data had subjects under ITNs during the whole biting period, and if the the πi value is to be factored in for each mosquito species (thus not via the usage value), the factors for preprandialKillingEffect change as follows:
holeFactor=πi * (proportion killed by intact untreated nets -baseFactor)
insecticideFactor=πi * (proportion killed by badly holed treated nets -baseFactor)
interactionFactor=πi * (proportion killed by intact treated nets)-baseFactor-holeFactor-insecticideFactor)
<postprandialKillingEffect baseFactor="0.10" holeFactor="0" holeScalingFactor="0.10" insecticideFactor="0.55" insecticideScalingFactor="0.10" interactionFactor="0"/>The relative post-prandial survival is calculated similarly to the pre-prandial survival.
</anophelesParams>
</description>
<continuous coverage="0.95" targetAgeYrs="0.0833"/>Note that at a very young age (under 1 year), the current models may force unrealistically high outmigration (see also comment in demographics section). If the amount of nets allocated is relevant (e.g. for costing), this has to be taken into consideration, especially when nets are distributed continuously at a very young age. The minimum targetAgeYrs has to be > timestep/365 in order to correspond to timestep=1, because timestep=0 is not allowed for continuous interventions.
<timed coverage="0.785258112" maxAge="5" minAge="0" time="364"/>
</ITN>The XML description from schema 30 may include a "twoStageDeterrency" parameterization of each of the effects. This may be mixed with the classic parameterization. For example:
<component id="LifeNet_propActive1" name="LifeNet on An. fluviatilis classic">
<usage value="1.0"/>
<holeRate mean="3.25" CV="0.8" distr="lognormal"/>
<ripRate mean="20" CV="0.8" distr="lognormal"/>
<ripFactor value="1"/>
<initialInsecticide mean="8.5" SD="0.2125" distr="normal"/>
<insecticideDecay L="2y" function="exponential" CV="0.95"/>
<attritionOfNets L="18.176" function="smooth-compact" k="18"/>
<anophelesParams mosquito="fluviatilis" propActive="1.0">
<twoStageDeterrency>
<entering insecticideFactor="0.1553273" insecticideScalingFactor="0.2722518"/>
<attacking baseFactor="0.9847168" holeFactor="-0.6102794" holeScalingFactor="0.01165491" insecticideFactor="-0.01033009" insecticideScalingFactor="0.2410076" interactionFactor="0.6358927"/>
</twoStageDeterrency>
<preprandialKillingEffect baseFactor="0.0" holeFactor="0.1058579" holeScalingFactor="0.001743896" insecticideFactor="0.2364187" insecticideScalingFactor="0.3" interactionFactor="0.6577234"/>
<postprandialKillingEffect baseFactor="0.01838159" holeFactor="0" holeScalingFactor="0" insecticideFactor="0.9816149" insecticideScalingFactor="0.4068023" interactionFactor="0"/>
</anophelesParams>
<anophelesParams mosquito="stephensi" propActive="1.0">
...
</anophelesParams>
</ITN>
</component>The proportion entering is multiplied with the proportion 'attacking' to obtain the complement of deterrency.
<entering insecticideFactor="0.1553273" insecticideScalingFactor="0.2722518"/>The relative proportion entering a hut with an ITN =exp(log(insecticideFactor * (1-exp(-InsecticideConcentration * insecticideScalingFactor)))
<attacking baseFactor="0.9847168" holeFactor="-0.6102794" holeScalingFactor="0.01165491" insecticideFactor="-0.01033009" insecticideScalingFactor="0.2410076" interactionFactor="0.6358927"/>The relative proportion of attacking mosquitoes out of mosquitoes that have entered a hut with an ITN =(baseFactor+insecticideFactor * (1-exp(-InsecticideConcentration * insecticideScalingFactor)) +holeFactor * exp(-HoleIndex.holeScalingFactor)+interactionFactor * exp(-HoleIndex * holeScalingFactor) * (1-exp(-InsecticideConcentration * insecticideScalingFactor)))/baseFactor
Since Schema 38, it is possible to model effect of ITNs on fecundity of mosquitoes. See Effects on fecundity of bloodmeal source and insecticide.
The XML description from schema 37 may include a "logit" parameterization of each of the effects. This may be mixed with the classic parameterization, as is done inside the twoStageDeterrency element in the example below:
<component id="LifeNet_logit_propActive1" name="LifeNet on An. fluviatilis logit">
<ITN>
<usage value="1.0"/>
<holeRate mean="3.25" CV="0.8" distr="lognormal"/>
<ripRate mean="20" CV="0.8" distr="lognormal"/>
<ripFactor value="1"/>
<initialInsecticide mean="8.5" SD="0.2125" distr="normal"/>
<insecticideDecay L="2y" function="exponential" CV="0.95"/>
<attritionOfNets L="18.176" function="smooth-compact" k="18"/>
<anophelesParams mosquito="fluviatilis" propActive="1.0">
<holeIndexMax value="145200"/>
<twoStageDeterrency>
<entering insecticideFactor="0.1553273" insecticideScalingFactor="0.2722518"/>
<attackingLogit baseFactor="-0.75405" holeFactor="0.47219" insecticideFactor="1.47636" interactionFactor="-0.17521"/>
</twoStageDeterrency>
<preprandialKillingEffectLogit baseFactor="-3.00830" holeFactor="-0.34248" insecticideFactor="3.44955" interactionFactor="-0.08499"/>
<postprandialKillingEffectLogit baseFactor="-3.800727" holeFactor="-0.011861" insecticideFactor="3.231888" interactionFactor="0.008622"/>
</anophelesParams>
<anophelesParams mosquito="stephensi" propActive="1.0">
...
</anophelesParams>
</ITN>
</component>The logit parameter values can be calculated by fitting a generelized linear model with logit link-function that assumes that the effect probability has logit-linear relationships with the log of the insecticide concentration (augmented with 1 to avoid taking the log of zero), and with the log of the holed surface area (also augmented with 1 to avoid taking the log of zero). The baseFactor is the intercept, the holeFactor is the coefficient of the log of the holed surface area, the insecticideFactor is the coefficient of the log of the insecticide concentration, and interactionFactor is the interaction term between the two.
The holeIndexMax is required to define the maximum holed surface area, typically the surface area of an ITN.
Since Schema 38, it is possible to model effect of ITNs on fecundity of mosquitoes. See Effects on fecundity of bloodmeal source and insecticide.
IRS acts via the same three factors described above, and is also deployed as a human-targeting intervention.
IRS can be modelled via a simple model (see GVI) or a model with indirect decay, similar to the ITN model but without hole factors. This is a description of the latter, previously called IRS version 2.
The description is as follows:
<component id="IRS" name="new param">
<IRS>
<!-- Initial insecticide: units are μg/cm²; no variance here -->
<initialInsecticide mean="118"/>
<insecticideDecay L="0.15" function="exponential"/>
<anophelesParams mosquito="gambiae_ss">
<deterrency insecticideFactor="0.12" insecticideScalingFactor="0.05"/>
<preprandialKillingEffect baseFactor="0.01" insecticideFactor="0.25" insecticideScalingFactor="0.008"/>
<postprandialKillingEffect baseFactor="0.01" insecticideFactor="0.5" insecticideScalingFactor="0.006"/>
</anophelesParams>
</IRS>
</component>Insecticide content decays according to the decay function given. Effects are a function of the remaining insecticide content:
- relative availability = exp( log(insecticideFactor) × [1-exp(-insecticideContent × insecticideScalingFactor)] )
- killing effect = baseFactor + insecticideFactor × [1-exp(-insecticideContent × insecticideScalingFactor)]
- survival factor = (1 - killing effect) / (1 - baseFactor)
Deployment has the same options as with the other human allocated interventions
Since Schema 38, it is possible to model effect of IRS on fecundity of mosquitoes. See Effects on fecundity of bloodmeal source and insecticide
Several different approaches can be used in OpenMalaria for simulation of interventions that make use of non-human hosts or use static trapping method se.g. larviciding, insecticidal baits, zoo-prophylaxis, odour-baited traps, or insecticidal barriers:
- When the objective is to estimate the public health impact of known changes in transmission rate, the
changeEIRspecification can be used with the non-Vector entomological model variant. - An approach that could be used for simulating e.g. zoo-prophylaxis or odour-baited traps is to include in the simulation a sub-population of dummy hosts that have zero susceptibility to infection and to which a generic vector intervention is applied.
- The effects can be simulated as in increase in mosquito mortality at a specific stage in the oviposition cycle. effects that can be modified are: death rate while host seeking , the probability of death while ovipositing, and the rate of emergence. Together these provide a flexible framework for simulating the impact of environmental changes on vector ecology. These interventions are described as
vectorPopinterventions. This element takes one or moreinterventionelements:
<interventions>
...
<vectorPop>
<intervention .../>
<intervention .../>
</vectorPop>
...
</interventions>Each intervention element describes effects per species and deployment times, as follows:
<intervention name="some name">
<description>
<anopheles mosquito="mosq id">
...
</anopheles>
...
</description>
<timed>
<deploy time="0"/>
<deploy time="18"/>
...
</timed>
</intervention>Deployment times are given in time steps; unlike human targeting deployments there are no additional details like coverage levels or age-based restrictions to include.
Effects are described per anopheles species; there must be exactly one anopheles element for each anopheles described in the vector model. The effects may be described at most once per intervention, may be described for some anopheles sub-species but not others, and may be described within more than one intervention. Where not described, the effect is nil.
<anopheles mosquito="arabiensis">
<!-- the following elements are all optional and can appear in any order -->
<seekingDeathRateIncrease initial="0.2">
<decay .../>
</seekingDeathRateIncrease>
<probDeathOvipositing initial="0.6">
<decay .../>
</probDeathOvipositing>
<emergenceReduction initial="0.1">
<decay .../>
</emergenceReduction>
</anopheles>The vector model specifies a rate of mosquito death while host seeking; this intervention gives a temporary increase in that rate. The rate becomes "old rate" × (1 + increase), where increase starts at initial and decays according to the decay function given (thus with any decay function except constant the increase will decay towards 0). Example:
<anopheles mosquito="...">
<seekingDeathRateIncrease initial="0.5">
<decay function="exponential" L="0.1"/>
</seekingDeathRateIncrease>
</anopheles>Initial must be greater than or equal to -1; a (post-decay) value of -1 implies no death while host seeking, 0 implies no effect, 1 implies double the usual death rate, etc.
The vector model describes a base probability of a mosquito surviving ovipositing to return to the host seeking population; this intervention describes an additional killing factor. The probability of surviving ovipositing becomes "old probability" × (1 − factor), where factor starts at initial and decays according to the decay function given (thus with any decay function except constant the factor will decay towards 0). Example:
<anopheles mosquito="...">
<probDeathOvipositing initial="0.6">
<decay function="exponential" L="1"/>
</probDeathOvipositing>
</anopheles>Initial must be between 0 and 1; a (post-decay) value of 0 implies no additional risk of death while a value of 1 implies no mosquitoes survive ovipositing.
Each day, some population of new vectors emerge from water bodies to join the population of flying vectors; this increases the number of flying vectors if it exceeds the number which died since the previous day. There are multiple models to describe the rate at which new vectors emerge. Modifications of the emergence rate with the EmergenceReduction intervention can be used to simulate either short-term (e.g. larviciding) or long-term (e.g. environmental modification) interventions that modify these emergence rates, including weather, climate or other environmental changes that may increase transmission potential.
This intervention acts on top of whichever emergence model is in use by specifying a killing factor; the emergence rate becomes "old rate" × (1 − factor), where factor starts at initial and decays according to the decay function given (thus with any decay function except constant the factor will decay towards 0). Example:
<anopheles mosquito="...">
<emergenceReduction initial="-1">
<decay function="constant"/>
</emergenceReduction>
</anopheles>Initial must be at most 1; a (post-decay) value of 1 implies no emergence, 0 implies no effect, -1 implies double the original emergence rate, etc.
From version 43.0 onward, two additional intervention blocks let you add new non-human hosts to the simulation, or modify existing non-human hosts. It is possible to combine them in order to add new non-human hosts and then modify them later.
This intervention adds new non-human hosts that have not been described in the <entomology> <vector> <anopheles> <nonHumanHosts> section of the input scenario file, and have not been used in the initialization routine. The intervention should be described by 5 parameters that fully describe the non-human host and its effects on each mosquito species:
mosqRelativeAvailabilityHuman The relative availability rate of one of these non-human hosts compared to the average availability of the entire human population with no intervention;
mosqProbBiting The probability of a mosquito surviving biting conditional on encountering this non-human host;
mosqProbFindRestSite The probability of a mosquito successfully finding a resting conditional on biting this non-human host;
restingSurvivalProbability The probability of a mosquito surviving the resting period conditional on finding a resting site; as well as a deployment time and a decay function for each of these parameters.
hostFecundityFactor Multiplicative factor for the number of fertile eggs laid by a mosquito after biting this type of host, relative to an unprotected human.
as well as a deployment time and a lifespan, after which the added non-human hosts will be removed.
<interventions name="No Interventions">
...
<addNonHumanHosts>
<nonHumanHosts name="unprotectedAnimalsNew">
<description>
<anopheles mosquito="gambiae_ss">
<mosqRelativeAvailabilityHuman value="1.0"/>
<mosqProbBiting value="0.95"/>
<mosqProbFindRestSite value="0.95"/>
<mosqProbResting value="0.99"/>
<hostFecundityFactor value="1.0"/>
</anopheles>
<anopheles mosquito="arabiensis">
<mosqRelativeAvailabilityHuman value="1.0"/>
<mosqProbBiting value="0.95"/>
<mosqProbFindRestSite value="0.95"/>
<mosqProbResting value="0.99"/>
<hostFecundityFactor value="1.0"/>
</anopheles>
<anopheles mosquito="funestus">
<mosqRelativeAvailabilityHuman value="1.0"/>
<mosqProbBiting value="0.95"/>
<mosqProbFindRestSite value="0.95"/>
<mosqProbResting value="0.99"/>
<hostFecundityFactor value="1.0"/>
</anopheles>
</description>
<timed>
<deploy time="189" lifespan="3y"/>
</timed>
</nonHumanHosts>
</addNonHumanHosts>
...
</interventions>This intervention modifies parameters of non-human hosts described in the <entomology> <vector> <anopheles> <nonHumanHosts> section of the input scenario file. The intervention is described by 5 parameters that define the change in each of non-human host parameters, for each mosquito species:
availabilityReduction Reduction in the availability rate, αi. For example a value of 0 will result in no change; a value of 0.2 will reduce the availability to 0.8 of its initial value; and a value of 1 will set the availability to 0;
prePrandialKillingEffect Reduction in the pre-prandial survival probability, PBi. For example a value of 0 will result in no change; a value of 0.2 will reduce PBi to 0.8 of its initial value; and a value of 1 will set PBi to 0;
postPrandialKillingEffect Reduction in the post-prandial survival probability, PCi. For example a value of 0 will result in no change; a value of 0.2 will reduce PCi to 0.8 of its initial value; and a value of 1 will set PCi to 0;
restingKillingEffect Reduction in the survival probability of the resting period, PDi. For example a value of 0 will result in no change; a value of 0.2 will reduce PDi to 0.8 of its initial value; and a value of 1 will set PDi to 0;
fecundityReduction Reduction in the number of fertile eggs laid by a mosquito after biting this type of host, relative to an unprotected human. For example a value of 0 will result in no change; a value of 0.2 will reduce the fecundity factor to 0.8 of its initial value; and a value of 1 will set the fecundity factor to 0;
as well as a deployment time and a decay function for each of these parameters.
Although killing mosquitoes in any of the three stages (before feeding; after feeding; or resting) does not affect transmission, we separate the killing effects to be able to relate mosquito numbers to field data.At the deployment time, the parameters of the non-human hosts will be altered as described in the intervention. This is applicable to interventions such as spraying livestock with insecticide and increasing or reducing the number of livestock.
<interventions name="No Interventions">
...
<nonHumanHostsModifications>
<intervention name="availabilityReduction" nonHumanHostsName="unprotectedAnimals">
<decay function="step" L="3.0"/>
<description >
<anopheles mosquito="gambiae_ss">
<availabilityReduction initial="1.0"/>
<preprandialKillingEffect initial="1.0"/>
<postprandialKillingEffect initial="1.0"/>
<restingKillingEffect initial="1.0"/>
<fecundityReduction initial="1.0"/>
</anopheles>
<anopheles mosquito="arabiensis">
<availabilityReduction initial="1.0"/>
<preprandialKillingEffect initial="1.0"/>
<postprandialKillingEffect initial="1.0"/>
<restingKillingEffect initial="1.0"/>
<fecundityReduction initial="1.0"/>
</anopheles>
<anopheles mosquito="funestus">
<availabilityReduction initial="1.0"/>
<preprandialKillingEffect initial="1.0"/>
<postprandialKillingEffect initial="1.0"/>
<restingKillingEffect initial="1.0"/>
<fecundityReduction initial="1.0"/>
</anopheles>
</description>
<timed>
<deploy time="116"/>
</timed>
</intervention>
</nonHumanHostsModifications>
...
</interventions>| Download openmalaria | Installation instructions | XML Schema Documentation |
| XML Schema Version | Program version | master |
develop |
|---|---|---|---|
| 43 | schema-43.0 |
 |
 |