Better Never Than Late

I often complain that the typical organizational IT infrastructure is too complicated and often not well-suited for the clinical lab. I am often asked to given an example, but so far my examples of complexity were, themselves, overly complicated and apparently quite boring.

Well, all that changed recently: now I have nifty example of what I mean.

One of our customers has a fabulous print spooling system: many pieces of hardware, many lines of code, all intended to ensure that your precious print job eventually emerges from a printer, no matter what issues may arise with your network. Best of all, you route all printing through it and it works automagically.

The fancy print job spooler is so smart, it can reroute print jobs from off-line printers to equivalent on-line printers. It is so smart it can hold onto a print job for you, "buffer" it, until an appropriate printer comes on-line.

Alas, neither of these features is a good fit for the clinical labs, at least for specimen labels. The ideal specimen label prints promptly and right beside the person who needs it. If the label cannot be printed, then the print job should disappear: the user will have had to use a hand-written label or some other downtime alternative. Printing the label latter is, at best, annoying. At worst, printing the label later is confusing and leads to mis-identified specimens. For this job, better never than late.

With effort, our client disabled the roaming print job feature, so the labels (almost) always print where they are needed. But the buffer cannot be turned off--it is the whole point of the spooler, after all--and so after downtime, the now-unwanted labels suddently come pumping out of the printers and if the draw station happens to be busy, the old labels mingle with the current labels and opportunities for serious errors abound.

Print spoolers are nifty. They serve office workers well. They are a standard part of today's smart IT infrastructure. But they don't serve the clinical lab in any real sense. The clinical lab is not a typical office environment: don't treat it like one.

App Retirement Party

Today marks the beginning of retirement for one of my apps--this one, in fact. As its Viking funeral ends in it sinks beneath the surface of the inky black waters of oblivion, I take a few minutes to ponder its useful life and its lessons.

Given its original mission, it was an astounding success: it allowed Outreach to dramatically grow its volume while greatly lowering the processing burden on the hospital lab.

Its secondary goal of paving the way for software in the draw station was also achieved, since rolling out its replacement was a fraction of the pain of introducing software to them in the first place.

Its tertiary goal of providing hard numbers with which to manage the collection operation seemed to be a glorious success, but since the organization did not bother to replace this functionality when they retired this app, perhaps this was as obviously valuable as I thought?

As an exercise in customization to support operating procedures, it also seemed to be a great success, but many of the most popular and most effective customizations are not being re-implemented, so their value was lower than it seems to me or their cost in the new environment is too high. The whole "this is better, because it cost more" movement baffles me and perhaps this is part of that.

The customizations which people most complain about losing are these:

• the ability to automatically cancel ordered tests, with an explanation, of those tests are not going to be done anyway per Lab policy
  
• the ability to automatically change  an order for an obsolete test with an order for its replacement, with documentation, if an equivalent replacement has been defined
  
• the ability to handle clinical trials and research draws, to ensure anonymity and proper billing

Rest in peace, app: you did all that we asked and more.

Godspeed, former users: may your manual work-arounds be as painless as possible and your upgrades lead you, eventually, to the level of efficiency you once enjoyed.

Google Maps for Data Visualization

We are looking into ways to make draw data and ordering statistics more useful to our clients. Perhaps a map? Check out this excellent tutorial on how to get started: I did and was very impressed.

http://www.w3schools.com/googleAPI/default.asp

Our proof-of-concept project has the following goals:

1. a map of the catchment area
1. marker for client
2. marker for each draw station
2. pop-up for each marker
1. show the absolute activity for that location
2. show the percentage activity for that location
3. do the same thing with ordering clinicians instead of draw stations.

We are eager to see if the coolness translates into actual usefulness.

Epic Draws

One of our clients retired our custom draw station solution in favor of Epic, but quickly found that Epic could not provide the management reports we had provided, so we were asked to somehow recreate our report package in the new environment.

After some consideration, the solution we choose was this: an extractor of data from the LIS (SoftLab) to populate the database on which the reporting package was based. So the orders come through Epic, into SoftLab and then into our database.

Once we defined and refined the business rules which let us determine which orders were collected in draw stations and which were not, the rest of the puzzle fell into place.

Along the way, we uncovered some ordering issues--misconfigured menus in Epic, out of date test definitions in SoftLab, receiving procedures not properly adjusted for the new environment--which is the first step to fixing them.

We also learned more than we wanted to about how orders are stored in the LIS, but that will be useful down the road I'm sure.

Advance Beneficiary Notice (ABN) Support

Today we start upgrading our draw station app to support Advance Beneficiary Notices (ABNs).

The formatting is not a problem, because I know how to use groff and ghostscript to make PDFs which match the specs.

The calculation of benefits is being done by the LIS, not because we can't parse the same file that they do, but because the client wants a single instance of this kind of calculation, which makes sense.

Closing the loop is where we excel: we are setting up a system to capture an image of the signed (or not signed) ABN and then automatically attach that image to the draw. Furthermore, we are automatically populating a web page for the billing folks so that they can either access the image directly or see which draws do not have ABN, but should have had ABNs.

Crossing internal boundaries is essential to our success in providing automation which really works.

Here is what one of our test ABNs looks like after scanning and being automatically attached via its bar code:

Note: the image is a bit crusty because I converted the original PDF into a PNG to appease Blogger

Phlebotomy Support

The client is a large hospital lab, recently given responsibility for Phlebotomy. Their problem is that the draw stations not only  are not on the LIS, the draw stations are not computerized at all.

Their problem is compounded by the fact that their LIS is not off-the-shelf but is rather long in the tooth.

Worse, the lab is entirely focused on inpatient specimens: their processes and procedures all assume an electronic order in the LIS followed by a tube labelled with an LIS collection label.

All we can count on at the draw stations is a secure network connection.

We bridge that gap in under two months:

• custom Linux-based thin clients to provide
• dependable known web browser
• barcode label printing and report printing
• a web app to
• greet the patient, establishing a start for wait time
• identify the patient using an up-to-date patient index
• support finding and using existing electronic orders (clinics)
• support turning a paper order into an electronic order
• UI of assays
• interface to LIS to place order as if from the HIS
• print a collection label compatible with the legacy LIS
• provide history of activity by draw station or across draw stations
• support drop-offs
• support clinical trials
• support ordering synonyms to match community ordering habits

We roll out our app to their completely computer illiterate user base, many of whom have never used a mouse.

We provide management metrics for wait times and patient visits and a link to the Lab Man database so that the phlebotomists have up-to-date collection instructions. (More on that original Lab Man here.)

Mon Dec 1 13:35:10 EST 2008
Major release:

• support EKG scheduling
• support Accession Issues to link front bench and draw stations
• support for Cc physicians
• support ordering web page matching custom requisitions

Sat Jun 27 06:26:44 EDT 2009
Major release:

• scanned req support: barcode and tracking and viewing
• tube tracking
• support cancelled code substitution
• support lab protocol order changing automatically

Sat Dec 12 06:33:47 EST 2009
Major release:

• support the new incoming LIS, SoftLab

Wed Feb 23 10:11:14 EST 2011
Major release:

• support ABNs: UI to accept the data, process to generate the forms
  

Custom Requisition Support

One of my colleagues provided the client with a very nice customer requisition creator:

• a database which holds practices and maps practices to their favourite assays;
• a UI to maintain the database;
• a formatter to put the custom information onto requistion forms

The customized requisitions were a huge hit with the providers, but not with the phlebotomists: the providers get an easy way to order just what they want to order but the phlebotomists get order forms which vary widely, making entering those forms into the computer harder than they would like.

In order to better support draw station operations, I upgraded our draw station software to accept the practice ID as part of the patient greeting process. This allows the draw station app to put up a web page which matches the paper requisition in the phlebotomist's hand.

So if they want to order the test which is the fourth box on the second row on the paper, they click on the fourth box on the second row of the screen.

Since the draw station procedure is to highlight the assays with a yellow marker as the assays are entered, to ensure entry accuracy, I mimic that on the screen: when a box is checked off, that assay has a yellow background.

The feedback was immediate and positive: the users who are not that comfortable with computers were instantly comforted by the close corelation of the physical and virtual.