Hi Mark, I am assuming that you problem is a little more complex than only one theta, e.g. that you would like to simulate typical CL for a number of subgroups, where several covariate values (impactful on CL) are different across sub groups. In that case Leoid’s nonmem code would be a quick way to achieve this, and for each replicate simulation (subproblem) you would get a different set of population parameters, so you can for example calculate the mean for each subgroup, in each replicate, and then the distribution of means across replicates represents the uncertainty (in mean of the typical CL, for each subgroup).
I noticed we discussed this on nmusers in 2016, so I include a reply I wrote at that point, regarding the use of TNPRI in simulations. I do not think I have used this way of simulating with uncertainty in population parameters, since then, so I just paste the text as is, without further comment. Wishing you all a nice weekend! Jakob > Hi Mark, > > Indeed there is: As an alternative to NWPRI, there is the TNPRI subroutine > that you can use with $PRIOR (frequentist prior). > This functionality is tripple normal, with regards to thetas, omegas and > sigma(s). > I will describe this more in detail than Mark would need (hopefully for the > benefit of others). > > I used to think that TNPRI was an appealing alternative when the standard > error of population parmeters were all modest. The implementation appears to > be appealing at a first glance (less error prone): Simply plug in the MSFO > file from a previous run (generating the prior), as a prior representing the > covariance matrix from that previous run. > In addition, if from that previous run one has reported SEs based on the > covariance matrix, it may be appealing to use the same distribution when > simulating with uncertainty in population parameters (what I call simulation > mode, below), or as a prior in the next analysis with a new analysis data set > (what I call estimation mode, below). > However, over the years I have been using it less and less due to various > limitations and “features”. > I am not sure if Marks question was with regards to estimation with support > of a prior (estimation mode), or simulation with uncertainty in population > parameters based on a prior distribution (simulation mode), but separate the > list of bugs/features/limitations we have come across, below. > Some of these features are documented, whereas others I believe are not. > > In estimation mode (using TNPRI) there are only a few limitations that comes > to my mind: > Any thetas that are fixed must appear as the last thetas in your model > (already when generating the prior) > When generating the prior, do not use the UNCONDITIONAL option for the > covariance step. Even in cases where the estimation is successful (so that > the UNCONDITIONAL option is not needed), the subsequent estimation with TNPRI > will fail (If I recall correctly, it will run forever). > If you use PsN: TNPRI is not supported by all programs, in particular, you > can not use scm. Some may raise their eyebrows, thinking that the prior does > not allow testing for (new) covariates, so I will adress that comment right > away. With a new patient population at hand, you may want to use scm to test > whether there is a significant difference in any of the population > parameters, as compared to the prior (prior not including the new patient > population). > > In simulation mode (using TNPRI) there are additional limitations that I > would tend to call bugs, and I will only mention a few: > From the TABLE output you can use IPRED (and the distribution of population > parameters), but other PRED defined variables can not be trusted, including > PRED itself: so any clever calculations you may do in your control stream > (e.g. change from baseline): Do not use it! The output may have been > generated based on the initial estimates (i.e. prior mode, despite > TRUE=PRIOR), rather than based on the simulations that include uncertainty in > population parameters > Limitations on which parameters needs to be fixed is even greater. If I > remember correctly, the whole model must be re-formulated in case you have > any terminal thetas: SIGMAs and OMEGAs must then also be fixed (to 1), and > magnitudes estimated as fixed effects (representing e.g. standard error of > IIV, or the covariance) - these additional thetas must then also appear > before the fixed thetas. But this is when generating the prior (in estimation > mode, before the subsequent simulation). Possibly, when using the prior in > simulation mode, then all previously fixed thetas must be unfixed again. > When generating the prior, do not use the UNCONDITIONAL option for the > covariance step. Even in cases where the estimation is successful (so that > the UNCONDITIONAL option is not needed), the subsequent simulation step will > fail (If I recall correctly, it will run forever). > > At Pharmetheus, we have not used TNPRI widely and tend to use it less and > less (favouring NWPRI), and we have never had the time to fully characterise > these bug/features: as soon as we have concluded it works for the task at > hand, we leave it without further exploring situations where TNPRI may > provide an unexpected/erroneous output. > Consequently, you may find my bug/feature description above a bit unclear. I > do not know exactly what situations trigger these bugs, and I could list > additional vague descriptions of bugs/features we have come across, if I look > back into previous projects. But I think if I do that it would raise more > questions than it answers... > However, this discussion is mainly on simulations, and maybe missess out > entirely on Marks question? Hopefully, someone will find it useful, still. > > Finally, back more towards Marks question, if SE is large in the sense that > the normal (uncertainty) distribution would go outside the boundaries (e.g. > OMEGA<0), for any population parameter (fixed and random), then there is > functionality to handle this. > I have never used TNPRI with any large SE:s, but Mats Karlsson once mentioned > to me that the functionality does not really handle this situation the way > you would expect: the tail of the distribution that goes outside the boundary > will be moved to the other end of the distribution. > Obviously, this is not what you want in case that tail constitutes a large > fraction, but if it is only a question of 1 out of 10 000 sample, this may be > harmless (in most cases). > > Maybe someone can complement with a fuller description on the limitations > with TNPRI than what I could provide? > Otherwise, I leave you with the following short summary, for when how to use > TNPRI: > In generating the prior > try to avoid fixing any theta (e.g. do not use a fixed theta to represent > allometric constants), and if the purpose of TNPRI is simulation try to avoid > fixing any omega as well > Do not use UNCONDITIONAL in the covariance step > In estimation with support of the TNPRI prior > Be aware you can not use PsN scm, for covariate selection (NWPRI works fine > with the new nonmem notation THETAP, etc. But you need to be aware of the > issues of testing covariates with suport of a prior that did not include that > covariate) > In simulation using TNPRI > From the TABLE output, you may use IPRED (and other variables that are not > simulated, like ID, trial-replicate nr, time and dose). THETAS, OMEGAS and > SIGMAS can be used to check the distribution across replicate simulations, > but pred-defined variables should not be used for anything! > > It used to be quite hairy and error prone to manually set up a complicated > nonmem control stream for using the NWPRI. > However, if you can use automatic functionality for adding the NWPRI > distribution in the control stream and just check it has been implemented > correctly, this is not a big hurdle. > For example, PsN has such a functionality as an option to the “update_inits” > program. > In addition, the new nonmem notation makes it easier for others to understand > the control stream (THETAP, etc). > Therefore, in most cases where I need to use a (frequentist) prior, NWPRI is > currently my first option. > (But I leave you with the cheery reservation that I do not mention much > around limitations/features with NWPRI, since that is clearly out of scope > for the topic in this tread :>) > > > Best regards > > Jakob > -- *This communication is confidential and is only intended for the use of the individual or entity to which it is directed. It may contain information that is privileged and exempt from disclosure under applicable law. If you are not the intended recipient please notify us immediately. Please do not copy it or disclose its contents to any other person.* *Any personal data will be processed in accordance with Pharmetheus' privacy notice, available here <https://pharmetheus.com/privacy-policy/>.** *
