The 24-hr AUC/MIC ratio

The trough level is but a surrogate marker for the true pharmacodynamic parameter for vancomcyin, the 24-hr AUC/MIC ratio. The target vancomycin trough level of 15-20 mg/liter was chosen in the 2009 vancomycin TDM guidelines to maximize the likelihood of achieving a 24-hr AUC/MIC ratio of >400 mg·h/liter.

Targeting the trough level has been criticized as trough concentrations underestimate the true AUC by 25% on average. Recent pharmacokinetic data suggest that the majority of patients can achieve AUC values of >400 with trough concentrations less than 15.

Although controversy remains regarding whether vancomycin has a direct toxic effect, vancomycin-associated nephrotoxicity has been linked to troughs greater than 15. Monitoring vancomycin by AUC would be expected to reduce unnecessarily high exposure and thus reduce nephrotoxicity.

Although clinical data suggest that targeting the daily vancomycin AUC above 400 will ensure efficacy, the AUC range associated with nephrotoxicity has not been clearly defined. Based on current data, it appears prudent to maintain the AUC below 600 (and trough below 20).

PK software

Since 2004 all of RxKinetics PK software has performed PK/PD parameter calculations. Unfortunately this feature was hidden behind a button in APK and AbPK. It makes me wonder how many folks using the software have missed this feature.

With that in mind, I’ve moved the AUC calculation in APK up front. No longer hiding behind a button, AUC is displayed along with the predicted peak and trough levels.

In addition, a Targeted AUC dialog has been added. This new dialog is accessed via the Tools menu.

The Targeted AUC dosing dialog does precisely what the name implies. Enter a target AUC and an ideal dose is calculated. This isn’t rocket science. The ideal interval is the half-life plus infusion time (usually one hour), plus distribution time (one hour). Ideal dose is then calculated with the AUC equation rearranged to solve for dose. After entering a practical dose and interval, the predicted 24-hr AUC, peak, and trough are displayed.

The PK/PD dialog remains unchanged, and is (still) accessed by the PK/PD button (or via the Tools menu).

Click Save on this dialog to copy the appropriate pharmacodynamic parameter. As detailed above, the 24-hr AUC/MIC ratio is the most useful parameter for vancomycin. For aminoglycosides, the peak/MIC ratio is the best predictor of efficacy.

Recommended reading

1. Zasowski E, Murray K, Trinh T, Finch N, Pogue J, Mynatt R, Rybak M. Identification of Vancomycin Exposure-Toxicity Thresholds in Hospitalized Patients Receiving Intravenous Vancomycin. Antimicrob Agents Chemother. 2017 Dec 21;62(1).
2. Chavada R, Ghosh N, Sandaradura I, Maley M, Van H. Establishment of an AUC0–24 threshold for nephrotoxicity is a step towards individualized vancomycin dosing for methicillin-resistant Staphylococcus aureus bacteremia. Antimicrob Agents Chemother 61 (5). 2017 Apr 24.
3. Pai M, Neely M, Rodvold K, Lodise T. Innovative approaches to optimizing the delivery of vancomycin in individual patients. Adv Drug Deliv Rev. 2014 Nov 20;77:50-7.
4. Andrew DeRyke, C & P. Alexander, Donald. Optimizing Vancomycin Dosing Through Pharmacodynamic Assessment Targeting Area Under the Concentration-Time Curve/Minimum Inhibitory Concentration. Hospital Pharmacy. 2009 44. 751-765.

Users of rxkinetics.net have been contributing to a large data set for the past three years. The web app has been saving anonymous data from serum level analysis during this time. See this blog post: The BBVM project part II.

It is important to state up front that there is no quality control over this anonymous data. Some of it could have been entered incorrectly. Also there is no way to know how much is real patient data versus someone experimenting with the web app.

The other problem with this type of data collection is that many don’t “run the numbers” when the results are within target range. Therefore, outliers tend to become more prominent in the data set.

With those caveats in mind, let’s examine the data.

Let’s delve into the statistics from the two largest groups.

BMI 19-30

The raw Vd histogram follows a normal distribution (as a large sample should).

But the histogram for Vd L/kg total body weight (TBW) has a noticeable negative (left) skew.

Because Vancomycin does not distribute well into adipose tissue let’s look at Vd L/kg of adjusted body weight (ABW), where ABW = LBW + 40% of the difference between TBW and LBW (i.e., the weight we used to dose Vancomycin “back in the old days”).

The histogram of Vd L/kg ABW is noticeably more normal than TBW (but not ideal).

Regression of CL vs CrCl results in a higher r^2 value when we use Normalized CrCl vs LBW-based CrCl, 0.528 vs 0.524. (CrCl Methods explained)

BMI > 30

As with the previous group, in obese patients the histogram for Vd L/kg of ABW has a more normal distribution than TBW.

The r^2 improvement is even greater in obese patients when using normalized CrCl for the Kel regression, 0.533 vs 0.412.

Summary
Again, since the data is not verified this analysis is debatable. However it does pose a couple of questions:

• Should we use adjusted body weight when modeling Vancomycin volume of distribution?
• Should we use normalized creatinine clearance when modeling Vancomycin elimination rate?

This is a feature that I have wanted to add to my PK programs for quite sometime. In the real world doses don’t get hung on time and dosages get changed before levels are drawn.

Complex is the keyword. This was incredibly complex to code, both the logic of data entry and analysis. It has taken weeks of intense work to complete. Currently in the testing phase, I hope to bring it to production soon.

When you select “Complex non-steady-state analysis” the program displays two grids, one for entering doses and the other for serum levels.

You may enter up to five doses of various amounts, given at different rates and at different times. You may enter up to two serum levels. Of course there are limitations (which the data entry routines catch). For example, you cannot enter a date/time for a level that conflicts with a dose date/time.

If the first serum level is drawn before the first dose it will be considered a baseline level. This is also something that I have wanted to add for years. It will be most useful when performing a follow-up pk consult on a long-term patient.

Another feature added from my to-do list is the ability to select an infusion rate for your recommended dose.

You will still see Bayesian fails. This new data entry methodology will not prevent them from happening. That is the nature of Bayesian and the highly variable nature of Vancomycin kinetics.

Even people who have used my programs for years fail to comprehend what Bayesian analysis involves. The first thing to realize is that Bayesian analysis begins with your population model. It then attempts to fit your measured levels to incremental variations of your population model. In classic Bayesian, if the data cannot be fitted to the model within reasonable statistical limits, then the data is thrown out. I do not believe that rule should be applied to clinical pharmacokinetics. So I leave it up to you to decide how to proceed by showing the “Bayesian analysis failed” dialog.

Essentially this dialog is telling you that your measured level differs too much from the model predicted level. You can find out what level the population model predicted by visiting the prospective tab. If you measured 6 but the model predicted 24, then never the twain shall meet. Either (1) you have chosen the wrong model for your patient, or (2) the measured level is wrong. That is your decision, not one to be made by a computer program, period.

Pulled an all nighter to update both the Windows and the Web versions of KinPlot. This is a simple tool for learning pharmacokinetic concepts by depicting the effects that various pk parameters have on serum levels, leading to a better understanding of drug regimen design.

I had a request for IV push modeling from a Cornell professor. The simplest solution was to utilize a 6 minute infusion to approximate IV push administration (the math is easier with decimals, i.e., 6 min = 0.1 hr).

Since they use Macs I needed to update the Web App as well.

Web version here.

The Windows version adds a few more bells and whistles: the ability to model oral pk and to save/load graphs.

Windows version here.

Enjoy.

I’ve spent much of my ‘free’ time during the last month been pouring over error reports received during the past year. Unfortunately most of the reports are vague and completely untraceable as to their cause. Focusing on the most commonly reported errors I’ve tried to deduce their causes, but I’m likely to be completely off base.

TfrmMain, TfrmPrint: EConvertError
‘Not a valid floating point value’. All of these error reports came from version .18. This was fixed in version .19 by changing all calls to StrToFloat to TryStrToFloat. Come on folks, updates are free, please keep your copies up-to-date.

TfrmMain: Range check error
There were several Range errors which I believe originate in the Topaz database engine (no trace available). I re-compiled Topaz with Range checking turned off, hopefully that will tone down the frequency of these error reports.

TfrmPrint: Multiple errors
Multiple errors were reported originating in the TfrmPrint class. Procedures flagged include: SaveConsult, SaveLevels, SavePatient, ValidPatData, GraphPrep, and ReDrawSerumLevelPlot. Hopefully recompiling Topaz will fix most of the Save errors. But, to add another layer of safety, I’ve added try..try..except..finally blocks to each procedure and changed the SerumLevel array from fixed to dynamic.

TfrmMonitor: No default printer selected
This was reported twice. I cannot imagine how or why someone would not have a default printer selected in Windows. Regardless, I’ve added this tiny bit of code to hopefully catch that condition (unfortunately I have no way of testing this):
if (Printer.PrinterIndex > 0)then
begin
// Print the consult
end;

TfrmPKPD: Division by Zero
The function AUC was flagged in one report. I cannot imagine how this procedure gets called without valid parameters, but, once again, I added try..try..except..finally block that will prevent the program from crashing.

TfrmLevels; EConvertError
‘is not a valid integer value.’ Sounding like a broken record, I simply cannot imagine how this procedure gets called without valid parameters, regardless I changed StrToInt to TryStrToInt in hopes of fixing this impossible error.

TfrmMain: Pack date invalid
This error came up twice, with no traceable cause. Because the user is able to change date settings in Windows at will, I assumed an incompatible date format is causing the issue. I added some code to force the short date format into the standard USA: ‘MM/dd/yyyy’. Originally I had declared the OutputBuffer within the var block of the function, but that was causing a memory leak on exit, even after adding a StrDispose in the cleanup (finally) block:
procedure TfrmMain.SavePackDate();
var
APKini : TIniFile;
strDateFormat : string;
strTemp : string;
OutputBuffer: PChar;
SelectedLCID: LCID;
begin
try
// Determine local short date format
OutputBuffer := StrAlloc(255);
SelectedLCID := GetUserDefaultLCID;
GetLocaleInfo(SelectedLCID, LOCALE_SSHORTDATE, OutputBuffer, 255);
strTemp := string(OutputBuffer);
// if first letter is d then set to 'dd/MM/yyyy' else 'MM/dd/yyyy'
if Copy(strTemp, 1, 1) = 'd' then
strDateFormat := 'dd/MM/yyyy'
else
strDateFormat := 'MM/dd/yyyy';
try
APKini := TIniFile.Create(PathName + 'apk.ini');
try
APKini.WriteString('dbMaint', 'Pack date', FormatDateTime(strDateFormat, Now));
finally
APKini.Free;
end;
except
on E:Exception do begin
MessageDlg('Error saving pack date',
E.Message,
mtError, [mbOK], 690, dckActiveForm);
end;
end;
finally
// Free up the string list memory
StrDispose(OutputBuffer);
end;
end;

After I moved the code into an inline function there were no more memory leaks:
procedure TfrmMain.SavePackDate();
var
APKini : TIniFile;
strDateFormat : string;
strTemp : string;
function ShortDateFormat: string;
var
OutputBuffer: array[0..255] of Char;
SelectedLCID: LCID;
begin
SelectedLCID := GetUserDefaultLCID;
GetLocaleInfo(SelectedLCID, LOCALE_SSHORTDATE, OutputBuffer, 255);
Result := OutputBuffer;
end;
begin
try
// Determine local short date format
strTemp := ShortDateFormat;
// if first letter is d then set to 'dd/MM/yyyy' else 'MM/dd/yyyy'
if Copy(strTemp, 1, 1) = 'd' then
strDateFormat := 'dd/MM/yyyy'
else
strDateFormat := 'MM/dd/yyyy';
APKini := TIniFile.Create(PathName + 'apk.ini');
try
APKini.WriteString('dbMaint', 'Pack date', FormatDateTime(strDateFormat, Now));
finally
APKini.Free;
end;
except
on E:Exception do begin
MessageDlg('Error saving pack date',
E.Message,
mtError, [mbOK], 690, dckActiveForm);
end;
end;
end;

Population analysis improvements
I did find some time to make several improvements in this version of APK. The main focus of improvements this go round is the population analysis function. Probably the biggest change is removal of the 500 record limit, it now uses dynamic arrays so the number of records that may be analyzed is virtually unlimited. I added text to display the current model for comparison to the population analysis and a regression line of the current Kel or CL calculation.

APK Population Analysis Report

Finally, I added a median Vd calculation, which is surprisingly complex:

function MedianVd: double;
var
n,i,middle : integer;
TempDouble : double;
TempArray : array of Double;
begin
// Set Length of TempArray
SetLength(TempArray,TotalPatients);
// Copy first column of RegressTable array
for i := 0 to TotalForArray do begin
TempArray[i] := RegressTable[i,0];
end;
// use truncated selection sort to find median
middle := (TotalForArray+1) div 2;
for i := 0 to middle do begin
for n := 1 to TotalForArray-i do begin
if TempArray[n] > TempArray[n-1] then
begin
TempDouble := TempArray[n];
TempArray[n] := TempArray[n-1];
TempArray[n-1] := TempDouble
end
end
end;
// find median
try
if odd(high(TempArray)) then
// when high(TempArray) is odd, there are an even number of elements in array.
// define median as average of two middle values.
result := (TempArray[middle] + TempArray[middle-1]) / 2
else
// when high(TempArray) is even, there are an odd number of elements in array.
// median is the middle value.
result := TempArray[middle];
finally
// Free memory used for TempArray
SetLength(TempArray,0);
end;
end;

As soon as I finish testing I will release this version into the wild. Enjoy.

And here’s my current favorite song (based on a true story), “Who’s the judge to decide how much this world should punish”: