Analysis of Targeted AUC Dosing

Recent evidence regarding vancomycin pharmacokinetics/pharmacodynamics has initiated a paradigm shift in vancomycin dosing from targeting trough concentrations to area under the concentration-time curve (AUC), specifically the 24-hr-AUC/MIC ratio.

Compelling clinical data suggests that targeting a vancomycin 24-hr-AUC/MIC ratio of at least 400 mg · h/liter will ensure efficacy. The 2009 consensus committee on vancomycin TDM made the assertion that the vancomycin trough level is a good surrogate for the AUC, because in most adult patients a steady-state trough concentration of 15 to 20 mg/liter correlates with a 24-hr-AUC/MIC ratio of at least 400 for an organism with an MIC of 1 mg/liter or less.

Since the implementation of the vancomycin consensus guidelines, several studies have documented a higher incidence of nephrotoxicity associated with the more aggressive trough goal. In contrast, a large meta-analysis suggested that a continuous infusion targeting a constant vancomycin concentration of 25 mg/liter is less nephrotoxic than standard intermittent dosing. This can be explained if we attribute the risk of vancomycin nephrotoxicity to the AUC, just as we do for efficacy.

To date the AUC threshold for vancomycin nephrotoxicity has not been clearly defined, 600 to 700 has been suggested. The goal of Chavada et al was to define the upper limit of the vancomycin AUC range. They found that a vancomycin 24hr-AUC of greater than 563 mg · h/liter was associated with significantly increased risk of AKI.

One of the features of APK that I am most proud of is the population analysis tool. Each time you save a consult based on serum level analysis, the pk parameters are saved. This data set is a goldmine of information about your patient population.

The data set presented below is from 1,671 adult general med-surg patients, with 1,078 in the subgroup of BMI less than 30. The vanocomyin pk model used for Bayesian analysis of this subgroup is similar to that used by Chavada.









Patient demographics
Total=1078, F=486, M=592
Ave
Min
Max
Age (years)
61.6
19
99
Weight (kg)
68.1
35.7
114.2
SrCr (mg %)
0.87
0.3
4.8
CrCl (ml/min)
55.7
10
120
Vd (L/kg)
0.72
0.62
0.83
Half-life (hours)
9.2
3.5
46.2

The patient specific pk parameters from this data set were then used to determine a dosing regimen based on either a target trough goal of 15 to 20 or a target AUC goal of 400 to 563. Dosing intervals were based on half-life and converted to a more practical 6, 8, 12, 18, 24 or 48 hours. Doses required to achieve the therapeutic goal were rounded to nearest 250mg whenever possible.

Assuming an MIC of 1 or less, the minimum target AUC was determined to be 400. The upper limit of AUC was set to 563, as determined by Chavada. This target range is displayed within the shaded area in the figures below.

Targeted trough dosing
Doses required in this group ranged from 400 to 2000mg. As we often see in clinical practice, a significant number of regimens (91) did not achieve a trough of 15 within what is considered a safe dose range.

All dosage regimens in the targeted trough group achieved an AUC of at least 400, which confirms the goal of the 2009 guidelines. However, the majority of these doses, 597/1078 (55%), resulted in an AUC above the likely AKI risk threshold.

Targeted AUC dosing
Doses required to achieve the target AUC ranged from 400 to 1500mg.

All dosage regimens in the targeted AUC group also achieved an AUC of 400. No doses resulted in an AUC above the AKI risk threshold. This analysis also confirms previously reported studies which found that, in the majority of patients, an AUC of 400 can be achieved with a trough less than 15. In this analysis, 77% of dosing regimens (831/1078) achieved the AUC goal with a trough 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. Targeted AUC dosing of vancomycin would be expected to reduce unnecessarily high exposure and thus reduce nephrotoxicity.

Reference
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.

Targeted AUC Dosing

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.

Web site revamp

I’ve spent the best part of the last two weeks simplifying rxkinetics.com in order to make the information easier to find. The home page is now a simple link tree, ugly but functional.

All vestiges of the message board, listserv and wiki have been removed. I’ve tried every setting to prevent it, but spammers keep finding ways to post inappropriate topics, mainly PPC (pills, porn, casinos). These features of the web site have never been popular, pharmacists with real jobs don’t have time for them. The only recent postings are from spambots. In the last year it has become completely overwhelming with spam posts every day. I have no time to deal with this idiocy. These vandals are ruining the internet.

RxKinetics.com is still ad-free. I stubbornly refuse to allow advertising on my web site. As a frequent web surfer myself, I hate intrusive ads and consider them another form of spam. I have used AdBlock for years, but many web sites have now installed block detectors and refuse entry to their web site if an ad blocker is in use. I find it disheartening to see this takeover of the web by advertising. Google is the worst offender. I mean, really, how much money do they need? If you want to keep this tiny corner of the web ad free, please buy something, anything, please?

Data Mining

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.

All BMI < 19 BMI 19-30 BMI > 30
Total 2937 180 1808 939
Male 1686 89 1074 523
Female 1251 91 734 416

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

BMI 19-30

Descriptive stats

Age BMI CrCl Vd L/kg TBW VD L/kg ABW
Min 15 19.04 8.0 0.38 0.38
Max 100 30.04 120 0.92 1.21
Mean 60.6 24.8 77.3 0.67 0.72
Median 63 24.6 72.0 0.69 0.73
Mode 65 23.2 120 0.70 0.70
S.D. 18.48 2.96 30.97 0.09 0.11

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

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

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”).
Vd_Adj_BW

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)
Clearance_vs_LBW_CrCl

Clearance_vs_NormCrCl

BMI > 30

Descriptive stats

Age BMI CrCl Vd L/kg TBW VD L/kg ABW
Min 17 30.1 10 0.37 0.45
Max 95 77.7 120 0.91 1.40
Mean 59.2 37.9 73.6 0.67 0.89
Median 60 35.4 71 0.69 0.89
Mode 57 32.4 120 0.70 0.59
S.D. 15.59 8.08 30.41 0.11 0.16

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

Large_Vd_Raw

Large_Vd_TBW

Large_Vd_ABW

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

Large_Clearance_vs_LBW_CrCl

Large_Clearance_vs_NormCrCl

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?

RxKinetics.Net issues

My web host sent out a notification last week that they were changing servers and updating from Windows Server 2003 to 2012.

To make this transition easier for you we have moved your entire account under the new environment using an offline migration meaning that your old website will remain active until you will verify that all your contents/databases have been moved under the new environment and finally switch your nameservers to have your domains pointed over under the new servers.

We are also afraid that as this was an automated process using a migration tool, some web/database contents might not be synchronized between our old and new shared windows servers. We urge you to check your contents as soon as possible and update your connection strings/nameservers as soon as possible to have your entire domain pointed over to the new environment as your old account under the old shared windows server will be removed in 15 days.

Yeah, right, their automated tool failed miserably for me. First of all, they didn’t transfer my old password, so that took 2 days to straighten out.

When I was finally able to log in I noticed they didn’t transfer any of my databases. Really? That took another day.

I changed the database connection string in my webconfig file and FTP’d the updated file to the server.

Then I asked, “how do I test the web site before go live?” The sysadmin responded:

update your name servers from your domain registrar then you test your website working fine on new servers or not.

To which I replied “So you’re telling me I have to go live in order to test it? I’d prefer not to do that if possible. If not, well, I guess I’ll jump in both feet.”

No response, so I did the DNS change. Well, of course it crashed.
rxkinetics_net_500

Much later I received a response from the “good” sysadmin:

You can always test your website using your local hosts file. Simply add the following lines under your C:\Windows\System32\Drivers\etc\Hosts file:
==
XX.XXX.XXX.X rxkinetics.net
==
Then clear your browser cache, flush your DNS and you should be able to browse your website hosted under our new environment before you will have your nameservers updated.

I’ve since switched back to the old DNS, but that take will take another day to revert back to the old server. And I’m worried that it will not actually revert back.

I should have known better. Something like this always happens to me with ASP.NET. Make one little change and it stops working, and doesn’t give any clue as to why. I haven’t touched this code in three years because I didn’t want to break it.

I’m pretty sure it’s a setting on the admin side, which I have no control over. I believe it’s related to this problem I blogged about 3 years ago Fun with ASP dot NET.

Complex non-steady-state analysis

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.
Complex_nonSS

When you select “Complex non-steady-state analysis” the program displays two grids, one for entering doses and the other for serum levels.
Complex_nonSS_data
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.
complex_recommend

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.
Complex_fail
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.

KinPlot Update

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.
KinPlot_web

Web version here.

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

Windows version here.

Enjoy.

Hacked again

Hacked again

Received an email from Google today:

  • Hacking suspected: http://rxkinetics.net/
  • Unfortunately, it appears that your site has been hacked.

What does it mean to have pages marked with the hacked site type “URL injection” in Search Console?

This means a hacker has created new pages on your site, often containing spammy words or links.

Typically, hackers modify your site in one of these ways:

  • By gaining access to an insecure directory on your server. For example, you may have inadvertently left a directory with open permissions. Nope, no anonymous FTP is allowed.
  • By exploiting a vulnerability in software running on your site, such as a content management system. For example, you might be running an older, insecure version of WordPress. Nope, don’t have WordPress or any content management system.
  • By hacking third-party plugins that you use on your site, such as visitor counters. Nope, no 3rd party plugins on this site.

None of the above are true, I believe they discerned my password yet again with a brute force attack.

List of alerts from Google:
Google_analytics_messages

It looks like they’ve been attacking my web site since March when it was defaced:
Page_Not_Found_Errors

Apparently they were searching for pages they could target. They searched for links common on most web sites, e.g. “Cart” and “FAQ” and “Feed back”. None of which exist on this web site.

I removed the spammy content, and changed my password yet again. I plan on changing password every week now. I wonder how long it takes Google to remove my site from their hacked sites list (sigh).

LunarPages support response was helpful, “we are planning to upgrade the Operating System that is used by your shared windows environment within the next months that will ensure that your Operating System is updated and will add a new layer of protection on your website security.” And they scanned my site for malware:
Scan_results

I’m beginning to think all this hassle just isn’t worth it anymore. It’s nearly impossible to get an email through anymore. I’ve resorted to using Gmail as my mail server, but even then many of my emails replies are rejected. My ListServ is a joke, the only requests are from spammers and scammers pushing the 3-P’s (Pills, porn and poker).

The terrorists have won.
Kim_Jong

Hacked!

Got home from a long night at work and checked my email to find this friendly FYI:

Hi Rick,
This is Steve ####.
Hope life is treating you well
FYI- your site rxkinetics.net coming up with “something unexpected” on home page.
Regards,
Steve

So I went to rxkinetics.net and found this lovely NSFW message (without the scambling).

The graffiti

Wow, hacked! Just like the big boys, I feel so special now .

Really? I think these losers would have something better to do than vandalize my insignificant little corner of the internet.

I sent a support ticket to Lunarpages, then discovered that typing in the full url bypassed the graffiti:
http://rxkinetics.net/default.aspx

It was a long night and I was dead tired, so I emailed Steve back and went to sleep.

About noon I woke up and checked my email. There was no reply from Lunarpages, so I got out of bed and dug into the web site files.

There were four suspicious .asp files on the site. They stuck out like a sore thumb because I don’t use .asp files on this web site:

  • pageface.asp
  • sin.asp
  • crx.asp
  • default.asp

None of the correct files were changed. I deleted the four rogue files and the site went back to normal.

Then I changed my ftp password and asked Lunarpages if there was anything else I needed to do. Well, it’s been over eight hours since I started the support ticket and I’ve yet to receive a response from Lunarpages. I’m pretty disappointed, because up to this point, they’ve always been quick to reply and provide help.

All of this makes me wonder if this was an inside job from a disgruntled employee at Lunarpages.

APK 3.1.20

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):

1
if (Printer.PrinterIndex > 0)then
2
  begin
3
     // Print the consult
4
  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:

01
procedure TfrmMain.SavePackDate();
02
var
03
   APKini  : TIniFile;
04
   strDateFormat : string;
05
   strTemp : string;
06
   OutputBuffer: PChar;
07
   SelectedLCID: LCID;
08
begin
09
   try
10
       // Determine local short date format
11
       OutputBuffer := StrAlloc(255);
12
       SelectedLCID := GetUserDefaultLCID;
13
       GetLocaleInfo(SelectedLCID, LOCALE_SSHORTDATE, OutputBuffer, 255);
14
       strTemp := string(OutputBuffer);
15
       // if first letter is d then set to 'dd/MM/yyyy' else 'MM/dd/yyyy'
16
       if Copy(strTemp, 1, 1) = 'd' then
17
          strDateFormat := 'dd/MM/yyyy'
18
       else
19
          strDateFormat := 'MM/dd/yyyy';
20
       try
21
          APKini := TIniFile.Create(PathName + 'apk.ini');
22
          try
23
             APKini.WriteString('dbMaint', 'Pack date', FormatDateTime(strDateFormat, Now));
24
          finally
25
             APKini.Free;
26
          end;
27
       except
28
          on E:Exception do begin
29
          MessageDlg('Error saving pack date',
30
                      E.Message,
31
                      mtError, [mbOK], 690, dckActiveForm);
32
          end;
33
       end;
34
   finally
35
      // Free up the string list memory
36
      StrDispose(OutputBuffer);
37
   end;
38
end;

After I moved the code into an inline function there were no more memory leaks:

01
procedure TfrmMain.SavePackDate();
02
var
03
   APKini  : TIniFile;
04
   strDateFormat : string;
05
   strTemp : string;
06
   function ShortDateFormat: string;
07
   var
08
      OutputBuffer: array[0..255] of Char;
09
      SelectedLCID: LCID; 
10
   begin
11
      SelectedLCID := GetUserDefaultLCID;
12
      GetLocaleInfo(SelectedLCID, LOCALE_SSHORTDATE, OutputBuffer, 255);
13
      Result := OutputBuffer;
14
   end;
15
begin
16
   try
17
      // Determine local short date format
18
      strTemp := ShortDateFormat;
19
      // if first letter is d then set to 'dd/MM/yyyy' else 'MM/dd/yyyy'
20
      if Copy(strTemp, 1, 1) = 'd' then
21
         strDateFormat := 'dd/MM/yyyy'
22
      else
23
         strDateFormat := 'MM/dd/yyyy';
24
      APKini := TIniFile.Create(PathName + 'apk.ini');
25
      try
26
          APKini.WriteString('dbMaint', 'Pack date', FormatDateTime(strDateFormat, Now));
27
      finally
28
          APKini.Free;
29
      end;
30
   except
31
      on E:Exception do begin
32
          MessageDlg('Error saving pack date',
33
                      E.Message,
34
                      mtError, [mbOK], 690, dckActiveForm);
35
      end;
36
   end;
37
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_analysis_report

APK Population Analysis Report

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

01
02
function MedianVd: double;
03
var
04
    n,i,middle : integer;
05
    TempDouble : double;
06
    TempArray  : array of Double;
07
begin
08
    // Set Length of TempArray
09
    SetLength(TempArray,TotalPatients);
10
    // Copy first column of RegressTable array
11
    for i := 0 to TotalForArray do begin
12
       TempArray[i] := RegressTable[i,0];
13
    end;
14
    // use truncated selection sort to find median
15
    middle := (TotalForArray+1) div 2;
16
    for i := 0 to middle do begin
17
       for n := 1 to TotalForArray-i do begin
18
          if TempArray[n] > TempArray[n-1] then
19
             begin
20
                TempDouble := TempArray[n];
21
                TempArray[n] := TempArray[n-1];
22
                TempArray[n-1] := TempDouble
23
             end
24
       end
25
    end;
26
    // find median
27
    try
28
       if odd(high(TempArray)) then
29
          // when high(TempArray) is odd, there are an even number of elements in array.
30
          // define median as average of two middle values.
31
          result := (TempArray[middle] + TempArray[middle-1]) / 2
32
       else
33
          // when high(TempArray) is even, there are an odd number of elements in array.
34
          // median is the middle value.
35
          result := TempArray[middle];
36
    finally
37
       // Free memory used for TempArray
38
       SetLength(TempArray,0);
39
    end;
40
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”: