longitudinal data package to support across packages

[yonicd]

@danielinteractive a new idea was brought up in the last meeting of the brms mmrm group (@wlandau, @chstock and I were in the meeting) .

To create a standalone package for various datasets that would be maintained independently of the groups modeling packages. The packages then would import the package as a dependency.

This would serve two purposes

• reduce size of modeling packages
• create single source of data used across the group that is versioned and documented in a transportable vehicle

What do you think?

[danielinteractive]

Thanks @yonicd , @wlandau , @chstock for the idea - sounds good to me in principle, just wondering whether it is worth it? That is, are the data sets that large, and is versioning the data sets relevant? (so far at least in mmrm each data set is pretty stable, if not unchanged since its creation I think)

[yonicd]

I think it is less about versioning and more about transportability and documentation. It is better to import data than duplicate copies of it and documentation across multiple packages. This opens up the need to manage multiple places that they are consistent language, which will be a headache the more packages the group creates.

I also think the community would use the data package regardless of modeling packages for projects we haven't thought of yet (packages, vignettes, blog posts, seminars), it would be good to be their "data source" for clinical longitudinal data.

[wlandau]

I agree with @yonicd, the datasets we are interested in are quite small, and we have found it is a larger burden to directly depend on the packages that maintain them (e.g. Hmisc has a lot of dependencies of its own). In addition, manually including a dataset in e.g. brms.mmrm is a lot of extra documentation work by the maintainers to make it transparent and clear where the data comes from.

[danielinteractive]

sounds good thanks @yonicd and @wlandau - so yeah then let's go for it!

[yonicd]

@danielinteractive can you create a new repo in openpharma org for the package development. How does {openclindata} or {clindata} sound?

[danielinteractive]

Is that too general?

[yonicd]

is there a specific flavor of clindata we want? lonclindata? I was thinking that this would be a good place to start

https://hbiostat.org/data/

[danielinteractive]

ok let's start with clindata

[wlandau]

This is great work. Closing in brms.mmrm because clindata is now its own package.