Lateral flow assay (LFA) tests are becoming more popular each year because of its ability to rapidly and cheaply detect small amounts of analyte³. However, straightforward questions, for instance, the appropriate concentration of capture sites, optimal test line location, or sufficient amount of sample volume can be answered only by experimentation⁴. Thus, the development of LFA tests is very tedious work and can exhaust the most valuable resources - time and money.

Visit the site

Although LFA strip tests are widely used in the healthcare industry, home care and in the monitoring of the water quality and food supply, software that would facilitate the development of such tests are not freely available on the market⁵. After we started to plan our experiments, it became hard to decide where to put control and capture probes. Also the optimal reagent concentrations should be known. Such problems are usually faced by anybody who has ever tried to design a LFA strip test. It would be desirable and convenient to have a sophisticated and easy to use tool that could rapidly and inexpensively predict various parameters of LFA. To solve this problem, our team presents a novel software tool - onFlow.

To implement this, we utilized the classic Waterfall engineering model. Even though more advanced models that use iterative approaches exist, we chose this one because it is the most appropriate choice for projects that are well defined, their requirements are clear and fixed, the duration of the project is short and the idea is concise. The waterfall model describes five main steps of the software life cycle: communication, planning, modelling, construction and deployment, all of which will be described in the further sections.

Figure 1. Diagram of the waterfall software development process model.

The first stage in designing any type of software is to gather all the requirements and specify what features will be implemented.

Since onFlow is a web based user interface of our mathematical model on LFA parameters, it requires only a few important features - fields for user inputs, API for front end and back end communication and clear output of results. We also added a feature that allows users to search for the values of several parameters in an external database and alleviates the workload even more.

As for the requirements, there were only a few - onFlow had to be intuitive and quick. Besides these, the most important requirement for the software was clear and easy-to-understand documentation of different parameters, utilized in the mathematical model of the system. Keeping these requirements and features in mind, we continued on to the planning stage of the engineering cycle.

Second stage of the software development life cycle usually involves three main steps: estimating the cost and schedule of the project as well as deciding on progress management principles. Firstly, we estimated the cost, which consisted of two parts - website domain registration and buying Virtual Private Server (VPS) for hosting onFlow (it was also used for ‘The 6th SynBio Sense’). Secondly, we planned our schedules to fit into the deadline of Wiki Freeze - October 27th. Since we came up with the idea for the software in mid-August, we had two months to finish our project. We distributed different tasks (e.g. front end, back end, external database integration, etc.) amongst ourselves and worked in parallel to speed up the process. Lastly, to keep track of our progress we held weekly meetings where we discussed what was done in that time period and what tasks await us in the next one. These steps helped us to ensure that onFlow would be delivered on time.

We divided our software architecture into two main parts - the back end, which is the logical component, and the front end, the graphical user interface. While the software front end is only used for taking user inputs and showing the results, the back end does all the ‘heavy lifting’ - obtaining suitable strip test design and sending API requests to the KOFFI external database. In this section we will describe the thought process of designing the back end structure of onFlow.

Figure 2. Diagram showing the sequence of operations in the software.

The whole data flow of the software is displayed in the diagram (Fig. 2). Most of the steps are straightforward. It must be noted that steps 1-4 are optional, because the user can input the association and dissociation rates themselves.

The back end and front end split is beneficial, because we can test the components individually and they can be reused later. The back end includes two API endpoints: one for accessing the rates from KOFFI DB, and the other one for the actual calculation interface.

Not every LFA user is able to understand Partial Differential Equations (PDEs), not to mention correctly formulate variational problems and simulate the whole nonlinear PDEs system. Therefore, as great agreement was met with our wet lab results, we decided to fill this gap by integrating our LFA mathematical model in the software.

We chose to implement the model using the Python-friendly computational finite element method platform FEniCS. This was done because it is open-source, has a Python interface, and its back-end is implemented in C++, as a result it does not compromise speed. The model simulates a partial differential advection-convection-reaction equation system and estimates the optimal test line location.

In the mathematical modeling section we describe the mathematical background of LFA, the problems that we have faced and the way how our modeling helped us to answer questions related to LFA strip design and facilitated the development process. Details can be found in the modelling page.

Briefly, at the initial user request the software’s back end uses FeniCS platform to generate two simulations that are based on PDEs. The first simulation evaluates the test line’s optimal location on the strip, which is the place where a sufficient amount of analyte-detection probe complex is formed. The second simulation then uses results from the first simulation to calculate the duration of the test and the minimum volume of the analyte, thus the amount of analyte needed to obtain sufficient sensitivity on the test line. Therefore, our software onFlow allows users to vary different lateral flow assay parameters such as capillary flow time, analyte concentration, probe concentration or affinity constants, in order to obtain suitable strip design, optimize reagent consumption and decrease the timeline and cost.

However during the development of our model and software we noticed that manual or experimental search of kinetic constants, which are important parameters for the lateral flow assay model, could take a lot of precious time. Therefore, we decided to broaden the scope of our software by incorporating the ability to extract the kinetic constants from recently published platform¹ that stores binding rates (association, dissociation) in a novel database². In short, our software can use KOFFI platform’s API to search for user defined dissociation or association rates of biomolecular interactions. In this way users can find the necessary kinetic constants of biomolecular interactions between DNA, RNA, proteins and chemical compounds that are necessary for LFA development. However, if such parameters are not available in the KOFFI platform’s database, the users can either use default values or specify their own binding parameters.

The overall structure of our back end is not complicated: it is split into two python scripts that are run consecutively. First, the test line location simulation is run, to find the optimal distance. Then, the second simulation is run with results from the first simulation, to determine the optimal concentration of the signal. The results are then sent to the front end.

onFlow uses quite a lot of different parameters (5 main parameters, and 8 association/dissociation rates) in order to make a rapid and accurate prediction of results. The amount of these parameters might be overwhelming for the user, therefore we had a goal to make our UI user-friendly as much as it was possible. To implement this, we documented each parameter not only with their descriptions but also short animations that visualise how the parameter fits into the whole system. This ought to help users to navigate the software easily even if it is their first time using complex mathematical modelling software such as this one.

For the front end of our software we used a modern Javascript library React. It allowed us to create an easily scalable and fast user interface while also maintaining our teams’ design brand.

View GitHub