Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

#283_adsl_vignette_tag #286

Merged
merged 5 commits into from
Jul 1, 2021
Merged

#283_adsl_vignette_tag #286

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
7f8c0e1
#283_adsl_vignette_tag
slamao Jun 30, 2021
050faae
#283_adsl_vignette_tag, headings
slamao Jun 30, 2021
7757973
283 adsl vignette tags
kabis-ops Jul 1, 2021
8aa9d3e
283 adsl vignette tags
kabis-ops Jul 1, 2021
fc54e57
283 adsl vignette tags
kabis-ops Jul 1, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
67 changes: 32 additions & 35 deletions vignettes/adsl.Rmd
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ knitr::opts_chunk$set(
)
```

## Introduction
# Introduction

This article describes creating an ADSL ADaM. Examples are currently
presented and tested using `dm`, `ex` , `ae`, `lb` and `ds` SDTM domains. However, other domains
Expand All @@ -27,27 +27,27 @@ could be used.
**Note:** *All examples assume CDISC SDTM and/or ADaM format as input unless
otherwise specified.*

## Programming Flow
# Programming Flow

* [Read in Data](#readdata)
* [Derive Treatment Variables (TRT0xP, TRT0xA)](#treatmentvar)
* [Derive/Impute Numeric Treatment Date/Time and Duration (TRTSDT, TRTEDT, TRTDURD)](#trtdatetime)
* [Derive Treatment Variables (`TRT0xP`, `TRT0xA`)](#treatmentvar)
* [Derive/Impute Numeric Treatment Date/Time and Duration (`TRTSDT`, `TRTEDT`, `TRTDURD`)](#trtdatetime)
* [Derive Disposition Variables](#disposition)
* [Disposition Dates](#disposition1)
* [Disposition Status](#disposition2)
* [Disposition Reason(s)](#disposition3)
* [Derive Death Variables (DTH, DTHADY, LLDTHELD, DTHCAUS )](#death0)
* [Death Date](#death1)
* [Duration Relative to Death](#death2)
* [Cause of Death](#death3)
* [Derive Last Known Date Alive (LSTALVDT)](#lstalvdt)
* [Disposition Dates (e.g. `EOSDT`)](#disposition_date)
* [Disposition Status (e.g. `EOSTT`)](#disposition_status)
* [Disposition Reason(s) (e.g. `DCSREAS`, `DCSREASP`)](#disposition_reason)
* [Derive Death Variables](#death)
* [Death Date (`DTHDT`)](#death_date)
* [Cause of Death (`DTHCAUS`)](#death_cause)
* [Duration Relative to Death](#death_other)
* [Derive Last Known Date Alive (`LSTALVDT`)](#lstalvdt)
* [Derive Groupings and Populations](#groupings)
* [Grouping](#groupings1)
* [Population Flags](#popfalg)
* [Grouping (e.g. `AGEGR1`)](#groupings_ex)
* [Population Flags (e.g. `SAFFL`)](#popfalg)
bundfussr marked this conversation as resolved.
Show resolved Hide resolved
* [Other Variables Required for Analysis](#other)
* [Example Script](#example)

### Read in Data {#readdata}
## Read in Data {#readdata}

To start, all data frames needed for the creation of ADSL should be read into
the environment. This will be a company specific process. Some of the
Expand Down Expand Up @@ -75,7 +75,7 @@ adsl <- dm
head(adsl)
```

### Derive Treatment Variables (`TRT0xP`, `TRT0xA`) {#treatmentvar}
## Derive Treatment Variables (`TRT0xP`, `TRT0xA`) {#treatmentvar}

The mapping of the treatment variables is left to the ADaM programmer. An example mapping may be:

Expand All @@ -84,7 +84,7 @@ adsl <- dm %>%
mutate(TRT01P = ARM, TRT01A = ACTARM)
```

### Derive/Impute Numeric Treatment Date/Time and Duration (`TRTSDTM`, `TRTEDTM`, `TRTDURD`) {#trtdatetime}
## Derive/Impute Numeric Treatment Date/Time and Duration (`TRTSDTM`, `TRTEDTM`, `TRTDURD`) {#trtdatetime}

The functions `derive_var_trtsdtm()`, `derive_var_trtedtm()` can be used to derive the treatment
start and end date/times using the `ex` domain.
Expand Down Expand Up @@ -120,9 +120,9 @@ head(adsl %>% select(USUBJID, starts_with("TRT"), -starts_with("TRT0")))
```


### Derive Disposition Variables {#disposition}
## Derive Disposition Variables {#disposition}

#### Disposition Dates {#disposition1}
### Disposition Dates (e.g. `EOSDT`) {#disposition_date}

The function `derive_disposition_dt()` can be used to derive a disposition date.
The relevant disposition date (`ds.DSSTDTC`) is selected by adjusting the filter parameter.
Expand All @@ -145,7 +145,7 @@ This call would return the input dataset with the column `EOSDT` added.
This function allows the user to impute partial dates as well. If imputation is needed and the date
is to be imputed to the first of the month, then set `date_imputation = "FIRST"`.

#### Disposition Status {#disposition2}
### Disposition Status (e.g. `EOSTT`) {#disposition_status}

The function `derive_disposition_status()` can be used to derive a disposition status at a specific
timepoint. The relevant disposition variable (`ds.DSDECOD`) is selected by adjusting the filter
Expand Down Expand Up @@ -205,7 +205,7 @@ adsl <- adsl %>%

This call would return the input dataset with the column `EOSSTT` added.

#### Disposition Reason(s) {#disposition3}
### Disposition Reason(s) (e.g. `DCSREAS`, `DCSREASP`) {#disposition_reason}

The main reason for discontinuation is usually stored in `DSDECOD` while `DSTERM` provides
additional details regarding subject’s discontinuation (e.g., description of `"OTHER"`).
Expand Down Expand Up @@ -269,9 +269,9 @@ adsl <- adsl %>%
)
```

### Derive Death Variables (`DTHDT`, `DTHADY`, `LLDTHELD`, `DTHCAUS`) {#death0}
## Derive Death Variables {#death}

#### Death Date {#death1}
### Death Date (`DTHDT`) {#death_date}

The function `derive_vars_dt()` can be used to derive `DTHDT`. This function allows
the user to impute the date as well.
Expand Down Expand Up @@ -304,10 +304,7 @@ adsl <- adsl %>%
)
```

### Derive Death Variables (`DTHDT`, `DTHADY`, `LLDTHELD`, `DTHCAUS`) {#death}


### Cause of Death {#death2}
### Cause of Death (`DTHCAUS`) {#death_cause}

The cause of death `DTHCAUS` can be derived using the function `derive_var_dthcaus()`.

Expand Down Expand Up @@ -387,7 +384,7 @@ adsl <- adsl %>%
adsl %>% select(USUBJID, starts_with("DTH")) %>% filter(DTHFL == "Y")
```

#### Duration Relative to Death {#death3}
### Duration Relative to Death {#death_other}

The function `derive_duration()` can be used to derive duration relative to death like the Relative
Day of Death (`DTHADY`) or the numbers of days from last dose to death (`LDDTHELD`).
Expand Down Expand Up @@ -417,7 +414,7 @@ adsl <- adsl %>%
adsl %>% select(USUBJID, starts_with("DTH"), LDDTHELD) %>% filter(DTHFL == "Y")
```

### Derive the Last Date Known Alive (`LSTALVDT`) {#lstalvdt}
## Derive the Last Date Known Alive (`LSTALVDT`) {#lstalvdt}

Similarly as for the cause of death (`DTHCAUS`), the last known alive date (`LSTALVDT`) can be
derived from multiples sources and the user must ensure the sources (`lstalvdt_source`) are
Expand Down Expand Up @@ -501,9 +498,9 @@ head(adsl %>% select(USUBJID, TRTEDT, EOSDT, LSTALVDT, starts_with("LAL")))
```


### Derive Groupings and Populations {#groupings}
## Derive Groupings and Populations {#groupings}

#### Grouping {#groupings1}
### Grouping (e.g. `AGEGR1`) {#groupings_ex}

Numeric and categorical variables (`AGE`, `RACE`, `COUNTRY`, etc.) may need to be grouped to perform
the required analysis.
Expand Down Expand Up @@ -548,7 +545,7 @@ adsl <- adsl %>%
head(adsl %>% select(USUBJID, AGE, SEX, COUNTRY, AGEGR1, REGION1))
```

#### Population Flags {#popflag}
### Population Flags (e.g. `SAFFL`) {#popflag}

Since the populations flags are mainly company/study specific and that it can easily be derived
using an `if_else()` statement, admiral did not implement a functionality to assist with
Expand All @@ -565,13 +562,13 @@ head(adsl %>% select(USUBJID, TRTSDT, SAFFL))
```


#### Derive Other Variables {#other}
## Derive Other Variables {#other}
The users can add specific code to cover their need for the analysis.

### Add Labels and Attributes {#attributes}
## Add Labels and Attributes {#attributes}
admiral does not **currently** support metadata integration, but the team is working on it!

### Example Script {#example}
## Example Script {#example}
ADaM | Sample Code
---- | --------------
ADSL | [ad_adsl.R](https://github.com/Roche-GSK/admiral/blob/master/inst/example_scripts/ad_adsl.R){target="_blank"}
Expand Down
69 changes: 69 additions & 0 deletions vignettes/faq.Rmd
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
---
title: "FAQ"
author: "admiral team"
date: "`r Sys.Date()`"
output:
rmarkdown::html_vignette:
toc: true
toc_depth: 6
vignette: >
%\VignetteIndexEntry{FAQ}
%\VignetteEngine{knitr::rmarkdown}
%\VignetteEncoding{UTF-8}
---

```{r setup, include = FALSE}
knitr::opts_chunk$set(
collapse = TRUE,
comment = "#>"
)
```

##### What does **generalized functions & facilitate** mean?

* Functions are usually not necessarily specific but parameter driven:
* e.g. the `derive_aage` has a parameterized start and end-date and a unit.
* Depending on the parameters results may vary as does the specification.

##### How does a user **know what a function does** exactly?

* Function details and its purpose, the requirements, parameters, dependencies and examples are documented in the header of each function.
* Complex functions potentially have an own vignette (wiki page) on the admiral homepage (date imputation).
* admiral does not provide a link to an explicit specification in the define.xml.

##### Would admiral **create a whole** ADaM dataset?

* No, users will use the functions from the admiral package to create their ADaM dataset.

##### In **which order** does a user need to execute the functions?

* Guidance will be provided for ADSL, BDS and OCCDS ADaM structure including template scripts.

##### Is the admiral package **validated**?

* All functions are reviewed and tested to ensure that they work as described in the documentation.
* Test cases for each function will be part of the R package.
* The testing the admiral team will do for each functions does **not to replace the QC and validation process at each company**.
* Users can add to the tests or provide additional feedback.

##### Will **admiral provide harmonized define.xml** or submittable specifications for functions?

* No. The functions are documented via programming headers, the define.xml is the responsibility of the end user.
* Functions are usually generalized and not specific. (see [What does **generalized functions & facilitate** mean?])

##### Will admiral provide ADaM IG **CDISC compliant** datasets?

* Although admiral follows CDISC standards it does not claim that the dataset resulting from calling admiral functions is ADaM compliant. This has to be ensured by the user.

##### How much of the **ADaM IG is covered by admiral? Proposal**:

* ADaM IG is a standard framework without a specific No of datasets or variables, so it cannot be used as a specific baseline to answer that question.
* We will provide guidance for each ADaM dataset structure (ADSL, OCCDS and BDS) that will highlight which functionality admiral covers. (see [In **which order** does a user need to execute the functions?])
* The guidance will also highlight the gaps to be filled by the user (e.g. timing, ranges).
* For standard ADaM datasets (ADAE, ADCM ...) we can provide an estimated coverage.

##### Will there be a user/**contribution** guide?

* All admiral information can be found on the [github webpage](https://roche-gsk.github.io/admiral/articles/admiral.html).
* Our programming strategy serves as a [contribution guide](https://roche-gsk.github.io/admiral/articles/contributing.html).
* How users can contribute technically is TBD.