GLEE - A Model-Driven Execution System for Computer-Based Implementation of Clinical Practice Guidelines

 
Abstract
We have developed the GLEE system for execution of guidelines encoded in GLIF3 format. This system can be integrated with a local clinical information system through standard interfaces to EMRs and clinical applications. The execution model ofGLEE takes the "system suggests and user controls" approach. A tracing system is used to record the state ofguideline steps and their transitions. The GLEE system provides an internal event-driven execution model that can be hooked up with a clinical event monitor in the local environment. Potential use of the GLEE system includes clinical decision support, quality assurance, guideline development and medical education.
 
Brief Description
In recent years, computer-based guideline models have been developed to address the need for guideline representation and execution. These models are used as generic templates to facilitate the translation of guidelines from their published formats into computerinterpretable algorithms, to share the clinical knowledge embedded within guidelines, and to assist the integration of guidelines with the clinical information system at a local institution to provide patientspecific clinical decision support.

In 1998, our group, the InterMed Collaboratory (a research consortium created by informatics groups from Columbia University, Harvard University, and Stanford University), published the GuideLine Interchange Format (GLIF) , aiming to use it as a standard representation model for the sharing of guidelines among different institutions. Later, a prototype guideline execution engine was designed and implemented to integrate with the clinical information system at a local institution for the execution of guidelines encoded in an enhanced format of the second version of GLIF (GLIF2). In response to that experience, the limitations of GLIF2, such as the ad hoc approach to the definition of patient data and clinical actions, the lack of a specification for the logical expressions, and the limited set of decision models, have been addressed, and new requirements for guideline modeling, such as the representation of a patient's clinical state, have been included, resulting in the third version of GLIF (GLIF3). This research was focused on design and implementation of the GLIF3 Guideline Execution Engine (GLEE) that tries to balance the requirements of the shareability of guideline encoding, the flexibility of guideline execution, and the maintainability of guideline implementation tool.

GLEE is an important component in InterMed's framework of guideline sharing [Greenes RA et al. 2001, Sharable computer-based clinical practice guidelines: rationale, obstacles, approaches, and prospects]. It is built as middleware that is intended to be integrated with the clinical information system at a local institution through defined interfaces to its electronic medical records (EMRs) and clinical applications. In addition to clinical decision support, GLEE aims to be used for quality assurance, guideline development, and medical education. GLEE is currently implemented using the JAVA programming language.

GLEE provides interfaces intended to support integration with the host clinical information system at a local institution. These interfaces are used to link GLEE to a local EMR at the back-end and associated clinical applications (e.g., a physician order-entry system) at the front-end. The communication between GLEE and the EMR at the back-end will enable GLEE's access to various resources in the local environment, such as retrieval of patient data and monitoring of clinical events in case the local institution needs to trigger a guideline through specific clinical events. The communication between GLEE and associated clinical applications at the front-end is intended to enable smooth integration of the decision support services provided by GLEE, such as alerts and reminders, within a clinician's workflow [Tierney WM et al., 1996, Computerizing guidelines: factors for success]. In other words, GLEE defines the business logic of a guideline application, the local EMR will provide data, and the associated clinical applications will support the interactions between users and a guideline implementation system. The overall system architecture is shown in Fig. 1


Figure 1. The internal structure of GLEE and its interactions with a local environment. GLEE's components can be classified into three conceptual layers, the GLIF3 model, the core components, and the interfaces to the host environment. The communication between GLEE and the EMR at the back-end enables GLEE's access to various resources in the local environment, such as retrieval of patient data, and monitoring of clinical events. The communication between GLEE and associated clinical applications at the front-end enables smooth integration of the decision support services provided by GLEE, such as alerts and reminders, within a clinician's workflow. The EMR, GLEE, and associated clinical applications define the data, the business logic, and the user interface for a guideline's application. Multiple GLEE clients can be instantiated simultaneously. The standalone user interface is used only for development and demonstration purposes.

Although GLEE's execution will ultimately be invoked by running specific clinical applications, we have built a standalone user interface at the client side. As shown in Fig. 2, this standalone user interface is used to present to developers and implementers the process structure of a GLIF3 guideline as well as the active steps at a specific moment when that guideline is being applied to a testing patient. It can also be used to check the detailed information regarding a guideline step. Users can interact with GLEE using this client-side standalone user interface to decide whether to start, continue, or stop the execution of a specific guideline step. They can also find the documentation about the guideline, such as the references to the original published guideline and the maintenance information about the encoded guideline. It is important to note that this standalone user interface is developed for system development, debugging, and demonstration purposes rather than to be used directly by clinicians in practice.


Figure 2. A screenshot of the standalone user interface at the client side of GLEE during development and testing. The algorithm of a GLIF3 guideline is shown as a flowchart at the upper-right portion of the screen. A list of active steps, the hierarchy of algorithms, and detailed information on the currently highlighted step are shown in the upper-left portion of the screen. The setting of the current client and the execution trace are shown in the lower portion of the screen. Maintenance information of the guideline is shown in the pop-up window. Note that this user interface is intended to be used by developers for testing and demonstration rather than by clinicians for patient care.
 
Discussion
GLEE is intended to be used as a modular interpreter of GLIF3 guidelines. Our results have shown that it can be used effectively for this purpose except on rare occasions due to a minor problem in the expression language used in the current implementation. However, even if an execution engine can correctly interpret guidelines, the recommendations it generates may still not be accepted by a clinician. The results of our evaluation have shown that poor data quality, imperfect encoding of a guideline, and clinicians' flexible interpretation of guideline may all lead to the unacceptability of a guideline's advice, even when otherwise the guideline would have been correctly executed. Thus, we believe the execution flexibility provided by GLEE is especially important to address this issue when implementing guidelines in clinical settings. With such flexibility, even if clinicians reject an irrelevant or inappropriate suggestion when applying a guideline to a patient, they do not have to abandon the application of the entire guideline. Instead, they can always come back to the guideline and start a relevant step at a later time when they think it is appropriate. In this way, GLEE may overcome the limitations of previous approaches that depend on (1) a guideline encoder's enumeration of all possible clinical states of a patient during the application of a specific guideline, (2) high quality of clinical data, and (3) clinicians' stringent interpretation of the guideline. Comparing to the approach used by GUIDE that can only handle a limited set of exceptions [Quaglini S, 2001, Flexible guideline-based patient careflow systems], the execution flow of GLEE can be arbitrarily changed by users as they judge as appropriate. Further evaluation of GLEE on its use for this purpose will be necessary after it has been integrated with the clinical information system at one or more local institutions to provide clinical decision support in practice.

Integration of decision support within clinicians' workflow is a critical factor for its success [Tierney WM et al., 1996, Computerizing guidelines: factors for success]. Thus, we believe a standard interface between a guideline execution system and associated clinical applications is important for guideline implementation in clinical settings. The interface to the clinical applications provided by the GLEE system is intended to facilitate this integration and to promote the use of guidelines in clinical practice. Nevertheless, we do not exclude the possibility that a local system can provide its own methods of communication and presentation for alerts and reminders. GLEE thus provides the messaging function at the backend so that it can be used in this case as an alternative to facilitate the communication and integration. Further evaluation on this capability of GLEE needs to be performed in clinical settings.

Finally, the interface between the guideline representation model and other parts of the execution engine facilitates the maintenance of the execution system itself, including the evolution of the representation model and the generalization of the execution model. Further discussion on this topic is beyond the scope of this paper but can be found elsewhere [Wang D. et al., 2003, GESDOR - a generic execution model for sharing of computer-interpretable clinical practice guidelines]. Due to the restriction of available resources, the evaluation of GLEE was performed in a lab setting on a limited scale. In a production environment, additional efforts should be placed into the guideline encoding process to maximize its correctness. In addition, when future evaluations on GLEE's capabilities are performed, more clinician judges should be included and trained to enhance the reliability of their judgments. We are now working on the integration of GLEE with the clinical information system at New York- Presbyterian Hospital. Once this integration is completed, we will perform further studies on GLEE's use in clinical settings, including the impact of its execution flexibility on clinicians' use of guidelines.
 
Conclusion
We have developed the GLEE system to balance the requirements of guideline sharing, execution flexibility, and system maintenance. The technical evaluation of GLEE has shown that it can be used effectively for execution of guidelines encoded in the GLIF3 format. GLEE's use in clinical settings needs to be evaluated in the future. We understand, however, that wide acceptance of a guideline system in clinical practice depends on many other factors, such as the development of a widely-accepted standard patient-data model and the indepth understanding of local adaptation of guidelines. These issues are not addressed in our current work but help to define the challenges for the future. On the other hand, we believe that the modular design of GLEE will facilitate adoption and use of such standards for guideline-based decision support when a consensus develops.
 
Publications
  1. Wang D, Peleg M, Tu SW, Boxwala AA, Ogunyemi O, Zeng Q, Greenes RA, Patel VL, Shortliffe EH. "Design and implementation of the GLIF3 guideline execution engine." Journal of biomedical informatics. 2004; 37(5):305-18.
 

University of Rochester Medical Center
601 Elmwood Avenue, Box 689, Rochester, NY 14642.
Webmaster | Last update: 5/10/2011