Feature request, change BLQ behavior: global imputations (BLQ, NA) happening after individual impute actions

[Gero1999]

As discussed partly in #447 we would like to consider the possibility of doing all global imputations (missing concentration, BLQ values) before the individual interval imputations specified by the user in the impute column (i.e, start_conc0, start_predose...).

The reason is the problem that a user can experience when using the imputation column and the BLQ options:

Context: I am doing a start_conc0 imputation in my extravascular study, but if simultaneously I decide to drop all my BLQ values then the App won't run. It seems like the imputed concentration is also being droped

library(PKNCA)
conc_data <- data.frame(
    conc = c(1, 2.5, 2, 1, 0.7, 0.5, 0),
    time = 1:7,
    subject = 1
)

dose_data <- data.frame(
    dose = 100,
    time = 0,
    subject = 1,
    route = "Extravascular"
)

# Create PKNCA objects without BLQ cleaning
o_conc <- PKNCAconc(conc_data, conc ~ time | subject)
o_dose <- PKNCAdose(dose_data, dose ~ time | subject, route = "route")
o_data <- PKNCAdata(o_conc, o_dose)
o_data$intervals$impute <- "start_conc0"
o_nca <- pk.nca(o_data)
o_nca$result

# Create PKNCA objects with BLQ cleaning
o_data2 <- o_data
o_data2$options$conc.blq <- list(
    first = "drop",
    middle = "drop",
    last = "drop"
)
# Won't run: Requesting an AUC range starting (0) before the first measurement
# BLQ cleaning seems to happen after start_impute, so it doesn't work!
o_nca2 <- pk.nca(o_data2)

Before merging/implementing we need to make sure it does not break the main PKNCA workflow in anyway.

[billdenney]

FYI, I changed the title to a feature request because as-discussed in #447, it's intentional and a difference in expectations rather than an error.

[Gero1999]

After thinking more carefully about this, it may be better to move impute_method handling into the parameter function. This prevents observation parameters from being affected by custom impute methods (i.e, #350). That way problems like the next one will be fixed:

library(PKNCA)
conc_data <- data.frame(
  conc = 4:1,
  time = 1:4,
  subject = 1
)

dose_data <- data.frame(
  dose = 100,
  time = 0,
  subject = 1,
  route = "Extravascular"
)

# Create PKNCA objects without BLQ cleaning
o_conc <- PKNCAconc(conc_data, conc ~ time | subject)
o_dose <- PKNCAdose(dose_data, dose ~ time | subject, route = "route")
o_data <- PKNCAdata(o_conc, o_dose)

# Define an impute method
PKNCA_impute_method_start_logslope <- function(conc, time, start, end, ..., options = list()) { # nolint
  
  ret <- data.frame(conc = conc, time = time)
  mask_start <- time %in% start
  if (!any(mask_start)) {
    all_concs <- conc[time >= start  &  time <= end]
    all_times <- time[time >= start  &  time <= end]
    if (!all(is.na(all_concs))) {
      c0 <- PKNCA::pk.calc.c0(all_concs, all_times, method = "logslope")
      if (!is.na(c0)) {
        ret <- rbind(ret, data.frame(time = start, conc = c0))
        ret <- ret[order(ret$time), ]
      }
    }
  }
  ret
}

# Use the impute method
o_data$intervals$impute <- "start_logslope"
o_nca <- pk.nca(o_data)

# cmax = c0 (instead of cmax = 4)
o_nca$result[o_nca$result$PPTESTCD == "cmax",]

Let me know though if I am missing something

[Gero1999]

hello @billdenney the fix for this indeed will be complicated as explained in my prev comment. I am considering either:

1. Move the impute_method inside each pk.calc function, increasing the args of each function

2. Move out BLQ/NA imputations from the calculation functions. Simply indicating for each parameter in add.interval.col(observational = TRUE / FALSE) and then in pk.nca-interval using imputed or observed data accordingly.

I personally feel 2) will simplify substantially for new users writing new parameter functions without having to understand in detail the imputation system. Plus, code efficiency will increase for pk.nca. But because is a lot of work and changes the behaviors for pk.calc operations, I would like to have your feedback before working on it.

[billdenney]

I do not think we should move imputation within each of the calc functions. That will both invite bugs in the future and make each of the calculations take significantly more time.

As I'm thinking more about your example case "I am doing a start_conc0 imputation in my extravascular study, but if simultaneously I decide to drop all my BLQ values then the App won't run. It seems like the imputed concentration is also being dropped", I think that this is more like an invalid pair of options (such as, "please give me a number that is less than -1 and greater than 1").

Can you describe a scenario where someone would intentionally like to drop all BLQ values (instead of dropping either "middle" and "last" or "after.tmax") and still impute a BLQ value predose?

The correct situation here may be to limit the choices in how BLQ/imputation can be used in combinations because in your example, the user is specifically giving instructions in conflict with each other (drop all BLQ, and please give me a BLQ).

Another option may be to have the user exclude all BLQ points using the exclude column.

[Gero1999]

Maybe my first example was not the best to clarify my concern. Let me propose another one in which I express my logic:

Let's say I am doing an oral single dose study. I don´t have a sample of the drug collected as a pre-dose, but I know that at the time of the dose, before the exposure, my concentration is exactly 0 (impute: start_conc0).

Now, I define a BLQ imputation. I know that my BLQ values are between 0 and my LLOQ. So I decide that (for example) I will impute BLQs with LLOQ/2.

Now my question is, why does my imputed concentration at dose time have to change as well with my BLQs, if I am certain that is 0 and not LLOQ/2? Or worse, if my strategy is to drop BLQ points before tmax, why do I have to loose the knowledge I possess of the initial concentration from my curve?

Then in my second example I have another concern that does not involve BLQ handling, but is just about how imputation currently is working. Let's imagine I have a bolus single dose study. So I decide that for a better approximation this time I will use c0 as a start concentration so my AUC is better derived. Why does that imputation have to affect my observational parameters such as cmax or tmax?

So my two concerns are: 1) Why do we treat imputed 0 values as if they were BLQ? and 2) Why do we allow imputations to be performed in all observational parameters? Would not be better to do what is described here in my 2nd option to solve both things?

[billdenney]

First example

For your first example, I think that I'm reasonably convinced about the rationale, and I think that the second option is the right path. My concern is now backward compatibility and people who may expect the old behavior.

The lightest touch way (and therefore closest to backward-compatible) that I can imagine making this work is to add something like a skip_blq_change argument to the functions that do the change BLQ concentrations. We will want it to default to backward compatibility, and then we can use the new method within pk.calc.intervals().

@john-harrold, do you have additional thoughts?

Second example

For the second example, if you impute c0 before you do the calculation you won't get the IV parameters as are intended to be reported, the suggested way to do that calculation is using the auciv* parameters:

library(PKNCA)
#> 
#> Attaching package: 'PKNCA'
#> The following object is masked from 'package:stats':
#> 
#>     filter
d_iv <- data.frame(conc = c(0, 4, 2.1, 1, 0.4), time = c(0:4))
o_conc <- PKNCAconc(d_iv, conc~time)
o_dose <- PKNCAdose(data.frame(time = 0), ~time)
o_data <- PKNCAdata(o_conc, o_dose, intervals = data.frame(start = 0, end = Inf, aucivinf.obs = TRUE))
o_nca <- pk.nca(o_data)
summary(o_nca)
#>  start end aucivinf.obs
#>      0 Inf         11.2
#> 
#> Caption: aucivinf.obs: geometric mean and geometric coefficient of variation
as.data.frame(o_nca)
#> # A tibble: 16 × 5
#>    start   end PPTESTCD            PPORRES exclude
#>    <dbl> <dbl> <chr>                 <dbl> <chr>  
#>  1     0   Inf c0                    7.62  <NA>   
#>  2     0   Inf tmax                  1     <NA>   
#>  3     0   Inf tlast                 4     <NA>   
#>  4     0   Inf clast.obs             0.4   <NA>   
#>  5     0   Inf lambda.z              0.829 <NA>   
#>  6     0   Inf r.squared             0.996 <NA>   
#>  7     0   Inf adj.r.squared         0.993 <NA>   
#>  8     0   Inf lambda.z.corrxy      -0.998 <NA>   
#>  9     0   Inf lambda.z.time.first   2     <NA>   
#> 10     0   Inf lambda.z.time.last    4     <NA>   
#> 11     0   Inf lambda.z.n.points     3     <NA>   
#> 12     0   Inf clast.pred            0.412 <NA>   
#> 13     0   Inf half.life             0.836 <NA>   
#> 14     0   Inf span.ratio            2.39  <NA>   
#> 15     0   Inf aucinf.obs            7.57  <NA>   
#> 16     0   Inf aucivinf.obs         11.2   <NA>

^{Created on 2025-11-05 with reprex v2.1.1}

[john-harrold]

Caveat: I've kind of read through this and I have a vague understanding of how all this works.

Here is an option that may work. Create a PKNCA option that specifies the order. Have the default value for the order represent the current behavior. Something like this:

impute_order = c("user", "global") 

That would preserve backwards compatibility. Then @Gero1999 can overwrite that for their current analysis

impute_order = c("global", "user") 

[Gero1999]

@billdenney Regarding my second example, my concern is broader than its impact on bolus studies. I believe it's problematic for any observational parameter to be influenced by imputations. For instance, an obvious case could be in an oral dose study imputing start_conc0, resulting in tmin = 0 & cmin = 0, which is not a truly observed point in the data.

I understand your concern for backward compatibility, but I feel this is more of a bug than a simple behavior change. Most results will remain unaffected; only parameters that are currently being inaccurately calculated will change. For instance, many users may use start_conc0, which could unintentionally affect observational parameters. And if on top they combine it with BLQ imputation, they will also have (at the least) inaccurate AUCs.

If we implemented the the second strategy) while keeping pk.calc functions with all their current arguments, and just removing options$conc.blq <- NULL for specifically pk.nca.interval , could this the address backward compatibility concerns?

[Gero1999]

@john-harrold Unfortunately, I believe this approach may not be sufficient. The issue lies not only in the order of imputations but also in the fact that they are being unevenly applied across parameters. Currently, BLQ imputations are only applied to AUC parameters (and their derivatives), while impute_methods affect all parameters.

An alternative might be to let users define the order of BLQ handling in the impute column. However, this would not solve but exacerbate the issue in the second example, as BLQ imputations would then also affect observational parameters.

If maintaining backward compatibility is a priority, we could implement something like:

impute_only_observational_parameters = c("user", "global")

That said, I personally think the current behavior results in incorrect calculations for some parameters, so I would advocate for a change. Of course, I’m happy to discuss further and remain open to other ideas

[billdenney]

We're having two separate conversations here. I'm splitting them up by heading.

Give observed results with imputation instructions

I understand how this could be considered a bug. Though to me, whether it's a bug or not depends on what you view to be correct based on the instructions you give PKNCA.

To me, if the instructions given to PKNCA say "impute time zero concentration as 0" (start_conc0), then you are telling PKNCA that for all calculations, treat time zero as having a concentration of zero. If you ask for cmin and tmin, they should be zero. (Pharmacokineticists don't typically ask for those parameters with single dose data for that reason. Pharmacokineticists would more typically ask for the concentration at a given time point like the concentration at 24 hours.)

If you want observed-only results without imputation, then you should not give imputation instructions as you are asking for something dissonant (please impute but please don't use that imputed value). In my mind, the way to get the observed cmin is to request cmin without an imputation given. That way, the results will be consistent-- they either include the imputation or they don't.

Asking for imputation to sometimes be used and sometimes not within a single interval calculation will very often not result in expected (and therefore desired) behavior. And, that would go back to one of the primary philosophies of PKNCA that it will not guess in a way that will not guess in a way that will make a choice that the analyst may have an alternate preference for (https://github.com/humanpred/pknca/blame/1d95c4a044e7a5397a53a61e4aba04287c221531/README.md#L19-L22 -- the statement is 11 years old!)

For all of the above, the method is not to use imputation if you don't want values with imputation. Then, you will get the result you expect without imputation; the analyst's instructions are clear. (If you want an AUC without a concentration at the beginning and without imputation, that is impossible because there is no data to integrate from the first time point.)

Imputation/BLQ handling order

That said, the BLQ handling issue is different. If the user gives instructions of "drop BLQ values" and "impute time 0 as BLQ", we have to make a decision of how to handle those two instructions, and what the user is intending is "first drop the BLQ values and then add a time 0 BLQ value". No other interpretation makes sense to me.

My hesitation to change the behavior is not that the interpretation is likely to be different but that some people use the half-life and AUC functions directly (most often for analyzing thousands or tens of thousands of simulation results-- they don't want the computation time that the rest of PKNCA gives). And, I want to almost never make a breaking change to PKNCA (bug fixes excepted).

[Gero1999]

Hello @billdenney! In aNCA we ended up inclining to this solution (PR #491):

An alternative might be to let users define the order of BLQ handling in the impute column.

What we basically do is to define a impute method function that does the BLQ handling. Then we can choose on which intervals and at which moment the imputation is applied.

So I guess that means that PKNCA already offers a solution to both problems. I will close the issue therefore, but let me know if you think I missed something and we can always re-open!