create a programming workflow for ADPC ADPP ADNCA(12h)

[koegerr]

goal: create a programming flow for ADPC and identify any potential new functionality.

• [x] Create dummy PC domain
• [x] Create dummy PP domain
• [x] #849
• [x] #850
• [x] #851

[bundfussr]

CDISD has just released a guidance for this: ADaMIG_for_Non-compartmental_Analysis_Input_Data_v1.0.pdf

[MichaelRimler]

Specifically for generation of plasma PK NCA parameters, I have experience and am happy to share this experience if needed. I have a suite of SAS macros to generate these parameters. Line of sight:

• Modular-lite approach
• over 80 parameters intended to replicate WinNonLin Phoenix calculations and consistent with Pharmacokinetic & Pharmacodynamic Data Analysis: Concepts and Applications, Gabrielsson and Weiner, 4th ed.
• Variety of AUC, AUMC, MRT, and other calculations (Cmax, Tmax, tau, etc)
• Choice of 4 trapezoidal methods for AUC calculation
• All 3 administration (IV Bolus, IV Infusion, Extravascular)
• Assumes a well defined concentration profile and terminal phase
• Does not calculate the terminal phase based on WNL rules (Highest r2 > 80%, >=3 points, etc). This requires pharmacokineticist review of the deterministic solution for the identification of the appropriate terminal phase.

SAS macros could provide some reduction in effort to derive here Some packages already exist in CRAN that would require evaluation for building from or cherry-picking code

Let me know if I can help.

[RealSlimMahdi]

Hi @MichaelRimler,

Antonio (tonirodriguezcontesti@gmail.com) Kindly shared with us a simulated PC by email. I guess you can try to run your SAS programs on this to see what's come out. I think Antonio intended to also create PP from his PC, maybe you could align with him first? Anyhow, the more parameters and the more realistic look the data the better! But don't spend too much time on this: maybe it would be good to have core team POV on this?

PC.zip

[MichaelRimler]

I've tried to simulate PC before - the challenge is they are not time independent...C(t) depends on C(t-1)! Much more difficult than simulating glucose values from Week 4 to Week 8. I'll take a look, but it won't be a quick turnaround...hope that's ok.

[RealSlimMahdi]

PC has already been simulated by Antonio, the file is available in my previous message. If you like you can try to derive PP from this PC ? In our company, we use WinNonlin for that so we don't really have some sort of script doing that ^^

[MichaelRimler]

We have a separate PK group here that derives the NCA parameters - I presume they use WNL. Yes, I can look to derive some parameters to evaluate the integrity of the PC simulated data, but it will take some time for me to find the bandwidth for hands on work like that (I haven't used these macros in some time!)

[MichaelRimler]

@RealSlimMahdi I suggest to update the EX data as follows:

1. Change EXROUTE to ORAL instead of the current TRANSDERMAL. This removes a level of complexity we don't need for our purposes. The current data is a continuous extravascular administration. With this type of administration, your PK concentration could increase because it continues to absorb through the patch. When you take an oral dose, the only addition of analyte to your body is that pill/capsule. So any accumulation and decline along the plasma PK concentration profile is due to the body's processing of the pill. For simplicity, I suggest to change the route of administration to an oral capsule (single, instantaneous administration).
2. Include TIME of administration in EXSTDTC (and EXENDTC). We need the time of administration, not just date of administration, so we can calculate actual time (in minutes) relative to dosing. This is the true horizontal axis on a PK Concentration Profile. This should be set to a reasonable time relative to the PK draws Given the assumption of nominal PK draw timepoints of 30min predose and 5min post-dose, I would expect EXSTDTC to be about 5 min prior to the first PK draw
3. Set EXSTDTC=EXENDTC to reflect that the dosing not administered over an interval. (IV infusion has different PK properties relative to IV Bolus, for example).

I have not looked closely at DM. So far PC looks ok - no requested changes yet.

Some other notes:

• As the the PC synthetic data is only for the BASELINE visit, we will only have PK profiles for the first dose (which is fine)
• It is noted that EXDOSE is the same level for all subjects at baseline (not on PBO), which is good because all PK Concentration curves are near to each other. We would expect higher doses to reflect a higher PK concentration curve (at least a higher Cmax)
• I have not checked consistency of EX and PC (only those on PBO should have all BLQ profiles)...but other elements seem internally consistent. It is a property we should have on the synthetic data.
• Overall, the PK concentration profiles otherwise look ok - I'll know more once I can derive actual time from dosing and start to generate NCA parameters (e.g., calculate the terminal phase).
• REQUEST It would be helpful if pc.rda could also be provided as PC.XPT (version 5) so I don't have to hop between platforms and environments (since I am doing this with SAS at the moment).

[RealSlimMahdi]

Created tasks for this issue to clarify a bit the upcoming PR + Labels.

Thanks, @MichaelRimler, for having a look at this. I can see your passion for PK, an uncommon quality 😄 ! I agree with your comments, which perfectly make sense. I also had a couple of comments in a PR for admiral.test: Having Different Analytes -> PCCAT Having Different specimens -> PCPSEC (for instance, Urine in addition to Serum) Add Noise in Status -> PCSTAT Add Maybe vomit flag, maybe like 1-2% of the specimen?

But those are nice to have, and the current PC already allows us to code without using study data, which is excellent. However, having the PC and PP as close as possible to reality would help catch special cases (Maybe Long term Objective?).

[MichaelRimler]

@RealSlimMahdi I'd think about a MVP for the test data - the vomit flag may be more complexity than needed, where there may be other important elements to consider. But, that depends on the scope of admiral here. If it will not derive NCA parameters, then I think enabling ADPP is difficult (teams will receive their parameters in different formats, hence we either must make assumptions which may reduce robustness across orgs). However, if we will derive NCA parameters, then we must think about jitters on our actual date/times of PK draws because AUC(0-48) and AUC(0-last) need not be the same (and may depend on the terminal elimination rate being estimable in order to derive. Another is enabling the PC test data to properly account for increases in dose (but in a way that allows dose proportionality to be assessed). Still another is whether we want to allow for multiple dosing to enable steady state analyses (I think this is not needed for MVP).

[MichaelRimler]

@RealSlimMahdi Please find attached plasma NCA PK parameters and data defn with some assumptions:

• First dose timing is hardcoded to be midnight (00:00) [given current EX data]
• Extravascular administration (different from current EX)
• Test data has no BLQ between Measurable concentrations (no imputation rules needed)
• Test data has all first PK draws post-dose as measurable
• Single dose administration (not multiple dose, no steady state)
• Single dose level (no dose proportionality assessment)
• Clearance and Volume of Distribution normalization factor assumed F=1
• Terminal elimination phase selected as highest r-squared with >=3 pts from t_last back up to and possible including t_max. No manual/visual review of PK profiles (though they are all very similar in shape)
• No condition of r2 >= 80% - indeed some are <.8 and some are quite low. Study teams may actually reject some of these, but they are retained here.
• Four trapezoidal methods for AUC calculations are included

UPDATED to correctly include 4 trapezoidal methods and summary stats for the example of Linear Log Trapezoidal method @RealSlimMahdi pkpar.xlsx

[toni-1991]

Hi Michael,

I created the PC data and had adjusted a bit since then. I had noise in the past to each entry at random, now I added the random noise into the theoretical elimination and absorption rate, to not have the random ups and downs.

I also modified a bit the BLQ behavior (first data set was having numerical PCSTRESN = 0 instead of missing) that usually depends on SAP, that indicate how the BLQ should be handle, so you have more experience than me on that topic, so correct me if I'm wrong, but usually what I had seen is to set only BLQ pre-dose to 0, since the others are considered to be BLQ (lower than certain threshold), but not 0.

Regarding your comments, I agree, the data is not the best to work on pharmacokinetics, we have first patch during 14 days, but the second using 100 days, so since I had no idea how to handle that, I used only first visit. So due to that, I think that Single dose administration assumption is ok. I used EXDOSE to calculate the "volume" needed as input to calculate the PC concentrations, so meanwhile it's a constant EXDOSE, it will be a constant dose level. There are no BLQ with this model in between measurable concentrations.

I add in here also the PP that I created using the data. I only calculated cmax, tmax, lambda for elimination, half life, auc 0 last, auc 0-inf.

I will add xpt versions, since you mention that they work best for you.

Kind regards, Antonio pc and pp.zip

[MichaelRimler]

@RealSlimMahdi and @toni-1991 I see the updated concentrations.

c_max, t_max: We are matching on CMAX and TMAX (the easy ones).

lambda-z, half-life: I match your lambda-z, when I force all points from t_max to t_last in the terminal phase (4 points for all profiles). Given these profiles, the only other option is 3 points, which yields an r^2=1, but it is technically higher. So, since my code selects the best fit (based on R^2, but should it be adj-r^2??) as the starting point (without a manual review), we will not match. Note that your approach includes t_max in the terminal phase, and that is also not usually the case.

AUC(0-last): I see you are using Linear Up Linear Down for trapezoidal method. Under that assumption, we match on partial AUCs (from timepoint to timepoint), however I think your algorithm adds a little triangle from t=0 to t=0.08 when concentrations increase from BLQ to something measurable. I am not sure which is correct - so I will dig more. I think you are...but I also have confidence in these SAS macros - hence there must be some user error on my side occurring as I dust them off.

AUC(0-inf): We will not match because it depends on the terminal elimination rate parameter lambda-z

In sum - from a test data perspective, you seem to have good enough PC and code for deriving PP to create ADPC and ADPP at some level. There are some nuances that may need to be considered. Please let me know if there's any other information I can provide to enable the test data. If admiral decides to include derivations of NCA parameters, I'd be happy to consult to ensure a robust package (and consistent with WNL Phoenix). There are also other open source R packages for NCA out there and some seem to have decent reviews (though I do not know how robust they are to different modeling assumptions).

Best of luck!

[MichaelRimler]

@toni-1991: For AUC(0-last) and, I imagine, AUC(0-inf), there were 2 issues:

1. My error in properly preparing the PKCONC (pk concentration) and ACTUTMN (Actual time) for inclusion. My pre-dose was set to missing and dropped - should have been 0 (as you now have).

This brought us close, but still no match.

2. The discrepancy is driven by the first post-dose timepoint. The easiest way to describe is that you seem to use nominal time (5min = 0.08 hours), but I use actual time (PK draw minus dose = 5 min >> 5/60 = 0.083333333). Actual time should be used, and unrounded.

Regardless, this doesn't impact your ability to generate meaningful test parameters to map ADPP within admiral, but it is an issue if admiral will derive any parameters itself. Case closed and THANK YOU for contributing to admiral (@RealSlimMahdi too)!

[billdenney]

Hi everyone, I'm new to admiral, but I have relevant experience for this as the author of the PKNCA R package (https://github.com/billdenney/pknca). The PKNCA package computes NCA parameters from datasets that mirrors something close to an SDTM.EX, SDTM.PC and creating something close to an SDTM.PP result. All of these say "something close" because the package is designed around the intent of SDTM interaction, but its goal is also to support work outside of clinical trials (e.g. an academic site).

As I'm reading through the comments here, I think that the underlying issue of generating PC and PP data has been resolved. But, I wonder if PKNCA could be a good intermediate step in the process here. It could be used to automate the calculations of PP results moving from PC/EX to PP.

As an aside on the BLQ values, my experience has been that BLQ is converted to 0 and that the subsequent use or ignoring of the value happens within the software used for NCA calculations. I would guess that this is dependent on the sponsor/workflow, though.

[MichaelRimler]

@billdenney Perhaps you and I could discuss your package and its features, relative to what I had implemented in SAS. Many groups rely on WinNonLin for NCA (blood and urine), but I think there's a real opportunity to deliver both the engine of parameter calculation, as well as a shiny interface on top (which could enable terminal phase determination).

[billdenney]

@billdenney Perhaps you and I could discuss your package and its features, relative to what I had implemented in SAS.

I'm happy to chat (here, in a PKNCA issue, or one-on-one). I also think that more cross-validation of algorithms is helpful for confirming accuracy.

Many groups rely on WinNonLin for NCA (blood and urine), but I think there's a real opportunity to deliver both the engine of parameter calculation, as well as a shiny interface on top (which could enable terminal phase determination).

WinNonlin is definitely the most used, but there are a growing number of alternatives (mostly open source). For the half-life, usually the calculations are done by a curve stripping algorithm and followed up with manual confirmation; PKNCA implements this standard method (https://cran.r-project.org/web/packages/PKNCA/vignettes/Half-Life-Calculation.html).

A shiny app is an often-requested feature by PKNCA users, and I would love to collaborate to create one.

[koegerr]

@RealSlimMahdi : do you have an update on this. We are wondering where we at with this. Maybe reach out to Thomas to quickly catch up.

[RealSlimMahdi]

@koegerr Sorry I had to deal with other high-priority matters, I think I should be able to allow more time this week or the week after. I'll try to chat with @thomas-neitmann later this week

[RealSlimMahdi]

Actually, I had a quick look and I still need the branch in admiral.test to be merged. This is blocking one of your tests and I cannot build the doc.

[bms63]

Since we have issues created for adnca and adpc I am going to close this out. I linked this in those two issues as well in case this discussion is relevant.

[VincentBuchheit]

Hi everyone - joining the PK task force :-) ADPC and ADNCA are for me the same, i.e. input dataset for Pharmacokinetic analysis

Regarding ADPP, I propose that we don't try to create PP in Admiral. There are already great tools/packages (PKNCA, Phoenix....) for this purpose. We should aim to create ADPP from the existing PP SDTM dataset.