NONMEM Users Network Archive

Hosted by Cognigen

Re: Code to avoid flip-flop kinetics

From: Paolo Denti <paolo.denti>
Date: Wed, 12 Aug 2009 17:49:25 +0200

Dear all,
thank you for the ready responses and thoughtful comments.

I examined more closely my results and acting only at population level
does seem to be the best option for my case.

The population typical values of Ka and Ke are not too close (~0.5 and
~0.2), but sometimes the flip-flop was occurring anyway at population
level. When fixing the problem for the population parameters (Ka>Ke from
literature and physiology) the phenomenon was still occurring for some
individuals.

At first, I was a bit surprised about these estimates apparently
inconsistent with the assumption made at population level, because I
though that NONMEM should pick, for each subject, the flip-flop
configuration maximizing the adherence to the population typical values
and therefore consistently with Ka>Ke.
Then, analysing the results more closely, I found out that NONMEM had a
indeed "good" reason for choosing the flip-flop configuration in spite
of the population assumption. If the Ka>Ke configuration had been chosen
also for the "anomalous" subjects, their estimated values of volume
would have been much larger than the population typical values,
proportionately larger than the deviation from the population mean
caused by Ka and Ke. This makes the individual values proposed by NONMEM
the most likely, even if not consistent with the Ka>Ke assumption.

The distributions of the etas do not display bimodality, so I decided to
use only the population correction. But again, fortunately it is only
few subjects and the results are not overly sensitive to them.

Thank you again for your help,
Paolo

Leonid Gibiansky wrote:
> Hi Jurgen
> I think one can do a simple simulation study:
>
> 1. Simulate dataset assuming that true population k and ka differ by
> 10%, corresponding ETAs are log-normally distributed with CV=20-25%
>
> 2 Estimate the model imposing k and ka ordering on the individual
> level. I would guess that resulting estimates will be biased (differ
> my more than 10%) and eta-distributions will be scewed.
>
> 3. Estimate the model imposing k - ka ordering of the population level.
> I think you are more likely to come up with correct answer using step
> 3 rather than step 2.
>
> A simple extreme example: assume that true population k and ka are
> equal and log-normally distributed with equal variances. It is clear
> that (2) will not work while (3) could give reasonable answer.
>
> I think that constraining individual parameters is not a good idea if
> population k and ka are close (this may lead to the biased estimates),
> and it is not important if they are far apart.
>
> Thanks
> Leonid
> --------------------------------------
> Leonid Gibiansky, Ph.D.
> President, QuantPharm LLC
> web: www.quantpharm.com
> e-mail: LGibiansky at quantpharm.com
> tel: (301) 767 5566
>
>
>
>
> Jurgen Bulitta wrote:
>> Dear Nick,
>> Dear Paolo,
>> Dear Leonid,
>> Dear All,
>>
>> Depending on the application, I think there are the following reasons
>> for constraining ka and ke:
>>
>> 1) Standard-two-stage (STS) approach: As discussed previously,
>> calculating average and SD from STS estimates is likely to yield
>> biased averages and SDs and this bias may have a great impact when
>> these descriptive statistics are used as means and variances in a
>> Monte Carlo simulation. Thus, manually switching of individual ka &
>> ke (if needed) makes perfect sense for STS.
>>
>> 2) Nonparametric population PK with nonparametric simulation: As the
>> interindividual distribution of PK parameters can take any shape, it
>> will make no difference for a non-parametric simulation based on the
>> list of support points whether ka and ke are constrained or not. Even
>> if a support point (with e.g. 10% probability and ka>ke) splits into
>> two equivalent support points with 5% probability each (5% for ka>ke
>> and 5% for ke>ka) this will not affect the results of a nonparametric
>> simulation. Thus for a nonparametric simulation, constraining is not
>> needed.
>>
>> 3) Nonparametric population PK with parametric simulation: Once one
>> computes averages and SDs (etc.) from the list of support points, the
>> same issue of biased averages and SDs arises as for STS, if ka and ke
>> are not constrained. As averages and SDs are commonly calculated for
>> nonparametric pop PK models, constraining at the individual parameter
>> estimate level seems most reasonable, as proposed by Vladimir
>> Piotrovsky (option 2 in Paolo's email). I think this was the approach
>> taken at the 2005 PAGE software comparison.
>> I am not aware of a method of constraining a nonparametric model at
>> the population level.
>>
>> 4) Parametric EM-algorithms: Assume true mean ka and true mean ke are
>> within 10% of each other and BSV has CV of 30% each. Clearly, there
>> must be substantial overlap in the true individual estimates of ka
>> and ke.
>>
>> 4.1) As one EM algorithm, the MC-PEM algorithm assumes that the
>> interindividual distribution of individual model parameters is normal
>> (or lognormal, or can be transformed to be normal). Otherwise, the
>> population mean and population variance-covariance matrix obtained
>> from the conditional means and condition variance matrices of each
>> subject (see eq. 23 and 27 in [1] and ref. [2]) does not necessarily
>> minimize the overall log-likelihood. Truncation of the
>> interindividual distribution of PK parameters, for example by use of
>> the EXIT command (option 3 in Paolo's email), seems to violate the
>> normal distribution assumption.
>>
>> 4.2) The conditional means calculated in the expectation-step can be
>> biased due to e.g. a bi-modal distribution caused by the flip-flop
>> (see also Serge's comment at the end of the discussion in 2003). This
>> might be a more severe concern compared to 4.1).
>> If such bias in the conditional means and in the conditional variance
>> matrices occurs, the computation of the population means and
>> population variance-covariance matrix via eq. (21) and (22) (see
>> Bauer et al. [1]) does no longer guarantee to minimize the objective
>> function, I think. Constraining ka and ke at the population level
>> (option 1 in Paolo's email) is unlikely to solve this problem, if
>> mean ka and mean ke are close.
>>
>> If one does not constrain ka and ke at the individual parameter
>> level, bias of conditional means is likely to occur, if:
>> a) the mean ka and mean ke are close given their interindividual
>> variability
>> b) the data are sparse and one therefore uses a wide envelope
>> function to approximate an individual's conditional density (this
>> problem is more likely to occur if one uses low values of gefficiency
>> [please see S-ADAPT manual] or if one uses e.g. a t-distribution with
>> small degrees of freedom as envelope function)
>> Therefore, constraining at the individual parameter level via
>> estimation of CL, V, and (ka-kel) (i.e. the Vladimir Piotrovsky
>> method) and use of a full var-cov matrix (as proposed by Leonid)
>> seems the best choice for the MC-PEM algorithm. I think this also
>> applies to the SAEM and MCMC algorithm. These algorithms usually have
>> no problem with estimating a full var-cov matrix and do not require
>> excessively longer runtimes to estimate a full var-cov matrix, as
>> opposed to FOCE.
>>
>>
>> SUMMARY:
>> 1) There is no need to constrain ka and ke for a nonparametric
>> estimation with nonparametric simulation. However, as constraining
>> does not hurt, I would still constrain ka and ke, since
>> interpretation of mean parameters is easier.
>> 2) For nonparametric estimation, ka and ke should be constrained at
>> the individual level, if means and SDs (etc.) are to be computed from
>> the list of support points (as commonly done).
>> 3) Constraining ka and ke at the individual level and estimation of a
>> full var-cov matrix seems most appropriate for parametric EM
>> algorithms and for nonparametric estimation with subsequent
>> parametric Monte Carlo simulations.
>>
>> Hope these comments are helpful despite their length.
>> Nick, I would agree that in many cases, fortunately the issues
>> mentioned above only have a minor practical impact.
>>
>> Best wishes
>> Juergen
>>
>>
>> References: [1] Bauer RJ et al. AAPS Journal, 2007, 9(1): E60-E83.
>> See bottom left and right column on page E64.
>>
>> [2] Schumitzky A . EM algorithms and two stage methods in
>> pharmacokinetics population analysis. In: D'Argenio DZ , ed. Advanced
>> Methods of Pharmacokinetic and Pharmacodynamic Systems Analysis. vol.
>> 2. Boston, MA : Kluwer Academic Publishers ; 1995 :145- 160.
>>
>> ------------------------------------------------------
>> Jurgen Bulitta, Ph.D., Senior Scientist
>> Ordway Research Institute, Albany, NY, USA
>> ------------------------------------------------------
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: owner-nmusers
>> [mailto:owner-nmusers
>> Sent: Friday, August 07, 2009 5:03 PM
>> To: nmusers
>> Subject: Re: [NMusers] Code to avoid flip-flop kinetics
>>
>> Hi,
>>
>> I agree with Leonid -- especially this:
>>> If population K and KA are close, then it is unclear why individual
>>> K and KA should be consistently ordered as K < KA and not vice versa
>>> for some subjects. If so, why not to allow the model to decide
>>> whether to have flip flop or not?
>> I do not understand what the concern is with flip-flop kinetics and
>> why people want to force K<KA. If you have a good reason then various
>> methods are available (as reviewed again by Paulo).
>>
>> I wonder if someone would like to describe why it is of interest to
>> force K<KA?
>>
>> Nick
>>
>> Leonid Gibiansky wrote:
>>> Paolo,
>>> Option 1 is very helpful. Option 2 is not attractive for the reason
>>> that you stated, especially, extra correlation introduced by this
>>> trick. If used, it should be used with the full OMEGA block
>>> (CL-V-KA). I used it once but only as the last resort when nothing
>>> else worked. I have not tried option 3 but this option artificially
>>> restricts distributions, so I am not sure whether it is good or not
>>> even when it is working.
>>>
>>> On the other hand, if population K and KA are sufficiently far
>>> apart, you are unlikely to get individual K and KA flip-flopped.
>>>
>>> If population K and KA are close, then it is unclear why individual
>>> K and KA should be consistently ordered as K < KA and not vice versa
>>> for some subjects. If so, why not to allow the model to decide
>>> whether to have flip flop or not?
>>>
>>> I would try to use option (1), and if you like the model, diagnostic
>>> plots, etc, I would not worry about individual K and KA relation.
>>> One of the diagnostics could be the fraction of patients with the
>>> flip-flop. If it is small, this would justify the approach. Another
>>> possible diagnostic is ETA_KA - ETA_K differences, If it is close to
>>> normal you are OK, if it has two mirror-symmetric (relative to the
>>> y-axis) peaks, then flip flop is interfering with the model.
>>>
>>> Thanks
>>> Leonid
>>>
>>> --------------------------------------
>>> Leonid Gibiansky, Ph.D.
>>> President, QuantPharm LLC
>>> web: www.quantpharm.com
>>> e-mail: LGibiansky at quantpharm.com
>>> tel: (301) 767 5566
>>>
>>>
>>>
>>>
>>> Paolo Denti wrote:
>>>> Dear NMUsers,
>>>> having to deal with the flip-flop kinetics phenomenon, I had a look
>>>> at previous posts on the NMusers list.
>>>> I found this post particularly enlightening:
>>>> http://www.cognigencorp.com/nonmem/nm/99aug072003.html
>>>>
>>>> Some code was proposed to avoid the flip-flop at population and
>>>> individual level. Here's a not-so-brief summary.
>>>>
>>>> This parameterization solves the issue at population level:
>>>> CL=THETA(1)*EXP(ETA(1))
>>>> V=THETA(2)*EXP(ETA(2))
>>>> TVKE=THETA(1)/THETA(2)
>>>> TVKA=TVKE+THETA(3)
>>>> KA=TVKA*EXP(ETA(3))
>>>>
>>>> However, it does not prevent the phenomenon occurring at individual
>>>> level. Vlamidir Piotrovsky proposed the code below, which does
>>>> solve the problem at individual level, but makes the interpretation
>>>> of the results a bit awkward and introduces correlation among the
>>>> model parameters. In particular, variance of ETA3 was greatly
>>>> increased.
>>>> CL=THETA(1)*EXP(ETA(1))
>>>> V=THETA(2)*EXP(ETA(2))
>>>> KE=CL/V
>>>> KA=KE+THETA(3)*EXP(ETA(3))
>>>>
>>>> Another approach, suggested by Nick Holford, implements error
>>>> recovery using EXIT 1. The code is reported below:
>>>> CL=THETA(cl)*EXP(ETA(cl))
>>>> V=THETA(v)*EXP(ETA(v))
>>>> KA=THETA(ka)*EXP(ETA(ka))
>>>> K=CL/V
>>>> IF (KA.LE.K) EXIT 1 101 ; try again (PREDERR message error code 101)
>>>>
>>>> As far as I understand, this interrupts the computation whenever
>>>> the flip-flop occurs and lets NONMEM restart. However, if such an
>>>> error arises at initialization, NONMEM does not recover and the run
>>>> goes no further. Nick probably experienced something similar, but
>>>> apparently received no answer
>>>> http://www.cognigencorp.com/nonmem/nm/99oct072004.html
>>>>
>>>> Does anyone know of a way around this drawback? Or have other code
>>>> to deal with flip-flop kinetics?
>>>>
>>>> Thank you in advance,
>>>> Paolo
>>>>
>>>>
>>>> --
>>>> ------------------------------------------------
>>>> Paolo Denti, Post-Doctoral Fellow
>>>> Division of Clinical Pharmacology
>>>> Department of Medicine
>>>> University of Cape Town
>>>>
>>>> K45 Old Main Building
>>>> Groote Schuur Hospital
>>>> Observatory, Cape Town
>>>> 7925 South Africa
>>>> phone: +27 21 404 7719
>>>> fax: +27 21 448 1989
>>>> email: paolo.denti
>>>> ------------------------------------------------
>>

--
------------------------------------------------
Paolo Denti, Post-Doctoral Fellow
Division of Clinical Pharmacology
Department of Medicine
University of Cape Town

K45 Old Main Building
Groote Schuur Hospital
Observatory, Cape Town
7925 South Africa
phone: +27 21 404 7719
fax: +27 21 448 1989
email: paolo.denti
------------------------------------------------
Received on Wed Aug 12 2009 - 11:49:25 EDT

The NONMEM Users Network is maintained by ICON plc. Requests to subscribe to the network should be sent to: nmusers-request@iconplc.com.

Once subscribed, you may contribute to the discussion by emailing: nmusers@globomaxnm.com.