The GLIF3 Guideline Execution Engine (GLEE)
Task Scheduling and Tracing System
Patient Data Retrieval, Clinical Event Registration, and Clinical Action Notification
Expression Language and Scheduling Constraint Specification Language
The GLIF3 Guideline Execution Engine (GLEE) is developed as a tool to support the execution of clinical practice guidelines encoded in the GLIF3 format. It is built as middleware to be integrated with the clinical information system at a local institution through standard interfaces to its electronic medical record (EMR) and clinical applications. In addition to clinical decision support, GLEE aims to be used for quality assurance, guideline development, and medical education. GLEE is implemented using the JAVA programming language.
GLEE provides standard interfaces to the hosting clinical information
system at a local institution, as shown in Figure 1. These standard interfaces
are used to integrate GLEE with 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 enables GLEE’s
access to various resources in the local environment, such as retrieval of
patient data and monitoring of clinical events, which are required by a
guideline implementation system. The communication between GLEE and the 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.
Figure 1. The relationship among GLEE, a local EMR, and the associated
clinical applications.
Internally, GLEE takes a layered approach to partitioning the functions
provided by its components. GLEE is built as a client-server system to obtain
maximum flexibility in its integration with hosting systems. In addition to the
standard interfaces to a local clinical information system, GLEE also provides
a standalone user interface to facilitate development and demonstration. The
internal structure of GLEE and its interactions with a local environment is
shown in Figure 2. Figure 4 in the Task Scheduling and Tracing System section
is a screenshot of the standalone user interface.
Figure 2. The internal structure of GLEE and its interactions with a local environment.
Task Scheduling
and Tracing System
GLEE’s execution model supports user-controlled task scheduling to provide extra flexibility in guideline execution. For this purpose, four execution states are used to represent the status of a guideline step during the guideline execution process. These four execution states include (1) prepared state, which means a step is suggested as executable by the execution engine, (2) started state, which means a step has actually been started by a user, (3) stopped state, which means a step has been intentionally stopped by a user before it starts or completes its execution, and (4) finished state, which means a step has normally completed its execution. The prepared state and the started state are jointly called active state. The finished state and the stopped state are jointly called inactive state. The execution states of a guideline step and the transitions between these states are shown in Figure 3.
Figure 3. The execution states of a guideline step and the transitions between these states.
GLEE keeps the trace of execution when a guideline is applied to a particular patient. These trace records are used as a hint for task scheduling in future encounters of the patient when the same guideline is reapplied. In addition, the execution traces can be used as a complete record of a guideline’s application for quality assurance purposes to determine whether the care provided to a patient is in compliance with guideline recommendations. The traces records are implemented as XML files stored at the server side of GLEE.
Figure 4 is a screenshot of GLEE’s standalone user interface, with the execution states of the active guideline steps and the execution traces presented.
Figure 4. A screenshot of the standalone user interface at the client side of GLEE. 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.
GLEE supports the event-driven execution model. For this purpose, GLEE
assumes there is a clinical event monitor within the clinical information
system at a local institution, and the GLEE server will be able to interface
with this clinical event monitor to use the services provided by it. When a
guideline step with a triggering event encoded is started, GLEE first registers
that event with the clinical event monitor at the local institution. After
that, the execution of that guideline step is put on hold until the registered
event occurs to trigger its execution. GLEE uses an internal event
registration record to manage all the events registered and triggered.
GLEE’s task execution is based on GLIF3 specification. Below is an
overview of the major tasks in GLIF3 guideline’s execution.
· action step: register events, process specific actions (clinical action notification, data retrieval, data assignment, subguideline), schedule next step.
· decision step: register events, select option through evaluation of decision criteria or by user decision, schedule next step.
· patient state step: present patient status, schedule next step.
· branch step: schedule multiple subsequent steps.
· synchronization step: evaluate continuation criterion, schedule next step.
Patient Data
Retrieval, Clinical Event Registration, and Clinical Action Notification
Access to patient data is a critical task in guideline execution. GLEE’s patient data retrieval is through a standard interface to the clinical data repository at a local institution, using the identification of a terminology, a concept in that terminology, a patient data model, and a specific data-model class to uniquely encode a patient data. A local institution needs to map this encoding of patient data to their clinical data repository to facilitate GLEE’s patient data retrieval. This approach is compatible with recent research on the development of a virtual medical record, which is a standard patient data model that needs to be mapped to the schema of the clinical data repository at a local institution. Clinical event registration and clinical action notification is handled by GLEE in a similar approach.
Expression
Language and Scheduling Constraint Specification Language
In GLIF3, the expression language is used to encode decision criteria and patient states. It is closely related to the data model that presupposes how the variables in an expression can be referenced. The current implementation of GLEE supports the Guideline Expression Language (GEL), which is developed at the Decision System Group of Harvard University. GLEE can be easily extended to support other expression languages.
The scheduling constraint
specification language is used in GLIF3 to encode the continuation criterion of
a synchronization step, which defines the coordination among different
guideline steps through logical combination.
Evaluation has shown that GLEE can be used for the effective execution
of the guidelines encoded in the GLIF3 format. Using physicians’ judgments as
the gold standard, GLEE’s performance has reached the level of the reference
systems.
An overview of the GLEE system, published as a paper in the Proceedings of the AMIA Symposium 2002, can be downloaded here. A longer version of the paper with detailed description of the GLEE system is in preparation and will be put up online soon. For further questions and comments, please contact Dr. Dongwen Wang, Department of Biomedical Informatics, Columbia University, at dongwen.wang@dbmi.columbia.edu.
·
Wang D. A
generic execution model for sharing of computer-interpretable clinical practice
guidelines. PhD Dissertation. Columbia University, 2003.
·
Wang D, Shortliffe EH. GLEE – a model-driven execution
system for computer-based implementation of clinical practice guidelines. Proc
AMIA Symp. 2002;:855-9. [full
text in PDF format]
·
Patel VL, Branch T, Wang D, Peleg M, Boxwala A.
Analysis of the process of encoding guidelines: a comparison of GLIF2 and
GLIF3. Methods
Inf Med. 2002;41(2):105-13. [full
text in PDF format]
·
Boxwala AA, Tu S, Peleg M, Zeng Q, Ogunyemi O, Greenes
RA, et al. Toward a representation format for sharable clinical guidelines. J
Biomed Inform. 2001;34(3):157-169.
[full
text in PDF format]
·
Greenes RA, Peleg M, Boxwala A, Tu S, Patel V,
Shortliffe EH. Sharable computer-based clinical practice guidelines: rationale,
obstacles, approaches, and prospects. Medinfo.
2001;10(Pt 1):201-5.
·
Peleg M, Boxwala AA, Ogunyemi O, Zeng Q, Tu S, Lacson
R, et al. GLIF3: the evolution of a guideline representation format. Proc
AMIA Symp. 2000:645-9.
·
Ohno-Machado L, Gennari JH, Murphy SN, Jain NL, Tu SW,
Oliver DE, et al. The GuideLine Interchange Format: a model for representing
guidelines. J
Am Med Inform Assoc. 1998;5(4):357-72.
[full text in PDF
format]
·
Shortliffe EH, Patel VL, Cimino JJ, Barnett GO, Greenes
RA. A study of collaboration among medical informatics research laboratories. Artif
Intell Med. 1998;12(2):97-123. [full
text in PDF format]
Last updated on March 26,
2003