Future-proofing with PediTools Universal

Preparing PediTools for the future: support for 120+ distinct growth curves and beyond, including bulk calculations, plotting, and custom growth chart generation.
R
Clinical
PediTools
Shiny
Published

February 1, 2025

PediTools was originally launched in January 2012 to provide calculations for the Fenton 2013 preterm growth charts. The original web page was hand-coded in a PHP script to support the 6 distinct growth curves (weight, length, head circumference, for two sexes).

With time, additional growth charts were added and each one was a separate PHP script. People contacted me requesting tools for very specific, niche charts and when possible, those were individually added as well

At the time of this post, I’ve obtained parameters describing more than 120 distinct growth curves, and it is clear that individually coding PHP scripts is not a sustainable long-term solution.

This post describes the initial deployment of a generalized, universal growth chart tool and the issues that guided its design and functionality. I will touch on the benefits (numerous) and downsides (also numerous, but hopefully acceptable).

Launch of updated PediTools Universal

Initial release made on 2025-01-31, at PediTools Universal

At the time of building this page, there were a total of 121 unique growth curves, listed further below with links to sources.

Example: CSV data upload for preterm growth

Example: Growth chart generation

Charts available

Plot of all charts available

Listing of all charts available with sources

Design and implementation considerations

Nothing below here will likely be of interest to you. This is for me to record decision-making thoughts and plans.

peditools R package for LMS calculations

In 2019, I released the peditools R package on GitHub under the open source MIT license. It includes R functions to perform the Z-score calculations of growth charts under the lambda / mu / sigma (LMS) parameterizations. When publicly available, it also includes the LMS parameters for growth charts.

The goal was to have a “one-stop” shop for dealing with growth charts. It also paved the way for creating a single universal tool for all growth charts, instead of a separate PHP script for each chart family.

More recently, I’ve been updating the peditools package so that chart metadata (e.g., which anthropometerics, X- and Y-axis units, publication source of data, etc.) are all kept within the package.

PediTools Universal shiny app

The old web tools were written in PHP which seemed appropriate for a webpage that needed to perform server-side calculations. However, PHP is not ideal for dealing with larger-scale calculations. And the early decision to write one PHP script per tool was severely problematic for adding and supporting more growth charts.

Using the peditools R package, I wrote a universal R shiny app to read it the full growth chart LMS parameters for all available growth charts.

The downside of using R shiny was that while PHP could be run server-side on pretty much any web server, maintaining the infrastructure for an R shiny server was more expensive and more complicated. For a while, the PediTools Universal app was hosted on RStudio’s (now Posit) free servers, but was limited to 25 active hours per month.

Also, the PediTools web pages get hundreds of thousands of hits per month, which would overwhelm a Shiny server.

Client-side Shiny with shinylive

In December of 2024, I learned for the first time of shinylive.

Shinylive is a new way to run Shiny entirely in the browser, without any need for a hosted server, using WebAssembly via the webR project.

Both the PHP and original Shiny apps did the computations server-side. The user would connect using a web browser, enter values into form fields and when they hit the submit button, the input values would be sent to the server, which would perform the calculations, and then send the results back to the client for display.

shinylive does something completely different, which is nothing short of magical. R, Shiny, and all of the required assets are compiled into WebAssembly (WASM) via webR which runs on the client-side browser to do all the calculations and display.

Basically, this means that once the shinylive web page is loaded, all computation and display is done locally within the client-side browser. The page can be hosted from any web server, even a static server, with no need for a Shiny server (or even PHP).

Difference of PediTools Universal as a Shiny app under shinylive

R vs PHP

  • using R instead of PHP allows easier handling of ALL growth charts under a single app
  • R can handle bulk upload of an unlimited number of data points for calculations, instead of one point at a time
  • R handles plotting much more easily, allowing custom on-the-fly generation of growth charts; e.g.,
    • can select exactly which percentile lines you want displayed
    • can hover over the plot lines or points to get additional information
  • page load is much slower with shiny (typically need to spin up server) compared to with PHP

shinylive vs shiny via Shiny Server

  • initial access requires transfer of MUCH more information so is much slower
  • once loaded, no internet connection is needed
  • no data is sent to the server
    • although generally, no protected health information (PHI) should be getting sent, this still make me feel better
  • I suspect that once loaded, the shinylive app should be usable indefinitely, until unloaded from memory
    • this may be useful in areas with difficulties with internet access
    • would love to see whether complete standalone app support may be possible in the future
  • of note, shinylive apps are completely open to inspection (as opposed to those run from a Shiny server, which are protected)
    • it’s quite trivial to obtain and inspect the complete source code and associated data files of a shinylive app
    • this isn’t a bad thing, from a trust perspective
    • it also means that someday, if I am no longer able to maintain PediTools, that anyone else can obtain the code and data and continue the project
    • the intent would be to release this as open source with a moderately permissive license appropriate for an open source web application (perhaps GNU GPLv3; maybe not MIT to prevent re-use without sharing source code)

Downsides

  • initial access is a large information transfer with significant delay in startup
    • not sure if this will run into bandwidth limits on the webserver; if so, the popular PHP scripts need to remain up
  • having a separate, customized PHP script for each and every calculator allowed features specific to each chart / use case; e.g.,
    • preterm growth calculators included calculations of gestational age, postmenstrual age, last menstrual period, due date
    • calculation of age (in the proper units) by entering date of birth and date of measurement
    • inputs could be customized for flexibly handling units; e.g., #-# in a weight field was interpreted as pounds and ounces; ## #/7 was interpreted as weeks and days of gestational age; #" was interpreted as inches. All these were really convenient for front-line use. It might be possible to implement in the future, but in a “Universal” app, it’ll be a major undertaking.
    • calculation of dates of first retinopathy of prematurity exams, when applicable
  • the PHP scripts typically had input fields for ALL anthropometric measures associated with a given growth chart; e.g.,
    • the preterm growth charts had weight, length, and head circumference
    • pediatric charts might have weight and height, from which a BMI could be calculated then analyzed by yet another chart
    • the Shiny apps only calculate for one measure at a time
  • some of the charts use units of measurement that are correct mathematically, but not useful in practice; e.g.,
    • the expanded WHO charts are meant for display precision rather than practical use, with ages from 0 to 1,856 days (~5 years age)
    • this could be manually customized in individual PHP scripts, but probably not a good idea in a Universal app
    • but, a major endeavor could theoretically be undertaken to try to make input more flexible