Data Mining

Users of 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).

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

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.




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



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.

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

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.

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.

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.


Hacked again

Hacked again

Received an email from Google today:

  • Hacking suspected:
  • 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:

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

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:

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.


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 coming up with “something unexpected” on home page.

So I went to 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:

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

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();
APKini : TIniFile;
strDateFormat : string;
strTemp : string;
OutputBuffer: PChar;
SelectedLCID: LCID;
// 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'
strDateFormat := 'MM/dd/yyyy';
APKini := TIniFile.Create(PathName + 'apk.ini');
APKini.WriteString('dbMaint', 'Pack date', FormatDateTime(strDateFormat, Now));
on E:Exception do begin
MessageDlg('Error saving pack date',
mtError, [mbOK], 690, dckActiveForm);
// Free up the string list memory

After I moved the code into an inline function there were no more memory leaks:
procedure TfrmMain.SavePackDate();
APKini : TIniFile;
strDateFormat : string;
strTemp : string;
function ShortDateFormat: string;
OutputBuffer: array[0..255] of Char;
SelectedLCID: LCID;
SelectedLCID := GetUserDefaultLCID;
GetLocaleInfo(SelectedLCID, LOCALE_SSHORTDATE, OutputBuffer, 255);
Result := OutputBuffer;
// 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'
strDateFormat := 'MM/dd/yyyy';
APKini := TIniFile.Create(PathName + 'apk.ini');
APKini.WriteString('dbMaint', 'Pack date', FormatDateTime(strDateFormat, Now));
on E:Exception do begin
MessageDlg('Error saving pack date',
mtError, [mbOK], 690, dckActiveForm);

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;
n,i,middle : integer;
TempDouble : double;
TempArray : array of Double;
// Set Length of TempArray
// Copy first column of RegressTable array
for i := 0 to TotalForArray do begin
TempArray[i] := RegressTable[i,0];
// 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
TempDouble := TempArray[n];
TempArray[n] := TempArray[n-1];
TempArray[n-1] := TempDouble
// find median
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
// when high(TempArray) is even, there are an odd number of elements in array.
// median is the middle value.
result := TempArray[middle];
// Free memory used for TempArray

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

UD Labels

In 1984, shortly after the pharmacy received a new IBM-PC XT with a green screen monitor and a dot matrix printer, I wrote my first practical pharmacy program: UD Labels.

In those days unit-dose packaging was a time-consuming and messy affair as the labels were printed with a mimeograph machine. It utilized stencils which were typed up on an IBM typewriter with the ribbon removed. The stencils were small and it was nearly impossible to line them up on the typewriter roller.

Before printing the roller had to be inked. Then, depending on how well it was inked, the first run of labels was either too faint or smeared with excess ink. After trial and error, eventually you were able to print labels that were somewhat legible.

The labels were pushed into the printing area with a mechanical arm, and often jammed or misaligned within the loud and complicated Rube Goldberg contraption. If you only needed a few pills for a rarely used drug, the machine was overkill. To save time, we dispensed a few pills into a prescription vial with a typed label. Any remaining pills had to be discarded.

It came to me one day while printing a report from the PC and watching (listening) to that ridiculous packaging machine chug away at labels, that a computer printer would be much easier, and would produce labels that could be easily read.

It took me about 2 days to write a simple little program in IBM BASIC, and it worked like a charm. My regional manager Russ Collins came by for a visit a few weeks later and I showed him what I’d developed. Shortly thereafter I was getting requests from other DOPS in our region for a copy of the program. And thus, my little software publishing enterprise began.

I’ve made countless improvements to the program in the thirty years since. The latest version is secure, has full database capabilities, and has the ability to print bar codes in any format.

A few software companies have since copied my idea, and charge a ridiculous price for their intellectual thievery. Even my current employer was duped into buying one of these ridiculously over-priced and impractical pieces of crapware. I was off one week then came back to find that all traces of my program were erased, they even erased all the old data. I was not advised or consulted. Blatant disrespect that I will certainly never forget.

Which brings us to 2014, thirty years after my brainstorm, UD labels has become the most popular RxKinetics PC software. Karma.

More Power (arr, arr, argh)

Tim “the tool man” approves.

“More models”.. I get this request often, and my usual answer is, in as nice a way as possible, do the work yourself lazy ass. I gave you the tools, learn how to use them.

But most people don’t get it. This sh*t isn’t carved into stone tablets by the hand of God. The way pharmacists are taught these days everything has to be in writing somewhere. So, here it is: Wagner: Fundamentals of Pharmacokinetics, nineteen-f**king-SEVENTY-FIVE. Yup, that’s right, almost FORTY f**king years ago. You weren’t even a gleam in your daddy’s eye. So, look it up old school in an actual lie-bary (sic) because it ain’t on the f**king inter-webs.

I’ve described the Wagner method before, in great detail here . No lie-bary required!

And now I’ve done all that work for you too! All it takes is a suck-up email to appeal to my altruism: “I like your program a lot because it is serious about PK/PD and pushes the concept of PK target attainment. As such, to optimize dosing with Abx is critical and apps to me are the future. I request that you build out the PK ability to dose other common beta lactams as well as the aztreonam and ceftazidime. I realize this can be done by entering the necessary parameters in the customizable part of the app but it would be easier for us if this was built in.”

Well, here it is.

I’ve also built the functionality to download these models into the Antibiotic Kinetics for Windows program.

AbPK how to
More Models!

Eventually this functionality will be added to the iOS and Android versions.

Group sing-along:

APK Eureka

Since adding EurekaLog to APK I’ve been able to track down the causes of some perplexing errors.


“X is not a valid floating point value”, this error has puzzled me for years. I have actually never seen it myself in 15+ years of using the program. I am only aware of it because of scattered reports from users.

Once nice feature of the EurekaLog report is a screenshot of the user’s current screen.

As usual, it is the user causing the error. Instead of entering a valid decimal value, ie, [1.02], they accidentally add a decimal point or two: [1.02.] or [1..02], etc. This error has cropped up twice in only 30 reports. I never would have imagined that someone would do something so fundamentally wrong. I also believe that it is impossible to imagine every possible scenario of software usage. I think it would take a troop of monkeys randomly pounding on multiple keyboards to approximate the myriad of potential mistakes.

Regardless, any software program must be able to prevent a user’s dumb mistake from causing a fatal error. All of the input boxes for numeric values in APK are coupled to procedures to prevent non-numeric input:
procedure TfrmMain.EditRecentSCrKeyPress(Sender: TObject; var Key: Char);
if not (Key in ['0'..'9', DecimalSep, #8]) then
Key := #0;

However, that’s not enough. I was under the impression that the StrToFloat function was fault tolerant, i.e., if the input was wrong, it would output a zero.
RecentSCr :=0;
if EditRecentSCr.Text <> '' then
RecentSCr := StrToFloat(EditRecentSCr.Text);

Unfortunately that’s not true. Instead, execution is halted with a fatal error and the program crashes.

The little known expression SysUtils.TryStrToFloat does have fault tolerance.
RecentSCr :=0;
if EditRecentSCr.Text <> '' then
TryStrToFloat(EditRecentSCr.Text, RecentSCr);
if RecentSCr <= 0 then begin ValidPatData := False; MessageDlg('Data entry error', 'Serum creatinine is a required field.', mtError, [mbOK], 100, dckActiveForm); EditRecentSCr.SetFocus; Exit; end;

Alternatively one can test the boolean result of TryStrToFloat within an if..then block to flag an error:
if TryStrToFloat(EditKel.Text, KelSD) = False then
IsOkay := False;
ErrMsg := 'Kel SD';

So, I've spent the better part of 3 days re-coding all the StrToFloat calls to TryStrToFloat (also StrToInt -> TryStrToInt). And I've been able to prevent fatal errors.

However, if the field is linked to a database, the type of error appears to be unavoidable. Although it's not a fatal error, it still generates a EurekaLog error dialog.

I feel that the EurekaLog dialog doesn't really fit this situation. I'd rather catch the error, display a dialog, and rollback the edit which produced the error. But I've hit a brick wall, unable to get to the event triggering the error. I've tried BeforePost, PostError, BeforeEdit, and EditError, none of these events are trapped when a db field is edited. In the case of database fields it appears that no event is triggered. WTF!?


Another error that EurekaLog discovered is "unable to save settings". The most fundamental requirement for use of this program is to have full read and write privileges to the APK folder. Without that, you can't really use the software. Again, regardless, any software program should not allow a user's dumb mistake to cause a fatal error. So, I combed through all code, and surrounded all ini writes in try..try..finally..except blocks:
UserIni := TIniFile.Create(AppDataPath + 'screen.ini');
UserIni.WriteInteger('Window Placement', 'Main.Top', frmMain.Top);
UserIni.WriteInteger('Window Placement', 'Main.Left', frmMain.Left);
on E:Exception do
MessageDlg('Error saving window placement',
mtError, [mbOK], 690, dckActiveForm);
Action := caFree;


The other common error that I've addressed in this update is "range check error". Unfortunately there are not enough reports to establish a pattern, so I simply switched off range error checking. Within the compiler settings, range error checking is turned off by default. I only switched it on because some Delphi guru advised it. Well, sorry guru, in the end your advice caused more problems than it solved.

Peace out.

Post script

Today I figured out how to bypass the EurekaLog dialog for the EDatabaseError 'not a valid floating point value':

  1. Activated Exception Filters in the EurekaLog options
  2. Added EDatabaseError
  3. Changed handler to RLT

Result is this "somewhat" more user friendly dialog, without the unnecessary "Send Error Report" option.: