Feature request: self-starting nlmixr models using NCA estimates.

[mattfidler]

I have been thinking of this for quite awhile, I think that NCA estimates could be use to create self-starting nlmixr models.

Something to think about between the 2 packages.

This may be a long term goal, just thought it may be useful.

[billdenney]

I think about it all the time, and I often do just that manually.

I like it as a goal, and it works well for 1- and 2- compartment models. It has a bit more trouble with 3-compartment models-- at least I've not directly used NCA to bootstrap estimates for 3-compartment other than starting with 2-compartment estimates and splitting the difference with the second and 3rd compartments.

As a secondary part to this, my hope would be that this could be relatively PKNCA-independent (in that it would work from any NCA not that I'm trying to snub the suggestion!). If we can define some reasonable rules for how it would work, I think that we could get to a pretty good model automation system.

[billdenney]

As I've thought on this overnight, here are some initial impressions:

• I think that the rules for converting NCA parameters to self-starting parameter choices would likely reside within nlmixr. The rationale here is that knowledge of how to convert NCA to initial estimates is more on the modeling than NCA side.
• As a first prototype, I would think that a simple function (again on the nlmixr side) to convert user-entered NCA parameters to initial estimates would make sense. Something like:
  • ss_nca_compartmental(cl, vz, lambda_z, cmax, tmax, dose) where the outputs would output initial estimates like list(ka=log(2)/(tmax/4), cl=cl, q=cl*v2/v1, q2=q*2, v1=dose/cmax, v2=pmax(vz - v1, v1*2), v3=2*v2). (The q, q2, and v3 estimates are somewhat arbitrary.)
  • Notably, the output of the ss_*() function is vectorized and it is intended to support up to 3 compartments.
  • Different inputs would be used for calculation depending on the parameters available. For example, c0 from IV bolus would be preferred over cmax, when available.
• If the list elements are scalars, then they are used for the parameters in the model. If the list elements are vectors, then the geometric mean (or median) is used as the initial estimate, and the geometric CV is used as the initial estimate for any random effects in the model.

The second step would then make plugs to connect specific other inputs (like PKNCA output) to that ss_nca_compartmental(). Effectively, I'd think that would be making ss_nca_compartmental() a generic that could either take in numeric input or a PKNCA object as input.

The third step would be to make it all internal such that the dataset would be automatically piped into PKNCA then the output of that NCA would be put into the input function defined above.

This seems straight-forward when there is a single route of administration, single formulation, etc. And, I think that gets us so close to the final goal that it makes sense to implement that part soon. We may tweak parts like how the conversion from NCA parameters to initial estimates occurs, etc.

[mattfidler]

I will have to think about what should be in nlmixr. I already have model piping, which should make the transition easy, the only thing I wonder if it is the scope of nlmixr or should be in a helper package. Let me think about it.

I suppose providing arbitrary NCA to nlmixr input may be enough and what you suggest makes sense and follows the common modeling practices. In theory you could also use the model itself to determine if geometric CV is a good estimate for random effects (in case someone uses something other than lognormal variability).

However if there is linkage to NCA, I suppose it should be arbitrary allowing other packages to interact too, so the pipe from PKNCA to nlmixr would reside in PKNCA and the conversion of parameters to estimates would be in nlmixr or helper package.

I also think it is OK if the estimates are not perfect since it is simply a starting place in estimation.

Mostly this seems like a nice to have but isn't as high priority as some of the other things in my todo list. I thought it would be an easier piece to put in, but now I'm not entirely sure it is...

[mattfidler]

Perhaps it would be good to keep the helper packages to a minimum and it should reside in nlmixr; That is the NCA parameter estimation -> initial estimates in nlmixr.

Lets table the discussion for now. I think I need some time to work on a few things first. If I get an intern like I did last year, perhaps they can tackle this too. Seems like a good project for an intern.

[billdenney]

I do prefer to keep helper packages to a minimum, or if they are created, then they are by-default re-exported when loading the main package. That way, people don't have to hunt for functionality quite as much. That said, I do like umbrella packages, so perhaps there could be a "pharmacokinetics workflow" package that imports and re-exports nlmixr, PKNCA, and the intermediary package. I admit that my preferences are subtle and could be considered contradictory, but it seems consistent between my ears, at least. :)

I think that it sounds like a great intern project, and if that doesn't work out, I'm starting to make more and more friends with professors. So, if not an intern, perhaps it could be a student project. (Hint, hint, to any student who is reading along and interested in working on this!)

[billdenney]

One other very important consideration will need to be unit management. (The units package should have all the features that we need for that, https://cran.r-project.org/web/packages/units/.)

[mattfidler]

Rxode already supports units from the units package. Eventually units could lead to automatic scaling.

[billdenney]

@mattfidler, I think that this would go better in the nlmixrExtra package than in PKNCA or nlmixr. What do you think? (For the moment, that would just mean moving the issue there.)

[billdenney]

This is being handled in babelmixr2: https://github.com/nlmixr2/babelmixr2/