GLIF: a representation format for sharable computer-interpretable clinical practice guidelines

The Guideline Interchange Format (GLIF) is a model for representation of sharable computer-interpretable guidelines. The current version of GLIF (GLIF3) is a substantial update and enhancement of the model since the previous version (GLIF2). GLIF3 enables encoding of a guideline at three levels: a conceptual flowchart, a computable specification that can be verified for logical consistency and completeness, and an implementable specification that is intended to be incorporated into particular institutional information systems. The representation has been tested on a wide variety of guidelines that are typical of the range of guidelines in clinical use. It builds upon GLIF2 by adding several constructs that enable interpretation of encoded guidelines in computer-based decision-support systems. GLIF3 leverages standards being developed in Health Level 7 in order to allow integration of guidelines with clinical information systems. The GLIF3 specification consists of an extensible object-oriented model and a structured syntax based on the resource description framework (RDF). Empirical validation of the ability to generate appropriate recommendations using GLIF3 has been tested by executing encoded guidelines against actual patient data. GLIF3 is accordingly ready for broader experimentation and prototype use by organizations that wish to evaluate its ability to capture the logic of clinical guidelines, to implement them in clinical systems, and thereby to provide integrated decision support to assist clinicians.
Brief Description
Clinical practice guidelines are intended to improve the quality and cost effectiveness of patient care by fostering best practices [Woolf SH et al., 1999, Potential benefits, limitations, and harms of clinical guidelines]. Such guidelines seek to reduce demonstrated unexplained practice variations among providers, and a surprisingly high incidence of suboptimal care and medical errors [Kohn LT et al., 1999, To err is human: building a safer health system]. Unfortunately, the promulgation of guidelines has not been optimally effective in changing clinical practice [Weingarten S. et al., 1995, The adoption of preventive care practice guidelines by primary care physicians: do actions match intentions]. One likely reason is the inherent limitation of the prevalent mode of dissemination of guidelines as text documents, with their clinical impact mainly dependent on education of providers. Reliance on educational approaches puts primary emphasis on human memory and thus limits the ability of guidelines to effect changes in clinical practice. Publication of text guidelines on the Internet or a practice's intranet can improve access to guidelines at the point of care [Zielstorff RD. et al., 1998, Online practice guidelines: issues, obstacles, and future prospects]. But even if they are available when needed, they are typically not custom-tailored for a specific patient and they require reading and interpretation during a busy clinical schedule, which limits their usefulness.

Studies have shown that computer-based decisionsupport interventions such as automated reminders and alerts to providers are beneficial and can change clinical practice [Johnston ME et al., 1994, Effects of computer-based clinical decision support systems on clinician performance and patient outcome. A critical appraisal of research]. Computer-based physician order entry (CPOE) is another point of contact where decision support has been shown to be effective [Bates DW et al., 1999, The impact of computerized physician order entry on medication error prevention]. Similarly, decision-support systems have been utilized successfully to deliver patient-specific guideline recommendations at the point of care [Lobach DF et al., 1997, Computerized decision support based on a clinical practice guideline improves compliance with care standards] although such systems have not been used widely and have typically depended on the local development of guidelines with idiosyncratic methods for introducing them into the clinical systems.

As we have noted, for guidelines to be most useful for decision-support, they need to be integrated into the patient care process and to be patient-specific. To achieve this, the clinical recommendations in guidelines must be encoded in a form that enables automated access to stored clinical data and unambiguous execution of their decision logic, i.e., they must support computerbased interpretation. We refer to guideline recommendations that are encoded for interpretation by computer programs as computer-interpretable guidelines (CIGs). Well-developed evidence-based guidelines are expensive to develop. The additional effort required to encode guidelines rigorously in a logically consistent, unambiguous, and complete computer-interpretable format imposes further demands on guideline developers.

Further, even guidelines that are encoded for computer interpretation often cannot be shared across institutions or even across different types of applications within an institution, due in part to differences in formats or languages that are used to represent the guideline knowledge, in data models and terminologies used within the encoded guidelines, and in clinical information systems with which they are integrated. Without sharing of guidelines, each institution, vendor, or research group seeking to implement approved guidelines via decision-support systems must redo the work involved in making them executable. Moreover, we have shown in other work [Peleg M, 2002, Support for guideline development through error classification and constraint checking] that this process of encoding and implementing CIGs is not straightforward, and often discloses differences in interpretation. The problem is compounded because guidelines are rarely static, and must be updated as medical knowledge changes. This means that implementations dependent on them must be also updated.

The Guideline Interchange Format (GLIF) was created by the InterMed collaboratory, a joint project of biomedical informatics groups at Harvard, Columbia, and Stanford universities, to serve as a common representation format for CIGs. Version 2 of GLIF (GLIF2) was an incomplete specification with respect to computer-interpretation and execution of guideline knowledge. Among the major deficiencies that we identified in GLIF2 were:
  1. It did not specify a structured representation for important attributes of guidelines and guideline steps, such as patient data to be acquired, recommended actions, and decision conditions. Values of most attributes were specified simply as text strings. Such guidelines could not be interpreted reliably by the computer.
  2. GLIF2 provided only a limited set of low-level flowcontrol constructs. Important concepts such as those for describing iteration, patient-state, exception conditions, and events were lacking.
  3. Integrating GLIF2 guidelines with heterogeneous clinical systems was difficult, as GLIF2 lacked features for mapping patient data references to entries in the electronic medical record (EMR).
The limitations of the GLIF2 model and the considerations pertinent to creating sharable guidelines are discussed in more detail elsewhere.

GLIF3 is a revision of GLIF that attempts to overcome several of GLIF2's limitations described above. The significant modifications in GLIF3 include
  1. Those providing more structure to the representation:
    • Specification of classes whose instances form values of the attributes of existing GLIF2 and new GLIF3 classes.
    • Addition of object-oriented expression and query languages.
  2. Those improving the flow-control:
    • Revision of classes for describing decisions (the Decision_Step class) and parallel flows (Branch_ Step and Synchronization_Step classes).
    • Addition of a new class for specifying patient states (Patient_State_Step class).
    • Addition of classes for specifying iterations, events, and exceptions.
  3. Those enabling interfacing GLIF guidelines with clinical information systems:
    • Addition of a layered model to facilitate interfacing to patient data and external medical knowledge during guideline execution.
  4. Those adopting open standards:
    • Use of resource description framework (RDF) as the exchange syntax for guidelines.
    • Use of Health Level 7 (HL7) standards and the ability to incorporate standard medical terminologies.
  5. Incorporation of features to manage complexity of large guidelines, which became an important requirement with a larger more complex representation model.

With the addition of these features, it is now possible to encode guideline recommendations in GLIF3, resulting in a specification that can then be interpreted by a computer program. Indeed, an execution engine has been developed for the latter purpose [22]. The encoded guidelines and the engine were validated by testing them against clinical data. Columbia University informatics researchers are working to enhance the decision-support capability of clinical information system at the New York-Presbyterian Hospital by integrating the GLIF3 execution engine with that system.

The GLIF3 model consists of classes, their attributes, and the relationships among the classes, all of which are necessary to model clinical guidelines. We have used Unified Modeling Language (UML) class diagrams [30] to describe the model. Additional constraints on represented concepts are specified in the Object Constraint Language (OCL), a part of the UML standard. A highlevel view of the GLIF1 class diagram is shown in Fig. 1.

Figure 1. A high-level view of the major classes in GLIF. The lines between classes denote relationships: a diamond-shape arrowhead indicates an aggregation or containment relationship, and a triangle shape indicates a generalization relationship.
In GLIF, guidelines are represented as flowcharts of temporally ordered nodes called guideline steps and represented by an abstract class called Guideline_Step. This class has the following subclasses:
  • The Decision_Step class represents decision points in the guideline. A hierarchy of decision classes provides the ability to represent different decision models.
  • The Action_Step class is used for modeling recommended actions or tasks
  • The Branch_Step and Synchronization_Step, working together, are used for modeling multiple concurrent paths through the guideline.
  • Patient_State_Step describes the clinical state that characterizes a patient. A patient state step can function as a label summarizing the clinical state of a patient and as an entry point into the flowchart.
The GLIF specification includes an expression and query language that operates on an object-oriented data model. The query language provides a means to access patient data and to map them to variables used in decision criteria and other expressions. The data model, used for representing patient information, is based on standards being developed in HL7 [Peleg M et al., 2004, The InterMed approach to sharable computer-interpretable guidelines: a review].

We accordingly offer a detailed technical specification on our web site at .

GLIF model includes the following components:
  1. Encoding the Guideline: The first step in encoding a guideline is to create an instance of a Guideline class. The Guideline class is used to model both top-level guidelines and subguidelines (i.e., detailed specification of the steps contained in the top-level guideline).
  2. Building the flowchart: The guideline recommendations are encoded in the form of a flowchart. The flowchart is an instance of the Algorithm class. It contains a collection of steps that are instances of the Guideline_Step class. The flow of the steps in the algorithm is specified by linking explicitly a step to its subsequent step(s) using appropriate attributes in each subclass of Guideline_Step, e.g., the next_step attribute of an Action_Step (Fig. 2). The first_step attribute of the Algorithm class indicates the starting point of the algorithm. However, alternative starting points in the algorithm can be specified using patient state steps, as is described later.

    Figure 2. Algorithm for the treatment of chronic cough showing different types of steps that are connected to each other, forming the flowchart. The step named "Chronic Cough" is the first step of this algorithm..
  3. Specifying actions: Action steps specify work that is to be performed by the decision-support system, the provider, or other external agents. The work is specified as a set of tasks, of type Action_Specification. The action specification hierarchy is divided into two major types of actions:
    • Actions that are carried out by the guideline execution engine (referred to in the GLIF object model as programming-oriented actions), such as invoking a subguideline, performing inferencing (e.g., stage of a tumor from a set of observations), or computing values for data (e.g., age of patient).
    • Clinical actions (referred to as medically oriented actions) that are carried out by a care-provider or an external agent, such as changing a medication for a patient. Medically oriented actions reference GLIF3s medical ontology for representation of clinical concepts such as procedures (as seen in Fig. 3), medications, or referrals. The ontology classes provide parameters for structured description of the medical action (e.g., medication name, dose, and frequency).

    Figure 3. Details of the four-view sinus radiograph Literal_Data_Item that is referenced in an Action_Specification. Concept specifies the unique identifier (Concept_Id) of a term from a controlled medical terminology (UMLS, in this example). Data_Model provides parameters for the task. In this example, the parameters are those of a medical Procedure, and include the procedures code (Service_Cd), the body site at which the procedure will be performed, the method by which the procedure will be performed, and the time at which to perform the procedure and its duration. Values for the latter two attributes are not specified in this example since such temporal constraints are not part of the guideline recommendation.
  4. Specifying decisions: Decision steps are points in the algorithm where a choice has to be made among competing, mutually exclusive alternatives known as decision options. These decisions are specified in the Decision_Step class. A Boolean attribute called automatic_decision distinguishes between decisions that are executed automatically and those that have to be approved by an external agent, such as a physician, other health care provider, or another software program. Each decision step contains multiple decision options (Fig. 4).

    Figure 4. A decision step from the algorithm in Fig. 2. The step has two decision options. The window overlying the decision step window shows the detail of one of the decision options. A decision option has a condition that is used in selecting among various options and a destination that specifies the step to execute if this option is selected. The condition is an instance of a Rule_In_Choice, where a strict-rule-in is specified in a formal expression language.
  5. Describing patient states: A Patient_State_Step is a guideline step that is used for two purposes. One use is to serve as a label that characterizes a patient state that is achieved as a result of the successful execution of previous steps. In this way, a guideline may be viewed as a state transition graph, where transitions among these patient state steps are formed by networks of other guideline steps. The other purpose of a patient state step is to serve as an alternative to the first step as an entry point to the guideline. At the time of invocation of a guideline, patient state steps are evaluated for applicability to the patient. If the patient is confirmed to be in the state specified in the step (i.e., the criterion for the state evaluates to true), the execution is moved to that step.
  6. Other flow-control mechanisms
  7. Modeling patient data and medical knowledge: To provide patient-specific automatic decision-support services during To provide patient-specific automatic decision-support services during clinical encounters, a CIG should be integrated with clinical information systems. Patient data items and medical concepts to which CIGs refer must be mapped to electronic medical record (EMR) entries. We designed a medical ontology that defines the structure of patient data and medical knowledge classes in a way that potentially facilitates such mapping, as explained below.
  8. Expression and query language:
  9. Managing complexity
GLIF3 is intended to facilitate the sharing of computer- interpretable guidelines. Our previous work on GLIF2 focused on defining guideline step classes and flow of control to make these more consistent, as a basis for sharing of guidelines. GLIF3 extends the work of GLIF2 by addressing logical consistency and syntactic and semantic control to enable execution of guidelines.

In addition, GLIF3 provides features that facilitate sharing of CIGs such as a flexible representation that can be used to encode different types of guidelines, an object-oriented data model (CIM) and a query language that allow mapping of decision variables to data in the medical record, and the use of controlled medical terminologies.

We have encoded 12 large, complex, and differing guidelines in GLIF3. One study, drawing on cognitive science approaches, has found that the CIGs developed in GLIF3 contained greater level of representational detail and less ambiguity than those developed in GLIF2 [45]. However, additional studies are needed to assess other aspects of the GLIF representation model such as sufficiency and consistency.

While these CIGs have yet to be implemented in the clinical setting, the execution of GLIF3-encoded guidelines has been evaluated using the GLEE execution engine. We used both simulated clinical data and real clinical data from an electronic medical record in the evaluation. The results demonstrated that GLIF3s semantics could be correctly interpreted by GLEE and that recommendations comparable to a reference system could be produced.

GLIF is designed to provide flexibility in modeling sharable guidelines. The ability to reference different domain ontologies, the use of standards being developed in HL7 to limit platform-dependence, independence from a particular application model (see next paragraph), and an extensible object-oriented architecture are all steps in this direction.

Because flexibility in modeling can lead to variation in encoding, when possible we avoided overlap in the functionality of different GLIF3 constructs, and we sought to assure that a single GLIF3 construct could not be used to model two different guideline situations. For example, the branch step is no longer used to represent decision choices, as as it had been in GLIF2, which inappropriately mixed semantics of concurrency and decision- making.

GLIF does not have a particular application orientation. Its focus is on portraying the medical decisions and actions and their proper flow of control. The form of interaction of the guideline with the user and the environment is a decision of individual implementers on particular platforms, in particular settings, and for particular applications. As a result:
  1. GLIF cannot encompass all of the features identified in the many guideline modeling research and development projects underway, some of which have been designed to facilitate specific kinds of applications. Thus, GLIF is not a true bi-directional interchange format. It cannot represent the full set of features of some models for export of guidelines developed in those modeling frameworks to other environments; similarly, importing a GLIF guideline into another modeling environment may require addition of some missing features that are specific to the GLIF model.
  2. GLIF is expected to evolve over time as a result of a lifecycle process in which the results of successful applications indicate certain guideline modeling features that should be included in sharable guideline specifications, thereby facilitating future development of similar applications. While the essence of the GLIF model as a flowchart of Guideline_Step classes should remain static, much of the evolution is likely to occur by extending or modifying the existing GLIF classes. Another limitation in GLIF3 is that it does not specify fully the implementation layer. Since this layer requires interfacing with heterogeneous clinical information systems, we are working with the HL7 CDSTC, to define the mappings between the guideline data model and the electronic medical record (i.e., the vMR work noted above), and to enable support for execution of guideline recommendations via order-entry systems.
We have developed a suite of software tools to be used for encoding and execution of computer-interpretable guidelines. These tools continue to guide our understanding of the requirements of GLIF for encoding and implementation of guidelines. Earlier versions of software for GLIF2 have been re-architected and implemented for use with GLIF3. A custom guidelineencoding tool has been developed. In addition, the Protege knowledge editing tool [49] can be used for encoding and validating [50] GLIF3 guidelines using the RDF schema mentioned previously. We also implemented our guideline execution engine (GLEE) based upon a flexible, client–server design. Future work depends to a large extent on the progress of HL7 as it addresses the above tasks and other decision- support related interface standards (including evolution of GELLO [Sordo M et al., 2003, GELLO: An objectoriented query and expression language for clinical decision support]), and on the appearance of tools that implement GLIF3 encoding, validation, navigation, eligibility searching and retrieval services, and execution. It also depends strongly on experience with implementation, determination of what kinds of applications are effective, and identification of what additional modeling features or tools would be helpful. A number of tooldevelopment and implementation projects are underway currently by us and by others.
GLIF3 extends the work of GLIF2, aimed at creating a formal means for specifying computer-interpretable guidelines that can be implemented at the point of care. Unlike a number of guideline modeling and implementation projects, the aim of GLIF3 is to facilitate the sharing and implementation of high-quality guidelines that are developed with the goal of widespread A.A. Boxwala et al./Journal of Biomedical Informatics 37 (2004) 147–161 159 dissemination and use in a variety of potential platforms and application settings. Further development of GLIF3 is focused on facilitating the integration of CIGs into a broad spectrum of clinical information systems.
  1. Boxwala AA, Peleg M, Tu S, Ogunyemi O, Zeng QT, Wang D, Patel VL, Greenes RA, Shortliffe EH. "GLIF3: a representation format for sharable computer-interpretable clinical practice guidelines." Journal of biomedical informatics. 2004; 37(3):147-61.

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