Building model-informed precision dosing software using R: blueprint for a state-of-the-art development process
Ruben Faelens[1], Nicolas Luyckx[2,5], Quentin Leirens[2,6], Thomas Bouillon[1,3], Dirk Kuypers[4], Pieter Annaert[1]
[1]: Katholieke Universiteit Leuven, [2]: SGS Exprimo NV, [3]: BioNotus GCV, [4]: Universitair Ziekenhuis Leuven, [5]: Calvagone (current), [6]: Pharmetheus (current)
Objectives: Over the last few years, the pharmacometrics community showed a renewed interest in model-informed precision dosing (MIPD). Although a pharmacometrician can certainly investigate the best dosing regimen for an individual patient using modeling software, a custom-built MIPD software is more user-friendly and allows use by clinicians.
To support these efforts, our group built tdmore. Tdmore is an R package that offers the mathematical routines and user interface components required to build MIPD software. Because this software intends to provide individual dosing advice, it is considered a medical device in the EU [1][2] and is therefore subject to stringent quality requirements, requiring development in accordance with the “state of the art” (cfr. EU legislation).
The state-of-the-art development process of tdmore offers an inspiring blueprint for anyone developing high-quality software in R.
Methods: We defined “state of the art” as how a software engineering team would build a modern large-scale software system. User requirements are collected through interviews with stakeholders. This is structured in a software roadmap, with iterative releases planned to allow for fast feedback from future users. Software is built using a modular design and tested using automated tests. Continuous integration and continuous delivery bring value to clients as soon as possible. Finally, user and administrator documentation should be readily available.
Results: The tdmore roadmap was driven by the roadmap of the supporting grant, and by timelines for the start of a clinical trial to test the software. Github Projects was used to plan development and keep stakeholders informed of progress. Technical R&D sprints were planned to reduce technical debt and investigate the best way to implement new features.
After evaluating existing modeling packages, the mathematical engine was implemented as a set of S3 methods: `model_predict` provides an interface to simulation of structural models (as algebraic, RxODE-based or Monolix-based models), and the `tdmore` S3 object contains all other required information (IIV structure, RE structure) to perform an empirical bayesian estimation, resulting in a `tdmorefit` object. Using S3 allowed us to implement standard methods like `predict`, `coef` and `plot` for the tdmorefit object. The `findDose` method completes the package, allowing to find the optimal dose to hit a specified target. A user interface was built using Shiny, ensuring the main shiny application code remained lean by leveraging Shiny Modules. Plumber was used to build a REST interface for connection to hospital systems.
At every git commit, the R package was tested automatically on the Travis continuous integration servers. A Docker image was also built and tested. An extensive set of tests was implemented. `vdiffr` was used to test plot outputs. For performance testing, `benchmarkme` was used to establish baseline machine performance, and `profvis` was used to manually investigate problem areas. Finally, `shinytest` with `phantomJS` was used to test shiny interfaces and gadgets.
If testing fails, developers are notified. If testing succeeds, a Github pages website is generated through `pkgdown`, containing all relevant documentation and vignettes. A documentation book is also produced through `bookdown`.
If all testing succeeds, the docker image is automatically deployed on the hospital Google Cloud infrastructure in a Kubernetes cluster. A reverse proxy takes care of load-balancing towards several cluster instances of Plumber and Shiny, who share data through a Mongo database.
The system has been running in test mode since end of 2019, receiving data from the patient system but not displaying this dosing advice to doctors. A clinical trial is planned.
Conclusion: Using R to build high-quality software is a daunting task for a pharmacometrician. Our experience building tdmore showed that all key software tools for a state-of-the-art development pipeline are available in the R ecosystem, although some lacked maturity. The blueprint presented above is a viable method of delivering high-quality software, be it for a MIPD medical device or any other high-quality software.
References:
[1] REGULATION (EU) 2017/746 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 5 April 2017 on in vitro diagnostic medical devices and repealing Directive 98/79/EC and Commission Decision 2010/227/EU
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32017R0746&from=EN
[2] REGULATION (EU) 2017/745 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 5 April 2017 on medical devices, amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and repealing Council Directives 90/385/EEC and 93/42/EEC
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32017R0745&from=EN
[3] Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR
https://ec.europa.eu/docsroom/documents/37581?locale=en
[4] Mastering Software Development in R, Roger D. Peng, Sean Kross, and Brooke Anderson, 2017
https://bookdown.org/rdpeng/RProgDA/
[5] Mango Solutions, R training
https://www.mango-solutions.com/training/r-training/
[6] RStudio webinars and resources https://resources.rstudio.com/
[7] R in production at T-Mobile, https://resources.rstudio.com/rstudio-conf-2020/we-re-hitting-r-a-million-times-a-day-so-we-made-a-talk-about-it-heather-nolis-dr-jacqueline-nolis
