pharmaverse / admiral

ADaM in R Asset Library

pharmaverse website

pharmaverse.org

This website is maintained and governed by the pharmaverse Technology and Templates Working Group. Further details of this WG are available here, and all WG members are shown on our homepage. The WG lead is considered the product owner for the website and has final say on any decisions related to the website.

For any questions or enhancements for the site, please make issues at this repo.

Hosted sites:

This website is available at 2 locations:

• production: pharmaverse.org
• develop branch: openpharma.s3-website.us-east-2.amazonaws.com/develop/

Development / git flow

When you push to develop OR make a pull request onto develop a github action will run which will render the site, and deploy it to the test server. But the test server is different depending on which route you took.

The code on develop is hosted to: http://openpharma.s3-website.us-east-2.amazonaws.com/develop/

The intended workflows expects that develop is the UAT branch where you check things pre-prod. While the 'build from PR` allows you to work on something very experimental and check results, before pushing it do develop.

This git flow is predicated on it being unlikely to have more than one person actively working on the site at any one time.

You cannot work directly on main branch. The only way to push in is via a PR. And it will be denied if you have not come through develop. Any PR requires approval from one other Technology and Templates WG member.

Data flows

'Scraped' data

Passive data is collected via openpharma.github.io, a sister org that is completely un-opinionated and has
a wider remit spanning discovery to access. This site contains no curated data beyond names - and is instead focused on collecting and sharing data on open source health and related metadata (e.g. CRAN status and riskmetric scores).
Information on the data collected is here: https://openpharma.github.io/#data.

Data is stored in a pharmaverse AWS account.

Package info

Curated package info is stored in the folder data/. pharmaverse packages are in the folder data/packages. Non-pharma packages that get a special mention are in data/nonpharma. Each package is a unique .yaml file.

The general structure is:

name: admiral
repo: pharmaverse/admiral
repo_source: github.com
docs: https://pharmaverse.github.io/admiral/cran-release/
hex: https://github.com/insightsengineering/hex-stickers/raw/main/PNG/admiral.png
task: ADaM
details: (ADaM In R Asset Library) - Modular framework to generate ADaM via R functions relying on community contributions
splash: include # this controls what is shown on the main page. Plan is to deprecate and put all hex's up

It should be self explanatory. Please use the categories in the site for task:.

People

Info on people is in data/people. The yaml should be something like below, with the filename being the github handle.

name: James Black
pharmaverse_roles: tech
company: Roche
company_logo: roche.png
# Following is more a nice to have for profile pages [and optional]
linkedin: https://www.linkedin.com/in/epijim/
site: https://epijim.uk
title: People and Product Family Leader for Insights Engineering, Scientific Computing Environment Product Owner
bio: James is currently leading our pan-study codebase for insights

General content of the site

Site content is in content. It's normal markdown files. See markdown-guide.md.

Calling package info in the site

To call a package, we have two shortcuts. pharmaverse means it's 'pharmaverse' - e.g. in the folder data/packages. otherpackages is for non-pharmaverse packages, in data/nonpharma.

{{< pharmaverse pkg="rtables" >}}

{{< otherpackages pkg="gt" >}}

Council meeting minutes

From 2023 onwards, our monthly council meeting minutes will be published in static/council meeting minutes. Other static files such as images are stored in static also.

admiral's Issues

Set up the ADaM package vignettes (?h)

Definition of done

Set up the initial vignettes based on documents/guidance already prepared and mature enough.

decide on how to structure function in files

Should we use one file per function or several functions per file?

create groups of analysis concepts based on the DAP M3 analysis concepts (3h)

• group same concepts together
• create a separate list of the remaining groups
  goal: a group of analysis concepts should apply to a function that could be used to create multiple variable (e.g. duration, study day)

prepare for workshop with GSK (1h)

Goal: prepare a set of questions/topics we want to have in the workshop with GSK

Setup lintr (2h)

Code checking.

describe a programming workflow for ADRS (6h)

goal: describe a first draft functional workflow for ADRS similar to ADVS

2h meeting
1h review
1h finalize in a flow chart

the workflow should address:

functionality
order of variables

program function to derive PARAM and PARAMCD

Program a function called derive_param() that takes dataset and mapping as input. mapping should be a metadata dataset looking like this (example for ADVS):

VSTESTCD VSPOS    PARAM                              PARAMCD
SYSBP    SITTING  Systolic Blood Pressure (Sitting)  SYSBPS

prepare for workshop with GSK (1h)

Goal: prepare a set of questions/topics we want to have in the workshop with GSK

document decisions from Q&A/review of functions (2h)

Link to the gDoc with Q&A

• update programming strategy presentation
• update readable code document
• create new guidance if necessary
• review and approve

create groups of analysis concepts based on the DAP M3 analysis concepts (3h)

• group same concepts together
• create a separate list of the remaining groups
  goal: a group of analysis concepts should apply to a function that could be used to create multiple variable (e.g. duration, study day)

Create Draft Guidance for git usage

Definition of Done:

• Draft guidance available in gDrive as gDoc
• Team review completed

Suggestions:
Name feature branches , e.g., 12_normal_ranges
Prefix commit messages with the issue number, e.g., “#12: implement ANRIND derivation”
Delete branches after they have been merged
Questions:
How should we handle dependencies between GitHub issues?
Do we need other branches than master and the feature branches?
Solution:
Create a GitHub workflow/best practices document
Name feature branches , e.g., 12_normal_ranges
Delete branches after they have been merged
Try to avoid merging feature branches one with another
Prefix commit messages with the issue number, e.g., “#12: implement ANRIND derivation”

derive_date v0.1

create accounts on public GitHub

If you don't have an account on github.com, yet, please create one. Once done, please paste your user name in the comments below so I can add you to the repo.

• @koegerr
• @dunieck
• @KABIS
• @bundfuss
• @millerg1

Setup lintr (2h)

Code checking.

Create Project Board

Definition of Done:

• [ ]

automate R package check when creating a PR

This is for the public GitHub automation.

automate R package check when creating a PR

This is for the public GitHub automation.

describe a functional workflow for ADaM-ADSL Dataset (2h)

describe a programming structure how the user would build his/her own ADSL dataset with particular emphasis on components and their functionality.

Store the document here (also see ADVS example): https://exbpbox.ent.box.com/folder/135158344442?s=wbsc3rkhbyxdvuua1csh4sez5n6nwl7n

propose how to organize the team (10h)

Goal:
come up with a team structure to keep us Agile and aligned across a larger and growing team and across companies taking into account the next project phases.

Definition of done:

• draft proposal
• team review and feedback
• adjust tools/meetings/backlog

Proposal: https://exbpbox.box.com/s/60x2ahhbyt7jn05kiqaptir58ddgzril

program functions to derive TRTSDTM and TRTEDTM (1d)

document decisions from Q&A/review of functions (2h)

Link to the gDoc with Q&A

• update programming strategy presentation
• update readable code document
• create new guidance if necessary
• review and approve

program function to derive date imputation flags (3h)

create a function with clear in/output to derive variable including Unit Test (basic functionality)

• potentially can be combined with function to impute dates (#43

break down QS metadata approach (1h)

• decide how to explore the metadata use for ADaM and create multiple issues on it

derive_date v0.1

describe a concept adding new Metadata as a user for non-standard Parameter in a BDS Domain (8h)

work out a concept how to create new metadata to a BDS domain (parameter, spec, label ...) within a modular approach

investigate how to get a backtrace on warnings

describe a programming workflow for ADEX (3h)

goal: describe a first draft functional workflow for ADEX similar to ADVS together with Shimeng

1h meeting
1h review
1h finalize in a flow chart

the workflow should address:

• functionality
• order of variables

Set up the ADaM package vignettes (?h)

Definition of done

Set up the initial vignettes based on documents/guidance already prepared and mature enough.

program function to derive PARAM and PARAMCD

Program a function called derive_param() that takes dataset and mapping as input. mapping should be a metadata dataset looking like this (example for ADVS):

VSTESTCD VSPOS    PARAM                              PARAMCD
SYSBP    SITTING  Systolic Blood Pressure (Sitting)  SYSBPS

describe the level hierarchy/categories of functions based on ADaM (2h)

Team: @koegerr @SuhasKiraniRavindra

• create a first draft chart that shows functional levels/categories around an ADaM framework

program function to impute dates and add imputation flags (4h)

create a function with clear in/output to derive variable including Unit Test (basic functionality)

decide on how to structure function in files

Should we use one file per function or several functions per file?

92: program functions to derive TRTSDTM and TRTEDTM

describe a programming workflow for ADRS (4h)

goal: describe a first draft functional workflow for ADRS similar to ADVS

2h meeting
1h review
1h finalize in a flow chart

the workflow should address:

functionality
order of variables

describe a programming workflow for ADEX (3h)

goal: describe a first draft functional workflow for ADEX similar to ADVS together with Shimeng

FDA draft: https://www.fda.gov/media/133252/download

1h meeting
1h review
1h finalize in a flow chart

the workflow should address:

• functionality
• order of variables

develop a final template for the header (1h))

update current template in all functions and wiki accordingly

Related to:

Issue/Question: How do we document properties of parameters, e.g., default value, permitted values?

Properties:

• default value
• permitted values
• permitted type
• Optionality

propose how to scale up the Scrum team (2h)

Goal:
come up with a meeting, sub-chats and work assignment structure to keep us Agile and aligned across a larger and growing team and across companies.

Definition of done:

• draft proposal
• team review and feedback
• share with GSK/ Suhas and obtain feedback
• adjust tools/meetings/backlog

prepare for Demo#2 (2h)

List link, also see issue #73 as a potential starting point for a list of functions.

Proposal for the demo:
https://exbpbox.ent.box.com/integrations/googledss/openGoogleEditor?fileId=799429916611&trackingId=3#slide=id.p2

goal: demo to users, management

program functions to derive TRTSDTM and TRTEDTM (1d)

Setup CI pipeline for package (4h)

Setup a continuous integration to run R CMD check whenever a pull request is opened.

Create Draft Guidance for git usage

Definition of Done:

• Draft guidance available in gDrive as gDoc
• Team review completed

Suggestions:
Name feature branches , e.g., 12_normal_ranges
Prefix commit messages with the issue number, e.g., “#12: implement ANRIND derivation”
Delete branches after they have been merged
Questions:
How should we handle dependencies between GitHub issues?
Do we need other branches than master and the feature branches?
Solution:
Create a GitHub workflow/best practices document
Name feature branches , e.g., 12_normal_ranges
Delete branches after they have been merged
Try to avoid merging feature branches one with another
Prefix commit messages with the issue number, e.g., “#12: implement ANRIND derivation”

prepare for Demo#2 (2h)

List link, also see issue #73 as a potential starting point for a list of functions.

• plan: meeting, timeline, stakeholders
• list of functions + documentation
• description of the overall concept
• programming instruction/template/skeleton for the ADVS program
• demonstrate how to create ADVS vs have users create their ADVS (tbd)

goal: demo the concept and first functions and have a team use it on a molecule by early/mid April (Pentraxin)

create a ADVS flowchart that visualizes the programming workflow (1h)

visualize the programming flow via lucid chart and highlight the required functionality based on:
https://docs.google.com/document/d/1lyiE67mlrAY5yA_nz-_y5qZCrIaby88SHFjV4EGF2W8/edit?usp=sharing

create a ADVS flowchart that visualizes the programming workflow (1h)

visualize the programming flow via lucid chart and highlight the required functionality based on:
https://docs.google.com/document/d/1lyiE67mlrAY5yA_nz-_y5qZCrIaby88SHFjV4EGF2W8/edit?usp=sharing

find a way how to measure the use of standard R functions (2h)

• define success and how define a way to measure the use of standard functions

program a prototype how to read in Metadata of an existing standard and write it to a study/molecule DAPM3 (8h)

program a first prototype of reading in standard Metadata, derive the standard variable, write the metadata to a study/molecule DAPM3.

investigate how to get a backtrace on warnings

Program functions to derive TRTSDTM and TRTEDTM

Setup CI pipeline for package (4h)

Setup a continuous integration to run R CMD check whenever a pull request is opened.

create accounts on public GitHub

If you don't have an account on github.com, yet, please create one. Once done, please paste your user name in the comments below so I can add you to the repo.

• @koegerr
• @dunieck
• @KABIS
• @bundfuss
• @millerg1