describe in detail about the guideline development process with GASTON and its major applications. Area of future .... Primitives in Gaston are based on version 2.0 of GLIF [8][10]. Four types of ..... (Eds)Amsterdam: IOS Press. [14] Tu SW ...
GASTON: A GENERIC FRAMEWORK FOR CLINICAL GUIDELINE DEVELOPMENT Manhui Li, Bogdan Superceanu, Zuoyu Zheng Emails{manhui, bogdan, zzheng}@cs.dal.ca
ABSTRACT: Development and implementation of clinical guidelines have been documented to reduce inappropriate variations in clinical practice and improve the outcome of health care as well as contain the cost. Although tremendous efforts have been spent on developing guidelines, for various reasons, the implementation hasn’t been very successful. GASTON, a generic architecture for guideline development involved with knowledge representation and acquisition, guideline verification, and execution, is one of the efforts to improve the implementation of clinical guidelines by means of translating paper-based guidelines to computer interpretable guidelines so that the knowledge in these guidelines can be stored into the knowledge base of the clinical decision support systems which will provide unobtrusive decision support to the clinicians at the point of care. As a generic framework, GASTON provides a newly developed guideline representation formalism that uses primitives, problem-solving method (PSM) and ontologies; (2) a guideline authoring environment that enables the users to develop guidelines with the new formalism; (3) a guideline execution environment in which the clinical guidelines are translated to encoded level so that it can be processed by an execution engine of the decision support system. In this paper we are going to describe in detail about the guideline development process with GASTON and its major applications. Area of future development will also be discussed at the end of this paper. KEYWORDS GASTON, Knowledge Representation, Ontology, Knowledge Acquisition, Clinical Practice Guidelines, Decision Support System, Computer Interpretable Guidelines
1. INTRODUCTION Clinical practice guidelines (CPG) have been developed and implemented to reduce the errors and unjustified variations in clinical practice so as to improve the health care quality based on the best practice as well as to contain the cost. The promotion of clinical guidelines aims to provide a quality standard for comparison among different health institutions. Although much effort has been made in developing clinical guidelines, they have a limited effect on physician’s behavior with various reasons [1]. Studies have shown that clinicians are often not familiar with written guidelines and also do not apply them appropriately during the actual care process. Implementing guidelines in computerbased decision support systems promises to improve the acceptance and application of guidelines in daily practice [2]. According to the Institute of Medicine (IOM), decision support systems are in fact crucial elements in long-term strategies for promoting the use of guidelines.
1
Strong evidence has demonstrated that computer interpretable guidelines (CIG) could improve the performance of physicians in patient care [3]. They promote guideline using by increasing the awareness and compliance of physicians to the implemented guidelines. By combination with an outside data sources such as electronic patient record or order entry system, CIGs are able to adapt to a clinical context and give specific recommendations at the point of care. Through translation from paper-based to computer interpretable guidelines, deficiencies and ambiguity of those guidelines can be highlighted and revised. In contrast to paper-based guidelines, the multi-media nature of CIGs enhances its function for didactic purposes by using images, videos, sounds, simulations and links to bibliographic databases. The most difficult part in implementing clinical CPG in decision support systems (DSS) is the translation of CPGs from their published text formats into computer algorithms. A lot of work has to be done to design appropriate models to represent a guideline and different modeling methodologies have been developed to convert natural language guidelines into an electronic format, executable by a computer. Examples of such methodologies can be found at www.openclinical.org In this article, we will first review the basic design requirements of DSS in general. Then we will take GASTON as an example and give a detailed picture how a generic framework has been developed. Future developments of GASTON will also be discussed at the end.
2. GENERAL DESIGN AND REQUIREMENTS OF CDSS Encoding guidelines into computer interpretable format requires tremendous effort. Interoperability and sharability of encoded guidelines are crucial to the dissemination and implementation in institutions with different clinical information systems. Several groups have dedicated in developing frameworks and set standards for DSS to enhance the sharability of clinical guidelines. Common areas in the development process are shared among these frameworks which include guideline representation, acquisition, verification, and execution [2].
2.1
Guideline representation
The general requirements of guideline representation emphasize the accuracy and expressiveness of the model. Clinical guidelines contain medical concepts such as diseases, symptoms, signs, procedures and laboratory tests. An in-depth understanding of these concepts is essential for guideline representation. An expressive guideline representation not only models explicit concepts and logic but also handles uncertainty in patient data and guidelines. But there are always tradeoffs between the complexity and the expressiveness to obtain the appropriate granularity for the guideline representation. Since guidelines are not static and they are always subject to changes according to the best evidence, the representation should be flexible enough to accommodate these changes without affecting the parts that remain the same. Furthermore, the clinical guidelines experience local adaptation to make them acceptable to the healthcare providers within a specific clinical setting, which requires the guideline representation to be as general as possible so that they can be shared in different institutions.
2.2
Guideline acquisition
Traditionally guideline acquisition relies on close cooperation between system engineers and domain experts, which can be time-consuming before they reach an agreement on a specific clinical guideline. Knowledge acquisition tools (KA tools), by separating domain independent algorithm from domain dependent ontology, enable the acquisition of knowledge directly from domain experts. The guideline acquisition process can be facilitated significantly if domain experts
2
use these KA tools to formulate the domain knowledge used in guidelines. Customized userfriendly interfaces of KA tools defined by plug-ins have been developed to enhance the ability of domain experts for knowledge entry [4].
2.3
Guideline verification and testing
Quality concerns demand the number of false alarm and error at a minimal level from the decision support system, which highlights a requirement of little ambiguity and maximal accuracy in both syntax and semantic in the encoding process of clinical guidelines. One of the useful strategies in the practice is to test the CIGs with existing patient records and then compare the outcome with that of the domain experts [5]. New features of the execution engine, such as usercontrolled task scheduling and tracing system of the guideline execution, provide new measures for quality assurance [6]. Automatic consistency checking also proves to be an efficient way to reduce errors in knowledge acquisition [7]
2.4
Guideline execution
In guideline execution, a general guideline acquired by domain experts is executed for a specific patient with a specific condition. In order for the execution engine to be reusable for different guidelines, it has to be domain independent provided that the clinical guidelines are represented in a standard formalism. It also must be task-independent so that it can be used not only for clinical decision support but also for education, critique and performance evaluation [7]. Currently lots of efforts are focusing on the communication of the decision support system with EPR. Unless the clinical guidelines share the same ontology with EPR, the mapping problem decides the proper implementation of the decision support system.
3. DEVELOPING THE FRAMEWORK OF GASTON For the purpose of translating paper-based CPG to CIG and making them sharable among different institutions, a variety of research groups have been endeavouring to establish a standard framework or architecture to facilitate the development of CIG applications. GASTON, developed by Eindhoven University of Technology; Maastricht University and Medecs, Netherlands since 1997 is a generic architecture for the design, development, validation and implementation of guideline-based medical decision support systems. Its development consists of four stages: (1) define domain and method ontologies; (2) develop libraries of PSMs; (3) author guidelines through a KA-tool; (4) execute guidelines [8]. Fig. 1 shows the development process view of GASTON framework.
Fig. 1. Process view of GASTON framework
3
3.1
Representing guidelines - Ontologies in Gaston
Two types of ontologies are used to represent guidelines: domain and method ontology. A domain ontology models domain specific knowledge in terms of entities, attributes and relations. A method ontology in Gaston model concepts such as primitives, PSMs and guidelines. Both ontologies used in Gaston are built with the Protégé ontology editor and both are represented in terms of entities, attributes and relations. 3.1.1
Representing domain knowledge - Domain Ontology
A domain ontology defines the concepts that are relevant to the application domain in terms of classes and attributes. Domain ontologies should be based on existing terminologies. This is because using standard medical terminologies in a domain ontology helps interfacing the decision support system with patient records and patient information systems which use such terminologies. For example, a domain ontology for a system used in primary care was built based on the International Classification of Primary Care (ICPC). In order to improve standardization aspects some authors recommend using standard terminologies such as UMLS or SNOMED for all medical ontologies used in decision support systems.[9]. The knowledge base that contains the actual guidelines is described by class instances in which attributes have specific values. Instances of a class are not considered part of the ontology but are acquired through knowledge acquisition. However, it depends on the domain and the developer of the domain ontology what is regarded as a class and what is regarded as an instance of a class. For example we can build either one class for every drug or one generic drug class and every particular drug is regarded as an instance of the generic drug class. Bellow we can see a graphical view of a part of a domain ontology in Intensive Care Unit (ICU) (Fig. 2) It shows concepts like drugs, diseases and relations between them. The first step when building a domain ontology is to draw such an entity–relation diagram. The “is_a” relation will help build hierarchy of classes that use the inheritance concept. Inheritance is often used to define additional classes that characterize more specific concepts (antibiotic is a specific drug)
Fig. 2 - Schema of a part of a domain ontology in ICU
4
The classes are arranged in a hierarchy like in the left pane of the picture below (Fig. 3). In such a hierarchy classes inherit attributes from parent classes and further define specific properties.(antibiotics “is_a” drug so drug class is a parent class for antibiotics class). Some attributes of classes are classes themselves (has_interaction attribute below is described by the interaction_relation class). Relationships between classes are described by this kind of attributes that are instances of other classes. Attributes can also refer to multiple class instances. The asterisk bellow indicates that a drug can have many interactions.
Fig. 3 - Part of a domain ontology in ICU (hierarchical representation of classes)
When building ontologies for the Gaston framework we also need to understand the concept of metaclasses. A metaclass is a class whose instances are themselves classes. It acts as a template for classes that are its instances. Therefore, every class has a dual identity: it is a subclass of a class (called superclass) in the class hierarchy and it is an instance of another class (called metaclass.) [8]. Concepts such hierarchy of classes, inheritance, metaclasses, are also found when modelling knowledge in object oriented programming. Concepts in domain ontology may contain references to patient records where the actual data can be found during the execution of a guideline. This enables the reuse of domain ontologies (e.g. a single domain ontology can be linked to multiple patient record systems) but incompatibilities may exist between concepts from the domain ontology and concepts from a patient record or terminology server. This problem is called the mapping problem and often has to be solved individually for each case. [10]
3.1.2
Method ontology
Method ontologies contain concepts such as steps typically undertaken by health care providers during reasoning. Method ontologies capture and represent these steps using concepts such as primitives, PSMs (problem solving methods) and guidelines. An example of frequent encountered steps during reasoning consists of three steps: an event indicating a certain patient state, a decision step (like diagnosing a disease) and an action step indicating what action has to be done to treat the patient with the previous diagnostic. Such steps together with other common steps in reasoning are stored as concepts in a method ontology. The picture below (Fig.4) shows a method ontology in Protégé editor. We can see in the left pane the hierarchy of classes that represent common tasks performed during the reasoning process. In the right pane we have attributes (slots) of the selected class. These classes represent primitives, PSMs and guidelines. For example K_of_N Criteria class is a primitive that models a decision. If K
5
criteria out of N are satisfied then process the task specified by the primitive on the Satisfied_ Step attribute, otherwise process the task specified by the primitive on the Otherwise_ Step attribute.
Fig. 4 – Part of a method ontology in Protege
Primitives are a set of non-decomposable building blocks, used to represent clinical tasks in a guideline. They represent both non-decomposable parts in a guideline (e.g. decisions and actions) and non-decomposable parts in PSMs. Primitives are used to describe single guideline steps, and to describe the internal structure of PSMs. Primitives in Gaston are based on version 2.0 of GLIF [8][10]. Four types of primitives are commonly used in Gaston to describe guidelines: • • • •
Action (intervention) primitives that specify clinical actions. Decision primitives that model decision points in a guideline. Branching primitives that direct the guideline flow to multiple (parallel) paths. Synchronization primitives that converge paths that previously diverged by means of a Branching primitive.
There are many models for representing primitives. Other types of primitives found in other systems like GLIF, EON etc. are: patient states, execution states and data collection. Patient states reflect the clinical status of a patient during the process of guideline application, while at the system side, execution states reflect the situation of a guideline implementation system at a specific time. [11].
6
Problem solving methods (PSMs) represent generic strategies to solve stereotypical tasks, independent of the system's application domain. PSMs can be reused to solve similar problems in different application domains by using different domain ontologies. PSMs are decomposable into subtasks, which can be executed by submethods. PSMs have a control structure that describes its internal structure in terms of subcomponents. This structure may refer to subtasks that are solved by other PSMs but also by primitives.[10][8] A comparison between the use of primitives versus PSMs in guideline representation shows the following advantages and disadvantages of the PSM based approach: An advantage of the PSM approach for representing guidelines is the separation of domain-specific knowledge and domain independent methods, which increases the reusability and shareability. A primitive is more difficult to reuse because often domain and procedural knowledge are intertwined. However there are two important disadvantages when using PSMs for guideline representation: • Because PSMs are domain independent representations, the visualization of a PSM through a KA-Tool may be too abstract for a domain expert to enter domain knowledge efficiently. • Certain types of protocols used in daily practice do not easily fit the highly formalized formats used in a PSM.[10] As a result of pros and cons with using PSMs, GASTON framework uses a new approach by combining primitives, problem-solving methods (PSMs) and ontologies to represent guidelines. Domain specific guidelines are usually too specific to be captured by PSMs so they are represented by a set of ptimitives. Guidelines that address more generic tasks are more suited to be represented by means of PSM. To represent guidelines, primitives need to be organized to form a specific model of clinical practice guidelines (CPG). During guideline execution there are scheduling constraints on primitives. Scheduling constraints specify the temporal order in which representation primitives can be executed during guideline application. Guideline representation model in Gaston permits nesting of guidelines. Nesting of guidelines defines a hierarchical relationship among guidelines and provides multiple level of abstraction. In Gaston scheduling constraints are represented as flowcharts or algorithms, nesting of guidelines is done through inclusion of subguidelines and modelling of patient data is done by using a domain ontology. [11]. The core method ontology. A core method ontology was developed to model various categories of guidelines. It defines the characteristics of a primitive, a PSM, a guideline and other related concepts (Fig.5). Figure 5 describes the guideline model through a hierarchy of classes. On the right side the most important classes of the core method ontology are presented in detail. Primitive class consists of attributes that specify the primitive name, author and an explanation. Parameters attribute may contain mappings to parameters from other primitives, to concepts from the domain ontology or to knowledge roles from a PSM. Visualization information is used by a system developer to define the characteristics of a primitive-specific user interface in a KA-Tool. The Procedure attribute contains execution-time information, used by a decision support system that incorporates the primitive.[8] PSM class also consists of attributes that are administrative like name, author, explanation. Similar to primitives, PSMs also contain visualization information that defines a specific user interface for use in a KA-Tool. However, the visualization information of the PSM is more complex since a PSM has access to all the visualization information of the subcomponents (primitives or PSMs) in its control structure. PSMs define input and output knowledge roles, used for communication outside the PSM. PSMs have a control structure that describes its internal
7
structure in terms of subcomponents. This structure may refer to subtasks that are solved by other PSMs but also by primitives. [8]
Fig. 5 A section of the core method ontology in GASTON
Guideline class describes an entire guideline or subguideline. A guideline is associated with a task it has to solve. This task can be solved explicitly by processing a set of primitives or by selecting an appropriate PSM. This class also has some administrative-like attributes (name, author explanation) and some guideline-specific attributes such as a task attribute that describes the task that has to be solved, validation attribute that indicates whether the guideline has been approved for routine use and target_users attribute that denotes the intended users of the guideline. In contrast to the control structure of a PSM, however, the control structure of a guideline does not support subtask decomposition: it contains a set of primitives or a reference to a single PSM. From the visualization information of a guideline, a flowchart will be created in case the control structure consists of a number of elements.[8] The relation between Domain and Method Ontologies. Even though both are ontologies they model different concepts: concepts from a particular medical field and clinical reasoning steps. Although there is not a direct relation between them they are complementary to each other. They are both used in the KA-Tool to represent guidelines. With method ontologies we can model the flow of tasks undertaken in the clinical care process but to completely specify a guideline we also need the concepts from a specific area which are provided and modelled by the domain ontology. The interaction between Domain Ontology and Method ontology is best seen by describing how guidelines are built with the KA-Tool. After building the domain and method ontologies the KA-
8
Tool loads the domain ontology, the required primitives and PSMs and creates a user interface that enables guideline authors to define guidelines in a clinical context. Even though this analogy may not be prefect we can think of domain ontologies as being substantives and attributes and method ontologies being verbs(actions) and conjunctions (decisions like - if ) in a clinical practice guideline statement. Gaston framework is flexible enough so depending on the requirements of the method ontology, existing domain ontologies can be extended with new attributes or relations. [10]. Vice versa is also possible. When we have very complex guidelines we can extend the method ontology with new primitives.
3.2
Method Library
In this stage, a method library is created by Protégé to collect the predefined PSMs, which can be used in the third stage for guidelines acquisition in various domains. Each PSM is represented by means of a collection of instances, but those instances are not regarded as part of method ontology. [8] Each PSM instance has ten attributes (defined in standard PSM class in Fig. 6). Besides the attributes that describe the PSM’s pragmatics (Name, Author and Description), the PSM instance also contains attributes that define the capabilities of the PSM such as the Goal, Visualization, Control, Refiners and Mapping attributes. Visualization and Control attributes of an instance are defined in this stage, and the first four attributes give the specific explanation of a PSM. Control attribute defines the global control structure, which describes the internal structure of a PSM in terms of subcomponent (may be primitives or PSMs), and Visualization attribute accesses to all the visualization information the subcomponent in the control structure and this visualization information is used by the PSM to define a specific user interface in knowledge acquisition stage by combining with the knowledge roles of each subcomponent.
Fig. 6. The attributes of Name, Caption, Goal, Explanation, Visualization and Control attributes of an instance are defined in this stage, and the rests are specified in guideline acquisition.
In addition, three types of knowledge roles are defined in method library, input roles, output roles and intermediate roles. Input and output roles refer to knowledge roles that are also used by other PSMs (e.g. another PSM that uses this PSM to solve a certain subtask), whereas intermediate roles refer to knowledge roles that are used only by the PSM internally. [8] Those knowledge roles are carried by Mappings attribute. Refiner attribute specifies which (combination of) attributes of the PSM are used to further refine the primitive. However Refiners and Mappings attributes are not defined in method library because those abstract PSMs instance are not yet specified in a specific domain, and the knowledge roles are also not yet specified, the mapping onto domain-specific ontology process that results in application-specific PSMs is carried out during the knowledge acquisition phase. Moreover, the Author and Description attributes are also defined in the knowledge acquisition phase.
9
3.3
Guideline Acquisition
An important issue in the development of guidelines is the knowledge acquisition process. The traditional knowledge elicitation methodology that required an intense cooperation between knowledge engineer and domain expert created a severe bottleneck as the two experts had to reach a common understanding before progress could be made [12]. Knowledge acquisition tools (KATools) are most used in this process to facilitate domain expert to acquire knowledge, formulate and structure domain knowledge for clinical decision support system efficiently in a visualized environment. Gaston develops a separate KA-Tools (not automatically generated by Protégé), which creates a user interface that enables guideline authors to develop guidelines in terms of primitives and PSMs by loading the required method ontology and domain ontology through a design-time interpreter. 3.3.1 Knowledge Acquisition Tools The KA-Tool in Gaston, used to facilitate the guideline authoring process, consists of a collection of modular components. An overview of these components is shown in Fig. 7.
Fig.7 System view of the components in the KA-Tools
The core of the KA-Tool is a design-time interpreter, which provides a means of communication between the user and various knowledge managers such as a Domain Manager, a Guideline Manager and a Method Manager. [8] In order to fit in various application domains, the KA-Tool has been implemented as a kernel that loads those knowledge managers as plugins, in which each plugin defines a different functionality. In current version, the design-time interpreter reads dynamic-link libraries (DLLs) programmed by any languages as plugins under Microsoft Windows system. Through this means the KA-tool can load multiple plugins as well as specific plugins to perform flexibly in different application domains. The design-time interpreter communicates with all loaded plugins through a standard interface and does not differentiate between different types of plugins. As there is also no limit on the number of loaded plugins, multiple plugins of similar functionalities can be loaded. Therefore, the KA-Tool may contain multiple domain ontologies, method libraries or guideline libraries. [8] After loading all plugins, design-time interpreter can combine information from all available managers, and then transfer those information into a user friendly visualized format according to the visualization information of ontologies, which are specified in guideline presentation process. Primitives are displayed in a flowchart representing the guideline, whereas PSMs are visualized by utilizing the visualization information of the PSM itself. The latter enables guideline authors to enter domain information regarding the corresponding task without the need to know the internal control structure of the PSM. [8]
10
KA-Tool provides a user-friendly interface to facilitate guideline author develop guideline through an easy way. The KA-Tool interface generally consists of three parts, the Method Ontology pane, Domain Ontology pane and Guideline pane. Method Ontology Pane contains all the method ontology in terms of unrefined primitives and PSMs in Method Library as well as all the already defined guideline stored in Guideline Library, Domain Ontology pane shows all concepts stored in an application-specific domain ontology, visualized through the Domain manager [8] while the Guideline pane gives a detailed description of the guideline (in terms of flowchart or specific user interface) to enable the guideline author create a new guideline or change the already defined guidelines, which is supported by the design-time interpreter. 3.3.2 Authoring Guidelines in KA-Tool Much of the current research on knowledge acquisition from domain experts is focused on the primitives and PSMs. The approach of guideline authoring with primitives is understand and can address very specific tasks flexibly in certain field, but it is difficult to reuse because usually domain and procedural knowledge are combining together. Therefore, guideline authors need to pay attention to design the specific guideline control structure and develop each guideline individually following its individual control structure. Obviously, authoring guidelines only in terms of primitives inevitably will lead to create a number of domain-specific primitive and drop the reusability to the minimum. In the contrary, PSMs represent generic strategies to solve stereotypical tasks through separating the domain specific ontology and domain independent ontology. PSMs improve the model reusability and shareability significantly, because PSMs are domain-independent and can be used in different application domains by mapping onto different domain ontology. However, PSMs are too abstract and cannot fit daily practice easily, which require domain expert to fully understand the application domain knowledge and guidelines. Gaston also supports subguidelines to enable the nesting of guidelines, which enable multiple levels of abstraction in guideline representation and provides different granularities for the views to a guideline [11]. Subguildeline may be a set of primitives or a PSM. In order to satisfy both the reusability and specificity, Gaston develops guidelines combining the approaches of primitives and PSMs. Three basic types of guidelines are used: 1) relatively simple rule-based guidelines, 2) multiple-step guidelines that consist of primitives and subguideline (flowcharts) and 3) guidelines that use Problem-Solving Methods (PSMs), generic strategies to solve domain-independent stereotypical tasks. [10] Therefore, guideline authors can develop comprehensive and complex guidelines that consist all of those three types of guidelines. 3.3.3 Authoring guidelines in terms of simple rule-based guidelines Simple rule-based guideline usually consists less steps and bases decision as “IF Then ”, and most simple rule-based guidelines only generate messages that are sent to the healthcare provider. [13] Authoring guidelines based on simple rule can be developed either by primitives or PSMs. 3.3.4 Authoring guidelines in terms of primitives and subguideline Guidelines that are more complex or domain-specific usually require a more low-level representation (e.g. a set of primitives) as these guidelines are usually to specific to be captured by PSMs.[10] The control structure of guidelines that consist of primitives or subguidelines is represented as flowchart. Each primitive and subguideline is created as a separated step in the flowchart, and the guideline author not only need to define each component (in terms of primitives
11
and subguideline) in the flowchart, but also need to explicitly specify the control structure of a guideline. The knowledge acquisition process can be broken down as two-step process: The first phase consists of describing the guideline’s structure in terms of primitives and subguideline in a flowchart. [8] In this phase, all primitives and subguidelines are first treated as black boxes without description and domain-specific concept and are visualized by the visualization information carried by the components themselves. Because the visualization information is already defined and carried by primitives themselves, the first phase is executed automatically. The second phase consists of specifying domain ontology and defining criteria of the specified ontology that is required by the various primitives. In this stage, guideline author can specify the criteria of the domain-specific concept through a user interface visualized from the visualization and criteria attributes of this domain-specific concept itself. In addition, criteria attribute contains relations operators such as ‘more than’, ‘less than’, ‘equals’ and so on. For example, if the author wants to adding a new primitive to the guideline, the Method Manager activates a primitive-specific ‘wizard’ to lead the author enter the description, refine the primitive’s intermediate roles by mapping onto domain-specific ontology, and finally input the criteria of domain-specific ontology. Adding a defined subguideline in terms of a set of primitives or a PSM into guideline is almost the same process as drag-and-drop method from the Method Ontology pane to the Guideline Pane. The author can go into the subguideline level by clicking on the component of subguideline and work in the same way as in a guideline (Authoring guideline in terms of PSMs will be introduced 3.3.5). Subguidelines facilitate the nesting views of guideline and provide an easy method to reuse defined guideline in a specific application. Usually complex guidelines include various scenarios, temporal and branching logic. [10] In order to represent these complex guidelines, the method ontology has been extended with new primitives, inspired by the recent EON protocol model [14]. This model defines guidelines by means of a number of concepts, such as scenarios, decisions, actions and activities. [10] In Gaston, there is a section of the method ontology extended with primitives presenting these concepts, and KA-tool presents those guidelines in terms of primitives and subguidelines again, by flowchart. 3.3.5 Authoring guidelines in term of PSMs In contrast to defining the control structure of a guideline in terms of primitives and subguidelines (3.3.4) by means of flowchart, the control structure of a guideline that is executed by means of a PSM is not explicitly described by a guideline author as this structure is already defined in the PSM internally. [8] Instead, an acquisition ‘wizard’ guides user to start the knowledge acquisition process through dialogs, based on the control structure and visualization of a certain PSM instance defined in Method Library. The guideline author is able to create an applicationspecific PSM by filling in specific values and mapping onto domain-specific ontology for the Refiner and Mapping attributes through this ‘wizard’ user interface. Internally, these strategies again consist of control structure concepts from the method ontology, but the control structure is hidden from the authors by a proper user interface. For specific tasks that can be used in various domains, PSMs approach can improve the efficiency, reusability and shareability of guideline authoring significantly. However, PSMs also has some limitations of PSMs approach in guideline acquisition phase. Mapping terms from one (domain or method) ontology to another is not very straightforward. [8] Problem arises if mapping are not one-to-one or, even worse, when there exist semantic differences
12
between the various ontologies. [15] PSM is lack of the flexibility to change the control structure in the stage of guideline acquisition. Guideline authors can easily change the control structure of a guideline consisting primitives and subguidelines in the flowchart provided by the KA-Tool, simply by adding or removing a component based on requirements. However, changing control structure of PSM is impossible in guideline acquisition and can only be changed in Method Library stage. Changing PSM not only needs to change a tool (from KA-Tool to Protégé) to develop, but also needs the KA-Tool to reload the updated Method Library. PSMs are difficult to be abstract from various domain-specific guidelines, and sometimes those already defined PSMs are too abstract and don’t fit daily practice easily, it may be difficult to develop guideline efficiently for the domain expert who are not familiar with the program.
3.4
Executing guidelines
As showed in Figure 1, domain experts use the KA-tool to retrieve the control structure of each guideline and PSM from the method library, which then are mapped to domain ontology. As a result, a symbol level clinical guideline is produced automatically by the design-time interpreter and made ready for execution. The execution-time representation is different from the ontological representation in its incapacity of being understood by guideline authors, but being able to meet the execution-time requirements such as compactness and execution speed. 3.4.1 Structure of the GASTON execution engine
Fig. 8. System overview of the components in the decision support system
The execution engine of GASTON consists a collection of modular components with an execution-time scheduler and a number of plug-ins as its kernel. The execution-time scheduler communicates with all the plug-ins with a standard interface without differentiating the different functionality of each plug-in. In Fig. 8, four typical plug-ins of GASTON are shown to be built on the Execution-time Scheduler through a common interface. The Procedure Manager plug-in communicates between the compiled structure and Execution-time Scheduler and informs the Execution-time Scheduler which guidelines are to be executed and in what order. Datasource Manager uses standard communication protocols to exchange clinical data with outside sources such as electronic patient record (EPR) and patient monitoring system. This Datasource Manager plug-in enables two-way communication with outside data sources through both acquisition and storage of clinical data. The Event Manager defines the specification of event that triggers the execution of guidelines. The trigger event may originate from outside EPR system (e.g. prescription of a new drug), patient monitoring system (e.g. abnormal ECG) or request for guidelines by user through manual entry. The Action Manager plug-in provides the interface for
13
communications between the user and the decision support system. It defines the means how the decision support is delivered to the user (e.g. alerts, reminders, or even an interactive dialogue). The plug-ins of GASTON execution engine are not mutually exclusive and yet they are functionally independent. The clinical data from EPR not only provide the trigger events for Event Manager to initiate the guideline execution but also provide the data for Datasource Manager to justify the execution of guidelines. And this justification process can be displayed by the Action Manager through interaction with the user. However, the plug-ins were developed independently in the functionality to enable their reusability. For example, if an old EPR system is replaced by a new one, only the Datasource Manager needs to be replaced while the other plug-ins are not affected. A new plug-in can be easily added to augment new functionality without changing other parts of the execution kernel. 3.4.2 Applications of GASTON GASTON has been used as a framework to develop clinical guidelines as a support to physicians in several domains. Valuable experiences have been collected in the process of implementation of computer interpretable guidelines [9]. CritICIS This is a decision support system for ICU of the Catharina Hospital, Eindhoven, Netherlands. The system had undergone a verification process, in which the guidelines were tested on a large number of existing patient records, before it was fully operational in the ICU. The CritICIS system provides a good example of guideline verification and testing [5]. GRIF This system was designed to help family physicians with their test ordering. The reminders generated by the system were compared with the assessments of human experts. Only 7% of the reminders were given incorrect. The amount and the level of detail of the patient information are crucial for the system to make a correct judgment [16]. M-PADS This is a decision support system designed to help physicians with prescription of psychoactive drug for psychiatric patients. It involved guidelines and PSMs to solve various tasks in a complicated clinical situation [17].
4.
FUTURE DEVELOPMENTS OF GASTON
As mentioned earlier, GASTON is a generic framework for guideline development, which encompasses the whole process of clinical guideline development as representation, authoring and execution. Still the model needs further improvements in the following areas. 4.1
Integration into institutional information system
Decision support systems not only provide advice according to best evidence in practice, but also should be able to integrate themselves into the clinical information system implemented in the local institution. In order for the clinical guidelines to be sharable, the effort to integrate the decision support system into the institutional systems should be minimized. However, inadequate standard implementation currently hampers this integration. One of the focuses is on the interfacing between decision support systems and EMRs. The mapping problem is very challenging if the ontology used for guideline representation doesn’t match with the medical vocabularies used in the EMR system. Three approaches have been implemented to solve this problem [18]. One approach, exemplified in the MLMs of Arden Syntax, is to separate the system-dependent data references from the medical knowledge. The second approach is the application of virtual EMR from which the mapping is performed to actual EMR. This approach allows sharing to occur at a higher level as the mappings between the guidelines and the virtual EMR are performed only once for each system. The third approach involves the effort of HL7 to promote the reference information model (RIM) as a shared information model for both EMR and decision support system.
14
4.2
Local adaptation of guidelines
Guidelines developed at national levels often need to be modified to suit for the local use in different clinical settings. Reasons for local adaptation include different type of institution, different availability of medical devices and medications, and different patient population. The representation format of the guidelines should be able to track and document the modifications to maintain the integrity of the setting independent guidelines during the process of local adaptation. It is particularly pertinent when new version of guidelines is disseminated to local institutions. If the generic guidelines are separated from local modifications, it can be updated and function immediately without repeating the adaptation process whenever the guidelines are updated [19]. 4.3
Representation of temporal constraints
So far Asbru [20] proposed the most explicit and extensive treatment of temporal constraints among all similar approaches. It takes into consideration the distinction between concurrent actions, sequential actions and repeated actions. LaTeR system in GLARE also proves to be a powerful temporal manager [7]. 4.4
Other
Besides the areas mentioned above, the high level description of PSM and guidelines are still informal in GASTON. There is no automatic mapping from a task description to the control structure of the PSM. Investigations are being made to integrate a formal PSM language into GASTON to make such mapping explicit. Also, GASTON is weak at processing uncertainty that is sometimes required by guidelines.
REFERENCES [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11]
[12] [13] [14]
Cabana MD, Rand CS, Powe NR, Wu AW, Wilson MH, Abboud PC, Rubin HR. Why don’t physicians follow clinical practice guidelines? A framework for improvement. JAMA, 1999, 282: 1458-1465. De clercq PA, Blom JA, Korsten HHM, Hasman A. Approaches for creating computer-interpretable guidelines that facilitate decision support. Artif Intell Med, 2004, 31: 1-27 Johnston ME, Langton KB, Haynes RB, Mathieu A. Effects of computer-based clinical decision support systems on clinician performance and patient outcome. Ann Intern Med, 1994, 120: 135-142 Gennari JH, Musen MA, Fergerson RW, Grosso WE, Crublezy M, Eriksson H, Noy NF, Tu SW. The evolution of Protege:an environment for knowledge-based systems development. Int J Hum Comput Stud, 2003, 58: 89-123 De Clercq CA, Blom JA, Hasman A, Korsten HHM. A strategy for development of practice guidelines for the ICU using automated knowledge acquisition techniques. Int J Clin Monit Comput 1999, 15: 109-117 Wang D, Peleg M, Tu SW, Boxwala ZA, Ogunyemi O, Zeng Q, Greenes RA, Patel VL, Shortliffe EH. Design and implementation of the GLIF3 guideline execution engine. J Biomed Inform, 2004, 37: 305-318 Terenziani P, Molina G, Torchio M. A modular approach for representing and executing clinical guidelines. Artif Intell Med, 2001, 23: 249-276 De Clercq PA, Hasman A, Blom JA, Korsten HHM. Design and implementation of a framework to support the development of clinical guidelines. Int J Med Inform, 2001, 64: 285-318 De Clercq PA, Hasman A. Experiences with the Development, Implementation and Evaluation of Automated Decision Support Systems. Medinfo 2004, 1033-1037 De Clercq PA, Hasman A. Johannes A. Bloma, Hendrikus H.M. Korsten. The application of ontologies and problem-solving methods for the development of shareable guidelines. Artif. Intell. Med. (2001) 22: 1-22. Dongwen Wang, Mor Peleg, Samson W. Tu, Aziz A. Boxwala, Robert A. Greenes, Vimla L. Patel, Edward H. Shortliffe. Representation primitives, process models and patient data in computer-interpretable clinical practice guidelines: A literature review of guideline representation models. Int. Journal of Medical Informatics 68 (2002) 59-70 Musen MA. Modern architectures for intelligent systems: reusable ontologies and problem-solving. Methods Proc AMIA Symp 1998: 46-52 Thierry Dart, Yigang Xu, Gilles Chatellier, Patrice Degoulet, Computerization of Guidelines: Towards a “Guideline Markup Language”. MEDINFO 2001 V. Patel et al. (Eds)Amsterdam: IOS Press Tu SW, Musen MA. A flexible approach to guideline modeling. Proc AMIA Symp 1999:420±4
15
[15] [16] [17] [18] [19] [20]
B. Chandrasekaran, T.R. Johnson, J.W. Smith, Task-structure analysis for knowledge modeling, Commun. ACM 35 (9) (1992) 124–137. Bindels R, Hasman A, Winkens RAG, Pop P, Van Wersch JWJ. Validation of a knowledge based reminder systems for diagnostic test ordering in family medicine. Int J Med Inf, 2001, 64: 341-354 van Hyfte DM, de Vries Robbe PF, Tjandra-Maga TB, van der Maas AA, Zitman FG. Towards a more rational use of psychoactive substances in clinical practice. Pharmacopsychiatry. 2001 Jan;34(1):13-18 Boxwala AA, Tu S, Peleg M, Zeng Q Ogunyemi O, Greenes RA, shortliffe EH, Patel VL. Toward a representation format for sharable clinical guidelines. J Biomed Inform, 2001, 34: 157-169 Fridsma DB, Gennari JH, Musen MA. Making generic guidelines site-specific. Proc AMIA Annu Fall Symp, 1996: 597-601 Shahar Y, Musen MA. Knowledge-based temporal abstraction in clinical domains. Artif Intell Med, 1996, 8: 267-298
16
