ScenarioHealthSystem
OpenMalaria simulates the occurrence of disease via pathogenesis models that take into account parasite densities and the age of the host (and hence indirectly immunity induced by previous exposure) to decide at each time step whether the host has uncomplicated malaria, severe malaria, or non-malaria fever. Each simulation also requires specification of case management parameters that hold during the warm-up phase of the simulation and during the main simulation unless/until they are replaced by a change in case management. These determine the coverage of case management, the simulated drugs used and their pharmacokinetic/pharmacodynamic characteristics. The parameters of the case management model are configured by the <healthSystem> element (and may be reconfigured by <changeHS> intervention elements). The case management system has no direct effect on the incidence of malaria disease, but affects this indirectly (by eliminating or reducing parasitaemia).
Model specifications are required for:
- The Health System Memory.
- The diagnostics used.
- The effect of treatment.
- Case fatality rates and sequelae rates
- A decision tree on either a five-day (the usual/default) or one-day timestep.
Depending on the options used, clinical and parasitological outcomes may depend on the models for drug action, pathogenesis, and within-host dynamics.
From the Glossary:
- event -- an occurrence without measurable duration. This can be a bout in the five-day time step model since the whole bout occurs on a single time step, but in the one-day time step model an event is strictly a state-change.
- bout -- a "bout of sickness" describes a fever, malarial or otherwise, or period of severe illness, usually lasting no more than five days.
- episode -- the health-system's reporting unit; each bout is either considered the start of a new episode, or, if occurring within the health system memory (usually set to 30 days, see below) of the start of the last episode, considered part of that episode. Thus, at least in low transmission settings, an episode should roughly correspond to one malaria infection (which can cause multiple bouts). An episode's severity (non-malarial, malarial or severe) is considered to be that of its worst bout.
The "healthSystemMemory" parameter specifies the duration of the period for which a recurrent bout of illness counts as the same episode (see above). This is part of the <model> element of the XML.
The same (or different) diagnostics can be specified for use in case management, monitoring of survey outputs and test-and-treat interventions. A description of diagnostic tests (in the <diagnostics> element of the XML) can be found here.
From schema 32, the action of treatments can be configured (see below under PK/PD for use of drug properties). Prior to this, treatment action (on effective treatment) is to clear all infections (including liver stage) retrospectively. This is the same as in the specification of test and treat interventions except without multiple options.
From schema 32:
<treatmentActions>
<!-- for each drug used (e.g. ACT, CQ, QN): -->
<QN name="short description">
<clearInfections stage="..." timesteps="..."/>
</QN>
</treatmentActions>Different drug descriptions can be used for first-line, second-line and inpatient. Each description may have a descriptive name, as well as any number of clearInfections elements (zero elements implies the treatment does nothing, but since treatment rates can be set to zero and this is intended as a descriptor of effective treatment, doing this is discouraged; two elements may be useful to describe liver- and blood-stage effects separately).
The clearInfections element has two parameters: stage (must be one of blood, liver or both) and timesteps (-1, 1 or a greater value). Infections are considered liver-stage on their first timestep (assumes 5-day timestep) and blood-stage thereafter. -1 implies retroactive treatment: clear infections after having updated densities and simulated sickness events based on these densities, but before reporting patent hosts, sum-log-parasite density, etc; this action is a legacy of the model's history. 1 clears infections on the next update, before calculating the new densities, but after reporting patent hosts etc. for the previous timestep, and is recommended for short-action drugs. Larger values allow model of prophylactic step longer than the timestep and specify the number of future updates at which infections should be cleared: e.g. 2 clears for one extra timestep (thus ten days, for a 5-day timestep model, in which infections are cleared).
This model was added in schema v33 to allow pharmacokinetics and pharmacodynamics to be simulated on either 5-day or a 1-day base timestep. This allows simulation of effects of immunity on drug action and selection of resistant parasites. It entails tracking of drug levels and consequences of treatment on parasite densities and hence clinical outcomes and transmission. Limitations are:
- This functions only with the Molineaux within-host model.
- Only treatment of uncomplicated malaria is included in the PK/PD modeling. Hospital treatment and outcomes of severe disease are handled as in earlier versions.
The model is a generalisation of the older ImmediateOutcomes model, thus all scenarios can, if desired, be changed to use the DecisionTree5Day model instead.
The model allows decision trees to be written for treatment in health centres as well as home-based treatment:
<treeUCOfficial>
<treatSimple durationLiver="0" durationBlood="1t"/>
</treeUCOfficial>
<treeUCSelfTreat>
<noTreatment/>
</treeUCSelfTreat>Documentation of available branching nodes in these trees can be found in the generated schema documentation under → scenario → healthSystem → DecisionTree5Day → treeUCOfficial (link for version 34.
The case fatality rate for severe disease and the probability of sequelae developing for severe malaria in inpatients must be input. (Projections for outpatients are made by specifying the relative risks for untreated severe disease.) A template health-system element, including standard data is:
<healthSystem>
...
<CFR>
<group lowerbound="0" value="0.09189"/>
<group lowerbound="0.25" value="0.0810811"/>
<group lowerbound="0.75" value="0.0648649"/>
<group lowerbound="1.5" value="0.0689189"/>
<group lowerbound="2.5" value="0.0675676"/>
<group lowerbound="3.5" value="0.0297297"/>
<group lowerbound="4.5" value="0.0459459"/>
<group lowerbound="7.5" value="0.0945946"/>
<group lowerbound="12.5" value="0.1243243"/>
<group lowerbound="15" value="0.1378378"/>
</CFR>
<pSequelaeInpatient interpolation="none">
<group lowerbound="0.0" value="0.0132"/>
<group lowerbound="5.0" value="0.005"/>
</pSequelaeInpatient>
</healthSystem>The ... should be replaced with either an <ImmediateOutcomes> or an <EventScheduler> element. (This is for schema version 24 onwards. For compatibility with older versions, remove the interpolation="none" attribute.)
The data here describes the case-fatality rates of hospitalised cases receiving successful treatment per age-group (or more precisely, a CFR-per-age function is constructed using step-wise linear interpolation of the (lowerbound, cfr) pairs).
Since collecting fatality-rate data for cases outside of hospital, the "community death rate" (used for cases not receiving hospital care, or, in the <ImmediateOutcomes> model, ineffective treatment) is constructed from the hospital CFR data by multiplying the odds by a parameter (exp of the LOG_ODDS_RATIO_CF_COMMUNITY parameter).
In practice, we always use the same data-set here. Some graphs, showing non-interpolated data in green and a linear interpolation in blue:
Tediosi et al, 2006 (implemented by the ClinicalImmediateOutcomes class) presented a clinical model for the case management of malaria. In this model there are three entry points to the decision trees: uncomplicated clinical malaria with no recent history of treatment, uncomplicated clinical malaria with recent history of treatment, and severe malaria. “Recent history” is defined as within the last 30 days. Parameterisation of this model is described below.
When the simulation uses a granularity of 5-day timesteps, fevers can be considered to occur entirely within a single timestep, and thus it is reasonable to decide parasitological, clinical and cost outcomes within a single timestep — hence this model was named the immediate outcome clinical model. Bouts of sickness are assumed to have concluded within this time period (either the individual recovers or dies). Following recovery, the individual can experience another bout at the next time step, but bouts of illness occurring within the health system memory of a previous bout are considered to be a recurrence of the same episode. The severity assigned to the episode (for reporting purposes) is that of the most severe bout within the health system memory (default 30-day) period.
Predictions are made across a range of different transmission intensities, by varying the entomological inoculation rate, and across case management scenarios with different coverage rates, by varying the decision tree probabilities.
There are two models of case management here:
- The original model,
ImmediateOutcomes, assumes a fixed model of case-management and treatment, with additions made over time to support new use-cases. - The
DecisionTree5Daymodel uses programmable decision trees, thus allowing simulation of new treatment strategies without adapting the OpenMalaria simulator.
For both models, severe malaria cases can either be treated as an inpatient, or not be treated at all, each with a corresponding age-specific case fatality rate. Parasites are cleared in all hospitalized cases who survive. The epidemiologic effect depends stochastically on the values of the joint probabilities of the clinical and parasitologic outcomes, conditional on the clinical event.
An initial bout of uncomplicated clinical malaria may either be treated at home or in peripheral health facilities, or go untreated, with the probability of a parasitological cure dependent on drug efficacy and patient compliance. In this model, treatment either completely clears parasites or has no effect. An uncomplicated malaria case that was treated during the health system memory is assumed to either seek care or not. If care is sought, it is assumed to take place in the formal health system, with treatment being based on the second-line drug.
An initial bout of uncomplicated clinical malaria may either be treated at home or in peripheral health facilities, or go untreated. For each of the cases that a bout is treated at home or that it is treated in a health facility, a decision tree can be specified to describe treatment. These decision trees describe a tree of possible end-points and may choose branches based on a variety of options: chance, the result of a diagnostic test, whether the case is a relapse, and the age of the patient. End-points may describe any of the following outcomes: treatment via a simple immediate-outcomes model, treatment via PK/PD simulation (one-day time-step within-host models only), treatment failure, no treatment, and optionally deployment of any human-specific intervention supported by OpenMalaria to this individual (e.g. a bed net or a vaccine).
Where case management is not the primary interest of the simulation, a simple parameterisation can be used, in which only the effective coverage of treatment:
- for uncomplicated disease by setting
pSeekOfficialCareUncomplicated1, andpSeekOfficialCareUncomplicated2to the coverage for uncomplicated disease (see below); - for severe disease by setting
pSeekOfficialCareSevere, need to be specified. The other parameters of the case management model can be assigned default values.
Values for the effective coverage are often obtained from survey data using 14 day recalls. These are used via a mapping of these values onto corresponding 5-day time steps
More generally, key parameters that should be considered are:
- The
healthSystemMemoryparameter is the maximum age (units: time-steps) at which a previous bout of fever/sickness is considered part of the current episode: 0 means the memory covers a single timestep (the reporting one), 1 means the memory extends back to events from the previous timestep (i.e. memory is 2×length-of-timestep), and negative values mean truely no memory. (This controls whether second-line treatment is used and whether a new episode is reported.) - Coverage of case management for uncomplicated disease which should be adjusted to allow for the time step used in the decision tree (most often data are available on access to care, using 14 day recall data from Demographic and Health Surveys). Details of this mapping are available from Penny et al (2015) Suppl info Table S5. Factors converting data on access to care to effective coverage, for 43 African countries are available from Galactionova et al, (2015)
More complicated 5-day timestep case management decision trees and parameterisations can be used for simulating variations in access, adherence, compliance etc.
An example XML element using the DecisionTree5Day model:
<DecisionTree5Day name="example name">
<pSeekOfficialCareUncomplicated1 value="0.04"/>
<pSelfTreatUncomplicated value="0.0"/>
<pSeekOfficialCareUncomplicated2 value="0.04"/>
<pSeekOfficialCareSevere value="0.48"/>
<treeUCOfficial>
<treatSimple durationLiver="0" durationBlood="1t"/>
</treeUCOfficial>
<treeUCSelfTreat>
<noTreatment/>
</treeUCSelfTreat>
<cureRateSevere value="1.0"/>
<treatmentSevere>
<clearInfections stage="blood" timesteps="1t"/>
</treatmentSevere>
</DecisionTree5Day>Documentation of the decision trees (treeUCOfficial, treeUCSelfTreat) is above.
An equivalent example XML element using the ImmediateOutcomes model:
<ImmediateOutcomes name="example name">
<drugRegimen firstLine="ACT" inpatient="QN" secondLine="ACT"/>
<initialACR>
<ACT value="1.0"/>
<QN value="1.0"/>
<selfTreatment value="0.0"/>
</initialACR>
<compliance>
<ACT value="1.00"/>
<selfTreatment value="1.0"/>
</compliance>
<nonCompliersEffective>
<ACT value="0"/>
<selfTreatment value="0"/>
</nonCompliersEffective>
<treatmentActions> <!-- only from schema 32 -->
<ACT name="clear blood-stage infections">
<clearInfections stage="blood" timesteps="1"/>
</ACT>
<QN name="clear blood-stage infections">
<clearInfections stage="blood" timesteps="1"/>
</QN>
</treatmentActions>
<pSeekOfficialCareUncomplicated1 value="0.04"/>
<pSelfTreatUncomplicated value="0.0"/>
<pSeekOfficialCareUncomplicated2 value="0.04"/>
<pSeekOfficialCareSevere value="0.48"/>
</ImmediateOutcomes>First, the drugs used for firstLine, secondLine and inpatient treatment are defined in the drugRegimen element. Drug codes may be one of CQ, SP, AQ, SPAQ, ACT, QN, or selfTreatment.
Then, compliance (adherence rate), initialACR (initial cure-rate for compliers) and nonCompliersEffective (effective cure-rate for non-compliers) are specified per drug (must be described for self-treatment but optional for other drugs; values default to 0). Setting 'compliance' does not affect 'inpatient' treatment.
Additionally, the following (fairly self-explanetory) elements must be described: pSeekOfficialCareUncomplicated1, pSelfTreatUncomplicated, pSeekOfficialCareUncomplicated2, pSeekOfficialCareSevere, and pSequelaeInpatient.
The 1-day timestep case managment decision tree (Crowell et al.) requires testing. It is an adaptation of the Tediosi et al model to a one-day time step. The decision trees in the Tediosi et al model were revised to describe more realistically the patient and provider decisions affecting case management coverage and to be more generally applicable for case management in areas of any level of P.falciparum risk. The shorter time step allows simulation of complex patterns of treatment seeking, and when linked with models of pharmacokinetics and pharmacodynamics, of parasite response to treatment and thus partial drug failure due to parasite resistance or inadequate dosing.
We break the model down into two components: clinical scheduler and clinical decisions.
Moving to a one-day time step implied the need for a clinical scheduler to mediate between the Pathogenesis, clinical decisions and severe outcomes models. The clinical scheduler decides and tracks the clinical state of the individual, based on the state as determined by the pathogenesis model and recent treatment history, allocates individuals to the clinical decisions and severe outcomes models as necessary, and determines final clinical outcomes.
The clinical decisions component of the model (implemented in the ESCaseManagement class) consists of stochastic decision trees concerned with determining the treatments given (including the actual schedule followed and dose sizes taken), along with whether the patient was hospitalized and whether treatment or hospitalization delays occurred. The decision trees also provide information necessary for calculating costs, derived from treatment-seeking behaviour, drugs administered, and diagnostic tests used.
In this model, each individual is assigned a clinical state which lasts until the next event. There is the possibility to enable the NON_MALARIA_FEVERS option. If this is not enabled, possible states are healthy, uncomplicated malarial fever, severe malaria, and dead. The corresponding events are start of an uncomplicated malarial fever from a healthy state, start of severe malaria (from healthy or uncomplicated malaria states), direct death (from a severe malaria state) and recovery (from uncomplicated malaria or severe malaria states). When the NON_MALARIA_FEVERS option is enabled, an additional state of uncomplicated non-malarial fever exists. Then, the corresponding events are start of an uncomplicated fever (malarial or non-malarial) from a healthy state, start of severe malaria (from healthy or uncomplicated fever states), direct death from a severe malaria state, death from a non-malarial illness, and recovery (from uncomplicated fever or severe malaria states). Transitions from severe malaria to uncomplicated fever, or from uncomplicated malaria to direct death, are not allowed.
A bout commences with a morbidity event and concludes with a recovery or mortality event (stressing terminology used). When the bout first occurs, the clinical scheduler calls the clinical decisions model. At the start of an uncomplicated fever, we model a potential treatment-seeking delay. In this model, the bout duration of uncomplicated malarial fevers and non-malarial fevers is fixed at three days from the time of seeking treatment, or from the start of illness (if treatment is not sought). If an individual delays seeking treatment for one or two days, bout duration becomes four or five days, respectively. During this time, the clinical scheduler maintains the individual in the same state, unless the Pathogenesis models indicate that the illness has progressed to severe or the individual has died from a non-malarial illness. After this time period, it is assumed that parasite densities have been reduced by treatment or immunity, or that the individual has recovered from the non-malarial illness, and the individual is returned to the healthy state.
While healthy or during an uncomplicated bout, a severe bout may commence. In this case, the clinical scheduler calls the clinical decisions model and cancels any recent drug treatment. The severe bout is fixed at six days long when the patient enters hospital immediately or not at all; a one-day delay to hospital entry is also considered possible which increases the bout length to seven days.
Mortality is possible during severe malaria bouts, and considered as a stochastic function of the proportional reduction in parasite density each day of the case (TODO: link article). Each day during the severe illness, the clinical scheduler calls the severe outcomes model, which applies the appropriate case fatality rate to determine whether or not the individual died that day. For delayed hospital entry, the community death rate takes effect on the first day. Mortality events are always modeled as happening at the end of the associated severe episode.
Case management in bouts of uncomplicated and severe sickness is determined using separate decision trees, with the following three entry points: uncomplicated fever with no recent history of treatment, uncomplicated fever with recent history of treatment, and severe malaria. In both cases, arbitrary decisions based on age, the outcome of a parasitological test, and decisions based on previous decisions and random sampling are allowed.
At the start of an uncomplicated fever, we model a potential treatment-seeking delay. The simulated individual has a fixed chance of seeking treatment immediately, or, if yet to do so, on the following two days. If treatment is not sought on all three occasions, the individual reverts to the healthy state. When the individual does seek treatment, the uncomplicated case management tree determines any treatments taken, and the individual is deemed to recover three days from the time of treatment-seeking.
The decision tree provides a more detailed description of treatment-seeking than the previous model, including from the informal sector. It accounts for sub-optimal provider compliance to treatment guidelines and varying quality of drugs and describes patient adherence more precisely by modeling vomiting, stopping treatment early, and selective adherence.
The uncomplicated case management decision tree allows for simulation of parasitological testing. Uncomplicated fevers may or may not be caused by malaria and, if they are non-malarial, may or may not be accompanied by parasitaemia. However, initially they appear identical to patients and health care providers and are thus included in the same entry point. Non-malarial fevers are generated by an age-dependent function in the pathogenesis model; parasitological testing helps health care providers to distinguish between non-malarial and malarial fevers and target antimalarial drugs more effectively.
If a bout of uncomplicated fever (whether malarial or not) occurs in an individual who has been treated with antimalarials within the last 14 days, it is considered a result of treatment failure which should be treated with the second-line drug. The decision tree is identical but the values of treatment-seeking, quality of care and compliance parameters are modified accordingly.
In the case of severe malaria, the path through the case management decision tree is determined at the start of the episode. The tree may determine that a one-day travel-time delay occurs, in which case in-hospital decisions are not determined until the next day.
Individuals can initially either seek treatment from a lower-level source, in hospital, or not at all. There is a possibility of pre-referral treatment with referral to hospital on the same or next day; pre-referral treatment reduces parasite densities on the first day of illness. Diagnostic testing is considered for costing purposes but is assumed not to affect treatment received. Treatment schedule is found and applied in the same way as with an uncomplicated case. Entry to hospital temporarily removes the individual from the transmission cycle.
In both severe and uncomplicated cases, the relevant case management decision tree determines treatments given. For each drug and age group, the standard regimen is specified– dose size (in milligrams), and times given (in hours), and then modified, based on the decision tree outputs, by reduced drug quality, adherence and delays to taking treatment.
The treatment schedule is applied to the individual as a list of pending medications that are given over the next time points. Any previously pending medications are cancelled when new treatments are prescribed, and drugs are only costed when taken, so that if an individual progresses to severe after receiving treatments for an uncomplicated case, remained unconsumed medications are not costed.
We assume that each individual has a probability of antibiotic administration, Pr(AB), according to whether s(he) has a NMF or a malarial fever and according to treatment-seeking location:
-
No treatment-seeking: Pr(AB) = 0
-
Health facility: Pr(AB) is a function of the average probability of being prescribed an antibiotic in the absence of a malaria test, P0; whether the individual had a negative or a positive malaria diagnostic test result, and whether the individual needs or does not need an antibiotic (this latter captures signs and symptoms that would indicate to a health worker need for antibiotics, in the absence of knowledge of malaria parasitological status). Thus:
β0= logit (P0) - β3 x Pr(NMF needs antibiotics)
and
Logit(Pr(AB)= β0 + β1 x I (MD-) + β2 x I(MD+) + β3 (need)
where β1 and β2 are the effect of a negative and positive test, respectively, on the log odds of receiving an antibiotic and β3 is the effect of needing an antibiotic on the log odds of receiving it. I(X) is 1 when event X is true and 0 otherwise, event "need" is the event that death may occur without treatment, events "MD-" and "MD+" are the events that a malaria parasite diagnostic was used and indicated no parasites and parasites respectively.
- In the informal sector:
Logit(Pr(AB)= β0 + β4
where exp(β4) is the effect of seeking treatment in the informal sector on the odds of getting antibiotics. In general, we do not know how the chance of getting an antibiotic depends on health facility attendance. Therefore, for the purposes of this model, we set β4 to 0, assuming that the overall probability of getting an antibiotic is not affected by seeking in the informal sector but targeting of antibiotics to those in need is improved in health facilities both by malaria diagnosis and additional diagnostic procedures (e.g. measuring respiratory rates, examining for symptoms of viral infection, etc).
- Community health workers:
If they are trained to administer only presumptive treatment for malaria, then we assume Pr(AB)= 0. If they are trained in malaria diagnostic testing and management of non-malarial fevers, then Pr(AB) is assumed to be as in the formal sector.
β0= logit (P0) - β3 x Pr(malarial fever needs antibiotics)
and
Logit(Pr(AB)= β0 + β1 x I (MD-) + β2 x I(MD+) + β3 (need)
The CFR of fevers that do not need antibiotics is assumed to be 0.
CFR(a)¦ need= γ0(a) (1-εAB x I(AB))
Where γ0(a) is the CFR(a) in absence of antibiotic, given need, and εAB is the efficacy of the antibiotic on CFR. I(AB) takes the value 1 if the individual receives an antibiotic and 0 if s(he) does not.
The following costs are considered:
- drugs medicated, including vomited doses but not doses skipped due to poor adherence
- parasite (RDT and microscopy) diagnostics used
- outpatient visits
- patient hospital days, using fixed average lengths for stays resulting in recovery and stays ending with mortality
- patient direct costs, including travel, medical and non-medical supplies
A rough diagram of the model processes is below (states and state choices in blue). The diagram ignores the time component (most notably: change in parasite density over a severe bout is what input the parasite density has on chance of death).
The event-scheduler model encapsulates a case-management model and schedules sickness events (fever start/end, recovery/death outcomes). An example XML element:
<EventScheduler>
<!-- Simple partially-realistic (poorly researched) health system description (DH). -->
<uncomplicated>
<decisions>
<decision depends="case,p" name="test" values="none,microscopy,RDT">
case(UC1){
p(.5): none
p(.3): microscopy
p(.2): RDT
}
case(UC2){
p(.4): none
p(.3): microscopy
p(.3): RDT
}
</decision>
<decision depends="result,p" name="treatment" values="MQ_treat,no_treat">
result(positive){
p(.9): MQ_treat
p(.1): no_treat
}
result(negative): no_treat
result(none) {
p(.5): MQ_treat
p(.5): no_treat
}
</decision>
<decision depends="age" name="bodyMass" values="5,20,60">
age(0-2): 5
age(2-6): 20
age(6-inf): 60
</decision>
</decisions>
<treatments>
<treatment name="MQ_treat">
<schedule>
<medicate drug="MQ" hour="0" mg="20"/>
</schedule>
<modifier decision="bodyMass">
<multiplyQty effect="MQ(5)" value="5"/>
<multiplyQty effect="MQ(20)" value="20"/>
<multiplyQty effect="MQ(60)" value="60"/>
</modifier>
</treatment>
<treatment name="no_treat">
<schedule/>
</treatment>
</treatments>
</uncomplicated>
<complicated>
<decisions>
<decision depends="result,p" name="treatment" values="AS_sev,none">
result(positive) {
p(.9): AS_sev
p(.1): none
}
result(negative): none
result(none): none
</decision>
<decision depends="" name="hospitalisation" values="none,delayed,immediate">
immediate
</decision>
<decision depends="p" name="test" values="none,microscopy,RDT">
p(.3): none
p(.5): RDT
p(.2): microscopy
</decision>
<decision depends="age" name="bodyMass" values="5,20,60">
age(0-2): 5
age(2-6): 20
age(6-inf): 60
</decision>
</decisions>
<treatments>
<treatment name="AS_sev">
<schedule>
<medicate drug="AS" hour="0" mg="2.4"/>
<medicate drug="AS" hour="18" mg="2.4"/>
<medicate drug="AS" hour="36" mg="2.4"/>
<medicate drug="AS" hour="54" mg="2.4"/>
</schedule>
<modifier decision="bodyMass">
<multiplyQty effect="AS(5)" value="5"/>
<multiplyQty effect="AS(20)" value="20"/>
<multiplyQty effect="AS(60)" value="60"/>
</modifier>
</treatment>
<treatment name="none">
<schedule/>
</treatment>
</treatments>
</complicated>
<ClinicalOutcomes>
<maxUCSeekingMemory>3</maxUCSeekingMemory>
<uncomplicatedCaseDuration>3</uncomplicatedCaseDuration>
<complicatedCaseDuration>6</complicatedCaseDuration>
<complicatedRiskDuration>6</complicatedRiskDuration>
<pImmediateUC>.8</pImmediateUC>
</ClinicalOutcomes>
</EventScheduler>The case-management part consists of decision trees and treatment schedules, split into two cases: uncomplicated for non-malarial and malarial fevers not requiring hospitalisation, and complicated for severe malarial fevers or those worsened through a further insult. Apart from a few decision rules, the uncomplicated and complicated elements have the same format: a decisions element and a treatments element.
As an example of how these decision trees work, lets consider a patient with uncomplicated clinical malaria. The first decision we come to depends on "case" (first-line or second-line) and "p" (indicates a random decision). Assuming the patient has not had another malaria case in recent history, he will recieve first-line ("UC1") treatment, and thus has only a 50% chance of having a parasite test — lets assume has gets tested via microscopy. Like "case", the "result" decision is built-in and indicates the outcome of a malaria parasite diagnostic, based on the outcome of the "test" decision. Lets assume our guy's test came back positive; thus, according to the "treatment" decision he has a 90% chance of getting treated with MQ (mefloquine). Unlike these, "bodyMass" decision is deterministic — in fact "age" decisions may not depend on "p" or any other parameter (if necessary a second decision may do so). Having determined all decisions, we get to the treatments section. If our patient recieved "MQ_treat", he will immediately recieve a single oral dose including 20 times 5, 20 or 60 miligrams of MQ.
The decisions element describes a model of treatment-seeking and health-system decisions, using a list of decision sub-elements.
A decision is described by:
- a name (an identifier of alpha-numeric characters plus
.and_) - a list of possible outcomes (decision outcomes are often referred to using the format
NAME(OUTCOME)) - a list of other decisions this decision depends upon in order to be determined
- some description of how an outcome is derived
A few built-in decisions exist, and a few particular decisions must be provided, but otherwise the number of decisions used and potential names are not fixed. The built-in and required decisions are:
| name | outcomes | description | |
|---|---|---|---|
case |
UC1, UC2
|
built-in, uncomplicated only |
Case is second-line (UC2) if, within the [[health-system memory |
result |
none, negative, positive
|
built-in | If the test decision has an outcome other than none, a parasite-density test is performed using the current density of the simulated case; otherwise the outcome is none. The number of RDT tests used is reported for costing purposes. |
test |
none, microscopy, RDT
|
required | Determines whether and which type of malarial diagnostic is used |
treatment |
required | Selects which treatment to medicate. Outcomes are not restricted, but must match exactly the treatments available (so probably a treatment called "none" will need to be added). | |
hospitalisation |
none,immediate,delayed
|
required for complicated
|
Determines whether the individual goes to hospital or not, and whether a 1-day delay to hospital entry occurs. Hospitalisation affects fatality rate, reporting, and protects patient from mosquito bites. A delay causes the afore-mentioned effects to be delayed as expected, but does not delay treatments — this allows immediate suppositories to be given, but means that hospital-administered drugs should be delayed by a day in the XML (using the "delay" modifier). |
Regarding costing, sometimes in severe cases 2 tests would be used (by a referring health centre, and by the hospital accepting the patient). One method of dealing with this, assuming the in-hospital test result has no impact on treatment decisions, is to assume all patients get an RDT test in hospital (by adding the number of hospital recoveries+deaths+sequelae to the number of RDTs reported), and use the test decision to describe whether an out-of-hospital test occurs.
Decisions described in the XML are all given as a decision element who's content is some form of tree; there are currently two varieties as in the table below. The syntax for a tree is:
// a symbol is one or more characters in the set: a-z A-Z 0-9 . _
symbol = ( alnum | '.' | '_' )+
// double_ means a floating-point number; a range looks like: x-y
range = double_ '-' double_
// types of values: a symbol, a number, or a numeric range
value_symbol = symbol
value_double = double_
value_range = range
// an outcome either looks like { <tree> } (where <tree> is another whole tree)
// or like :<symbol> (where <symbol> is some symbol)
outcome = ( '{' tree '}' ) | ( ':' symbol )
// a branch looks like: X(Y)
// if X is "p" we have a probability branch; if it's "age" we have an age-range;
// otherwise X should be the name of a decision and Y one of the decision's outcomes
branch_p = "p" '(' value_double ')' outcome
branch_age = "age" '(' value_range ')' outcome
branch_decision = symbol '(' value_symbol ')' outcome
// A branch set is a list of one of more branches (all of the
// same type and, if decision branches, for the same decision).
// In whichever relevant way the set must be complete: probabilities
// add up to 1 or all outcomes of some decision be represented.
branch_set = ( branch_p | branch_age | branch_decision ) +
// A tree is either a branch set, or simply an outcome.
// This is the "entry point" -- describing the whole decision --
// but can also occur as a sub-tree.
tree = branch_set | symbol
Besides the special "age" and "p" cases (see table below), this allows us to determine an outcome based on another decision (this decision must, then, be listed under depends). Note that a decision used as a branch point (or "p" or "age") may be used again in a sub-tree (in particular, using multiple random trees may simplify writing decisions).
| Tree type | Description |
|---|---|
| age-dependent | The tree must have exactly one dependency: age. Branches should be identified with the syntax age(a-b) where a and b are in the range [0,inf] (allowing the special value inf). In a branch-set these ranges must not overlap and must cover the entire range [0,inf] (i.e. lowest bound must be 0 and highest inf with matching boundaries). Age ranges are considered half-open, open at the top (i.e. an age on a boundary matches the higher age-group). |
| stochastic | A generic decision whose outcomes are determined by input decisions and/or random samples. Unless purely deterministic, p must be used as in input dependency and then probability branches may be specified using p(x) where x is the probability of the branch being chosen. All probabilities in a branch-set must add up to 1. |
The treatments element consists of a list of treatment elements. Each treatment element has a name attribute (which must correspond to one of the outcomes of the treatments decision), a schedule element and a list of zero-or-more modifier elements.
The schedule element describes the base schedule of medications taken: a list of medicate elements describing each drug dose given, with a drug code and the hour at which it is given (from 0, start of timestep on which case management occurs). If duration is zero or not specified, the dose is assumed to be taken orally, and the size of the dose is given in mg of active ingredient. If a non-zero duration is specified (units: hours), the dose is administered via IV (uses different equation and separate costing from oral drugs), and the dose is instead specified as mg active ingredient per kg weight of the patient (again using the "mg" attribute). Example of IV drug:
medicate drug="XX" hour="0" mg="1" duration="8"/>Drug codes available are those specified in the drug library.
Since one base schedule may be well or poorly adhered to in several variations, we have modifier elements. Each modifier corresponds to one decision and has one of three types (see table below). Each of these consists of a list of sub-elements, each of which have attributes value (the decision's outcome), effect (effect of the modifier per drug-code prescribed; of the form DRUG1(x),DRUG2(y) where x and y are effects as described below), and optionally the boolean attribute affectsCost (whether costs are modified in the same way as the doses administered; defaults to one if not present; can be used to simulate low-quality drugs at standard cost and vomited doses).
| sub-element name | description |
|---|---|
multiplyQty |
multiplies dose size; useful for age-specific dosing and poor-quality drugs |
delay |
delays each dose by the given number of hours; can be used for delayed arrival to a health facility but this won't affect the start/end time of the bout of illness |
selectTimeRange |
Causes doses outside the time range given to be missed (also not costed unless affectsCost is set false). The range x-y is interpreted as a half-open interval; for dose at time t to be taken we must have x <= t < y. |
The EventScheduler element also has a ClinicalOutcomes element, describing:
| name | type | description |
|---|---|---|
| maxUCSeekingMemory | int | Maximum number of timesteps (including first of case) an individual will remember they are sick before resetting. |
| uncomplicatedCaseDuration | int | Fixed length of an uncomplicated case of malarial/non-malarial sickness (from treatment seeking until return to life-as-usual). Usually 3. |
| complicatedCaseDuration | int | Fixed length of a complicated/severe case of malaria (from treatment seeking until return to life-as-usual). |
| complicatedRiskDuration | int | Number of days for which humans are at risk of death during a severe or complicated case of malaria. Cannot be greater than the duration of a complicated case or less than 1 day. |
| pImmediateUC | double | Probability that, when sick with uncomplicated fever, treatment seeking will be done immediately, on the second, or on the third day when sick. |
By default, no Non-Malaria Fevers (NMFs) are modelled. If the option NON_MALARIA_FEVERS is enabled, incidence is modelled; NMFs only occur if no malaria fever is present and are handled as uncomplicated cases (no chance of morbidity). Note that comorbidity (UC malaria + coinfection) modelling is not affected by this non-malaria fever option.
In the case of 1-day time-steps using the EventScheduler health system model, antibiotic usage and non-malaria fever deaths are also modelled. Two categories of NMF are considered: bacterial/viral infections which are self-limiting, never fatal and therefore require no treatment, and bacterial infections which may lead to death and thus should be treated. The extra outcomes reported are the numbers of NMF deaths and of antibiotic treatments taken.
Incidence of NMF (all health systems) and the probability that the NMF requires treatment (EventScheduler only) are described like below. Link to schema doc. Link to example incidence data.
<model>
<ModelOptions>
<option name="NON_MALARIA_FEVERS"/>
</ModelOptions>
<clinical healthSystemMemory="15d">
<NonMalariaFevers>
<!-- rate of incidence of clinical fever per person per year by age -->
<incidence>
<group lowerbound="0" value="0.1"/>
<group lowerbound="1" value="0.1"/>
</incidence>
<!-- probability that a case requires treatment by age -->
<prNeedTreatment>
<group lowerbound="0" value="0.1"/>
<group lowerbound="10" value="0.1"/>
</prNeedTreatment>
</NonMalariaFevers>
</clinical>
...
</model>Treatment and outcomes of NMFs are described as part of the health-system model. The uncomplicated decision tree is followed as for uncomplicated malaria, the only difference being that malaria diagnostics are likely to give a negative result unless the patient also carries malaria parasites.
When using the EventScheduler, two additional decisions are made for NMFs: whether antibiotics are administered and whether the fever is fatal. (Antibiotics are never administered for malaria fevers.) These decisions are described by the parameters below. Link to schema doc.
<healthSystem>
<EventScheduler>
<uncomplicated ... />
<complicated ... />
<ClinicalOutcomes ... />
<NonMalariaFevers>
<prTreatment>0.7</prTreatment>
<effectNegativeTest>0</effectNegativeTest>
<effectPositiveTest>0</effectPositiveTest>
<effectNeed>0</effectNeed>
<CFR>
<group lowerbound="0" value="0.1"/>
<group lowerbound="10" value="0.1"/>
</CFR>
<TreatmentEfficacy>0.6</TreatmentEfficacy>
</NonMalariaFevers>
</EventScheduler>
</healthSystem>This intervention updates the case management system by providing an entirely new description; e.g. it can be used to simulate the effects of improved access to treatment. Prior to version 32 it is described like:
<interventions>
<changeHS name="name of new health system">
<timedDeployment time="0">
<ImmediateOutcomes .../> <!-- or EventScheduler -->
<CFR .../>
<pSequelaeInpatient .../>
</timedDeployment>
</changeHS>
...
</interventions>Any number of timedDeployment elements may be used, each of which specifies a time of deployment (in timesteps) and has the same type of content as the healthSystem element used to describe the initial health system.
| Download openmalaria | Installation instructions | XML Schema Documentation |
| XML Schema Version | Program version | master |
develop |
|---|---|---|---|
| 43 | schema-43.0 |
 |
 |