MEDINFO 2001 V. Patel et al. (Eds) Amsterdam: IOS Press © 2001 IMIA. All rights reserved
An Approach to Guideline Implementation with GEM Richard N. Shiffman, Abha Agrawal, Aniruddha M. Deshpande, Peter Gershkovich Yale Center for Medical Informatics, New Haven, CT, USA
Abstract
The Guideline Elements Model (GEM) is an XML-based guideline document model that can store and organize the heterogeneous information contained in clinical practice guidelines [6]. It has been used effectively to facilitate evaluation of the quality of guideline documents, by organizing relevant text components for analysis with published guideline appraisal instruments [7]. In this paper, we describe guideline implementation based on GEM markup that makes direct use of the guideline document as a knowledge base. The process requires 3 tasks: (1) knowledge extraction from the guideline, (2) knowledge customization for the local enterprise, and (3) knowledge integration into clinical workflow. Several issues germane to each task are presented.
Implementation of practice guidelines refers to the creation of strategies and systems to operationalize the knowledge and recommendations set forth by guideline developers. We describe an approach to guideline implementation that makes direct use of the guideline document as a knowledge base. The Guideline Elements Model (GEM) provides an XML-based guideline document model that facilitates implementation of guidelines. Knowledge extraction using GEM requires document markup rather than programming and can promote authenticity and consistent knowledge encoding. Knowledge customization for the local enterprise requires addition of meta-information to pertinent components of the GEM hierarchy in a design database. GEM provides an audit trail to track local adaptation. Knowledge integration with patient data can be promoted using information management services. A design goal is to devise a system that can be applied by local clinical domain experts, quality assurance experts, and information systems programmers without requiring trained informaticians and knowledge engineers to serve as intermediaries
GEM GEM is intended to facilitate translation of natural language guideline documents into a format that can be processed by computers. The GEM Document Type Definition (DTD) has been proposed as a standard by the ASTM Committee E31.25. This DTD models the names of allowable elements and their attributes, the content of each element, and the structure of the document (i.e., the order and cardinality of each element).
Keywords: practice guideline, XML, implementation, knowledge acquisition, local adaptation
GEM was designed to be: •
Comprehensive, i.e., capable of expressing all pertinent information that is contained in guidelines,
•
Semantically sufficient, i.e., able to convey the nuances of clinical medicine while remaining informationally equivalent to the original guideline
•
Flexible, i.e., able to model constructs at high and low levels of granularity and to accommodate missing semantic constructs
•
Comprehensible stakeholders
Background Implementation of practice guidelines refers to the creation of strategies and systems to operationalize the knowledge and recommendations set forth by guideline developers. Several studies have shown that simply creating and disseminating guidelines does not result necessarily in behavior changes on the part of practitioners or changes in health outcomes for their patients [1, 2]. Among the most effective strategies for changing the process and outcomes of care are those that make use of computer-mediated decision support [3-5].
271
to
a
variety
of
guideline
Chapter 4: Knowledge Representation
Prose Guideline Document
Wizard DOM
Gem Cutter GEM Document Design Database Knowledge Customization
Knowledge Extraction
EMR
Info Mgmt Svcs
Knowledge Integration
Figure 1. Relationships among knowledge extraction, customization, and integration tasks
•
Sharable across institutions, and
•
Reusable across all phases of the guideline lifecycle.
In the proposed framework, the substrate for implementation is the published guideline document. In the knowledge extraction phase, information and knowledge that are pertinent to implementation are identified in the document and classified as components of the Guideline Elements Model. Many of these elements relate to the guideline’s recommendations, however, information stored elsewhere in the model may also be vital to implementation. For example, inclusion and exclusion criteria from the Target Population subtree, rating schemes for evidence quality from the Methods of Development tree, and rationale and objective from the Purpose subtree are all critical for the implementation process.
The model is defined as a multi-level hierarchy with more than 100 discrete elements in 9 major branches. GEM represents the union of components from a wide range of existing guideline representations—from health services and informatics researchers. As such, it is appropriate for use during guideline development, dissemination, implementation, and maintenance. The major branches of the GEM hierarchy include Identity and Developer (header elements), and Purpose, Intended Audience, Method of Development, Target Population, Testing, Revision Plan, and Knowledge Components (body elements). Knowledge components store and categorize the expert knowledge that constitutes the essence of practice guidelines, the advice propounded by the guideline development team. The GEM hierarchy of knowledge components was derived largely from previous work with augmented decision tables [8].
Iterative refinement adds inferred elements (i.e., data not derived verbatim from the guideline text, but inferred from careful examination of the guideline) and refines knowledge components into atomic elements. In particular, recommendation statements are analyzed into component decision variables, values, and actions. The product is an XML file that contains GEM-encoded knowledge from the practice guideline and meta-knowledge about guideline elements.
Knowledge Extraction Using XML, knowledge extraction can be construed as a markup of the guideline document—rather than as an encoding of the knowledge in a programming language. XML markup results in an intermediate, electronically processable document that preserves the intent of developers, while remaining human-readable. We believe that markup is inherently simpler to perform than programming. Our goal is to devise a system that will allow markup to be performed by trained domain experts who are not skilled programmers. This task might be performed centrally by members of a guideline development committee at the time a guideline is published or locally by domain experts when a guideline is selected for implementation.
This GEM file is parsed into memory, creating an XML Document Object Model (DOM), which, in turn, can be operated upon by XML's native methods. These methods are next applied to query the DOM tree, to extract pertinent elements, and to insert them into appropriate fields in a design database. The outcome of this step is a partially populated design database. Maintaining Authenticity The GEM file is intended to represent guideline knowledge content authentically. Rector et al. described the fundamental necessity for an “authentic” recording of clinician’s observations for recording of clinical observations in an electronic medical record [9].
272
Chapter 4: Knowledge Representation
elements are intended to store the actual text of the guideline’s advice in a sentential structure.
Authenticity requires allowance for conflicting statements, acceptance of uncertain and negative statements, expression at the clinicians’ natural level of abstraction, and allowance of descriptions at arbitrary level of detail. We believe that such authenticity must also pertain in translation of guideline developers’ intent.
In the next level of analysis, individual decision variables (and values), actions, and directives are extracted. Each of these elements is assigned a unique identifier stored as an id attribute. The element contains logical operators that describe the combinations of decision variables, actions, and directives that are dictated by the advice.
Promoting Consistent Markup Past work in translation of guideline knowledge into executable systems has demonstrated considerable variation in the process of translating prose guidelines into executable decision support tools [10-12]. Work is ongoing to define training that will minimize this inconsistency. We have created a GEM-specific XML editor (GEM Cutter) that is intended to diminish differences in markup (available at http://ycmi.med.yale.edu/GEM).
Elements residing at various levels in the GEM hierarchy participate in a variety of types of relationships. In general, XML allows for description of elements in 2 ways: through an "attribute" at the same level as the element in question (which we have reserved for computer-readable items like identifiers) and as nested elements at the next lower level. Decision variables and actions are subelements of conditionals and directives are subelements of imperatives; their relationship to their parent nodes may be described using the traditional "part-of". Reason, recommendation strength and logic also modify conditional and imperative statements; they have been situated as child elements with a relationship that might be termed "describer-of".
A major issue in consistency relates to the atomization of concepts. The GEM hierarchy calls for atomic constructs at the level of the decision variable, action, and directive. Particularly when several words are required to define a single construct, disagreement may arise as to the minimal number of words sufficient to define the construct.
Knowledge Customization
The recommendation tree in GEM was designed to provide several layers of abstraction. Examination of published guidelines indicates that recommendations are stated in two different formats that require different considerations for implementation. Conditional recommendations define activities that are applicable only under specific circumstances; they can usually be understood as IF…THEN statements. On the other hand, imperative recommendations are broadly applicable to the target population. Individual characteristics of the population or the situation do not define their applicability; imperatives simply state that an activity should or must be performed. In effect, an imperative can be seen as a recommendation conditional on meeting the broad criteria for eligibility.
Adding Meta-information Creating operational decision support systems requires addition of considerable meta-information to the knowledge extracted directly from the guideline. We collect this metainformation using a “knowledge customization wizard". Hales and colleagues have demonstrated the feasibility of this approach with their "guideline entry wizard" that helps convert guidelines into relational format [13]. As these new data are collected, they are added to the Design Database, along with data extracted from the DOM. The meta-data added relate specifically to individual elements. For example, each decision variable record includes fields for:
In a conditional, the IF clause defines one or more decision variables that must be satisfied, i.e., the value for the variable must be matched with real world data, for the THEN clause—the recommended action—to trigger. In an imperative, the recommended action is termed a directive to avoid confusion. Often, additional text is present in a recommendation that describes: •
• Identifiers (unique identifier, GEM id attribute, and controlled vocabulary term, e.g., UMLS concept identifier or SNOMED, LOINC, CPT, ICD-9, or other applicable code) • Clinical source (a specification of the portion of the patient encounter during which this data will be collected, e.g., during history taking, performance of the physical examination, review of laboratory results, assessment phase, or recording of plans and orders)
the reason for the conditional recommendation
• the quality recommendation
of
evidence
that
supports
the
• the strength of the recommendation as seen by the guideline developer
• Control type (type of control to input this information, e.g., checkbox, radio button, listbox)
• additional information about test quality, costs, risks and benefits, flexibility, references, etc.
• Prompt (a phrase that may be presented to the end-user to elicit the necessary information).
The element stores a brief title or identifier for a single recommendation or a set of related advice statements. Each can contain 0, 1 or more elements and 0, 1, or more elements. Conditional and imperative
• Other data will be defined that are necessary for completion of the implementation design task. Likewise, operationalization of guidelines requires addition of meta-information pertinent to actions and directives.
273
Chapter 4: Knowledge Representation
The HL7 Unified SAM (USAM) views actions as verbs that unite nominal phrases about actors, targets, and beneficiaries. They further specify descriptors of actions that must be considered in the operationalization process— the kind of action (what happens), location (where), time (when), manner (how) and reasons or motives (why) [14]. Each of these attributes is added to fields in the design database.
Knowledge Integration The third major task in guideline implementation integrates the extracted and customized guideline knowledge with patient-specific information to provide tailored clinical recommendations. Operationalizing this task is expected to be quite site-specific. Ideally, an electronic medical record will permit direct delivery of computer-mediated decision support to clinician users.
Local Adaptation
In the creation of knowledge integration tools, we apply the information management services model as a framework for the design of decision support systems that are closely integrated into clinical workflow [19]. System designers can apply a checklist of information management services to maximize the benefits derived from the system Many GEM elements are intrinsically related to providing specific services [20]. For example, contents of the reason, evidence quality, and recommendation strength elements relate to providing explanation services and target population elements relate to registration services.
Guidelines developed centrally by large organizations can take advantage of the resources available to those organizations to identify, review, and extract evidence and to disseminate the results. However, centrally produced guidelines may be impractical for implementation at a local level. Local adaptation is the term applied to the process by which national recommendations are translated into systems that operate at a local level. Local adapters may deliberately or inadvertently transmute guideline knowledge so that it no longer reflects the original intent of the guideline developers. Implementation of guidelines must account for legitimate variation in clinical settings, populations served and resources available [15, 16]. The Institute of Medicine report recognized that even "well developed guidelines are unlikely to foresee or accommodate all the varying characteristics and objectives of potential users” [17]. However, the IOM panel cautioned about local adaptation that is performed to protect professional habits or economic self-interest by endorsing unnecessary care.
Conclusions Text guidelines marked up as Guideline Elements Model documents can serve as portable knowledge repositories for guideline-based decision support systems. Additional metainformation can be added to customize the guideline knowledge to meet the needs of a particular institution. Ultimately, the system can be integrated with patient data and clinical workflow to create efficient systems.
Customization of guideline knowledge to operate in local circumstances is a separate step (discussed below). Other guideline knowledge representations move knowledge from the guideline text directly to an executable programming language without this intermediate step. The GEM representation permits a careful tracking of the transition and allows auditing of changes. The source attribute of each element indicates whether text is extracted verbatim (explicit) or is inferred by the guideline encoder.
We have created prototype systems to perform knowledge extraction, customization, and integration. Current work focuses on refining and evaluating these components into a Web-based, guideline implementation framework.
Acknowledgments This work was supported in part by the National Library of Medicine through grants 1-R29-LM 05552-01A1 and T-15LM07056 and by the National Institute of Standards and Advanced Technology through grant 70 NANB 7H3035. Dr. Shiffman is a Robert Wood Johnson Foundation Generalist Physician Faculty Scholar.
Handling Abstract Constructs A critical issue in guideline knowledge customization focuses on how abstract concepts will be addressed. Many guidelines include decision variables described at an abstract level, which must be concretized at the time of implementation. For example, the American Academy of Pediatrics guideline on urinary tract infection includes a decision variable "sufficiently ill to warrant immediate antimicrobial therapy" [18]. The implementation system designer must decide whether to include this complex construct as is—perhaps as a “yes/no” response to the question “Is the child sufficiently ill to warrant immediate antimicrobial therapy?”— or to collect related information such as presence of fever, level of interaction, playfulness, level of discomfort, etc. Use of the abstract construct may be suitable for implementations involving sophisticated end-users (e.g., experienced pediatricians) but would be inappropriate for use by medical students and junior-level physicians-in-training.
References 1. Kosecoff J, Kanouse D, Rogers W, McCloskey L, Winslow C, Brook R. Effects of the National Institutes of Health Consensus Development Program on physician practice. JAMA 1987;258:2708–13. 2. Lomas J, Anderson GM, Domnick-Pierre K, Vayda E, Enkin MW, Hannah WJ. Do practice guidelines guide practice? the effect of a consensus statement on the practice of physicians. N Engl J Med 1989;321:1306-11.
274
Chapter 4: Knowledge Representation
3. Grimshaw JM, Russell IT. Effect of clinical guidelines on medical practice: a systematic review of rigorous evaluations. Lancet 1993;342:1317–22.
American Medical Informatics Association. Nashville, TN: , 1997: 163-7. 14. Russler DC, Schadow G, Mead C, Snyder T, Quade L, McDonald CJ. Influences of the unified service action model on the HL7 reference information model. In: Lorenzi NM, ed. American Medical informatics Association. Washington, DC: Hanley and Belfus, 1999: 930-4.
4. Davis DA, Taylor-Vaisey A. Translating guidelines into practice: a systematic review of theoretic concepts, practical experience and research evidence in the adoption of clinical practice guidelines. Can Med Assoc J 1997;157:408-16. 5. Hunt DL, Haynes RB, Hanna SE, Smith K. Effects of computer-based clinical decision support systems on physician performance and patient outcomes: a systematic review. JAMA 1998;280:1339-46.
15. Owens DK. Use of medical informatics to implement and develop clinical practice guidelines. West J Med 1998;168:16675. 16. Woolf SH, Grol R, Hutchinson A, Eccles M, Grimshaw J. Clinical guidelines: potential benefits, limitations, and harms of clinical guidelines. BMJ 1999;318:527-30.
6. Shiffman RN, Karras BT, Agrawal A, Chen R, Marenco L, Nath S. GEM: a proposal for a more comprehensive guideline document model using XML. J Am Med Informatics Assoc 2000;7:488-98.
17. Institute of Medicine, ed. Guidelines for clinical practice: from development to use. Washington, DC: National Academy Press, 1992:(Field MJ, Lohr KN, ed.
7. Agrawal A, Karras BT, Shiffman RN. Automated support for evaluation of guideline quality (abstract). Annual Meeting of the Society for Medical Decision Making. Cincinnati, Ohio: , 2000: .
18. Anonymous. Practice parameter: the diagnosis, treatment, and evaluation of the initial urinary tract infection in febrile infants and young children. American Academy of Pediatrics. Committee on Quality Improvement. Subcommittee on Urinary Tract Infection. Pediatrics 1999;103(4 Pt 1):843-52.
8. Shiffman RN. Representation of clinical practice guidelines in conventional and augmented decision tables. J Am Med Inform Assoc 1997;4(5):382-93. 9. Rector AL, Nowlan WA, Kay S, et al. Foundations for an electronic medical record. Methods of Information in Medicine 1991;30:179-86.
19. Shiffman RN, Liaw Y, Brandt CA, Corb GC. A design model for computer-based guideline implementation based on information management services. J Am Med Informatics Assoc 1999;6:99-103.
10. Ohno-Machado L, Gennari JH, Murphy SN, et al. The guideline interchange format: a model for representing guidelines. J Am Med Informatics Assoc 1998;5:357-72.
20. Agrawal A, Brandt CA, Shiffman RN. Promoting workflow integration with information management services and GEMencoded guidelines. Proceedings of the Annual Meeting of the American Medical Informatics Association 2000;:(in press).
11. Patel VL, Allen VG, Arocha JF, Shortliffe EH. Representing clinical guidelines in GLIF: individual and collaborative expertise. J Am Med Informatics Assoc 1998;5:467-83. 12. Karras BT, Nath SD, Shiffman RN. A preliminary evaluation of guideline content markup using GEM—an XML guideline elements model. Prtoc AMIA Symp 2000;:413-7.
Address for correspondence
[email protected]
13. Hales JW, Gadd CS, Lobach DF. Development and use of a guideline entry wizard to convert text clinical practice guidelines into relational format. In: Masys DR, ed. Annual Meeting of the
275
