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.

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

Bug: The result of derive_param_tte() depends on the sort order of the input #2481

Closed
bundfussr opened this issue Jul 18, 2024 · 12 comments · Fixed by #2569
Closed

Bug: The result of derive_param_tte() depends on the sort order of the input #2481

bundfussr opened this issue Jul 18, 2024 · 12 comments · Fixed by #2569
Assignees
Labels
bug Something isn't working programming

Comments

@bundfussr
Copy link
Collaborator

What happened?

The result of derive_param_tte() depends on the sort order of the input. See example below.

An order argument should be added to event_source() and censor_source(). It should be defaulted to NULL. It expects a list of variables, which are used in addition to date for sorting the input data.

The check_type argument should be added to derive_param_tte() and defaulted to "warning". The uniqueness of the selected records should be checked by calling signal_duplicate_records().

Session Information

No response

Reproducible Example


adsl <- tibble::tribble(
  ~USUBJID, ~TRTSDT,           ~TRTEDT,           ~EOSDT,
  "01",     ymd("2020-12-06"), ymd("2021-03-02"), ymd("2021-03-06"),
  "02",     ymd("2021-01-16"), ymd("2021-01-20"), ymd("2021-02-03")
) %>%
  mutate(STUDYID = "AB42")

ae <- tibble::tribble(
  ~USUBJID, ~AESTDTC,     ~AESEQ, ~AEDECOD,
  "01",     "2021-01-03",      1, "Flu",
  "01",     "2021-03-04",      2, "Cough",
  "01",     "2021-01-03",      3, "Flu"
) %>%
  mutate(
    STUDYID = "AB42",
    AESTDT = ymd(AESTDTC)
  )

ttae <- event_source(
  dataset_name = "ae",
  date = AESTDT,
  set_values_to = exprs(
    EVENTDESC = "AE",
    SRCDOM = "AE",
    SRCVAR = "AESTDTC",
    SRCSEQ = AESEQ
  )
)

eot <- censor_source(
  dataset_name = "adsl",
  date = pmin(TRTEDT + days(10), EOSDT),
  censor = 1,
  set_values_to = exprs(
    EVENTDESC = "END OF TRT",
    SRCDOM = "ADSL",
    SRCVAR = "TRTEDT"
  )
)

derive_param_tte(
  dataset_adsl = adsl,
  start_date = TRTSDT,
  event_conditions = list(ttae),
  censor_conditions = list(eot),
  source_datasets = list(adsl = adsl, ae = arrange(ae, AESEQ)),
  set_values_to = exprs(
    PARAMCD = "TTAE"
  )
)

produces

# A tibble: 2 × 10
  USUBJID STUDYID EVENTDESC  SRCDOM SRCVAR  SRCSEQ  CNSR ADT        STARTDT    PARAMCD
  <chr>   <chr>   <chr>      <chr>  <chr>    <dbl> <int> <date>     <date>     <chr>  
1 01      AB42    AE         AE     AESTDTC      1     0 2021-01-03 2020-12-06 TTAE   
2 02      AB42    END OF TRT ADSL   TRTEDT      NA     1 2021-01-30 2021-01-16 TTAE   

but

derive_param_tte(
  dataset_adsl = adsl,
  start_date = TRTSDT,
  event_conditions = list(ttae),
  censor_conditions = list(eot),
  source_datasets = list(adsl = adsl, ae = arrange(ae, desc(AESEQ))),
  set_values_to = exprs(
    PARAMCD = "TTAE"
  )
)

produces

# A tibble: 2 × 10
  USUBJID STUDYID EVENTDESC  SRCDOM SRCVAR  SRCSEQ  CNSR ADT        STARTDT    PARAMCD
  <chr>   <chr>   <chr>      <chr>  <chr>    <dbl> <int> <date>     <date>     <chr>  
1 01      AB42    AE         AE     AESTDTC      3     0 2021-01-03 2020-12-06 TTAE   
2 02      AB42    END OF TRT ADSL   TRTEDT      NA     1 2021-01-30 2021-01-16 TTAE   
@bms63
Copy link
Collaborator

bms63 commented Jul 18, 2024

Is this a bug we need to push a patch out for or something we can wait on till next release?

@rossfarrugia
Copy link
Collaborator

I'd say next release as its not a bug as such (the function does what it says) - its more just the lack of a useful feature

@bms63
Copy link
Collaborator

bms63 commented Jul 18, 2024

Should I tag the team and community team to see if anyone is interested or do we feel like this is a bit more complicated?

@bundfussr
Copy link
Collaborator Author

I think it is something in between a bug and a feature. Maybe we should call it a gap because for the scenario of more than one record per date the expected behavior of the function is not described.

I think it is OK to tag the team and community team but it shouldn't be labelled as "good first issue". It could be a good issue for team members who have some time and are interested in getting familiar with one of the more complex admiral functions.

@bms63
Copy link
Collaborator

bms63 commented Jul 18, 2024

@pharmaverse/admiral and @pharmaverse/admiral_comm this is a good one to tackle, but it is not a "good first issue". You will get into the weeds a bit, but great way to learn more about admiral!!

@ProfessorP-beep
Copy link
Collaborator

@bms63 @bundfussr @rossfarrugia I have some free time and can take a look. When is our next release date again?

@rossfarrugia
Copy link
Collaborator

@rossfarrugia
Copy link
Collaborator

Ha sorry @manciniedoardo - i quoted from the site, but think I remember you and Ben saying it'll push back to Jan

@bms63
Copy link
Collaborator

bms63 commented Sep 10, 2024

Ha sorry @manciniedoardo - i quoted from the site, but think I remember you and Ben saying it'll push back to Jan

at the rate we are going we might just do a release in early December. Work has really chilled out! Unless you want to lead some huge refactor @rossfarrugia ??

@rossfarrugia
Copy link
Collaborator

@ProfessorP-beep will this one be ready for the next release? If you were able to get the updates in main in the next month or so then I could do some testing on the Roche side as we need to make updates to our template code when this update comes.

@ProfessorP-beep
Copy link
Collaborator

ProfessorP-beep commented Nov 5, 2024

@ProfessorP-beep will this one be ready for the next release? If you were able to get the updates in main in the next month or so then I could do some testing on the Roche side as we need to make updates to our template code when this update comes.

@rossfarrugia Sorry, things got very chaotic at work and I had to shift focus. Give me a week and I can update you on if I can get it done by the next release.

@ProfessorP-beep
Copy link
Collaborator

Should have a lot of time to work on this the rest of the week and aiming to get a push out by Friday / Saturday.

@bms63 bms63 moved this from In Progress to Done in admiral (sdtm/adam, dev, ci, template, core) Jan 8, 2025
@bms63 bms63 moved this from Done to In Review in admiral (sdtm/adam, dev, ci, template, core) Jan 8, 2025
bundfussr added a commit that referenced this issue Jan 13, 2025
bundfussr added a commit that referenced this issue Jan 13, 2025
bms63 added a commit that referenced this issue Jan 13, 2025
…rder of the input (#2569)

* Added order arguments to censor_source and event_source. Also added signal_duplicate_records to derive_param_tte.

Still troubleshooting the test-derive_param_tte script. Failed tests have a "Required variable `AEDECOD` is missing in `dataset`" error.

* Added order argument to tte_source as part of development and error fixes.

* Fixed previous erros but still need to address failed tests for Test 9, 15, and 16 in test-derive_param_tte

* added check_type arg_match to derive_param_tte so user has to input a valid argument

* Changed position of signal_duplicate_records function in derive_param_tte to fix missing data error

* lintr changes by removing whitespace.

* styler fix.

Pushing again and confirmed check_type argument is in derive_var_obs_number in derive_joined.R scripts

* updated NEWS.md with changes to derive_param_tte,. Removed Test 17 from test-derive_param_tte as it was redundant, and ran pharmaverse4devs format test script addin to format testest-derive_param_tte.

* changed the signal_duplicate_records within derive_parame_tte to handle dataset_adsl and source_datasets by combining them with bind_rows before to address error of AEDECOD missing from the dataset when just calling dataset_adsl. This starts on line 381 of derive_param_tte.R

* added a tryCatch() to filter_date_sources to catch duplicates to address failed runs in Test 16 of test-derive_param_tte.

removed signal_duplicate_records() from within derive_param_tte

Still need to troubleshoot errors in test script.

* Moved duplication check to filter_date_sources in tryCatch() and rewrote Test 15 and 16 on test-derive_param_tte to deal with update to duplicate warnings within tryCatch and not directly by signal_duplicate_records inside derive_param_tte function.

Accepted snapshots from devtools::check

* 1. Moved updates in News section to admiral dev section

2. Made suggested fixes to derive_param_tte script.

* Ran styler, lintr fixes, and devtools check.

* styler changes

* accepted snapshots from testthat and addressed bds_tte.Rmd error for devtool checks()

* added documentation for order and check_type arguments added to functions. Directly called rlang::try_fetch in derive_param_tte script.

* requested updates to documentation and test script for derive_param_tte

* corrected documentation and removed rlang from bds_tte.Rmd

* updated derive_param_tte documentation and added test to derive_param_tte test script.

* fixed spelling error

* updates to derive_param_tte documentation and test examples.

* Update NEWS.md

Co-authored-by: Stefan Bundfuss <[email protected]>

* update to derive_param_tte test, function examples, and documentation.

* snapshots accepted

* passed local checks. Pushing again

* ran styler

* added "message" as a option for check_type in derive_var_obs_number

* Update NEWS.md

Co-authored-by: Ben Straub <[email protected]>

* #2481: cosmetics

* #2481: fix lintr

---------

Co-authored-by: Stefan Bundfuss <[email protected]>
Co-authored-by: Ben Straub <[email protected]>
Co-authored-by: Stefan Bundfuss <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working programming
4 participants