PMCCPMCCPMCC

Search tips
Search criteria 

Advanced

 
Logo of procamiaLink to Publisher's site
 
AMIA Annu Symp Proc. 2005; 2005: 854–858.
PMCID: PMC1560650
Applying Hybrid-Asbru Clinical Guidelines Using the Spock System
Ohad Young, BSc and Yuval Shahar, MD, PhD
Medical Informatics Research Center, Department of Information Systems Engineering, Ben Gurion University, Beer Sheva 84105, Israel, http://medinfo.ise.bgu.ac.il/medlab/, {ohadyn,yshahar}/at/bgumail.bgu.ac.il
Clinical Guidelines are a major tool for improving the quality of medical care. Currently, a major research direction is automating the application of guidelines at the point of care. To support that automation, several requirements must be fulfilled, such as specification in a machine-interpretable format, and connection to an electronic patent record. We propose an innovative approach to guideline application, which capitalizes on our Digital electronic Guidelines Library (DeGeL). The DeGeL framework includes a new hybrid model for incremental specification of free-text guidelines, using several intermediate representations. The new approach was implemented, in the case of the Asbru guideline ontology, as the Spock system. Spock’s hybrid application engine supports application of guideline represented at an intermediate format. Spock was evaluated in a preliminary fashion by applying several guidelines to sample patient data.
Clinical practice guidelines are a powerful method for standardization, improvement of the quality of medical care, and sometimes even the survival of patients [1]. Clinical guidelines are most useful at the point of care [2]. However, care-providers, overloaded with information, rarely have the time, nor the computational means, to assist them in utilizing the valuable knowledge, encoded in free-text guidelines, during treatment. Therefore, there is a pressing need to facilitate the automation of guideline-based care. Since computers cannot yet interpret unstructured text-based guidelines, due to limitations of current technologies, such automation requires representation of guidelines in a formal, (i.e., a machine-interpretable) format.
During the past 20 years, there have been several efforts to support complex guideline-based care over time in automated fashion. An excellent comparative review of most current approaches is provided by Peleg et al.’s [3] comprehensive paper. In general, each of the frameworks for automation of guideline-based care includes a computerized system for runtime application of clinical guidelines. Examples include the task-based guideline execution engine in the EON framework [4], several applications developed with the Gaston framework [5], an execution engine, GLEE, for the GLIF 3.0 guideline ontology [6], and a guideline management system developed with NewGuide framework [7].
An effective framework for support of automated application of clinical guidelines must address several key requirements [2] such as:
  • Formal specification of guidelines, to enable interpretation by computers.
  • Retrieval of specified guidelines, to determine relevance to the patient prior to a guideline’s application, when several potential guidelines exist
  • Visualization of encoded guidelines, to assist the care provider to unambiguously and intuitively comprehend the guideline's contents
  • Reusing and sharability of guidelines through guideline specification using terms originating from controlled medical vocabularies.
  • Accessing patient data electronically, to apply a formal guideline to a particular patient.
  • Integration of the execution engine with the local clinical host systems (e.g., an order-entry system) via standard interfaces (e.g., HL7). In addition, the execution engine should be independent of any specific user interface.
  • Storing the runtime application state, to support episodic guideline application over extended periods, and various documentation needs.
Most guidelines are in free text, and their conversion to a formal format is a highly complex and time consuming task [2]. Expert physicians cannot program in guideline-specification languages, while programmers and knowledge engineers do not understand the clinical semantics of the guidelines.
The DeGeL Framework
To gradually convert clinical guidelines to formal representations, and answer the first desideratum, we have developed a hybrid (i.e., one that has multiple representation formats co-existing simultaneously), multifaceted representation, and an accompanying distributed computational architecture, the Digital electronic Guideline Library (DeGeL) [8]. The DeGeL framework supports all the tasks involved in automating guideline-based care, from specification and classification of guidelines, through retrieval and visualization of guidelines, to sophisticated application of the guideline to a patient. The DeGeL Web-based authoring tool, Uruz, incrementally transforms a set of clinical guidelines through several intermediate formats, eventually arriving at a fully formal representation of the guideline. The incremental conversion process uses the following representation formats: (1) Semi-structured Text – snippets of text, assigned by the medical expert, to top-level knowledge-roles (e.g., eligibility criteria) of the guideline ontology; (2) Semi-formal representation – further specification, mostly adding explicit procedural control structures (e.g., apply the actions in sequence or in parallel) performed jointly by the knowledge engineer and medical expert; (3) Formal representation – final specification, performed by the knowledge engineer, resulting with the guideline converted to a formal format in the selected ontology.
Thus, the output of the guideline conversion process is a hybrid representation which contains, for each guideline, or even for different knowledge roles within the same guideline, a mixture of the above formats and a pointer to the original textual source. The hybrid representation supports also the second desideratum, effective search and retrieval (at the point of care) of an appropriate guideline for application. The DeGeL search engine, Vaudurya, exploits the existence of textual representations for retrieval of guidelines from the DeGeL guideline knowledge-base. The third desideratum is answered by the DeGeL VisiGuide tool, which enables to visually inspect the search results (or any set of guidelines) by supporting interactive browsing of the guidelines contents. To support the fourth desideratum, the DeGeL specification tools are linked to a set of controlled medical vocabularies, which, in conjunction with a search and retrieval vocabulary engine, enable the author of the guideline to embed in it standard terms originating from international medical-terminology standards (e.g., SNOMED).
The Hybrid Asbru Guideline Ontology
The default ontology for guideline specification in DeGeL is the Asbru ontology. The Asbru guideline specification language [9] is an expressive guideline ontology developed as part of the Asgaard project for automation of guideline-based care [10]. Asbru plans include several knowledge-roles, such as conditions for controlling plan transitions into different states during plan’s application (e.g., a complete condition must hold in order for a plan to finish successfully). Highly expressive control structures (e.g., sequential or concurrent sub-plans) enable expression of synchronization constraints of actions to perform within the plan-body knowledge-role. Explicit intentions represent desired patterns regarding care-provider actions and patient outcomes. Atomic plans represent non-decomposable primitive actions, such as administration of a medication. Plans are decomposable into subplans, except for atomic plans (e.g., drug administration), which are not.
A hybrid version of Asbru, Hybrid-Asbru, was defined. The Hybrid-Asbru guideline ontology includes all of Asbru’s knowledge-roles, such as conditions (e.g., abort-condition), various synchronization constraints of sub-guidelines (i.e., do in parallel) and time-annotations for describing temporal constraints of patient’s clinical condition or plan state. However, each semantically meaningful knowledge role (e.g., Intentions) also contains a slot for the semi-structured content. In addition, more complex structures were created to store the content of the semi-formal format. For example, temporal-patterns are expressed using combinations of text, logical operators and time-annotations. New knowledge-roles were added, for example, instead of using Asbru’s formal notion of variables, parameters, constants and arguments relevant only to a fully automated application system, each semi-formal Asbru guideline has a list of patient-related data, obtained-values, defined during design-time and instantiated during the semi-automated application of the guideline for storing relevant patient data (e.g., hemoglobin levels). Finally, a set of common clinical actions, clinical-steps, such as drug-prescription, extends the notion of the Asbru atomic plans. Each of the semi-formal expressions includes optional pointers to the standard terms from our medical-vocabulary server.
We introduce the Spock system, an architecture that exploits the DeGeL framework which is aimed to assist a care provider in application at the point of care of guidelines specified using the Hybriid-Asbru ontology over long time periods. It is designed to support the application process to some extent, regardless of the guideline's representation level. It is also designed to conduct a practical dialog with the care-provider, regardless of whether an Electronic Patient Record (EPR) exists. Naturally, the services offered by Spock improve as the level of sophistication of the knowledge and data representation increases.
The Spock Hybrid Runtime Application Model
Spock's application model is hybrid in two senses:
  • The guideline representation level – due to DeGeL’s incremental guideline conversion process, the intermediate formats can be used also for application purposes. Thus, a candidate guideline for application can be in an intermediate or formal representation level available in the hybrid model.
  • The availability of an EPR or lack of it – the patient data required for guideline application is not always available electronically. Thus, interaction with the care-provider with respect to patient data might be required during guideline’s application especially when applying parts of a guideline that are in one of the intermediate formats.
The two dimensions of the hybrid application model, each with two values, imply four possible scenarios for applying guidelines. Although application of guidelines in a fully-automated fashion is feasible only when the guideline is in a formal format, automated support to some extent can be provided to guidelines in any of the intermediate representation levels as well. Formal guidelines can be applied if and only if an EPR is available. The nature of the formal format prevents its content from being interpreted by a human agent without having expert knowledge of the guideline ontology (e.g., Asbru), a capability which cannot be expected from a typical care-provider. Thus, only a computerized agent can interpret the formal content during guideline’s application, for example to determine the next sequence of actions to perform according to guideline's encoded recommendations. Conversely, guidelines represented using any of the intermediate representations, can be applied even when an EPR is not available. Only the relevant content of the guideline, depending on its state, will be displayed to the care-provider. Although most of the decision making is carried out by a human agent rather than by a computerized one, the overall workload on the care-provider is significantly diminished, since the care-provider is not required to consult the original textual guideline. The care-provider is guided more closely through the stages of applying a guideline since the semi-formal representation is expressive enough to describe the exact control structure of guideline’s procedural knowledge (e.g., perform actions in sequence). If an EPR is available, supplementary tools can be used to assist the care-provider in evaluating intermediate expressions regarding patient state. Nevertheless, if an EPR is not available, these intermediate expressions, expressed mainly in plain text, can still be evaluated by a human agent browsing the patient record. Thus, the care-provider can act as a patient-data mediator and provide Spock with results which will be used to determine the next appropriate step in the application of the guideline.
Since we expect most guidelines to be in intermediate representations within the near future, the current version of Spock focuses mainly on the scenarios of having an intermediate represented guideline with or without an EPR available.
The Distributed Architecture of the Spock System
The Spock client-server architecture (figure 1) consists of: (1) an application engine capable of applying Hybrid-Asbru guidelines, (2) a central repository for storing guideline application history, and (3) a user interface module for interacting with the care provider. In addition, it relies on external resources for its operation: (1) a knowledge-base of hybrid guidelines, (2) a service that can access heterogeneous clinical data repositories, and (3) a vocabulary server of controlled medical standards.
Fig. 1
Fig. 1
The Spock client-server architecture.
All of the resources, external (e.g., guideline knowledge-base) and internal (e.g., GUI), used by the application engine follow a specific behavior defined in a set of programmatic interfaces published by the Spock system. For example the interface for the GUI details operations such as displaying the guideline's recommended actions.
Patient Data Related Tasks
To answer desideratum five, access to patient data, the IDAN [11] framework is used. The IDAN framework encapsulates the complexity of accessing heterogeneous clinical data repositories and provides mechanisms to perform complicated abstractions of time-oriented raw data (e.g., hemoglobin levels) into more meaningful concepts (e.g., levels of anemia). Whenever a query regarding patient data comes up during guideline application, several options exist:
  • Direct Access – queries to IDAN’s mediator can be made directly if the expression is formatted in IDAN’s query language which is supported by the semi-formal Asbru representation format.
  • Indirect Access – using a dedicated patient-data visualization and exploration tool, KNAVE-II [12], the care-provider can perform intelligent analysis, visualization and exploration of electronic patient data.
Thus, if an EPR is available, the user can benefit from KNAVE-II and IDAN by quickly browsing the patient’s clinical data relevant for the guideline.
The Spock Guideline Execution Engine
For addressing desideratum six, integration with local clinical host systems, the execution engine (figure 2) development followed the Model-View-Control (MVC) design pattern, which enables the decoupling of the logic layer (i.e., applying a guideline) from the other layers (e.g., data access and the presentation layers). Thus, the application engine is independent of the other layers it uses. Hence, each potential deployment site can seamlessly link its own specific GUI to the execution engine. Albeit, the Spock system includes a default GUI.
Fig. 2
Fig. 2
The Hybrid-Asbru guideline execution engine.
A parser for the Hybrid-Asbru ontology was developed for interpreting the content of a guideline. The parser transforms the content, which is in XML format, based on the ontology's XML Schema.
For applying a guideline, the care provider first selects a guideline using the search engine of DeGeL. For each application of a guideline, an application-instance is created. As the application proceeds, a plan-instance is created for every recommended sub-guideline (or plan) that is activated. The application process follows the Asbru state transition model. All of the plan-instances, generated for the same application-instance, are connected in a network of state transitions propagation. Every state transition is either downward propagated (e.g., suspension of a plan suspends all of its child plans) or upward propagated (e.g., termination of a plan might cause its parent plan to terminate).
First, the selection phase is performed by evaluating the eligibility criteria (i.e., Asbru's filter and setup conditions). If applicable, the application phase commences by adding other conditions (e.g., abort and complete conditions) to the plan-instance's list of monitored conditions. The user is prompted occasionally to check the status of the monitored conditions throughout each application session. Secondly, the plan-body is interpreted and the user is given recommendations for actions to perform according to the specified plan-steps. There are two types of plan steps: (1) action-step (e.g., order a laboratory test) or (2) decision-step (e.g., if-then-else statement) which might result with an additional plan-step. Each plan-step is assigned with a state (e.g., suggested, apply, and declined) depending on its type and synchronization constraint (e.g., do in parallel) of its containing plan-body. In case a recommendation is declined, the user is prompted to supply an explanation justifying it. The explanation is recorded in the application log for further use (e.g., by a retrospective quality assessment module).
The Guideline Application Log
For answering desideratum seven, storing the runtime application state, essential to the Spock system since its process of applying a guideline is a process spanning long time periods performed in an episodic fashion during patient’s visits. The guideline application log contains several data structures for each application-instance such as: (1) state transitions of a plan-instance (e.g., activated or completed), (2) list of recommended plan-steps issued during application (e.g., order a lab test), and (3) list of obtained-values relevant for each plan-instance. Thus, when resuming an application-instance which had been started previously, the history of its previous sessions is retrieved in order to continue from the point last stopped at. Furthermore, other modules can benefit from the historical information, for example a retrospective quality-assessment module. Finally, the application log is stored on a centralized repository located on a remote server, accessible to any Spock client operated from a computer anywhere in the local network.
The Default GUI Module of the Spock System
A default GUI (figure 3) was developed for evaluation purposes. It consists of: (1) Application plan tree – portrays the plan-instance hierarchy of the current application-instance enabling the user to navigate between the different plan-instances. (2) Plan information console – a dynamic content area which displays the information of a certain plan-instance depending on its state. For example, during the selection phase, the eligibility criteria is displayed while during the application phase the plan-instance's recommended plan-steps and monitored conditions are displayed. (3) Application trace - a textual summary of all information (e.g., state transitions of plans) related to the current application session.
Fig. 3
Fig. 3
The default user interface of the Spock system.
We have specified several guidelines in the Endocrinology, Pulmonology, and Gynecology areas using the Hybrid-Asbru ontology, with collaborators from Stanford University, California, USA, and Ben-Gurion University, Beer-Sheva, Israel. In addition, sample patient records, covering various options, for all specified guideline were prepared as well. The focus of the evaluation was to test the feasibility of applying guidelines represented in intermediate formats. Thus, with the assistance of a medical expert, a list of expected recommendations was prepared for each combination of specified guideline and set of patient simulated records. Meanwhile, the Spock system was applied to the same guidelines and simulated patient records. The expected recommendations list is then compared to Spock's output. The initial results were encouraging and we are currently in the process of a more formal evaluation.
The Spock architecture is designed to support application of guidelines that are at various levels of formatting, when patient data are in either electronic or paper format, whereas, other approaches for applying guidelines assume the existence of a guideline in a formal format and require a connection to an EPR. We expect that in the near future the most common configuration when applying clinical guidelines will involve intermediate representations, with or without an EPR. Thus, it is imperative to provide a flexible application engine that supports variable guideline representation formats. The current Spock system focuses on supporting application of intermediate representation formats. Our future plans include adding of support to application of fully formal Hybrid-Asbru guidelines. In addition, we intend to test whether the Spock system’s features are suitable to additional tasks such as an educational tool for simulating test scenarios.
Acknowledgments
This research was supported in part by NIH award LM-06806. Drs. M. Goldstein, S. Martins, L. Basso, H. Kaizer, E. Lunenfeld, and G. Bar were extremely helpful in the evaluation of all of the DeGeL tools.
1. Micieli G, Cavallini A, Qauglini S. Guideline Compliance Improves Stroke Outcome - A Preliminary Study in 4 Districts in the Italian Region of Lombardia. Stroke. 2002;33
2. Zielstorff, R., Online Practice Guidelines: Issues, Obstacles and Future Prospects. Journal of the American Medical Informatics Association, 1998. [PMC free article] [PubMed]
3. Peleg M, Tu S, Bury J, et al. Comparing Computer-Interpretable Guideline Models: A Case-Study Approach. Journal of the American Medical Informatics Association. 2003;10(1)
4. Tu, S. and Musen, M. From guideline modeling to guideline execution: defining guideline-based decision-support services. Proc. of AMIA, 2000. [PMC free article] [PubMed]
5. de Clercq P, Hasman A. Experiences with the development, implementation and evaluation of automated decision support systems. Proceedings of MEDINFO-04. 2004:1033–7.
6. Wang, D., Peleg, M., Tu, S., et al., Design and implementation of the GLIF3 guideline execution engine. Journal of Biomedical Informatics, 2004. [PubMed]
7. Ciccarese P, Caffi E, Boiocchi L, et al. A guideline management system. Proceedings of MEDINFO-04. 2004:28–32.
8. Shahar Y, Young O, Shalom E, et al. A Framework for a Distributed, Hybrid, Multiple-Ontology Clinical-Guideline Library and Automated Guideline-Support Tools. Journal of Biomedical Informatics. 2004;37(5):325–344. [PubMed]
9. Miksch, S., Shahar, Y., and Johnson, P. Asbru: A Task-Specific, Intention-Based, and Time-Oriented Language for Representing Skeletal Plans. Proceedings of the 7th Workshop on Knowledge Engineering: Methods & Languages 1997.
10. Shahar Y, Miksch S, Johnson P. The Asgaard project: A task-specific framework for the application and critiquing of time-oriented clinical guidelines. Artificial Intelligence in Medicine. 1998;14:29–51. [PubMed]
11. Boaz, D. and Shahar, Y. Idan: A distributed temporal-abstraction mediator for medical databases. Proceedings of AIME-03, 2003.
12. Shahar, Y., Goren-Bar, D., et al., Distributed, intelligent, interactive visualization and exploration of time-oriented clinical data. In press for Artificial Intelligence in Medicine. [PubMed]
Articles from AMIA Annual Symposium Proceedings are provided here courtesy of
American Medical Informatics Association