ModelInterventions

Preventive Interventions

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 (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.

<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).

Human allocated interventions

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>

Parameterisation of components

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 programmes

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:

component elements list the components which are deployed when a deployment happens; the id references a component described above
continuous elements control the selection of humans for deployment by potentially recruiting humans who reach a certain exact age
timed elements control the selection of humans for deployment by potentially recruiting humans at a certain time during the simulation
component elements must come before continuous elements which must come before timed elements

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

Target coverage level

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>

Order of deployments

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.

Vaccines

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

Efficacy

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).

Doses and schedules

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.

Description in XML (from version 32)

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>

Mass drug Administration

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

<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>

treatPKPD

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>

Configurable Treatment

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 latentp is 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 timesteps attribute 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>

Test-and-Treat

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:

screen

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>

decisionTree

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>

Uninfect vectors

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>

Mosquito-stage interventions allocated to individual humans

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.

Generic vector intervention (GVI)

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:

deterrency describes a parameter x such that the availability of a protected host to mosquitoes becomes (1 - x) × preInterventionAvailability
preprandialKillingEffect describes a parameter y such that the probability of a mosquito successfully biting a chosen protected host (instead of dying) becomes (1 - y) × preInterventionProbability
postprandialKillingEffect describes 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 scema 42 onwards, the option is obsolete and will be ignored (set to 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.

Insecticide treated nets (ITNs)

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.

Indoor residual spraying (IRS)

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

Host-independent vector interventions

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 changeEIR specification 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 vectorPop interventions. This element takes one or more intervention elements:

<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>

Death rate increase (or decrease) while host seeking

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.

Probability of death while ovipositing

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.

Emergence reduction or increase

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.

Non-Human Hosts interventions

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.

<interventions name="No Interventions">
   ...
        <addNonHumanHosts>
          <nonHumanHosts name="unprotectedAnimals2">
            <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>

Modifying existing non-human hosts

<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>
          <intervention name="fecundityReduction" nonHumanHostsName="unprotectedAnimals">
            <decay function="step" L="1.0"/>
            <description >
              <anopheles mosquito="gambiae_ss">
                <availabilityReduction initial="0.0"/>
                <preprandialKillingEffect initial="0.0"/>
                <postprandialKillingEffect initial="0.0"/>
                <restingKillingEffect initial="0.0"/>
                <fecundityReduction initial="1.0"/>
              </anopheles>
              <anopheles mosquito="arabiensis">
                <availabilityReduction initial="0.0"/>
                <preprandialKillingEffect initial="0.0"/>
                <postprandialKillingEffect initial="0.0"/>
                <restingKillingEffect initial="0.0"/>
                <fecundityReduction initial="1.0"/>
              </anopheles>
              <anopheles mosquito="funestus">
                <availabilityReduction initial="0.0"/>
                <preprandialKillingEffect initial="0.0"/>
                <postprandialKillingEffect initial="0.0"/>
                <restingKillingEffect initial="0.0"/>
                <fecundityReduction initial="1.0"/>
              </anopheles>
            </description>
            <timed>
              <deploy time="554"/>
            </timed>
          </intervention>
        </nonHumanHostsModifications>
    ...
</interventions>

| Download openmalaria | Installation instructions | XML Schema Documentation |

Status

XML Schema Version	Program version	`master`	`develop`
43	schema-43.0

ModelInterventions

Preventive Interventions

Human allocated interventions

Parameterisation of components

Deployment programmes

Target coverage level

Order of deployments

Vaccines

Efficacy

Doses and schedules

Description in XML (from version 32)

Mass drug Administration

treatSimple

treatPKPD

Configurable Treatment

Test-and-Treat

screen

decisionTree

Uninfect vectors

Mosquito-stage interventions allocated to individual humans

Generic vector intervention (GVI)

Insecticide treated nets (ITNs)

Indoor residual spraying (IRS)

Host-independent vector interventions

Death rate increase (or decrease) while host seeking

Probability of death while ovipositing

Emergence reduction or increase

Non-Human Hosts interventions

Modifying existing non-human hosts

Status

Home

Model structure and specification

Simulating Interventions

Monitoring

Tools

Technical Details

How to apply OpenMalaria to field sites

Publications on OpenMalaria

Terminology / Glossary / Index

Clone this wiki locally