Design: Current guideline document models are limited in that they reflect the specific orientation of the stakeholder who created them; thus, developers and disseminators often provide few constructs for conceptualizing recommendations, while implementers de-emphasize concepts related to establishing guideline validity. The authors developed the Guideline Elements Model (GEM) using XML to better represent the heterogeneous knowledge contained in practice guidelines. Core constructs were derived from the Institute of Medicine's Guideline Appraisal Instrument, the National Guideline Clearinghouse, and the augmented decision table guideline representation. These were supplemented by additional concepts from a literature review.

Results: The GEM hierarchy includes more than 100 elements. Major concepts relate to a guideline's identity, developer, purpose, intended audience, method of development, target population, knowledge components, testing, and review plan. Knowledge components in guideline documents include recommendations (which in turn comprise conditionals and imperatives), definitions, and algorithms.

Sponsoring organizations most often publish practice guidelines as paper-based, prose documents, which sometimes include algorithmic flowcharts. These publications are typically unavailable during clinical consultations. Zielstorff² noted that while electronic dissemination can “solve the problem of accessibility to the guideline itself... access to knowledge embedded in the guideline can still be problematic.” She called for defining guideline knowledge in “standard interchange formats that permit installation in a wide variety of technical infrastructures.” Guideline querying, electronic distribution, and decision support systems that implement the guideline's recommendations can all be facilitated when the knowledge contained in the guideline is represented in digital form.

The proposed Guideline Elements Model (GEM) is intended to serve as a document model, i.e., an idealized abstraction of a guideline document that masks certain details to bring forth others (after Degoulet and Fieschi³). By describing concepts pertinent to guideline representation, attributes of those concepts, and relationships among the concepts, GEM promotes translation of natural language guideline documents into a format that can be processed by computers. The framework is intended to be useful to developers, disseminators, implementers, maintainers, and end users of guidelines.

XML (the Extensible Markup Language) offers a powerful technology for representing electronic documents. It allows both computers and human beings to access the information in a document and extract it for reuse or modification.⁴ In XML, guideline documents are conceptualized as a hierarchy of elements—basic units of information that store data and define structure by virtue of their position in a tree.⁵ Element tags demarcate text and provide labels that characterize the semantic content of the element. Tagging a document does not require programming skill, yet it can create a computer-processible representation of the knowledge contained in a guideline.

An XML document type definition (DTD) models the names of allowable elements and attributes in the document, the content of each element, and the structure of the document (i.e., the order and cardinality of each element). A validating parser can ensure that any tagged document conforms to the DTD. A parser (such as Internet Explorer 5) can read an XML document file and populate a tree in memory, thereby exposing all the elements and attributes to manipulation by an application.⁶ That application might, for example, select certain components for presentation to the user (e.g., costs) or interact with facts in a clinical database to provide guideline-based decision support.

Several stakeholders combine their efforts to develop, disseminate, implement, and maintain the knowledge contained in guidelines throughout the guideline life cycle. Not surprisingly, therefore, the models that have been created to represent this knowledge vary, depending on the orientation of the stakeholder.

Models devised by those who build and evaluate practice guidelines tend to emphasize descriptions of the methods applied in guideline development, issues of guideline testing and maintenance, and details about the sponsors, objectives, and intended audiences; however, they often provide few details for conceptualizing recommendations. For example, the National Guideline Clearinghouse (NGC) model contains most of the concepts found in the health services literature, yet it provides only a single slot for “Major Recommendations.”⁷

On the other hand, informatics researchers tend to model guideline recommendation components in great detail but often fail to address the concerns of the health services community, such as evidence strength and quality, potential biases of sponsors and developers, and validity checks. For example, although our own augmented decision table model for representing guidelines knowledge recognized the importance of “collateral information,” it fell short in defining a comprehensive set of considerations.⁸

One of the most ambitious efforts to build an electronic guideline representation is the Guidelines Interchange Format (GLIF) of the Intermed Collaboratory. GLIF includes constructs for the name of a guideline and its authors, purpose, and eligibility criteria, but it specifies only a vaguely defined component called didactics to “provide background or supporting information.”⁹ The emphasis in GLIF is on detailed specification of guideline recommendations.

Since different stakeholders who work with a single guideline have different information needs and require different computer applications to support those needs, an ideal electronic model of a guideline should be capable of representing all pertinent aspects of the document. In this work we attempt to bridge the deficiencies in existing designs by proposing a guideline model that includes a more comprehensive set of components. It would be naïve to believe that any model could completely meet the needs of all current and future users. We therefore set a goal of creating a “more comprehensive” model that would represent the most important guideline components and be sufficiently flexible to allow future extensions if needed.

In this work, we describe our approach to developing GEM, followed by a presentation of the model itself. We next illustrate how a variety of guideline models from both the health services and informatics literature map to GEM, and we briefly describe our experience modeling a variety of published guidelines with GEM. We conclude with a discussion of attributes of an ideal guideline document model.

Second, for concepts related to guideline dissemination, the NGC provides an online resource for evidence-based guidelines.⁷ Sponsored by the U.S. Agency for Healthcare Research and Quality (formerly the Agency for Health Care Policy and Research), the American Medical Association, and the American Association of Health Plans, it provides a schema for classification of the components of guideline documents. This model includes a set of “key attributes” for summarizing each guideline to facilitate search and retrieval of information from the NGC Web site and comparison between guidelines. The NGC also offers several sets of controlled vocabulary constructs to describe concepts in the model.

Third, for concepts related to implementation of guideline recommendations, we apply a set of constructs derived originally from the augmented decision table model.⁸ This approach has been used to represent knowledge derived from:

The original model has been substantially enhanced and extended. GEM represents a key infrastructure component for a proposed object-oriented framework for development of computer-based guideline implementations.¹⁵

Constructs extracted from these sources were supplemented by additional concepts derived from published models. We searched the MEDLINE database (1990 to 1999) using the OVID search engine. The search strategy looked for “practice guidelines” as a subject heading and “guideline” as a text word. The results were combined with “knowledge representation” or “model” or “evaluation.”

In another search we looked for papers that had been published in the Journal of the American Medical Informatics Association, Methods of Information in Medicine, or the proceedings of AMIA annual meetings that addressed guidelines. The bibliographies of selected articles were also searched for relevant publications, as were the authors' reference files. Articles were selected that modeled and categorized the content of clinical practice guideline documents. Papers that failed to specify detailed modeling constructs and designs that described models of guideline implementations without describing document models were excluded.

Components of GEM are defined as XML elements. Elements have distinct names and are delimited with start and end tags, e.g.,

Elements may contain other elements, they may store text, or they may be empty. Elements may appear as often as required. Most elements store information that is presented literally in the guideline text itself, e.g., release date, name of sponsoring organization, and recommendation text. A small number of metalevel tags provide information about the guideline, which has been interpreted, e.g., developer.type. To indicate whether an element's content is explicitly stated in the guideline document or was inferred by the person who performed the markup, each element has an attribute called “source.” The source attribute can take values of “explicit,” “inferred,” or in some cases “NGC” (to indicate that the NGC structured vocabulary is used).

GEM has been proposed as an ASTM E31.25 standard representation for guideline documents. Following ASTM and HL7 conventions, element names in GEM are formatted in lower case and words are separated by periods. In this report, italics indicate specific elements (e.g., title, decision.variable). The complete GEM hierarchy, definitions for all elements, a GEM template, the document type definition, and the schema can be viewed at http://ycmi.med.yale.edu/GEM. In the next sections, we describe the major elements of the GEM hierarchy.

We attempted to map GEM elements to constructs described in these published models. Each publication was reviewed by at least two authors to establish whether a particular concept was described in the publication. Conflicts were resolved by discussion among the authors. In general, we tended to be liberal in these mappings, because we recognized that the published specifications of models might be incomplete.

To represent “health services” models, we selected the Institute of Medicine's Appraisal Instrument,¹⁰ the NGC model,⁷ a proposal for structured abstracts of scientific papers that describe clinical practice guidelines,²² and a recent evaluation of guideline quality.²³ Informatics models of guideline documents include the Arden Syntax, an international standard for encoding logic in decision support systems²⁴; GLIF, a knowledge representation intended to facilitate guideline sharing⁹; a relational model that captures both structured guideline content and procedural logic²⁵; PRESTIGE, a generic approach to representation of guideline knowledge in the European Community²⁶; a Web-based guideline dissemination system available nationally on the Kaiser Permanente intranet^27,28; and a model based on augmented decision tables.⁸

In , we show the high-level concepts from GEM that are represented in these selected models. In general, health services models were more explicit with regard to developer, purpose, intended audience, and method of development concepts than were informatics models, as indicated by the density of the gray bars in those segments. On the other hand, although every model had a construct for “recommendation,” the informatics models tended to atomize knowledge components into more detailed constructs than did the health services models. The display is somewhat deceptive, because each element is given equal visual weighting. Nonetheless, it is clear that many informatics models lack constructs for encoding knowledge about guideline development methodology and validity assessment. Likewise, the health services models under-specify features that facilitate implementation of recommendations.

As might be expected, there was substantial variation in the use of GEM elements from guideline to guideline. No two guidelines—whether produced by the same organization on different topics or produced by different organizations and covering the same health condition—are constructed identically. We noted that a number of tags were not used to model any of the documents.

An ideal guideline knowledge model should be:

GEM markup can be used as a first step in translating paper-based, narrative guidelines into formats that can be processed electronically. Developers can use a GEM-encoded document as a set of empty slots to be filled to create a high-quality guideline; e.g., a fully tagged document could facilitate decision table verification of guideline logic,³² or an XSL-formatted template can help automate the extraction of components that indicate methodological quality.²³ Disseminators can use XML's Web capabilities to publish guidelines. Implementers can use the tagged data for assistance in encoding recommendations, understanding terminology, and even direct execution. For example, a conditional recommendation's decision variables could be automatically extracted from a GEM document and used to label a data collection control, while the potential values are used to name radio buttons. End users can select various aspects of interest from GEM-encoded documents (e.g., the quality of evidence that supports individual recommendations, the costs of interventions) or compare guidelines on the same topic from different sources.

Use of XML for representation of GEM offers a number of advantages.³³ The self-descriptive capability of XML improves searching for, indexing, and locating information. Moreover, the open XML standard facilitates development of tools for document processing. XML is an intrinsic part of the Web, with presentation and parsing capabilities built into Web browsers. Software to process XML documents is expected to become ubiquitous and inexpensive. Over their lifetime, documents represented in XML can be used and reused in a multitude of ways, including (most likely) some that have not yet been invented.

GEM has several limitations. The model is simply an abstraction of the guideline document and, as such, must rely on extrinsic systems to apply it in ways that are useful. GEM does little to resolve the ambiguities that are present in many guidelines. It can, however, faithfully present them to a user for resolution. Use of a system that forces developers to define recommendations as if-then-else statements might help avoid introduction of ambiguous statements.³⁴ Although GEM extends the work of multiple researchers, this model is probably not comprehensive. Additional elements, attributes, and relationships may be necessary to adequately encode guidelines, depending on the needs of stakeholders. The XML representation can be updated easily to accommodate these needs. Since the model currently incorporates more than 100 elements, effective markup with GEM will require training and practice to achieve optimal results.

Next steps in our work with GEM will involve refining the model and building and evaluating tools that facilitate activities throughout the guideline life cycle. We are working to create parsing and editing tools, specifically designed for guideline markup, that will promote consistent encoding. We envision Web-based tools for guideline developers that will allow them to collaborate effectively without face-to-face meetings—a major source of guideline development expense. Another goal of this project is to create clinical decision support tools automatedly from guideline documents stored in GEM format. Boxwala et al.³⁵ have described an architecture for a guideline execution engine using ActiveX, which operates from guidelines encoded in GLIF. We plan to apply ASP (active server pages) technology to dynamically configure intranet Web pages from XML documents.