Movatterモバイル変換

admiral

ADaM in R Asset Library

Purpose

To provide an open source, modularized toolbox that enables thepharmaceutical programming community to develop ADaM datasets in R.

Installation

The package is available from CRAN and can be installed with:

install.packages("admiral")

To install the development version of the package from GitHubrun:

pak::pkg_install("pharmaverse/admiral",dependencies =TRUE)

Cheat Sheet

Release Schedule

The{admiral} family has several downstream and upstreamdependencies and so releases are done in two Phases:

• Phase 1 release is for{admiraldev},{pharmaversesdtm},and{admiral}core
• Phase 2 release is extension packages, e.g. {admiralonco},{admiralophtha},{admiralvaccine}and{pharmaverseadam}.

NB: We strive for a regular 6 month release schedulefor{admiraldev},{pharmaversesdtm},and{admiral}.Extension packages releases are on a content-basis and as such may bemore infrequent than the below schedule shows.

NB: We strive for a regular 6 month releaseschedule.

Main Goal

Provide users with an open source, modularized toolbox with which tocreate ADaM datasets in R.As opposed to a “run 1 line and an ADaMappears” black-box solution or an attempt to automate ADaM.

One of the key aspects of{admiral} is its developmentby the users for the users. It gives an entry point for all tocollaborate, co-create and contribute to a harmonized approach ofdeveloping ADaMs in R across the pharmaceutical industry.

Scope

To set expectations: It is not our target that{admiral}will ever provide all possible solutions for all ADaM datasets outsideof study specific needs. It depends on the user’s collaboration andcontribution 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 coverageof 100% of all ADaM derivations as ever achievable—ADaM is endless.

We will provide:

• A toolbox of re-usable functions and utilities to create ADaMdatasets using R scripts in a modular manner (an “opinionated” designstrategy).
• Pharmaceutical communities and companies are encouraged tocontribute to{admiral} following the provided programmingstrategy and modular approach
• Functions that are comprehensively documented and tested, includingexample calls—these are all listed in theReferencesection.
• Vignettes on how to create ADSL, BDS and OCCDS datasets, includingexample scripts.
• Vignettes for ADaM dataset specific functionality (i.e. dictionarycoding, date imputation, SMQs …).

The {admiral} Family ofPackages

There are three types of packages in the{admiral}family:

• Core package—one package containing all core functions required tocreate ADaMs, usable by any company (i.e. general derivations, utilityfunctions and checks for ADSL, OCCDS and BDS).
• TA (Therapeutic Area) package extensions—one package per TA withfunctions that are specific to algorithms and requirements for thatparticular TA (e.g. {admiralonco}).
• Company package extensions—specific needs and plug-ins for thecompany, such as access to metadata (e.g. {admiralroche} or{admiralgsk}).

Related Packages

Related data packages include:

• {pharmaversesdtm}—thiscontains test SDTM data sourced from theCDISC pilotproject or constructed ad-hoc by the{admiral} team.This is a prerequisite package for{admiral}.
• {pharmaverseadam}—thiscontains test ADaM data automatically generated by running the ADaM{admiral} and TA package extensions templates on the{pharmaversesdtm}data.

Both these packages are developed by the{admiral} team,but can used across the pharmaverse as common, open-source test SDTM orADaM data.

The following packages are also useful when working with ADaMdatasets:

• {metacore}and{metatools}—theseenable users to manipulate and work with dataset metadata.
• {xportr}—thisprovides functionality to get xpt files ready for transport.

Admiral Manifesto

For{admiral} and all extension packages, we prioritizeproviding our users with asimple to adopt toolkit thatenables them to producereadable andeasilyconstructible ADaM programs. The following explains ourphilosophy, which we try to adhere to across the{admiral}family of packages. There isn’t always a clear single, straightforwardrule, but there are guiding principles we adhere to for{admiral}. This manifesto helps show the considerations ofour developers when making decisions.

We have four design principles to achieve the main goal:

Usability

All{admiral} functions should be easy to use.

• Documentation is an absolute priority. Each function reference pageshould cover the purpose, descriptions of each argument with permittedvalues, the expected input and output, with clear real-life examples—sothat users don’t need to dig through code to find answers.
• Vignettes that complement the functional documentation to help userssee how best the functions can be applied to achieve ADaMrequirements.
• Functions should be written and structured in a way that users areable to read, re-use or extend them for study specific purposes ifneeded (see Readability below).

Simplicity

All{admiral} functions have a clear purpose.

• We try not to ever design single functions that could achievenumerous very different derivations. For example if you as a user pickup a function with >10 different arguments then chances are it isgoing to be difficult to understand if this function could be appliedfor your specific need. The intention is that arguments/parameters caninfluence how the output of a function is calculated, but not change thepurpose of the function.

• We try to combine similar tasks and algorithms into one functionwhere applicable to reduce the amount of repetitive functions withsimilar algorithms and to group together similar functionality toincrease usability (e.g. one study day calculation rather than afunction per variable).

• We strive to design functions that are not too general and tryingto fulfill multiple, complex purposes.

• Functions should not allow expressions as arguments that are usedas code snippets in function calls.

• We recommend to avoid copy and paste of complex computationalalgorithms or repetitive code like checks and advise to wrap them into afunction. However we would also like to avoid multi-layered functionalnesting, so this needs to be considered carefully to keep the nesting of3-4 functions an exception rather than the rule.

Findability

All{admiral} functions are easily findable.

• In a growing code base, across a family of packages, we make everyeffort to make our functions easily findable.
• We use consistent naming conventions across all our functions, andprovide vignettes and ADaM templates that help users to get started andbuild familiarity. Each{admiral} family package website issearchable.
• We avoid repetitive functions that will do similar tasks (asexplained above with study day example).
• Each package extension is kept focused on the specific scope,e.g. features that are relevant across multiple extension packages willbe moved to the core{admiral} package.

Readability

All{admiral} functions follow theProgrammingStrategy that all our developers and contributors must follow, sothat all our code has a high degree of consistency and readability.

• We encourage use of tidyverse (e.g. dplyr) over similarfunctionality existing in base R.
• For sections of code that perform the actual derivations(e.g. besides assertions or basic utilities), we try to limit nesting oftoo many dependencies or functions.
• Modularity is a focus—we don’t try to achieve too many steps inone.
• All code has to be well commented.
• We recognize that a user or a Health Authority reviewer may have thewish to delve into the code base (especially given this open sourcesetting), or users may need to extend/adapt the code for their studyspecific needs. We therefore want any module to be understandable toall, not only the{admiral} developers.

References and Documentation

• Please go toGetStarted section to start using{admiral}.
• Please see thepharmaverseYouTube channel for videos related to{admiral}.
• Please see theProgrammingStrategy to understand how functions are created.
• Please see theFAQfor the most frequent questions.
• Please see theContributionModel for how to get involved with making contributions.
• Please seeFAQ:R and Package Versions for why we develop with certain R and packageversions.

Pharmaverse Blog

If you are interested in R and Clinical Reporting, then visit thepharmaverse blog. Thiscontains regular, bite-sized posts showcasing how{admiral}and other packages in the pharmaverse can be used to realize the visionof full end-to-end Clinical Reporting in R.

We are also always looking for keen{admiral} users topublish their own blog posts about how they use the package. If thiscould be you, feel free make an issue in theGitHub repo and getstarted!

Recent ConferencePresentations

For a full collection of{admiral} conferencepresentations over the years, please travel to ourPresentationArchive.

Contact

We use the following for support and communications between user anddeveloper community:

• Slack—for informaldiscussions, Q&A and building our user community. If you don’t haveaccess, use thislinkto join the pharmaverse Slack workspace.
• GitHubIssues—for direct feedback, enhancement requests or raisingbugs.

Acknowledgments

Along with the authors and contributors, thanks to the followingpeople for their work on the package:

Jaxon Abercrombie, Mahdi About, Teckla Akinyi, Anthony Arroyo, AlexAssuied, James Black, Claudia Carlucci, Asha Chakma, Liming Clark, BillDenney, Kamila Duniec, Alice Ehmann, Romain Francois, Ania Golab, AlanaHarris, Declan Hodges, Anthony Howard, Shimeng Huang, Samia Kabi, JamesKim, John Kirkpatrick, Leena Khatri, Robin Koeger, KonstantinaKoukourikou, Pavan Kumar, Pooja Kumari, Shan Lee, Wenyi Liu, SadchlaMascary, Iain McCay, Jack McGavigan, Jordanna Morrish, Syed Mubasheer,Kirill Muller, Thomas Neitmann, Yohann Omnes, Barbara O’Reilly, LinaPatil, Celine Piraux, Hamza Rahal, Nick Ramirez, Tom Ratford, SukalpoSaha, Tamara Senior, Eric Simms, Sophie Shapcott, Vladyslav Shuliar,Ondrej Slama, Andrew Smith, Daniil Stefonishin, Steven Ting, VigneshThanikachalam, Michael Thorpe, Annie Yang, Ojesh Upadhyay, FranciszekWalkowiak, Enki Wang, Phillip Webster, Andrii Yurovskyi, Kangjie Zhangand Zelos Zhu.