Closes #2302 New parameter, group_var added #2362

ashachakma · 2024-03-06T12:26:34Z

Thank you for your Pull Request! We have developed this task checklist from the Development Process Guide to help with the final steps of the process. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the admiral codebase remains robust and consistent.

Please check off each taskbox as an acknowledgment that you completed the task or check off that it is not relevant to your Pull Request. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the main branch until you have checked off each task.

github-actions · 2024-03-06T12:30:16Z

Package	Line Rate	Health
admiral	96%	✔
Summary	96% (4859 / 5058)	✔

bms63 · 2024-03-11T20:00:23Z

@kaz462 do you have some time this week to review this update?

bms63 · 2024-03-11T20:01:02Z

R/admiral-package.R

 #' @importFrom stats setNames
+#' @importFrom stats lag


Suggested change

#' @importFrom stats setNames

#' @importFrom stats lag

#' @importFrom stats setNames lag

@ashachakma should we use dplyr::lag instead of stats::lag?

bms63 · 2024-03-11T20:05:15Z

tests/testthat/test-derive_var_trtemfl.R

-## Test 3: considering trt end time ----
-test_that("derive_var_trtemfl Test 3: considering trt end time", {
+## Test 3: with end_window and worsening within grouping variable----
+test_that("derive_var_trtemfl Test 3: with end_window and worsening within grouping variable", {


I feel like more tests should be written - that is a lot of new code under the hood that just has one test backing it up!!

What happens if group_var is specified and some of the other arguments are missing or poorly defined?

Sure Ben, I will add some more tests.

can we add the following data for testing -
currently, there are some differences between expected2 and comp, do you agree with TEAE_expected values from expected2?

expected2 <- tribble( ~USUBJID, ~ASTDTM, ~AENDTM, ~AEITOXGR, ~AETOXGR, ~AEGRPID, ~TEAE_expected, # starting before treatment and ending during treatment "1", "2021-12-30", "2022-01-14", "3", "3", "1", NA, "1", "2022-01-05", "2022-06-01", "3", "1", "1", NA, "1", "2022-01-10", "2022-01-11", "3", "2", "1", "Y", "1", "2022-01-13", "2022-03-01", "3", "1", "1", "Y", "1", "2021-12-30", "2022-01-14", "2", "2", "2", NA, "1", "2022-01-05", "2022-06-01", "2", "1", "2", NA, "1", "2022-01-10", "2022-03-01", "2", "1", "2", NA, ) %>% mutate( ASTDTM = lubridate::ymd(ASTDTM), AENDTM = lubridate::ymd(AENDTM), TRTSDTM = if_else(USUBJID == "1", lubridate::ymd("2022-01-01"), ymd("")), TRTEDTM = if_else(USUBJID == "1", lubridate::ymd("2022-04-30"), ymd("")) ) comp <- derive_var_trtemfl( expected2, new_var = TEAE_derived, trt_end_date = TRTEDTM, end_window = 10, initial_intensity = AEITOXGR, intensity = AETOXGR, group_var = AEGRPID )

comp:

# A tibble: 7 × 10 USUBJID ASTDTM AENDTM AEITOXGR AETOXGR AEGRPID TRTSDTM TRTEDTM TEAE_expected TEAE_derived <chr> <date> <date> <chr> <chr> <chr> <date> <date> <chr> <chr> 1 1 2021-12-30 2022-01-14 3 3 1 2022-01-01 2022-04-30 NA NA 2 1 2022-01-05 2022-06-01 3 1 1 2022-01-01 2022-04-30 NA Y 3 1 2022-01-10 2022-01-11 3 2 1 2022-01-01 2022-04-30 Y Y 4 1 2022-01-13 2022-03-01 3 1 1 2022-01-01 2022-04-30 Y Y 5 1 2021-12-30 2022-01-14 2 2 2 2022-01-01 2022-04-30 NA NA 6 1 2022-01-05 2022-06-01 2 1 2 2022-01-01 2022-04-30 NA Y 7 1 2022-01-10 2022-03-01 2 1 2 2022-01-01 2022-04-30 NA Y

bms63 · 2024-03-14T13:07:44Z

Hi @kaz462 - does this PR's core code meet your expectations for your issue? I think we need some more tests

kaz462

@ashachakma Thanks a lot for implementing the grouping argument!
I left some comments but haven't finished the review, will continue after clarifying the current findings

kaz462 · 2024-03-21T22:28:21Z

R/admiral-package.R

 #' @importFrom stats setNames
+#' @importFrom stats lag


@ashachakma should we use dplyr::lag instead of stats::lag?

kaz462 · 2024-03-21T22:40:14Z

R/derive_var_trtemfl.R

+#'  If the argument is specified, events which start before treatment start and
+#'  end after treatment start (or are ongoing) and worsened (i.e., the
+#'  intensity is greater than the initial intensity), are flagged.


Suggested change

#' If the argument is specified, events which start before treatment start and

#' end after treatment start (or are ongoing) and worsened (i.e., the

#' intensity is greater than the initial intensity), are flagged.

#' If the argument is specified, events which start before treatment start and

#' worsened during treatment are flagged.

should we update "end after treatment start (or are ongoing) and worsened ..." to "worsened during treatment"? this way it includes the period between TRTSDT to TRTEDT+end_window

should we remove or rephrase the following:

" (i.e., the intensity is greater than the initial intensity)"

as shown in the third record below, the intensity is not greater than the initial intensity and it's still flagged

Yeah, I agree with your suggestion. Will update it to "worsened during treatment".

Would be good to rephrase it- " If the argument is specified, events which started during the treatment period irrespective of worsening condition or events which start before treatment start and end after treatment start (or are ongoing) and worsened during treatment (i.e., the intensity is greater than the initial intensity), are flagged." Let me know if you agree with this.

kaz462 · 2024-03-21T22:54:56Z

R/derive_var_trtemfl.R

+        group_by(USUBJID, !!group_var) %>%
+        mutate(worsen_date = case_when(
+          start_date >= trt_start_date &
+            (!!intensity > !is.na(!!initial_intensity)) ~ as_datetime(!!start_date),


Suggested change

(!!intensity > !is.na(!!initial_intensity)) ~ as_datetime(!!start_date),

(!!intensity > lag(!!intensity)) ~ as_datetime(!!start_date),

from #2302 (comment) step 1: compare with the previous record after TRTSDT ordered by ASTDT

lag() gives NA for the first record, so it would miss those where 1st record is a worsened one (tried a random example).

I was considering that AEITOXGR will remain consistent for a group ID, it might be more convenient to compare with AEITOXGR to identify the worsened records. What do you think?

I think we need to clarify the definition of "worsened" - do you think the 3rd and 4th records should be flagged as TEAE in comp from here?

The change of AETOXGR for this episode of AE: 3->1->2->1

The 3rd record has AETOXGR=2, AEITOXGR=3, and its previous record has AETOXGR=1. If we compare it with the previous record, the 3rd record is worsened, but it's improving if we compare it with AEITOXGR.

If we assume AEITOXGR is derived from the first record within each group_var, i.e. the first record has AEITOXGR = AETOXGR, then it's okay to have NA for the first record as no comparison is necessary.

The TEAE_expected values below are just my opinion, please let me know your thoughts. Thanks for delving into this!

# A tibble: 7 × 10 USUBJID ASTDTM AENDTM AEITOXGR AETOXGR AEGRPID TRTSDTM TRTEDTM TEAE_expected TEAE_derived <chr> <date> <date> <chr> <chr> <chr> <date> <date> <chr> <chr> 1 1 2021-12-30 2022-01-14 3 3 1 2022-01-01 2022-04-30 NA NA 2 1 2022-01-05 2022-06-01 3 1 1 2022-01-01 2022-04-30 NA Y 3 1 2022-01-10 2022-01-11 3 2 1 2022-01-01 2022-04-30 Y Y 4 1 2022-01-13 2022-03-01 3 1 1 2022-01-01 2022-04-30 Y Y

Thanks @kaz462 for clarifying my doubts and apologies for the delayed response -

I agree with the 3rd record being flagged as TEAE since its AE severity worsened from 1>2. Comparing it with the previous record makes more sense.

For 4th record, I think it shouldn't be flagged since the severity improved within the trt window (I remember we agreed before, that any record after the worsened record should be flagged as TEAE, but I was referring to this paper again and it mentions how to handle this scenario. Pls refer to scenario 4 and let me know if you agree to this- TEAE: Did I flag it right?

Pls refer to scenario 4 and let me know if you agree to this- TEAE: Did I flag it right?

I agree with not flagging the 2nd record (improved). For the 4th record, this type (worsened then improved) is flagged as TEAE in the study I'm working on, similar to the ASEQ =6 record discussed here. We may need to re-visit this decision:

Once a record within a grouped AE is flagged as a TEAE, then any subsequent record during treatment should also be a TEAE regardless of the severity

Options to consider are:

stay with the current decision

the 4th record shouldn't be flagged as it has improved compared to the previous one

add more flexibility to accommodate the above two scenarios

details to be discussed...

# A tibble: 7 × 10 USUBJID ASTDTM AENDTM AEITOXGR AETOXGR AEGRPID TRTSDTM TRTEDTM <chr> <date> <date> <chr> <chr> <chr> <date> <date> 1 1 2021-12-30 2022-01-14 3 3 1 2022-01-01 2022-04-30 2 1 2022-01-05 2022-06-01 3 1 1 2022-01-01 2022-04-30 3 1 2022-01-10 2022-01-11 3 2 1 2022-01-01 2022-04-30 4 1 2022-01-13 2022-03-01 3 1 1 2022-01-01 2022-04-30

@pharmaverse/admiral I added this topic to the next meeting agenda

At Roche AEITOXGR is the initial grade, i.e., the grade observed when the AE started regardless if it was before or after treatment start. However, this is Roche specific, AEITOXGR is not a CDSIC SDTM variable.

Why do we need AEITOXGR if group_var is specified? We could select the last record before treatment start and all records thereafter. If any worsening (compared to the previous record) occurs, the record is flagged (and all records after that). Did I miss something?

If we combine the following AEs into a single record -

USUBJID AEGRPID ASTDT AENDT AETOXGR TRTSDT TRTEDT <chr> <chr> <date> <date> <chr> <date> <date> 1 1 2 2021-12-30 2022-01-04 2 2022-01-10 2022-04-30 2 1 2 2022-01-05 2022-01-09 3 2022-01-10 2022-04-30 3 1 2 2022-01-10 2022-03-01 3 2022-01-10 2022-04-30

Use the first record before treatment AEITOXGR=2 as the initial intensity , the combined AE below should be flagged as TEAE, same for the 3rd AE above.

USUBJID AEGRPID ASTDT AENDT AEITOXGR AETOXGR TRTSDT TRTEDT TRTEMFL <chr> <chr> <date> <date> <chr> <chr> <date> <date> <chr> 1 1 2 2021-12-30 2022-03-01 2 3 2022-01-10 2022-04-30 Y

Use the last record before treatment AEITOXGR=3 as the initial intensity, the combined AE below shouldn't be flagged as TEAE, same for the 3rd AE above.

USUBJID AEGRPID ASTDT AENDT AEITOXGR AETOXGR TRTSDT TRTEDT TRTEMFL <chr> <chr> <date> <date> <chr> <chr> <date> <date> <chr> 1 1 2 2021-12-30 2022-03-01 3 3 2022-01-10 2022-04-30 NA

The current derive_var_trtemfl determines worsened record by comparing the intensity with initial_intensity. Should initial_intensity/AEITOXGR be interpreted as pre-treatment status in the function, and with the same definition regardless of AE data collection method?
When determining pre-treatment status, should we always use the last record before treatment, or allow flexibility?

Should initial_intensity/AEITOXGR be interpreted as pre-treatment status in the function, and with the same definition regardless of AE data collection method?

I would interpret initial_intensity/AEITOXGR as the grade/intensity when the AE started. I would use it only if a single record per AE is collected. If a separate records is collected for each change in grade/intensity, I would ignore initial_intensity/AEITOXGR and just use intensity/AETOXGR. This seems easier and clearer to me.

When determining pre-treatment status, should we always use the last record before treatment, or allow flexibility?

Using the last record seems reasonable to me. I am not aware of a use case where I would deviate from this. Thus I would not allow flexibility for now.

Determining TEAEs is definitely not as easy as it looks upon first glance. I don't know if it will help, but the PHUSE/CS Working Group on TEAEs published this poster last fall- https://www.lexjansen.com/css-us/2023/POS_PP09.pdf. It contains results of a survey they conducted, with responses from people in a variety of the disciplines involved in clinical trials, and as you can see, there were several scenarios without any sort of general agreement as to whether the AEs in question should be considered as treatment-emergent. Maybe the best thing to do is make sure the situations where there was broad agreement are being handled correctly, and then pick a direction for the rest, but be sure it's documented somewhere how those have been resolved, and allow a way to override the default behavior since there isn't a standard industry approach in those cases.

As discussed in the meeting, we have decided to implement the group_var feature based on option 1 for now.

We can cross-check the functionality with two white papers when they become available, and add features as needed later. @nbrucken17 please keep us posted, thanks :)

https://advance.phuse.global/display/WEL/Treatment+Emergent+Definitions+Recommendations
https://advance.phuse.global/display/WEL/Adverse+Event+Collection+Recommendations

kaz462 · 2024-03-21T23:30:53Z

tests/testthat/test-derive_var_trtemfl.R

-## Test 3: considering trt end time ----
-test_that("derive_var_trtemfl Test 3: considering trt end time", {
+## Test 3: with end_window and worsening within grouping variable----
+test_that("derive_var_trtemfl Test 3: with end_window and worsening within grouping variable", {


can we add the following data for testing -
currently, there are some differences between expected2 and comp, do you agree with TEAE_expected values from expected2?

expected2 <- tribble( ~USUBJID, ~ASTDTM, ~AENDTM, ~AEITOXGR, ~AETOXGR, ~AEGRPID, ~TEAE_expected, # starting before treatment and ending during treatment "1", "2021-12-30", "2022-01-14", "3", "3", "1", NA, "1", "2022-01-05", "2022-06-01", "3", "1", "1", NA, "1", "2022-01-10", "2022-01-11", "3", "2", "1", "Y", "1", "2022-01-13", "2022-03-01", "3", "1", "1", "Y", "1", "2021-12-30", "2022-01-14", "2", "2", "2", NA, "1", "2022-01-05", "2022-06-01", "2", "1", "2", NA, "1", "2022-01-10", "2022-03-01", "2", "1", "2", NA, ) %>% mutate( ASTDTM = lubridate::ymd(ASTDTM), AENDTM = lubridate::ymd(AENDTM), TRTSDTM = if_else(USUBJID == "1", lubridate::ymd("2022-01-01"), ymd("")), TRTEDTM = if_else(USUBJID == "1", lubridate::ymd("2022-04-30"), ymd("")) ) comp <- derive_var_trtemfl( expected2, new_var = TEAE_derived, trt_end_date = TRTEDTM, end_window = 10, initial_intensity = AEITOXGR, intensity = AETOXGR, group_var = AEGRPID )

comp:

# A tibble: 7 × 10 USUBJID ASTDTM AENDTM AEITOXGR AETOXGR AEGRPID TRTSDTM TRTEDTM TEAE_expected TEAE_derived <chr> <date> <date> <chr> <chr> <chr> <date> <date> <chr> <chr> 1 1 2021-12-30 2022-01-14 3 3 1 2022-01-01 2022-04-30 NA NA 2 1 2022-01-05 2022-06-01 3 1 1 2022-01-01 2022-04-30 NA Y 3 1 2022-01-10 2022-01-11 3 2 1 2022-01-01 2022-04-30 Y Y 4 1 2022-01-13 2022-03-01 3 1 1 2022-01-01 2022-04-30 Y Y 5 1 2021-12-30 2022-01-14 2 2 2 2022-01-01 2022-04-30 NA NA 6 1 2022-01-05 2022-06-01 2 1 2 2022-01-01 2022-04-30 NA Y 7 1 2022-01-10 2022-03-01 2 1 2 2022-01-01 2022-04-30 NA Y

nbrucken17 · 2024-04-05T13:28:00Z

For what it's worth, there is some discussion happening right now over how AEs should be collected, and thus how TEAE flagging should work. There are 2 PHUSE WGs developing white papers; the AE Collection Recommendations WG (https://advance.phuse.global/display/WEL/Adverse+Event+Collection+Recommendations) is currently incorporating public review comments, while the TE Definitions Recommendations (https://advance.phuse.global/display/WEL/Treatment+Emergent+Definitions+Recommendations) WG should have their white paper out for public review sometime in the next few months. However, both WGs have found considerable variation across sponsors both in how AEs are collected (single event at max severity, every time severity worsens, every time severity changes, etc.), and how TEs are defined/determined. So there's definitely a need for flexibility in how this function handles various scenarios- or maybe even multiple functions to handle the current variety of approaches.

kaz462 · 2024-04-05T16:51:24Z

For what it's worth, there is some discussion happening right now over how AEs should be collected, and thus how TEAE flagging should work. There are 2 PHUSE WGs developing white papers; the AE Collection Recommendations WG (https://advance.phuse.global/display/WEL/Adverse+Event+Collection+Recommendations) is currently incorporating public review comments, while the TE Definitions Recommendations (https://advance.phuse.global/display/WEL/Treatment+Emergent+Definitions+Recommendations) WG should have their white paper out for public review sometime in the next few months. However, both WGs have found considerable variation across sponsors both in how AEs are collected (single event at max severity, every time severity worsens, every time severity changes, etc.), and how TEs are defined/determined. So there's definitely a need for flexibility in how this function handles various scenarios- or maybe even multiple functions to handle the current variety of approaches.

@nbrucken17 Thanks for your information and connecting the dots here! A summary of different AE collection methods and TEAE scenarios across sponsors would be very helpful. Maybe we can revisit this topic after the white paper is out?

bms63 · 2024-04-05T19:11:38Z

For what it's worth, there is some discussion happening right now over how AEs should be collected, and thus how TEAE flagging should work. There are 2 PHUSE WGs developing white papers; the AE Collection Recommendations WG (https://advance.phuse.global/display/WEL/Adverse+Event+Collection+Recommendations) is currently incorporating public review comments, while the TE Definitions Recommendations (https://advance.phuse.global/display/WEL/Treatment+Emergent+Definitions+Recommendations) WG should have their white paper out for public review sometime in the next few months. However, both WGs have found considerable variation across sponsors both in how AEs are collected (single event at max severity, every time severity worsens, every time severity changes, etc.), and how TEs are defined/determined. So there's definitely a need for flexibility in how this function handles various scenarios- or maybe even multiple functions to handle the current variety of approaches.

@nbrucken17 Thanks for your information and connecting the dots here! A summary of different AE collection methods and TEAE scenarios across sponsors would be very helpful. Maybe we can revisit this topic after the white paper is out?

This is great @nbrucken17 thank you for chiming in. @kaz462 I would still be interested in implementing if it doesn't impact the original functionality - my understanding is that this is the case. However, maybe a separate function(s) could be explored?

bms63 · 2024-04-19T12:47:16Z

Hi @ashachakma - Is Option 1 already implemented?

ashachakma · 2024-04-22T06:51:57Z

Hi @ashachakma - Is Option 1 already implemented?

Hi Ben, I've been holding off on implementing the updates for option 1 until receiving this confirmation. I will work on those updates by this weekend.

github-actions · 2024-05-08T01:55:36Z

This Pull Request is stale because it has not been worked on in 15 days.

bms63 · 2024-05-08T13:22:06Z

@ashachakma we need you! Can you complete this soon! EOW?

ashachakma · 2024-05-08T15:54:57Z

@ashachakma we need you! Can you complete this soon! EOW?

Sorry Ben, this week I've a planned holiday starting from Friday till next Tuesday 🫣

I was working on this issue intermittently but due to study work, not been able to finish it yet. I am at the testing stage but issues are there as well. I will prioritize this task next week for sure!

# Conflicts: # R/admiral-package.R

bms63

Is there supposed to be a NOT in here?

bms63 · 2024-06-03T01:27:31Z

Ohhh - this is making me pause. Is this necessary as you are just grabbing USUBJID? Is there a scenario where a user will need something more and should we give them so much leeway? If it is needed, can we recommend for them to check out set_admiral_opiton() and get_admiral_option() in the argument documentation.

bms63 · 2024-06-03T01:34:26Z

wheew...my head hurts. I saw a diagram floating around. Perhaps in 1.2.0 we could publish the diagram in inst folder for folks to reference to? Would that be useful for the users? IT would be for me, but I'm a bit dull!! If useful, do you mind making an issue and placing the diagram in the issue. We can clean it up or remake but just as a placeholder for now.

So close to being done!! yay!!

bms63 · 2024-06-03T01:37:36Z

Should we add ability to suppress the warning message if a user wants this? Or should it just be a message to the user instead of a warning?

bundfussr · 2024-06-03T15:58:00Z

Should we add ability to suppress the warning message if a user wants this? Or should it just be a message to the user instead of a warning?

I don't think we need an extra argument for this. To avoid the warning initial_intensity shouldn't be specified.

We should update the example.

bms63 · 2024-06-03T16:02:33Z

Should we add ability to suppress the warning message if a user wants this? Or should it just be a message to the user instead of a warning?

I don't think we need an extra argument for this. To avoid the warning initial_intensity shouldn't be specified.

We should update the example.

Good point!! - should the warning message tell the user to remove initial_intensity

bundfussr · 2024-06-03T16:08:31Z

Should we add ability to suppress the warning message if a user wants this? Or should it just be a message to the user instead of a warning?

I don't think we need an extra argument for this. To avoid the warning initial_intensity shouldn't be specified.
We should update the example.

Good point!! - should the warning message tell the user to remove initial_intensity

We don't know if initial_intensity or group_var should be removed. Thus we could add "Please only specify one of them." to the message.

bms63 · 2024-06-03T17:20:25Z

@kaz462 do you some time? Just a few minor tweaks.

kaz462 · 2024-06-03T19:11:15Z

@kaz462 do you some time? Just a few minor tweaks.

Yes, will update later today

kaz462 · 2024-06-04T00:13:16Z

@ashachakma @bms63 @bundfussr Thanks for your review! I've addressed the new comments, please let me know if I missed anything.

@bms63 Issue created to improve the documentation: #2455

R/derive_var_trtemfl.R

bms63 · 2024-06-04T17:36:35Z

@kaz462 Stefan tweaked the code a bit. Do you mind doing quick review (if you have time) and then I will look over as well and we can merge in.

bms63 · 2024-06-04T18:31:50Z

Yes!!!

#2302 New argument, group_var added

b4fa466

ashachakma requested a review from bundfussr March 6, 2024 12:26

ashachakma self-assigned this Mar 6, 2024

ashachakma linked an issue Mar 6, 2024 that may be closed by this pull request

Enhancing derive_var_trtemfl() to deal with AEs recorded on multiple lines #2302

Closed

jerryekohe and others added 4 commits March 6, 2024 19:25

#2302 Fixed spelcheck and styler error

0e43eef

#2302 Fixed lintr and roxygen related issues

3b29697

#2302 Fixed styler issue

d08c5ee

Merge branch 'main' into 2302_enhance_derive_var_trtemfl

35069bd

bms63 reviewed Mar 11, 2024

View reviewed changes

Merge branch 'main' into 2302_enhance_derive_var_trtemfl

bcde79b

bms63 added 2 commits March 16, 2024 13:23

Merge branch 'main' into 2302_enhance_derive_var_trtemfl

fbfbf41

Merge branch 'main' into 2302_enhance_derive_var_trtemfl

98f310b

manciniedoardo requested a review from kaz462 March 20, 2024 15:29

kaz462 reviewed Mar 21, 2024

View reviewed changes

ashachakma requested a review from bms63 March 25, 2024 15:18

Merge branch 'main' into 2302_enhance_derive_var_trtemfl

900885b

github-actions bot added the stale label May 8, 2024

github-actions bot removed the stale label May 9, 2024

kaz462 added 5 commits May 31, 2024 18:20

#2302: add subject_keys, update check for initial_intensity

4facbe7

Merge branch 'main' into 2302_enhance_derive_var_trtemfl

3f78ebf

# Conflicts: # R/admiral-package.R

#2302: update new AE derivation/get_new_tmp_var

b83f866

#2302: devtools::document()

b9908a4

#2302: upversion roxygen2

68e0bb6

kaz462 requested review from bundfussr, manciniedoardo and bms63 June 1, 2024 04:29

bms63 reviewed Jun 3, 2024

View reviewed changes

bms63 mentioned this pull request Jun 3, 2024

Closes #2415 replaced hard coding of expr(USUBJID, STUDYID) or expr(USUBJID) with … #2452

Open

15 tasks

kaz462 added 2 commits June 3, 2024 15:02

Merge branch 'main' into 2302_enhance_derive_var_trtemfl

a3a0153

#2302: update group_var/subject_key description, check, and example

0542e1f

bundfussr requested changes Jun 4, 2024

View reviewed changes

R/derive_var_trtemfl.R Outdated Show resolved Hide resolved

R/derive_var_trtemfl.R Outdated Show resolved Hide resolved

#2302 enhance_derive_var_trtemfl: update subject_keys argument

70fdf3a

bundfussr approved these changes Jun 4, 2024

View reviewed changes

#2302 enhance_derive_var_trtemfl: fix example

4e9de5e

kaz462 approved these changes Jun 4, 2024

View reviewed changes

bms63 merged commit 92ce191 into main Jun 4, 2024
16 checks passed

bms63 deleted the 2302_enhance_derive_var_trtemfl branch June 4, 2024 18:32

	#' @importFrom stats setNames
	#' @importFrom stats lag
	#' @importFrom stats setNames lag

	(!!intensity > !is.na(!!initial_intensity)) ~ as_datetime(!!start_date),
	(!!intensity > lag(!!intensity)) ~ as_datetime(!!start_date),

Closes #2302 New parameter, group_var added #2362

Closes #2302 New parameter, group_var added #2362

Conversation

ashachakma commented Mar 6, 2024 • edited

github-actions bot commented Mar 6, 2024 • edited

bms63 commented Mar 11, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kaz462 Mar 21, 2024 • edited

Choose a reason for hiding this comment

bms63 commented Mar 14, 2024

kaz462 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ashachakma Mar 28, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nbrucken17 Apr 16, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kaz462 Mar 21, 2024 • edited

Choose a reason for hiding this comment

nbrucken17 commented Apr 5, 2024

kaz462 commented Apr 5, 2024

bms63 commented Apr 5, 2024 • edited

bms63 commented Apr 19, 2024

ashachakma commented Apr 22, 2024

github-actions bot commented May 8, 2024

bms63 commented May 8, 2024

ashachakma commented May 8, 2024

bms63 left a comment • edited

Choose a reason for hiding this comment

bms63 commented Jun 3, 2024

bms63 commented Jun 3, 2024

bms63 commented Jun 3, 2024

bundfussr commented Jun 3, 2024

bms63 commented Jun 3, 2024

bundfussr commented Jun 3, 2024

bms63 commented Jun 3, 2024

kaz462 commented Jun 3, 2024

kaz462 commented Jun 4, 2024

bms63 commented Jun 4, 2024

bms63 commented Jun 4, 2024

ashachakma commented Mar 6, 2024 •

edited

github-actions bot commented Mar 6, 2024 •

edited

kaz462 Mar 21, 2024 •

edited

ashachakma Mar 28, 2024 •

edited

nbrucken17 Apr 16, 2024 •

edited

kaz462 Mar 21, 2024 •

edited

bms63 commented Apr 5, 2024 •

edited

bms63 left a comment •

edited