In middleware, expert rules use marches on
Ever had a friend suggest going out to dinner, then say he didn’t know what he felt like eating? Sysmex senior product manager Anne Tate found herself facing a similar situation years ago, when discussing expert rules with users of her company’s middleware product, the Sysmex WAM system.
“We used to say, ‘What do you guys want?’” she remembers. “And no one could articulate what kind of rules they wanted.”
So, much like a patient friend reciting a list of the most popular restaurants in the neighborhood, Sysmex gave its middleware customers a basic set of rules that could be deployed on WAM. “Then from there,” she says, “customers got the idea of how rules are structured and which rules are recommended.”
Boy, did they ever. Now, Tate says, customers have become exponentially more comfortable with writing and using expert rules: “We’re seeing a lot more patient-specific rules. We’re seeing an emerging trend of writing rules off a diagnosis code. And customers want what we’re calling extended delta checking. They’re not just looking back at the last result; they want to look at a range of delta results—flags that have triggered in the past, operator alerts that have triggered in the past, critical results that have occurred in the past.”
In other words, customers’ understanding of expert rules has grown, and middleware vendors’ ability to help their customers write, amend, and manage these rules has increased accordingly. CAP TODAY solicited the perspectives of middleware manufacturers and users to uncover the latest ways in which rules engines are revving up.
“There’s more and more people actually doing it”—that is, using expert rules—“instead of just talking about it,” says Paul Dean, Data Innovations implementation consulting services manager. “That trend has been going on for the last 10 years, but it’s still gaining.” Lately he sees customers adding rules that apply to multiple assays, as well as rules that expand the laboratory’s ability to detect specimen-labeling and collection errors.
Some experienced customers, he says, are purposely using fewer rules, not more. “When I was in the lab 15 years ago,” he recalls, “our medical director had us repeat a lot of samples. The trend today is that people seem to be trusting their analyzers and not necessarily using rules to repeat critical results. That’s the biggest change I’m seeing in the industry. We often write rules [for repeating samples] for customers, and then they come back and say, ‘Can we deactivate that? If I repeat a sample, it could add another 10 minutes to my turnaround time, and if almost 100 percent of the time the result is the same, I can save a lot of time,’ as long as they can prove that the method is stable enough to do that.”
At the same time, other users are just beginning to venture into rules-writing territory. That’s why Data Innovations customers can take one of four approaches when implementing expert rules. “We can provide training, and they can do the rules themselves,” Dean says. “In some situations, we can give the customer a starter set of rules, and they can get training and then modify the rules to fit their own laboratory. We can take the same starter set, and they can pay us to modify and activate them. Or, if none of those options are what they want, they can come to us and say, ‘Here are our standard operating procedures; you go and write custom rules for us.’” Some customers want to do it themselves so they don’t have to depend later on their vendor; others want to be independent but don’t have the time or resources.
For potential middleware users who are wondering how difficult this rules-writing business is, Dean offers advice. As far as Data Innovations’ products are concerned, “if you have the ability to create an if-then statement in an Excel spreadsheet, you should be able to pick up the rules pretty quickly,” he says. “The bigger struggle people have is, ‘What rules do I need to write, and what information do I need to collect, and how do I validate it?’” His suggestion: “Take your current standard operating procedures and just turn those into rule sets, and you’re already on the way. You can go from there and start building more complicated rules.”
Going with a vendor that offers a rules development kit is another option, says senior sales executive Jay Sax of Dawning Technologies, which plans to display the latest version of its JResultNet middleware application at the AACC annual meeting in July. “One of the critical factors in developing rules is the ability to create, test, and manage those rules before implementing them in a live environment,” he points out. “Our JResultNet rules development kit is an offline application that someone can use to build rules outside of the live middleware and create test-case libraries in order to verify those rules before implementing them live.” Without that ability to build and test offline, he adds, “you’d either have to do it live, which can be disruptive to the lab,” or “have a separate instance of the middleware running on the side.
“While that’s effective,” he continues, “we prefer our approach because it allows you to build these libraries of test cases. Since you want to test the vast majority of variables a rule can encounter, it may not be easy to get that from the live data. You can also print out an XML representation of the rule firing in complete sequence and keep it as a reminder that the rule fired the way it was intended. It’s a nice record-keeping tool for auditing.”
On the physician office side, Sax sees a growing interest in rules that allow the customer to overcome incompatibilities between an electronic medical record and a laboratory information system. “In a lot of cases, doctors’ offices that have more than a couple of analyzers will have an LIS in their lab,” he says. “But a lot of labs find it cost-prohibitive to invest in an LIS only to manage connections to one or two analyzers. The challenge is, the EMR speaks only HL7, and very few analyzers output results in HL7. So to avoid having the EMR vendors custom-code their own direct analyzer interfaces, they will rely on other tools, like middleware, to bridge that gap. We’ll take the result coming out of the analyzer in its native language and translate it to HL7. Rules are a powerful way to overcome incompatibilities.”
BioMérieux’s focus on microbiology affects the way it views expert rules, says Jacques Baudin, vice president of commercial operations IT solutions. “Since we work with living organisms, the field is changing constantly,” he points out. “It’s fairly easy in clinical chemistry to write rules that take into account quality control, for instance. But in microbiology, it’s a little bit more complex. People have been trained to be microbiologists; they certainly have not been trained to be IT experts. And not everybody has access to people specialized in data reporting or expert rule writing.”
That’s why BioMérieux’s approach, he says, “is to really package the rules as much as possible. Why reinvent the wheel from laboratory to laboratory, when as an IT vendor, we can provide a set of common rules that we have developed and validated? I think it’s a pity if you need to validate your rule-based system and then, every time you write a rule, you have to again validate the system. We are trying to come up with standard rules, commonly used rules, so that piece does not need to be redone by the end user. It’s a burden that will be eliminated.”
But enough from the vendors.
What do laboratories have to say about middleware expert rules and their usefulness?
As the laboratory manager at Sparta Community Hospital, a 25-bed critical-access hospital in Sparta, Ill., Dan Walker, MT(AMT), BSEE, knows he’s not the typical middleware user. “I’m fairly confident we are one of the first critical-access hospitals, if not the first, in the state of Illinois to start using middleware,” he says. “It’s that whole philosophy of, ‘Small labs don’t need it. It’s overkill for a small lab.’ But we found that it’s been a tremendous benefit.”
Though Sparta’s current LIS “has what they call autoverification,” Walker says, “it’s limited, and I didn’t really trust it. You could build some rules; I just wanted a little more than that.” Instead, Sparta’s laboratory uses Roche Middleware Solutions, supplied by Data Innovations, on its Roche Cobas e411 immunoassay analyzer and Cobas c501 general chemistry analyzer.
“We hit the ground with it five or six months ago, and it’s working very well,” Walker says. “The package to write the rules is very user-friendly. First, you must visualize the purpose or intent of the rule. Once you have this in mind, the Roche middleware solution makes the actual process of writing the rules very simple.”
When it came to building the rules, “I divided them into two different types in my mind, speed rules and quality rules,” Walker says. “The first speed rules I wrote were for critical values: Hold that test; alert the tech to call the physician. I also wrote some abnormal value rules, where it’s not a critical value yet, but as a good, conscientious lab tech, you should look at it. With just those rules alone, you’re going to reduce your turnaround time tremendously.” The quality rules, such as rules for delta checks and indices rules, were the second phase. “That’s when I could sleep at night and say that the values that are going out without a tech seeing them are valid, accurate results.” Next, he will add QC rules. In addition, he hopes to soon begin using the middleware with the laboratory’s Sysmex XT-4000i hematology analyzer and Sysmex CA-1500 coagulation analyzer.
As a result of implementing autoverification rules, Walker says, the laboratory’s turnaround time has plummeted, and his staff has become more productive. “One of the other big advantages I’m starting to see is the improved troubleshooting skills of my techs,” he says. “If you look at every value and see ‘Normal, normal, normal’ over and over, it becomes easier to miss that abnormal result. You get jaded. Middleware removes the mundane activity of reviewing normal results. I feel it’s helped their ability to identify those values that truly warrant their attention.”
Middleware-based rules have proved just as valuable at the vastly larger Sutter Health Shared Laboratory, Livermore, Calif., which runs about 2.4 million tests a year and uses the ApolloLIMS laboratory information management system (supplied by Common Cents Systems). “It’s a modular middleware system that performs four major functions for us: instrument manager, rules engine, occurrence management, and specimen archiving,” says shared laboratory administrative director David Velasquez, CLS, MT(ASCP).
“We take in work from our affiliates, and it’s a very diverse group of laboratories, hospitals, clinics, foundations,” he explains. “I have to manage orders coming in from disparate systems. So I needed a central system that I could adjust to all the differences.” In addition, “we have a legacy LIS, and that’s essentially where the autoverification occurs. But on the instrument side of the LIS, we have a lot of very sophisticated technology that’s constantly changing. That’s another reason I use the middleware—it allows me to adjust to changing technologies on the floor more easily. If I have a need to help these communicate in a better way, that’s where the rules come in: making up for any deficiencies on the instrument data manager side or the LIS side.”
Scanning incoming orders for incorrect data is what Velasquez and his colleagues are working on now. “For example, with creatinine clearance, where you need a height, weight, and total volume, many times that information either is lacking or isn’t formatted correctly. So we’re in the process of writing rules that will scan those fields as they come in and then send an automatic notification to our customer service department.” Because those orders come in quite some time before the specimen reaches the laboratory, the hope is that the customer service staff will be able to call the affiliate and get the order corrected even before the specimen arrives in the lab, thereby preventing delays in turnaround time and reporting.
Echoing the remarks of Data Innovations’ Dean about experienced users employing fewer rules, Velasquez says, “I actually find that the rules become simpler over time. A lot of times we try to overthink the process. For example, if we’re constantly repeating a certain value over and over again, and it repeats 100 percent of the time, we’re intervening too often. We’ve been doing it for four or five years now, and right now we’re pretty set. A lot of that fine-tuning of the rules was really done in the first couple years.”
As far as where rules should be deployed—at the instrument, in the LIS, or in the middleware—Velasquez recommends taking it case by case. “One instrument may be very rules-dependent,” he says, “and on another instrument, I may be able to filter and manage the data and have very few rules written for it in the middleware. You have to really understand how your LIS works. If your LIS can do the best job for a particular rule, then that’s where I would do it. But generally, the more complicated the rule becomes, the more you need to lean toward the middleware.”
Interestingly, it’s that kind of complication that leads J. Mark Tuthill, MD, to avoid middleware—but not rules, of course—as much as possible. “We have found that 90 percent of the time, we actually don’t need to resort to middleware solutions,” he says. “Every middleware solution we have ever implemented, we have uninstalled, because four years later, the LIS can do what the middleware can do. Having five servers and four sets of programs creates so much more complexity that as soon as the LIS can subsume that function, we get the middleware out.” Dr. Tuthill is division head of pathology informatics at Henry Ford Health System, Detroit.
Instead, he says, “many of the rules we are running actually run on the analyzer itself.” Other rules run on the LIS, which at Henry Ford is updated every one to two years. “One of the things that typically happens is that the rules engines that are available on the LIS improve significantly between versions—better autoreleasing rules, or better interaction with reflex testing, or indications with making a manual differential slide.”
“What I can certainly speak to,” Dr. Tuthill adds, “is the value of expert rules. We have built very sophisticated rules in our LIS that have allowed us to automate the reporting of a huge chunk of our standard results. Because those rules have become increasingly sophisticated, we are able to autovalidate and autorelease an increasing number of laboratory test results. It used to be that more complicated tests, like coagulation tests, you almost couldn’t auto-release, because you didn’t have enough rules to determine which tests needed to be repeated. That’s all gone away. There’s almost nothing we can’t figure out how to write a rule to autorelease at this point in time.”
Dr. Tuthill sees rules beginning to be created not just on the clinical side, but on the anatomic pathology side as well, “which is a place we don’t usually think about rules or middleware.”
“The new version of [Sunquest Information Systems’] CoPath will allow you to reflex HPV testing for certain ages and demographics,” he says. “If you wanted to do that in the past, you may have had to use a middleware solution, and now that’s actually built into the AP information system. Similarly, the AP LIS is now having rules implemented that will allow samples to be routed in different directions, and that includes routing to a pathologist with a particular specialty, or routing based on a pathologist’s schedule. To me, this is one of the more interesting aspects of what’s happening in rules, middleware-based or not: The AP side of the street is finally starting to get some attention.”
Along that line, he predicts that AP lab information systems will begin to have rules around QA procedures, too. “In the AP LIS cytopathology world, there are pretty sophisticated rules that have been built to address CLIA ’88, and the rules will actually identify those accession numbers. This is going to happen in surgical pathology as well,” he says. “For the next version of CoPath, I can see it coming that that there will be sophisticated rules to help us do a better job of QA in a randomized prospective manner, as opposed to a more retrospective or iterative manner. Ideally, you’d like to have a rules engine in the surg path part of the LIS that would say, ‘Hey, by the way, it’s the end of the month and you said you want to review three percent of your cervical biopsies. Here’s a list of the cases the computer has pulled out of your database; now go and review them.’”
One longtime laboratory IT expert sees middleware as a growing market. “There’s a huge movement now toward a company called Epic and its LIS, which is called Beaker,” says Bruce Friedman, MD, emeritus professor of pathology at the University of Michigan Medical School, Ann Arbor. “The reason it’s so popular is that Epic provides everything wall-to-wall. But their system is currently very immature and leaves large functionality gaps. So a lot of hospitals are going to be in the market for relatively inexpensive software that increases their functionality.” And as the market for middleware grows, the discussion around expert rules will only become more fervent.
Anne Ford is a writer in Evanston, Ill.