Checklist For Developing A Disease Module

Phase 1: Initial Design

1.1. Confirm the definition of the disease, the sequalae and associated interventions that are within scope for the TLO Model:

• Look up the Malawi EHP and the DCP3
• Consult any subject matters experts collaborating

1.2. Identify others who are working in related or adjacent areas and find/create the slack channel that will be used for all discussion and documents regarding this module.

1.3. Search for and review research articles relating to the disease (preferable original publications of major findings, review articles and the DCP3 chapters). Research articles on intervention effects should include all evidence from any region of the world where possible. Research articles on disease incidence and prevalence and use of interventions should come from Malawi or the surrounding area where possible.

1.4. Discussion with team about data that is available in Malawi on this topic. Identify data sources which are likely to include information on aspects such as prevalence, incidence and risk factors for the disease.

1.5. Design how this disease will be represented in the model. Consider:

• Stages of disease and progression between these, if appropriate;
• Symptoms, and these will maps to DALY weights and propensity to seek care;
• Proximal Causal Factors (remember that we set a high bar for evidence for a causal association) and work out which of these factors are already in the model;
• Note any underlying factors that have been found to be associated with this disease (will the model capture such indirect effects and, if not, how is that justified?);
• Strategies for parameterisation of each parameter value;
• Define what a successful calibration will look like (What do we want to ensure the model captures well?);
• Are the interventions arguably consistent with the Malawi Treatment Guidelines and/or international treatment guidelines? Interventions which are not included currently in such guidelines (including because they are new interventions) but which could plausibly be considered for implementation in future it would be helpful if these are included, but initially kept "switched off" in the code.
• What is the flow of Health System Interaction events, health care seeking, and how 'squeezing' will affect these?
• How this will relate to other modules; study their formats and discuss with TLO team members how this interaction can work?

1.6. Consult the high level design decisions document and pose any questions if needed.

1.7. Write up an outline draft of the Methods Write-up (a Word document)

1.8. Propose this model design to PI's and Alison and the whole TLO Team.

Phase 2: Full Design

2.1. Conduct any necessary data analyses, collation of data and/or reviews of literature in order to fully specify and parameterise the model.

2.2. Reformat the input data/parameters so as to be suitable for direct read-in by the Model Code (call these: 'ResourceFile_').

• Polished files reproducing this from a raw file (stored on dropbox) to the 'resource file' are to be stored in the repo (/src/scripts/data file processing/ [filename prefix 'formatting_']).
• NB. It is OK for these files to either be a set of .csv files or as sheets within an Excel workbook.

2.3 Do the same reformatting for any data to which that the model output will be compared.

2.4. Produce a complete and updated version of the 'Methods Write-up'. This must

• have the completeness and formal tone such that this document is suitable to be included in a final technical appendix of the whole model;
• as it will be presented to external audiences, it should have the standard introduction about the TLO Model
• be fully referenced;
• at the top clearly and precisely define the scope of the disease, sequelae and interventions that are covered;
• where necessary, design decisions should be justified and defended;
• include a diagram explaining the causal influence of factors;
• include other diagrams as necessary to understand the progression between disease states;
• include diagrams that explain the flow of persons through health systems interactions in the course of the provision of treatments;
• include tables listing parameter values and justifications/sources;
• have placeholders showing the data/indicators to which the model will be matched;
• include a specific section ('Limitations') reflection on what the biggest limitations are in the module;
• include a specific section ('Outstanding Issues') that list any modifications that will need to made in the future when any other modules have been completed;
• have placeholder section for contributors to this disease module.

Phase 3: Review

3.1 Prepare for review.

• Check that the 'Methods Write-up' contains within it full information relating to the questions noted in step (1.5) above.
• Check that you the documents is able to satisfy the following questions:
  • Is this what really happens in Malawi?
  • Is there duplication of a property with other modules?
  • Is the understanding/use of each shared property the same in your module as in other modules? (ie. make sure you have resolved any inconsistencies directly with the developer of the other relevant module).
  • Have you determined how your properties will be populated at on_birth()?
  • How will this module initiate its properties at the beginning of the simulation?
  • Is the evidence strong enough to assume a causal association between X and Y?
  • Why is intervention X not included?
  • I have heard that X causes Y but it’s not shown here: why not?
  • Is every intervention in the EHP and DCP3 included here?
  • Is this consistent with the Malawi Treatment guidelines document?

3.2. Contact Alison and ask for her initial review of the proposed module design (send her the 'Methods Write-up')

3.3. Arrange (via colleagues in York) for an expert in Malawi to review what you have proposed

• Look for an expert (See this list of proposed persons so far).
• Edit this template letter accordingly.
• Arrange for TLO PI’s to send out invitation letter on our behalf.
• Arrange a meeting (TC) with the expert (with help of York admin team if helpful) and talk them through the design. Ask questions about your proposed abstraction of the disease and the interventions as they relate to the Malawian context.
• Log their contribution and contact details in the Methods Write-up

3.4. Once agreed, file your methods documents in the dropbox in ‘\04 – Methods Repository\’

Phase 4: Implementation

4.1. Decide how this module will be coded in the python framework:

• Consult with team members and look and what others have done (most things have been done before!)
• Check the wiki for helpful utility functions to use

4.2. Start a new branch off master and develop your code:

• Following the latest version of skeleton.py
• Adhere to conventions in terms of file placement, naming etc.
• Confirm the property names that this module will ‘address’ (created by others and read by this module) and ‘own’ (created and managed by this module).
• Add any resource files to the repository
• Ask any questions the public slack #programming channel

4.3. Test the logical performance of the code

• Build-in confirmatory on-the-fly checks using ‘assert’
• Build-in overall test for the performance of the module using ‘pytests’

4.4. Test the epidemiological sense of the model

• Produce outputs of key epidemiological indicators
• Demonstrate agreement between model output and input data or independent data, as planned
• Demonstrate that all the interventions have the right effect (including any effect of squeezing)
• Code all these checks and production of figures in an 'analysis' script.

4.5. Consider having a further consultation with the technical expert in Malawi that will focus on examining the model outputs.

4.6. Confirm that methods write up and the content of the methods template exactly reflect the final version of the code.

Phase 5: Finalisation

5.1. Finalise methods document: this should now be fully complete and polished.

5.2. Contact Alison and PI's and ask for final sign-off of the module.

5.3. Prepare the code for the pull request (see Pre-PR Checklist)

5.4. Launch a Pull Request

5.5. Conduct any follow-up that is required.

5.6. When PR is approved, inform all persons involved that the module has been completed.

5.7. Have a day off!

After Finalisation

• Track comments received later in the methods document (under 'Outstanding Issues')