How best to store and reference the required growth charts metadata from CDC and WHO in our package?

[rossfarrugia]

e.g. We could store them direct in the package as R datasets or maybe instead offer functions that recreate the metadata as a dataset via tibble (then users would run this first before using as input to their ADaM)?

We would need to make clear in our documentation the versions of the input metadata used so that we could update in future releases if ever these source files evolve in future as happened before with: "2022 CDC Extended BMI-for-Age Growth Charts for Children and Adolescents With Very High BMIs"

[rossfarrugia]

For the referencing point, after email discussion with David I'm thinking best to refer in our package documentation as:
2006 WHO Growth Standards (https://www.who.int/toolkits/child-growth-standards/standards)
2022 CDC Extended BMI-for-age Growth Charts (https://www.cdc.gov/growthcharts/extended-bmi.htm)

For the storage of metafiles I generally prefer recreating in code rather than storing datasets as part of the package, but interested to hear other's views.

[bms63]

I didn't look at the files, but would a separate data package be warranted - this way we could update the data package if changes or additions are needed rather than update admiralpeds

Just thinking about LB stuff and how we have the grading stuff stored in admiral. In the past, a few issues have been spotted in the grading code/files and we have to fix it in admiral and do a re-release for the whole package.

Just musing here...the package is "supposed" to be small so maybe no biggie!!

[rossfarrugia]

Might be overkill i think as David told said these files only changed once in the past 20+ years and he doesn't foresee them changing again.

[bms63]

[CDC-DNPAO]

If people want to use the CSV files I created, I'm fine with that. All I did was combine info from the CDC or WHO reference files.

If anyone wants to re-create the reference files, the reference data for the CDC charts are at
https://www.cdc.gov/growthcharts/percentile_data_files.htm
You'd only need the data in numbers 6 (wt), ht (7), and 8 (BMI). You only need that data for sex, age, L, M, and S. But having some of the calculated percentiles might be a good check on the calculations.
[L M S are the 3 smoothing parameters to transform the data to approximate a normal distribution - they're the L (Box-Cox transformation for normality), M (median), and S (coefficient of variation)

For WHO, the reference data are at
https://www.who.int/toolkits/child-growth-standards/standards
You want to click on 'standards' and then on 'weight-for-age', length/height for age, BMI-for-age, or weight-for-length/height. And you want to look at the 'Expanded Tables' - this gives the L M S values by day of age.

One question with the WHO charts is whether people want to use weight-for-length or BMI-for age for infants. The official CDC guidance is to use weight-for-length, but this will result in some missing data for kids who have a length outside the range in the WHO data. There's a least 1 paper I know of that concludes that BMI-for-age is better, but I think the 2 metrics are very similar.

Both the CDC and WHO reference files are very small. The CDCref_d.csv has 1s and 2s at the end - this is because 20 years ago, I didn't know how to interpolate in SAS. The LMS values in the CDC growth charts are for each month of age, but I wanted to interpolate in case people had more accurate information on age.

[CDC-DNPAO]

Sorry - I should have chimed in on the question about recreating the data files or storing them in the package. While it's true that the reference data won't change, their URL (particularly for WHO) and the names of the files change every few years (when someone tries to fix the poor organization of the WHO or CDC websites). I'm not sure if this would affect 'recreating in code'.

[rossfarrugia]

thanks @CDC-DNPAO - good to know. by recreating in code, here's a basic example extract of what i meant as used for some other vital signs metadata. it would mean that we only need to give in our package 1 CDC and 1 WHO set of metadata for example and not weigh down our repo with R datasets or CSV files, and then any company could substitute these for whatever other version of the metadata they might ever choose to use (as long as they kept to the same structure of the dataset the code creates). Also such a code script is machine readable by GitHub so if we ever change anything it tracks this in the history, whereas for R datasets or CSV files we're unable to track the changes of these via git over time - it just tells us the file changed but not what exactly changed.

  tibble::tribble(
    ~PARAMCD,    ~ANRLO,  ~ANRHI,  ~A1LO, ~A1HI,
    "DIABP",         60,      80,     40,    90,
    "PDIABP",        60,      80,     40,    90,

[CDC-DNPAO]

Thanks - I didn't understand what 'recreating in code' meant. Good idea about the metadata - I could imagine someone would want to substitute data from a different growth chart, but every chart that I know of has the same LMS structure.

And I should clarify one thing/mistake that I said: neither the CDC nor WHO reference data has ever changed. The one thing that changed was a few lines in the R/SAS program for the CDC charts. In 2022, CDC switched to a new method for calculating z-scores/percentiles for very high BMIs. I can't imagine the reference data for either growth chart would ever change.

[ngiangre]

Based on reading the comments above, there seems to be many different datasets that could be used (correct me if there aren't more than a handful). That may warrant deploying datasets as code like Ross said, but also having a function that dispatches datasets based on a convention, like a string, using switch or something similar. The dispatch function should then guarantee a specific dataset format, like the same column names. However, we can preserve the data in built-in datasets while having an easy to use function that dispatches the appropriate dataset based on a convention. This approach gives room for adding in datasets later. Does this make sense?

[rossfarrugia]

It's definitely another possibility Nick. What do you think about the argument for more traceable changes in the git history via creating datasets via code though? With rda or csv we'll only be able to tell the file changed but not exactly what changed. Maybe a moot point if these standards rarely change, but that's been a point that helped guide us this route for other packages I worked on. Plus it avoids larger files clogging our repo and having to look into git LFS.

[ngiangre]

Yes exactly. I agree with traceable changes via code! Using tribble for example, like you mentioned. I think that is the minimum we should consider.

[zdz2101]

Issues #15 and #17 have been created to work on this

[rossfarrugia]

thanks Zelos!