Closes #276 crpr: describe handling of CR, PR in RECIST vignettes

NEWS.md

@@ -1,3 +1,11 @@
+# admiralonco (development version)
+
+## Documentation
+
+- The vignettes "Creating a Basic ADRS" and "Creating ADRS (Including
+Non-standard Endpoints)" were updated to describe how the case `CR` followed by
+`PR` is handled. (#276)
+
 # admiralonco 1.1.0
 
 ## Documentation

vignettes/adrs.Rmd

@@ -30,6 +30,15 @@ implementing other response criteria than RECIST 1.1, e.g., iRECIST or
 International Myeloma Working Group (IMWG) criteria for the diagnosis of
 multiple myeloma.
 
+For confirmation of response particularly, `CR`, the case that `CR` is followed
+by `PR` (or `SD`) is considered as a data issue and the derivations of the
+parameters don't handle this case specially. It is recommended to fix the issue
+in the source data, e.g., by changing the `PR` to `PD` rather than handling it
+in the parameter derivations. This ensures consistency across parameters.
+However, `admiral::derive_extreme_event()` is so flexible that it is possible to
+handle it in the parameter derivations, for example, by redefining the `bor_pr`
+event and adding an additional `PD` event.
+
 Examples are currently presented and tested using `ADSL` (ADaM) and
 `RS`, `TU` (SDTM) inputs. However, other domains could be used. The
 functions and workflow could similarly be used to create an intermediary

vignettes/adrs_basic.Rmd

@@ -19,9 +19,19 @@ library(admiraldev)
 
 # Introduction
 
-This article describes creating an `ADRS` ADaM with common oncology
-endpoint parameters based on RECIST v1.1. Therefore response values are
-expected as either `CR`, `PR`, `SD`, `NON-CR/NON-PD`, `PD` or `NE`.
+This article describes creating an `ADRS` ADaM with common oncology endpoint
+parameters based on RECIST v1.1. Therefore response values are expected as
+either `CR`, `PR`, `SD`, `NON-CR/NON-PD`, `PD` or `NE`.
+
+For confirmation of response particularly, `CR`, the case that `CR` is followed
+by `PR` (or `SD`) is considered as a data issue and the derivations of the
+parameters don't handle this case specially. The `{admiralonco}` functions don't
+provide functionality to handle this case. It is recommended to fix the issue in
+the source data, e.g., by changing the `PR` to `PD` rather than handling it in
+the parameter derivations. This ensures consistency across parameters. The
+functions `derive_param_confirmed_bor()` and `derive_param_confirmed_resp()`
+issue a warning if `CR` is followed by `PR` (the warning does not display if
+`CR` is followed by `SD`).
 
 Please note that this vignette describes the endpoints which were considered by
 the admiralonco team as the most common ones. The admiralonco functions used to