ADaM in R Asset Library
To provide an open source, modularized toolbox that enables the pharmaceutical programming community to develop ADaM datasets in R.
The package is available from CRAN and can be installed by running
install.packages("admiral")
.
To install the latest development version of the package directly from GitHub use the following code:
if (!requireNamespace("remotes", quietly = TRUE)) {
install.packages("remotes")
}
::install_github("pharmaverse/admiral.test", ref = "devel") # This is a required dependency of {admiral}
remotes::install_github("pharmaverse/admiral", ref = "devel") remotes
{admiral}
releases are targeted for the first Monday of
the last month of each quarter. Pull Requests will be frozen the week
before a release. The admiral
family has several downstream
and upstream dependencies and so this release shall be done in three
Phases:
{admiraldev}
and
{admiral.test}
, which feed into all admiral
packages{admiral}
{admiralonco}
Release Schedule | Phase 1- Date and Packages | Phase 2- Date and Packages | Phase 3- Date and Packages |
---|---|---|---|
Q4-2022 | November 28th | December 5th | December 12th |
{admiraldev} |
{admiral} |
{admiralonco} |
|
{admiral.test} |
|||
Q1-2023 | February 27th | March 6th | March 12th |
{admiraldev} |
{admiral} |
{admiralonco} |
|
{admiral.test} |
Provide users with an open source, modularized toolbox with which to create ADaM datasets in R. As opposed to a ârun 1 line and an ADaM appearsâ black-box solution or an attempt to automate ADaM.
One of the key aspects of {admiral}
is its development
by the users for the users. It gives an entry point for all to
collaborate, co-create and contribute to a harmonized approach of
developing ADaMs in R across the pharmaceutical industry.
To set expectations: It is not our target that {admiral}
will ever provide all possible solutions for all ADaM datasets outside
of study specific needs. It depends on the userâs collaboration and
contribution to help grow over time to an asset library that is robust,
easy to use and has an across-industry focus. We do not see a coverage
of 100% of all ADaM derivations as ever achievableâADaM is endless.
We will provide:
{admiral}
following the provided programming
strategy and modular approachThere will be 3 foreseeable types of {admiral}
packages:
{admiralonco}
){admiralroche}
or
{admiralgsk}
)For {admiral}
and all extension packages, we prioritize
providing our users with a simple to adopt toolkit that
enables them to produce readable and easily
constructible ADaM programs. The following explains our
philosophy, which we try to adhere to across the {admiral}
family of packages. There isnât always a clear single, straightforward
rule, but there are guiding principles we adhere to for
{admiral}
. This manifesto helps show the considerations of
our developers when making decisions.
We have four design principles to achieve the main goal:
All {admiral}
functions should be easy to use.
All {admiral}
functions have a clear purpose.
We try not to ever design single functions that could achieve numerous very different derivations. For example if you as a user pick up a function with >10 different arguments then chances are it is going to be difficult to understand if this function could be applied for your specific need. The intention is that arguments/parameters can influence how the output of a function is calculated, but not change the purpose of the function.
We try to combine similar tasks and algorithms into one function where applicable to reduce the amount of repetitive functions with similar algorithms and to group together similar functionality to increase usability (e.g. one study day calculation rather than a function per variable).
We strive to design functions that are not too general and trying to fulfil multiple, complex purposes.
Functions should not allow expressions as arguments that are used as code snippets in function calls.
We recommend to avoid copy and paste of complex computational algorithms or repetitive code like checks and advise to wrap them into a function. However we would also like to avoid multi-layered functional nesting, so this needs to be considered carefully to keep the nesting of 3-4 functions an exception rather than the rule.
All {admiral}
functions are easily findable.
{admiral}
family package website is
searchable.{admiral}
package.All {admiral}
functions follow the Programming
Strategy that all our developers and contributors must follow, so
that all our code has a high degree of consistency and readability.
{admiral}
developers.{admiral}
{admiral}
.{admiral}
workshop slides from PHUSE EU Connect 2021)We use the following for support and communications between user and developer community: