Experience Using a Programmable Rules Engine to Implement ... - NCBI

Experience Using a Programmable Rules Engine to Implement a Complex Medical Protocol During Order Entry John M. Starmer, M.D., Douglas A. Talbert, Randolph A. Miller, M.D. Division of Biomedical Infornatics, Informatics Center Vanderbilt University Medical Center, Nashville, Tennessee

ABSTRACT

The VGR system has been successfully used to implement simple protocols such as the ordering of restraints and to implement numerous pharmacy guidelines. However, until recently, this approach had been untested for complex protocols. This paper discusses the authors' experience with using the VGR system to implement a complex diagnosis and treatment advisor for the suspected or confirned disorders, deep venous thrombosis (DVT) and pulmonary embolism (PE).

WizOrder, Vanderbilt University Medical Center's (VUMC) clinician order entry system, is an excellent platform for delivering high-quality decision support to clinical end-users. A scripting language designed to make it easy for non-programmer domain experts to enter rules helps distribute the generation and maintenance of the knowledge-base necessary to drive effective decision support. Domain-experts have used this system to successfiully implement relatively simple protocols. The VUMC Care Improvement Committee identified diagnosis of and treatment for suspected or confirmed deep venous thrombosis or pulmonary embolism as an area where decision-support could improve clinician compliance with established evidence-based protocols. The authors describe our experience with using our existing scripting system to implement decision supportfor a complex medical protocol.

THE VGR SCRIPTING LANGUAGE VGR is a scripting language designed to specify rules for implementing decision support (Figure 1). When triggered during order entry by selection of individual orders tied to scripts, a script is read into memory and executed in a top-to-bottom fashion. Script execution has two phases; an NIT phase occurs prior to the loading of the initial HTML page, and an EDIT phase takes place each subsequent time the user indicates they are "finished" with an HTML page. There are simple logical statements which include IF-THEN with AND, OR, AND_NOT, and OR_NOT. Within each VGR script, variables are defined and can be mapped to the "name" field of HTML form input tags. Certain patient-specific variables (such as the patients age and most recent platelet count) are made available to VGR at runtime and may be used in the decision support logic or displayed to the end-user. Together with the IF-THEN logic, these variables may also be used to check the quality of an entered value (such as checking for a weight which is above a particular number) as well as to initiate appropriate orders.

INTRODUCTION

Computerized decision-support delivered at the point of order entry, where clinical decision making is crystallized and turned into action, has been shown to be beneficial for both quality [1] and efficiency [2] of patient care. At Vanderbilt University Medical Center (VUMC) all inpatient orders are entered through the WizOrder [3] clinician order entry system providing a conduit for delivery of decision-support to clinical end-users. The WizOrder client contains an imbedded web-browser [4] to display information to end-users, including forms used for order entry. WizOrder is implemented across all specialties at VUMC, initially making maintenance of the knowledge-base that drives decision support somewhat problematic [5]. In order to aid in knowledge-base maintenance and provide a mechanism for implementation of clinical decision support during order entry, a simple programmable rules engine was developed [6].

IMPLEMENTATION OF A COMPLEX PROTOCOL

Diagnosis and treatment of DVT and PE involve a complex sequence of confirmatory tests, as well as initiation of anticoagulant therapy. The latter requires complex dosing regimens with potentially frequent modifications to therapy based on various monitoring tests [7]. Computerized applications designed to assist with anticoagulant dosing have been shown to

The rules engine works in concert with HTML forms, and uses a locally developed scripting language, known as VGR (Vanderbilt Generic Rules). VGR was designed to be easy for non-programmers to use.

1067-5027/00/$5.00 © 2000 AMIA, Inc.

829

The treatment advisor was written using VGR for the processing rules, HTML forms for the user-interface, and extending the VGR engine to enable background monitoring of patient lab values, such as the activated partial thromboplastin time (PTT). Particular laboratory tests and pharmacy orders, such as Lower Extremity Doppler Ultrasounds, Pulmonary Arteriograms, and Heparin Infusions were identified as "triggers" for the protocol. Logic was included as WizOrder "exit checks" for determining if proper actions had taken place during an order-entry session. For instance, if a heparin infusion was discontinued, but the monitoring test specific to the infusion (PTT) was not, a warning message is displayed. In addition, the system monitors lab results for "PTT Too Low" or "PTT Too High" to trigger a suggestion to modify the heparin infusion if no changes to the infusion have been made during the session.

improve patient care [8]. The Care Improvement Committee at VUMC identified the diagnosis and treatment of suspected and confirmed DVT and PE as an area which decision support could improve compliance with evidenced-based protocols by providing an easy way to order groupings of recommended tests depending on the status of the patient. After a year of literature review and consultation with local clinical experts, the Care Improvement Committee designated a complex protocol for diagnosis and treatment of those conditions. The protocol was developed from the on Conference Consensus Fifth ACCP Antithrombotic Therapy published in Chest [9] which includes a comprehensive review of the relevant medical literature. The protocol includes weightbased dosage calculations, as well as dosage adjustments based on the results of monitoring laboratory tests. In addition, there are recommendations regarding monitoring of potential complications to anticoagulant therapy, such as Heparin-Induced Thrombocytopenia. Patients with confirmed DVT or PE require anticoagulation with an injectable agent (when not contraindicated) until oral agents have an adequate therapeutic effect.

W-

# variable declarations

*

INIT,MAP,LOCAL,patient name,TO,pt.name

INIT,MAP,LOCAL,patient DOB,TO,pt.birth_date INIT,MAP,LOCAL, PLT.value,TO,pt. lab result. PLT.value INIT,MAP,LOCAL, PLT.date,TO,pt . lab result. PLT.date

i0

:

NO *

INIT, SET,RADIO, indication,TO, # load the initial web page to display INIT, LOAD, FORM,,, IVHEPO,AND INIT, EXIT,THIS # VGR logic for page IVHEPO EDIT, IF, form, EQ, IVHEPO ,AND EDIT,IF, ,indication,EQ,suspectedDVT,THEN EDIT, LOAD, FORM,,, IVHEP1A,AND EDIT, EXIT, THIS

- I

1

I 0 li -.

Figure 1. Sample VGR Script Flpgre I contais a sample VOR script. When the script is first trgered, all of the INIT statements are evaluated which in this exampl results in the mappmig of variabls to _ patient data, and a variable which matches a set ofradio buttons in form IVHEPO (fipre 2). This forn is then loaded ad evabution of the script is temiated (EDIT,EXIT,THIS - EDIT,EXIT,ALL would terminate the entire VGR session). Folowing user wsetion of one of the options on the displayed form, the NIT stements are ignored, and any EDIT statements in the script are evaluated. In the case of this example, clicking on the "suspectd DVI" radio button would result in the loading of a new form (IVHEPIA) to display to the user.

Figure 2. Inial Page Displayed Upon Triggering the VGR Script

The VGR script includes logic to make sure that the data entered into the HTML forms is complete, as well as accurate (e.g. certain "bounds" checking on drug dosages). The script also has code to log patientspecific and user-specific data for later analysis.

The user-interface includes not only the actionable items and descriptions of the recommended protocols, but also informational pages relating to treatment and diagnosis of DVT and PE. The system makes it easy to select a relevant ICD9 code to support medical necessity for the confirmatory test being ordered. Additionally, the interface displays all relevant active anticoagulant medication orders for the patient, as well as most recent relevant laboratory results such as the intemational normalize ratio (INR) and PTT.

VGR Protocol for DVT/PE The system is triggered by an order for an item that is likely to be ordered when a DVT/PE is either suspected or confirmed. Initially, the user is prompted to select the indication for the item that triggered the protocol (Figure 2). If the indication is

830

results needed to be monitored and acted upon outside of the confines of a particular VGR script. In fact, PTT results can act as a trigger for a VGR script. The current implementation of the VGR system allows only for evaluation of user entered rules at the time a particular script is executed. This made it necessary to extend base WizOrder code to implement checks for proper behavior based on laboratory results. Ideally, one should be able to easily specify rules to be acted upon both inside and outside of the context of a VGR"session".

for a confirmed or suspected DVT or PE, the advisor continues with recommendations which are matched to the particular indication. If the user selects "other" for the indication (such as a patient who had a heparin infusion ordered for a diagnosis of "unstable angina"), a flag is set to suppress the heparin trigger for 72 hours (triggers such as Lower Extremity Venous Dopplers, and V/Q scans remain active). Once the protocol has been activated by the user for a patient with confirmed DVT or PE, the system monitors the patients laboratory results as well as orders entered during a session to aid in appropriate management of the heparin infusion. For instance, if a patient has a subtherapeutic PTT, and has not had any modifications made to their heparin drip orders since the time of the laboratory result, the user is notified when they try to exit the system, at which time they are also given the opportunity to make the appropriate adjustments to the patients orders.

LESSONS LEARNED VGR was implemented in large part to allow users with a wide range of computing experience to contribute their domain expertise for the purpose of effecting clinician behavior through order-entry decision-support. Other systems, such as CGI or Java Servlets/Applets, have widely been used to easily generate applications that could be used for the same purposes. However, these languages are not intuitive for non-programmers. In addition, none of these systems address the "background monitoring" issue of how a rule should act within the overall system.

The system went live in December, 1999 and has been well received by end-users. Data is being collected to enable the evaluation of the effect of the treatment advisor on user compliance with the protocol as well as the effect on patient care as measured by the time to therapeutic anticoagulation without under or over anticoagulation.

CONCLUSION

Initially, the VGR code was straightforward and simple, but as the variety of tests to be considered grew, and the checks for appropriate behavior increased, the code became difficult to manage. It is important to note that the treatment advisor was successfully implemented using the VGR scripting language and the VGR rules engine, but the limitations identified when "stressing" the system with a complex problem call into question the scalability of this particular system. One of the strengths of the system is its ability to be used effectively by non-programmer domain experts. For relatively straightforward decision support applications, VGR has been a valuable tool at VUMC used for improving maintenance and delivery of decision-support at the point of order entry. Two key problems which an improved system must overcome in order to more effectively address complex decision-support applications include the code maintenance problem introduced by the non-modular nature of the scripting environment, and extending the scope within which a rule may be applied.

EXPERIENCE WITH THE VGR SYSTEM

Code Complexity The coded VGR rules for previously implemented simple applications have proved to be straightforward and easy to manage. Because of the number and complexity of the rules required to implement the VGR protocol for DVT/PE, limitations of the current VGR implementation came to light. The top-down (non-modular) nature of processing the scripts made it necessary to occasionally uncouple chunks of code from their logical place in the script in order for the application to function properly, making the code difficult to read and maintain. For instance, the handling of a "cancel" request had to appear towards the top of the script instead of being logically grouped with the rest of the potential actions associated with a particular HTML form. A possible solution to this problem would be the ability to write subroutines. This could have a beneficial effect on code readability, maintainability, but could also have the adverse effect of making the language too complex for non-programmers to use.

ACKNOWLEDGEMENTS Background Monitoring Another shortcoming of the VGR system surfaced when it was necessary to set up rules which should be evaluated outside of a particular VGR "session". PTT

The authors wish to acknowledge the contributions of the members of the VUMC Care Improvement Committee Chaired by Lonnie Burnett, MD.

831

5.

Additionally, this work was supported in part by grants from the U.S. National Library of Medicine (5 G08 LM05443 and 5 RO1 LM06226).

6.

REFERENCES 1. 2.

3. 4.

Evans RS, Pestonik SL, Classen DC, Clemmer TP, et al. A computer-assisted management program for antibiotics and other antiinfective agents. New EnglJMed. 1998;338:232-8 Tiemey WM, Miller ME, Overhage JM, McDonald CJ. Physician inpatient order writing on microcomputer workstations: effects on resource utilization. JAMA. 1993;269:379-83 Geissbuhler A, Miller RA. WizOrder, A User-Friendly Interface for Order Entry and Clinical Decsion Support Tools. Proc AMIA Symp, 1995;1002 Geissbuhler A, Grande JF. Embedding a Web-browser in an order entry system to improve the distributed maintenance of decision-support resources. Proc AMIA Symp, 1997;939

7.

8.

9.

832

Geissbuhler A, Miller RA. Distributing Knowledge Maintenance for Clinical Decision-Support Systems: The "Knowledge Library" Model. Proc AMIA Symp, 1999;770774 Heusinkveld J, Geissbuhler A, Sheshelidze D, Miller RA. A Programmable Rules Engine to Provide Clinical Decision Support Using HTML Fonns. Proc AMIA Symp, 1999;800803 Hyers TM, Agnelli G, Hull RD, et al. Antithrombotic Therapy for Venous Thromboembolic Disease. CHEST 1998; 114:561S-578SMungall D, Lord M, Cason S, Treadwell P, Williams D, Tedrick D. Developing and testing a system to improve the quality of heparin anticoagulation in patients with acute cardiac syndromes. Am JCardiol 1998;82: 574-9 Dalen JE, Hirsh J (editors). "Fifth ACCP Consensus Conference on Antithrombotic Therapy." CHEST 1998; 114(5)