3.3.4.1 Analysis Parameter Variables

[bms63]

@cpiraux - it might be easier to make this into a discussion so we talk about each section without loosing track

[cpiraux]

I reviewed the variables from Table 3.3.4.1.1, 'Analysis Parameter Variables for BDS Datasets'. My findings mainly involve adding precision and details, which can be included if you think it is useful.

BCHG, PBCHG,

The following functions are used to derive CHG and PCHG: derive_var_chg, derive_var_pchg. In the ADaM IG, there are also variables for "change to" rather than "change from": BCHG and PBCHG. Should we also consider adding "change to baseline" in these functions?

[bms63]

Shall we consider allowing "change to" - currently only one direction. Discussed in the IG!!!!

[cpiraux]

AVALCATy, CRIT and MCRIT

It is not always clear to users when to use the AVALCATy or (M)CRIT variables, so we could provide some guidance. There are also rules and examples for the CRIT variables to clarify when to use CRIT or when a new parameter should be created in ADaM IG.

[bms63]

@cpiraux check out https://pharmaverse.github.io/admiral/dev/news/index.html

[cpiraux]

1. These functions are a great addition and will be very useful 👏. Having a function for CRITy(FL) will ensure that the Y/N/null rules are implemented as expected in the ADaM IG. Previously, the derivation of Y/null for CRITyFL was implemented incorrectly in the Hy’s Law user guide, but it is now derived correctly.

2. In the derive_vars_cat vignette, there is now an example for MCRITy. So we now find a result for MCRITy when searching in the search bar .

3. I still believe it could be beneficial to explain which variable to use for categorization:

• AVAL: Only AVAL is used for categorization, and the categories are mutually exclusive.
• MCRITy(FL): Any variable can be used for categorization with values belonging to the same records; the categories are mutually exclusive.
• CRITyFL: Any variable can be used for categorization with values belonging to the same records. If the categorization is not mutually exclusive, then multiple CRITyFL variables can be created to cover all categories.

[cpiraux]

BASETYPE

derive_basetype_records Vignette: In the description, it states that BASETYPE must be non-null on all records of any type for that parameter. In the ADaM IG, it must be non-null for all records for that PARAM within that dataset where either BASE or BASEC are also non-null. I propose adding “either BASE or BASEC are also non-null” because BASETYPE can be null for screening records when only BASE is derived for post-baseline records.

[bms63]

@cpiraux please make as a documentation update in admiral - https://github.com/pharmaverse/admiral

[cpiraux]

BASETYPE

It is clearly stated in the section on Creating a BDS Finding ADaM:

“It is important to derive BASETYPE first so that it can be utilized in subsequent derivations. This will be important if the data frame contains multiple values for BASETYPE.”

However, in the derive_basetype_records vignette, it is not clear that ABLFL and BASE should be derived after BASETYPE.

I think the derivation of the basetype would be clearer if ABLFL and BASE were included in the example of the derive_basetype_records vignette. However, since BASE and ABLFL are derived after the basetype, this might cause some confusion. What do you think?

[bms63]

@cpiraux can you also add to issue for basetype as a sub-task

[cpiraux]

derive_var_base: vignette

The example contains “N” for ABLFL, but ABLFL should only contain “Y” and null values. Therefore, I suggest updating the example in the vignette to include only “Y” and null values for ABLFL.

[bms63]

ooohhh this is a super good catch! @cpiraux !! can you make this into an issue for admiral please?

[cpiraux]

PARCATy

A common error when creating PARCAT is that a parameter can only belong to one parameter category. While there is a validation rule in P21, it is sometimes overlooked. Therefore, I think it would be potentially helpful to mention this in the documentation where the PARCAT derivation is explained (for both BDS findings and BDS exposure).

The current documentation correctly handles the derivation, and I feel that the lookup table or PARCAT derivation in BDS exposure already guides users in the right direction, so including this mention could be optional.

[bms63]

@bms63 to add this as an issue

[cpiraux]

Derive Analysis Ratio (R2BASE)

I think it’s important to specify that R01ANRLO is a user-defined variable and that by default, it should be R2ANRLO (it is clearly explained in the vignette). However, the user guide gives the impression that the default approach is to create a new variable name. User-defined variables can be used, but it is not recommended, as non-ADaM IG variables do not have P21 validation rules.

[bms63]

Perhaps a comment on this being a custom variable and not a standard variable. @bms63

[cpiraux]

R2AyHI/R2AyLO

No results were found when searching for R2AyHI, but it can be derived using the derive_var_analysis_ratio method. function

[bms63]

I think this is a great documentation update for us!! Can you make an issue in admiral please!!

[bms63]

@cpiraux please flood admiral!!

[cpiraux]

Derive Shift (e.g. SHIFT1)

There is no output dataframe provided in the user guide for Derive Shift (e.g., SHIFT1). It would be helpful to include the dataframe to visualize the output of the derivation.

[bms63]

can you make this recommendation in admiral issues! Be great first issue!!

[bms63]

@cpiraux please make another one!!!!