Leonard Dunikoski, Ph.D., Assistant Vice President of Clinical Operations at Raritan Bay Medical Center (Perth Amboy, New Jersey, USA) saw that for himself during a recent presentation to clinical lab professionals. When he asked how many were currently using autovalidation for their results, only about half raised their hands.
And yet, all these labs face many of the same challenges—namely, increasing regulations, decreasing reimbursements, competition for capital from other hospital departments and ongoing staffing shortages.
“The writing is on the wall,” says Dunikoski. “In five to 10 years, we will have a severe shortage of laboratory technologists. Everyone acknowledges it, but many aren’t quite sure what to do about it.”
Some Possible Options
Just how are labs going to decrease their dependence on a shrinking labor pool? Some may choose to turn a blind eye and do nothing. Others are already considering a “virtual laboratory” model, whereby they’ll outsource their routine work to national reference labs and make due with a skeleton staff. But depending on the contract terms and associated costs, this option may not always pay off.
The most logical solution for many labs is to decrease their dependence on labor. This approach not only solves a lab problem, it boosts the bottom line for the hospital since labor accounts for 50 percent of its overall budget.
Automation and Computerization
In an effort to maximize limited labor resources, many laboratories continue to turn to automation and increased computerization.
Dunikoski’s facility—Raritan Bay Medical Center—is one of them. It uses the Power Processor to automate front-end sample handling at its 360-bed hospital and uses DL2000 middleware to deliver fast, accurate test results at both this and its 119-bed facility.
Both these solutions help the lab standardize the testing process, optimize available staff members and speed the delivery of accurate test results via autovalidation.
If your lab is still looking for ways to do more with less staff, it may finally be time to get on board with autovalidation. The following tips may help you get started on the right foot.
Getting Started With Autovalidation
In order to do autovalidation right, you must first understand its function. At the core, autovalidation is simply a set of rules that does automatically what a good technologist would do manually.
The theory behind autovalidation is simple: Use computerized algorithms to automatically release acceptable test results—without manual intervention by a technologist—while flagging unacceptable results that call for manual review. This process often cuts the number of tests needing manual review from 100 percent to 30 percent.
Like many processes, the rule of “garbage in, garbage out” definitely applies—and your autovalidation process will only be as good (or bad) as the rules that guide it. The good news is that once the rules are set, your autovalidation process will be standardized—delivering the same results from day to day, shift to shift and person to person.
Setting Good Rules
What should you consider as you set-up (or fine-tune) your autovalidation rules? Dunikoski recommends asking several questions, such as:
- Do you want to set high and low limits on each test?
If so, you’ll need to determine how you’ll pick those limits.
- Should you simply use the normal range for each test?
This may not be very efficient because in an acute hospital setting, many people will be either above or below the normal range.
- Do you go by the linearity of the instruments?
You could consider the measuring range that the instrument can produce accurately and precisely.
- Do you want to go by critical values?
Results from certain tests can be life-threatening if action isn’t taken. How will your technologists be alerted of these results?
- Do you want to use Delta checks to compare the current results to the previous results for same patient for the same test?
If so, how far back do you want to go…an hour, a day? This answer may change based on the test.
- How will you respond to instrument flags and error codes?
When you get one, you need the software to alert you to the problem.
- Do you want to review the results of associated tests?
Sometimes the result needs to be reviewed in context of other test results. If that’s the case, you need to define what other tests to compare it to.
After your rules are defined, testing them is critical. This process will lead you to make a few more decisions, such as:
- Do the results need to pass all rules, or only some of them?
- Will you let the autovalidation algorithms judge (and pass) each test independently?
- If one test fails autovalidation, will you hold all of the other tests for that specimen as well?
“It will really come down to how much you trust your rules,” says Dr. Dunikoski. “The rule of thumb is to be overly conservative initially. It’s usually better to err on the side of caution and pass only 50 percent of your total results with confidence than to release a higher number of results before your lab is totally familiar with the new process.”
Advantages of Autovalidation at Both the LIS and Middleware
After your rules are set, you need to cross the next bridge: Deciding how to alert technologists about failed results—especially critical ones.
That’s where performing autovalidation at more than one location can help. Ten years ago, labs had no choice about where to perform autovalidation—they had to do it on the LIS. But today, there’s more choice—autovalidation can be done either at the LIS, through middleware or on the instrument itself.
When Raritan Bay Medical Center started using autovalidation in 1996, it used the lab’s LIS to handle the process. From the start, the advantages were huge—reducing the number of tests that had to be manually reviewed from 100 percent to 30 percent. However, notifying technologists of failed results wasn’t quite so simple.
Technologists still had to use the LIS to manually scroll through each specimen to see which tests had not been autovalidated. This put the burden on the technologist, when the burden should have been on the “system.”
This problem was solved a few years ago when the lab made another bold move—adding the DL2000 middleware. By duplicating its LIS autovalidation rules on the DL2000 middleware, the lab was able to do two things: Use the LIS to autovalidate the test results that passed all the rules, but use the DL2000 to alert its technologists of failed results.
“We programmed the middleware to print out only the test results that need someone’s attention,” he says. “Thus, for about 70 percent of patient test results, nothing prints out; but as soon as something prints, that’s our alert to the technologists right then and there. This addressed our need to alert technologists quickly and easily—right from our middleware system.”
Another advantage of the middleware over the LIS is this: Labs can customize exactly how they want to be alerted. In some cases, labs choose to get print-outs of non-validated results (in order to do this, the request must be complete). Other alert options include popup windows (that display messages or comments which are generated by rules) and dialog boxes that allow the user to display customized results (such as “out of validation range,” “not validated” or “not uploaded to host”).
“The added value of running autovalidation on both the LIS and middleware is worth it to us right now,” says Dunikoski. “Eventually, we may cut back to using only the middleware, but for now, our current process is working well.”
Thanks to both automation and autovalidation, Raritan Bay Medical Center has been able to increase its testing volume and add new tests while reducing staff by attrition—thereby saving $200,000 each year in labor expenses alone.
“We’ve learned that autovalidation works, and it works even better if you add in the middleware,” says Dr. Dunikoski. “If a small hospital in New Jersey can be doing it successfully for more than 10 years, I’m sure that a lot more labs could be doing it today.”
|
