1 Introduction

1.1 Problem and Background

Covid-19 has influenced how we shop, how we are educated and how we socialise, pushing many of these events online. However, following successive epidemic waves and subsequent development of vaccines we are now seeing a drive to get people back into more public spaces, such as classrooms and Halls of Residences at Universities.  

We have generated an individual-based simulation algorithm that predicts the infection spread of Covid-19 within educational spaces and we have used it to provide Welsh Government policy-makers with results on how best to intervene and reduce infection spread. However, in our interactions we have found that policy-makers often need different simulations at different times, which require simple adjustments to our code.  

Currently, the code is in the form of MATLAB script, which only trained mathematicians can use. To optimise the interaction between policy-makers and academics, we will construct a simple web-based General User Interface (GUI) that will allow users to simulate their own scenarios and, thus, predict the outcome of interventions under a vast array of conditions. 

1.2 Solution summary in simple terms

We have constructed an algorithm (https://github.com/joshwillmoore1/COVID-19-LFD-IBM) that can track individual infections across a variety of different education environments, under several different interventions. The code is comprised of different modules that can be turned on, or off, as appropriate, so that the simulation can match a variety of policy situations. Figure 1 illustrates the ideas behind the algorithm. 

Figure 1: Flowchart illustrating the general iterative process controlling the infection dynamics of a discrete population over a typical day. 

We have already tested the code across a variety of scenarios. However, policy-makers always require more simulations as new data is produced and as they think up new scenarios. We will convert our complex simulations into simple user interfaces using “Shiny Applications” that put the power back into the policy-maker's hands. Namely, policy-makers will be able to simulate and intervene in different scenarios as fast as they can think them up. 

1.3 Solution summary in technical terms

Figure 2 illustrates the detailed structure behind our individual-based simulation. The algorithm accepts many different input variables, such as: 

• probability people follow the rules; 
• interventions e.g., masks, ventilation, etc.; 
• ratio of asymptomatic spreaders to symptomatic spreaders; and 
• probability of false-negative and false-positive results in COVID-19 tests. 

Thus, we can simulate many hypothetical scenarios, such as cases in secondary schools in which compliance is good, but the ratio of asymptomatic individuals is high and the lateral flow devices have a high false-negative probability. 

However, with every additional factor that can be changed the number of possible scenarios that can be modelled grows combinatorically. Thus, instead of choosing which results we think policy-makers may be interested in we want to split our expertise. Specifically, we focus on our strengths of producing a usable and robust interface that provides policy-makers with the ability to generate the results they require, whilst exploring different intervention options that will reduce the number of future infections. 

Figure 2: Flowchart illustrating infection spread. Colours represent subroutines: grey is base infection, green is testing, red is secondary infection estimation and blue represents infections from outside the population. SI corresponds to secondary infections. 

1.4 State of advancement of the project

The research behind this project has been completed and can be found as a preprint at https://medrxiv.org/cgi/content/short/2021.03.08.21253122v1. 

The MATLAB code for the simulations exists (https://github.com/joshwillmoore1/COVID-19-LFD-IBM). 

This project focuses on converting the MATLAB code into R code, which can be used to produce a simple web-based GUI, as a Shiny App. The grant will fund a 14-day project which will proceed as proposed below. 

• Days 1-2 Convert basic algorithm loop into R code (see Figure 2). 
• Days 3-4 Add in interventions. 
• Days 5-6 Construct interface using https://www.shinyapps.io/. 
• Day 7 Test output consistency. 
• Day 8-10 Iterate usability with test group. 
• Day 11-13 Documentation writing. 
• Day 14 Contingency. 

2 Project Implementation 

2.1 Solution

We seek to create a solution to the problem of policy-makers wanting to vary simulations to understand prediction sensitivity to parameter and intervention changes. Specifically, whenever we present our research to policy-makers, we are only able to illustrate a small number of solutions that we believe they will be interested in. However, policy-makers are frequently interested in new scenarios, as well as wanting to run simulations with updated data. 

By constructing a well-documented, user-friendly GUI, as illustrated in Figure 3, we provide policy-makers with a simple front-end to a complex algorithm (see Figure 2) that can be used to simulate multiple scenarios. Specifically, the blue sections represent inputs. The parameter table on the left represents default parameters, as estimated from current data. These input parameters can either be left at their default values or updated based on a user’s knowledge. 

The grid at the top delineated by black lines presents a set of toggle switches that can be turned on, or off, depending on the scenario that is being simulated. For example, we would assume a secondary school population would not mix on the weekend (the toggle would be set to ✗) and we would want to isolate individuals who generate a positive covid-19 test (the toggle would be set to ✓). Moreover, we can set specific days of the week for tests to occur and what signal causes testing to begin. Namely, by default, the testing schedule is assumed to be fixed (as specified by the choice of testing days). However, if “Testing after first symptomatic is found” is ticked then testing does not start until a symptomatic individual is detected. The probability of this event is then highly dependent on the ratio of asymptomatic individuals (parameter in the left blue table). 

Figure 3: Schematic diagram of the General User Interface, GUI. 

Once the parameters have been set and the scenario switches have been chosen. The calculate button is clicked and the simulation as defined in Figures 1 and 2, is run 100 times. The algorithm is run multiple times due to the stochastic nature of an individual-based simulation. Specifically, by running the simulation 100 times we can provide an estimate for the mean values of several output metrics. Namely, the grey box represents four suggested outputs, i.e. (left to right, respectively) number of non-isolated and infected individuals on a given day, total number of infections, number of isolating individuals and number of recovered individuals. Finally, two summary statistics are quoted: the average total number of infections that have occurred by the end of the simulation and the total number of days spent in isolation, per individual. The goal of the policy-maker is, thus, to find scenarios that minimise these statistics. 

For ease of use we will also include the ability to save and load parameter values as text files and output simulation data as “comma separated values” (.csv), which is a standard file type that can be read by all spread sheet software. Thus, a policy-maker can quickly and easily manipulate their scenario, trialling multiple perturbations. Moreover, a user can save their results, allowing them to easily collate, compare and plot their data using external software. 

Currently, the Covid-19 simulator has been used to simulate educational environments, such as secondary school classrooms and a University’s Halls of Residence. However, the simulator could be used to predict infection spread in more diverse scenarios. For example, we have been asked to consider situations such as mixing between hospital wards and care homes. These environments could easily be encapsulated into the algorithm with minor alterations.

2.2 Methodology

The agent-based model considers a population of N susceptible individuals split into groups of size N_g. The parameter N_g is the number of local contacts an individual has and represents the number of isolations that would occur should a member of a group become identified as infectious. This parameter can be varied to test a range of isolation policies.  

Critically, the effectiveness of isolation is modulated by a ‘compliance’ parameter. Namely, after receiving a positive test result, or becoming symptomatic, an individual isolates themselves with a probability specified by the compliance parameter. 

During any day that testing is applied all individuals that are not isolating are tested. The testing phase occurs before the mixing phase (see Figure 1). Thus, any individual triggering a positive result is isolated before they can infect others. 

The blue sections of Figure 1 and 2 control external infections, i.e., infections that enter the modelled population due to infected individuals outside of the modelled population. The red sections of Figure 1 and 2 control how secondary infections are generated due to mixing between individuals. During any day where the students can mix, any infectious individual can infect other people. Once a person becomes infected three delay timers are attached to each of them. The three delays, t_i, t_d and t_r, represent: 

• the time between becoming infected to becoming infectious, t_i = 3 days; 
• the time between becoming infected to becoming detectable by a LFD test, t_d = 5 days; and 
• the time between becoming infected to recovery, t_r = 10 days. 

Any recovered person is assumed to be non-infectious and immune to further infections and that the tests being used are Lateral Flow Devices, LFD, which are assigned to have a false positive probability and a false negative probability. 

At the point of infection each agent is either given a symptomatic or an asymptomatic flag based on a prescribed probability. Asymptomatic individuals can infect susceptible individuals and will not isolate unless a positive test is returned. Symptomatic individuals are assumed to follow self-isolation guidance at a rate determined by the compliance parameter at any time they show signs of infection. 

To produce the web-based simulator, we need to convert the existing algorithm from the computational language of MATLAB to the language of R. Most MATLAB functions have direct analogues with R functions and as our implementation of the algorithm has minimal dependencies on MATLAB, we expect the conversion to R will result in no loss of functionality, but rather an increase in accessibility and locality optimisation. 

2.3 Results

The output of this project will be a GUI, as illustrated in Figure 3. The parameters will be set in the left table. The switches at the top of the GUI will allow a user to create a specific scenario, easily and quickly, with given interventions. Each numerical input parameter will be a reactive variable that will feed directly into the model once the “COMPUTE” button is pressed.  

Finally, we will provide the user a button to reset all data to default values and a button to save simulation inputs and outputs to the local machine. The input/output data will be assembled into a single data frame and will be exported to .csv format using Shiny app functionality. 

Each component of the model can be active/inactive and, thus, adapted to investigate various infection settings. For example, Figure 4 demonstrates the ability of the model to quickly test the efficacy of two currently proposed isolation policies in classrooms by simply adjusting model parameters.