-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SD and geoSD of ratio of PK parameters for population simulations seem to be wrongly calculated #536
Comments
@Yuri05 Can you confirm? |
Wrong person to ask 😄 |
@AnnikaRPS |
That's true, in case the reference and the comparator population are the same (e.g. in DDI scenarios), statistics on the individual ratios are more precise |
Yes. I do confirm. The equations given above calculate an estimate of the respective statistic of the distribution of the ratio. This is only applicable in case that indviduals differ between the two populations to be compared. Please note that we need in all other cases (same population is compared under different scenarios, e.g. DDI), we DEFINITELY need the statitiscis over the individual ratios, i.e.Let's say we are interested in the ratio of the AUC (AUCR):Let AUC_x be n AUC values of scenario x, and AUC_y be n AUC values of the reference scenario y. geoMean_AUCR = geomean(AUC_x/AUC_y) = exp(mean(log(AUC_x/AUC_y))) arithMean_AUCR = mean(AUC_x/AUC_y) quantile_q_AUCR = quantile(AUC_x/AUC_y, q) with q being the q th quantile between 0 and 1 |
OK, that means that for every calculation of PK-Ratios between 2 SimulationSets: RE must check if the used population is the same or not and depending on that use the appropriate calculation. |
Derivations of equations provided by @AnnikaRPSBeing Arith. MeanApplying the first order taylor expansion to Arith. SDApplying the first order taylor expansion to For the geometric statistics, things are easier since the logarithm already linearizes the issue. GeoMeanDefine new random variable z as the ratio x over y: log transform both sides: take the mean: exponentiate both sides: Left hand side is geoMean of z: With GeoSDDefine new random variable z as the ratio x over y: log transform both sides: take the variance: transform to standard deviation: exponentiate both sides: Left hand side is geoSD of z: With |
YES! |
CASE 1: same population is compared under different scenariosLet's say we are interested in the ratio of the PK Parameter
with q being the q th quantile between 0 and 1, i.e. 0.05, 0.25, 0.5, 0.75, 0.95 CASE 2: different populations (population 1 and 2) are comparedLet's say we are interested in the ratio of the PK Parameter Analytically (via First order Taylor expansion)
For quantiles, this is however not straight-forward, thus @abdullahhamadeh had in a brief chat about it the idea to solve the issue via MC sampling. MC samplingThis method is needed for quantiles and might be even superior to first order Taylor expansion, in particular for arithMean and arithSD. Let B the number of replicate samples (e.g. 10000). Exemplary R code:
Are we ready to implement? Any objections against the MC sampling method? @Yuri05 @abdullahhamadeh @pchelle @msevestre @PavelBal @AnnikaRPS @Christoph27 |
SUMMARYAfter some discussione with @AnnikaRPS, we here now present the desired implementation. Population workflow: PARALLEL COMPARISON (with 1 reference population)Let's say we are interested in PK Parameter The following tables should be reported: Table 1: PK_Param - Population Statisctics
Table 2: PK_Param - Population Statistics compared to the reference: Population 1 (of size n1)
In Table 1 the statistics reflect simply the given statistic over the respective PKParam values in each population,
with q being the q th quantile between 0 and 1, i.e. 0.05, 0.25, 0.5, 0.75, 0.95 In Table 2 the statistics reflect the relative change in the respective statistic,
with q being the q th quantile between 0 and 1, i.e. 0.05, 0.25, 0.5, 0.75, 0.95 Thus, the comparisons of the statistics itself becomes a standard output (not only for ratio comparison workflows). Population workflow: RATIO COMPARISONThe tables Table 1 and Table 2 from the "Population workflow: PARALLEL COMPARISON (with 1 reference population)" as descibed above should also be part of the output for this workflow. CASE 1: same population is compared under different scenariosLet's say we are interested in the ratio Table 3: PK_Param Ratio - Population Statistics on the ratio of PK_Param with the reference: Scenario x (of size n).
In Table 3 the statistics are calculated as follows on the "individual" ratios,
with q being the q th quantile between 0 and 1, i.e. 0.05, 0.25, 0.5, 0.75, 0.95 CASE 2: different populations are comparedLet's say we are interested in the ratio of the PK Parameter Table 3: PK_Param Ratio - Population Statistics on the ratio of PK_Param with the reference: Population 1 (of size n1).
Now, in Table 3 the statistics are calculated as follows,
For the geometric statistics, well-defined analytical solutions exist:
For the arithmetic and percentile statistics, we approximate the ratio statistics via MC Sampling:Let B the number of replicate samples (e.g. 10000). Exemplary R code:
@Yuri05 @abdullahhamadeh @pchelle @msevestre @PavelBal @AnnikaRPS @Christoph27 |
Looks good, no objections from my side. For pediatric workflows, parallel comparison (with 1 reference population) would be the default |
@Yuri05 : not only a feature. For workflow "ratioComparison", it is a bug. The current results are not at all what would be expected by any user. |
@sfrechen 1- How do you assert that 2 populations are "the same" ? 2- In the report, do you want the analytical solution for geomean, geosd, etc. or would Monte Carlo solution be better ? 3- I will add 2 settings for the Monte Carlo sampling in the task |
Ideally, we would check some kind of checksum / hash of the population file. Sometimes (due to automization) we have different file names with the same content...
Great. Monte Carlo solution should be default.
Sounds very reasonable. Great! |
Can you give an example of a use case, where this could happen? 2 different population files with de-facto the same population?
Yes, sure :) |
We have plenty of them (I would say) |
Can you give some concrete examples? For me it sounds more like a user error. Instead I would e.g. load populations into dataframes and compare them numerically. |
No, no use error. Concretely: We have pool of virtual individuals. Then a script generates the different work packages with certain instructions which individuals to pull from this pool, creates the pkml files etc. Finally, the script saves everything in folders and gives matching names to poulation and pkml file... |
This comment was marked as outdated.
This comment was marked as outdated.
…s if same population
The ratio of PK parameters for population workflows seems to be calculated as the ratio of the respective summary statistics of the population of interest and the control population, e.g. if the case example compares a pediatric population to an adult population the ratio summary parameters are calculated as:
mean of ratio = mean_pediatric/mean_adult
geomean of ratio = geomean_pediatric/geomean_adult
SD of ratio = sd_pediatric/sd_adult
geoSD of ratio = geosd_pediatric/geosd_adult
This calculation of ratios is an appropriate approximation in case of mean and geomean but wrong for SD and geoSD. Here, the delta method is needed.
For the arithmetic SD this would be:
z = x/y
dzdx = 1/meanY
dzdy = -meanX/meanY^2
meanZ = meanX/meanY
sdZ = sqrt(dzdx^2 times sdX^2+dzdy^2 times sdY^2)
For the geometric SD this would be:
z = x/y
geomeanZ = exp(log(geomeanX)-log(geomeanY))
geosdZ = exp(sqrt(log(geosdX)^2+log(geosdY)^2))
The text was updated successfully, but these errors were encountered: