Bridging the Guideline Implementation Gap: A Systematic, Document-Centered Approach to Guideline Implementation

Abstract

Objective: A gap exists between the information contained in published clinical practice guidelines and the knowledge and information that are necessary to implement them. This work describes a process to systematize and make explicit the translation of document-based knowledge into workflow-integrated clinical decision support systems.

Design: This approach uses the Guideline Elements Model (GEM) to represent the guideline knowledge. Implementation requires a number of steps to translate the knowledge contained in guideline text into a computable format and to integrate the information into clinical workflow. The steps include: (1) selection of a guideline and specific recommendations for implementation, (2) markup of the guideline text, (3) atomization, (4) deabstraction and (5) disambiguation of recommendation concepts, (6) verification of rule set completeness, (7) addition of explanations, (8) building executable statements, (9) specification of origins of decision variables and insertions of recommended actions, (10) definition of action types and selection of associated beneficial services, (11) choice of interface components, and (12) creation of requirement specification.

Results: The authors illustrate these component processes using examples drawn from recent experience translating recommendations from the National Heart, Lung, and Blood Institute's guideline on management of chronic asthma into a workflow-integrated decision support system that operates within the Logician electronic health record system.

Conclusion: Using the guideline document as a knowledge source promotes authentic translation of domain knowledge and reduces the overall complexity of the implementation task. From this framework, we believe that a better understanding of activities involved in guideline implementation will emerge.

Clinical practice guidelines provide a rich source of up-to-date knowledge about best clinical practices. Guidelines can reduce inappropriate practice variation, speed the translation of research into practice, and support quality and safety initiatives.^1,2 However, guideline knowledge must be implemented before it can be expected to influence clinicians' behavior.³ Implementation is the phase in the guideline lifecycle in which strategies, systems, and tools are created to operationalize the knowledge and recommendations set forth by the guideline developers.⁴ In a computerized environment, implementation involves a number of steps to translate the knowledge contained in guideline text into a computable format and to integrate the information into a clinical workflow.

Unfortunately, a gap exists between the information contained in published guidelines and the knowledge and information that are necessary to implement them.⁵ Those who are charged with operationalizing guidelines must bridge this implementation gap. Currently, implementers use poorly specified, largely tacit knowledge acquisition processes and a multiplicity of guideline knowledge representations to create computable decision support systems from published guidelines. This approach results in considerable inconsistency in the encoding of guideline knowledge and in the functionality of the systems that are created.⁶ In some cases, Patel et al.⁷ have found that different recommendations would be given for the same patient using computable representations of the same guidelines that are formulated by different individuals.

This work describes our progress toward understanding the activities that are required to bridge the “guideline implementation gap.” We describe a generic process for translation of document-based knowledge into workflow-integrated decision support tools. Our goal is to define a set of replicable activities that will help to systematize the process and make its component activities explicit. We describe this approach as document-centric because the guideline document is used as the authentic source of domain knowledge. This approach differs from that applied by many current models, which design clinical decision support based on designers' understanding of the guideline authors' goals or intentions and their conceptualization of guideline logic.⁸

Background

Tierney et al⁹ described their frustration in creating a computer-based implementation for an evidence-based guideline to assist with management of heart failure. That guideline, like many others, lacked explicit definitions, focused on omission errors (rather than errors of commission), and did not account for comorbid conditions, concurrent drug therapy, or timing of interventions. Peleg et al.¹⁰ observed specialty society experts as they created flowcharts based on narrative guidelines and found excessive ambiguity and problems in sequencing. In addition to these problems, guidelines are often incomplete, i.e., they regularly fail to describe appropriate behavior for an exhaustive set of situations that may befall practitioners.¹¹ Moreover, conditional recommendations are regularly undecidable, i.e., they fail to specify in a clear, consistent manner the parameters on which decisions are based. Likewise, actions may not be executable. Often, the level of abstraction at which decision variables and actions are described is inappropriate for implementation. Grol et al.¹² found that clinicians were considerably less likely to adhere to vague and nonspecific recommendations.

For optimal implementation, all guideline recommendations must be integrated with clinical workflow,^13,14 a principle characterized by widespread variability of practice. Tu et al.¹⁵ have devised a “deployment-driven” approach to integration of guideline recommendations into workflow that is currently being tested. Cabana et al.¹⁶ have created a useful conceptual framework that describes critical barriers to successful implementation, including awareness of and familiarity and agreement with guideline content, and clinicians' self-efficacy, outcome expectancy, and ability to overcome inertia of previous practice. Attention to knowledge deficits and attitudinal issues are also critical in the design of successful systems.

Guideline Elements Model: A Reusable Guideline Document Model

We use the Guideline Elements Model (GEM) as a computable representation for clinical practice guidelines.¹⁷ GEM is an XML-based document model that uses a multilevel hierarchy to store the heterogeneous kinds of information contained in clinical practice guidelines, including identification of the guideline's developer, description of the development process, definition of the guideline's purpose, the intended audience, the target patient population, and the recommendations themselves. The hierarchy contains more than 100 tags by which guideline information can be classified (marked up) and modeled at varying levels of abstraction. GEM was conceived and built in XML and, therefore, can take advantage of each of the emerging XML-related technologies. GEM facilitates translation of guideline information and knowledge into a format that can be processed by computers while remaining readable by humans. American Society of Testing and Materials (ASTM) International has adopted the GEM Document Type Definition as a standard representation for guidelines using XML.

GEM has been used successfully to assist with guideline quality appraisal¹⁸ and to translate guideline recommendations into Arden syntax.¹⁹ Gershkovich and Shiffman²⁰ demonstrated the feasibility of guideline implementation from a GEM file by automatic generation of Web forms for data entry, but this system was not integrated into clinical workflow. Georg et al.²¹ recently demonstrated the superiority of GEM encoding over traditional methods as a first step in the development of a knowledge base from textual documents.

Formulation of the Guideline Implementation Model

In the current work, we set a short-term goal of understanding what meta-information is commonly necessary to supplement guideline-derived knowledge for computer-based guideline implementation. The implementation model was formulated empirically during several experiences in the design and development of guideline-based decision support tools. As such, it reflects the longitudinal experience of one group operating on a variety of guidelines over more than a decade.

In early work, we marked up a number of guidelines to gain an overview of the kinds of information contained in them. Next, we envisioned how decision support systems designed to implement the guideline knowledge might operate. We then characterized the kinds of information that would be necessary to move from the guideline markup to a fully operational decision support system, i.e., to bridge the implementation gap.

Several principles governed our design activities.

• The approach should be systematic, replicable, and reusable.

• Knowledge acquisition using markup is an iterative process, in which narrative text is refined and clarified.

• The final implementation of the guideline knowledge must be closely integrated with workflow. In general, workflow is site specific. To encourage integration with workflow, we advocate offering end-users a decision support system with as many services as possible to offset the inevitable downside associated with using any information technology.^14,22 Effective decision support designs integrate guideline knowledge with beneficial services that are appreciated by users, consider the volume of advice and prioritize it so as not to overwhelm users, and employ effective user interface design principles. Use of an electronic health record system or physician order entry system offers an opportunity to integrate patient-specific, guideline-prescribed advice into the clinician–patient interaction.

• Any local adaptation of the guideline knowledge must be transparent, i.e., an audit trail must be constructed.

• The information systems designers who build the decision support tools need not possess high-level informatics skills.

• The process should result in output generalizable to multiple platforms. To optimize the generalizability of the model, we chose to not create tools that directly incorporate the processed guideline knowledge into the local information system. Instead, the output we are aiming for is a detailed requirements specification to serve as a starting point for an iterative process that can be applied in a variety of information environments.

Model Description and Validation

The proposed document-centric model describes the translation of guideline knowledge and the acquisition of relevant meta-information into a framework that can be operationalized within a computer-mediated decision support system. Generically, the meta-information necessary for implementation falls into two main categories: (1) information that more precisely specifies the guideline knowledge and (2) information that facilitates workflow integration.

In this section, we describe the model and, at the same time, provide details of our experience with implementation of an asthma guideline that validates the model. The model provides a design pattern that reduces the overall complexity of the translation task by specifying combinations and sequences of activities that are crucial to accomplish the task.²³ We describe a set of generic activities that takes as input a narrative guideline and provides as output a detailed specification for a workflow-integrated decision support system.

We draw examples from our recent experience in translating recommendations from the National Heart, Lung, and Blood Institute's guideline on management of asthma²⁴ into a workflow-integrated decision support system that operates within the Logician (GE Medical Systems, Hillsboro, OR) electronic health record system at the Yale New Haven Hospital. We gained considerable experience over the last several years, initially implementing parts of this guideline on handheld computers and ultimately deploying a decision support system throughout the ambulatory and inpatient pediatric units at Yale New Haven Hospital. As currently deployed, the chronic asthma management system prompts for the collection of a patient's symptom information, interprets these findings and suggests classification of asthma severity and level of control, facilitates prescription of appropriate medications and referrals when indicated, and provides a handout with customized management advice—all based on guideline content.

An overview of this approach to guideline implementation is shown in ▶. The remainder of this section describes the component activities. In the indented text, we describe how our experience with the asthma guideline demonstrates that the model can be applied in the real world. Guideline text extracts are shown in italics.

Figure 1.

An activity diagram that displays processes involved in guideline translation.

Guideline Selection

To initiate the implementation process, a specific practice guideline must be chosen as a knowledge source. In many cases, several developers will have created guidelines on the same topic. The guideline selection process is based on user or organizational imperatives, e.g., identified areas in which there is exceptional local practice variation, areas in which new knowledge ought to be put into practice, or areas in which resource use is inappropriate.

At this early juncture in the implementation process, the validity of the guideline as well as its likely implementability must be considered. Instruments from Shaneyfelt²⁵ and the AGREE Collaboration can be used to assess guideline quality.²⁶ Guidelines that have been reported according to the COGS statement²⁷ are likely to be easier to assess for validity because they systematically report precise details that are critical for understanding a guideline's development, its recommendation statements, and potential issues in its application.

Some guidelines are likely to be operationalized more readily than others. We are developing an Implementability Rating Profile (IRP) that helps users consider several intrinsic guideline attributes that affect implementation success. The IRP instrument examines decidability, executability, effects on process of care, measurable outcomes, flexibility, and several other dimensions to assist users in anticipating barriers to implementation.

Asthma has been recognized as a major problem in the community served by the Yale Primary Care Center (PCC), with more than 600 admissions for asthma occurring annually for children alone. There was a widespread perception among clinicians and administrators that asthma care could be improved. The National Heart, Lung, and Blood Institute (NHLBI) released an evidence-based guideline on asthma in 1996 that has achieved wide use and acceptance.²⁴ A committee of PCC clinicians, administrators, and information systems personnel selected this guideline for implementation.

When applying a document-centric approach to guideline translation, the individual recommendation, not the guideline as a whole, is the essential unit of implementation. Therefore, a secondary selection step is to choose specific recommendations within the selected guideline to be implemented. Most guidelines contain several recommendation statements, and some may be beyond the scope of a current effort.

The implementation effort at the Yale Primary Care Center was directed at increasing the appropriate use of pharmacologic interventions for chronic asthma management, facilitating pulmonary specialty referrals, and enhancing patient education. Three specific guideline-prescribed tasks seemed amenable to automation:

• Classification of asthma severity as mild-intermittent or as mild-, moderate-, or severe-persistent based on clinical findings

• Choosing appropriate medications, based on classification, level of control, age, and current medications

• Providing a take-home message in the form of a customized handout.

For this implementation, users elected to not operationalize those guideline components that dealt with diagnosis of asthma or management of acute exacerbations.

Markup

If the implementer plans to use XML tools to facilitate operationalization, the first step after guideline selection is markup. (This is the only step in the translation process that is specific to an XML-modeling approach.) Guideline knowledge components relevant to operationalization are identified and tagged. In addition to the Knowledge Components subhierarchy in GEM (which includes recommendations, definitions, and algorithm hierarchies); additional elements that describe the guideline's purpose, intended audience, target population, and schemas for rating evidence quality and recommendation strength are usually valuable for implementation.

Guidelines most often define recommendations as imperatives, i.e., activities applicable to the entire eligible population, or as conditionals, i.e., activities recommended in specifically defined circumstances. Conditionals can be expressed as

where decision variables and their values describe antecedent conditions that must be fulfilled if a recommendation is to be applicable, and actions describe consequents that are recommended under these circumstances. Imperatives, on the other hand, are stated simply as:

where directives describe guideline-prescribed activities that are presumed to be applicable to the entire target population of the guideline, without restriction. GEM accommodates markup of both imperatives and conditionals as well as supplementary information relevant to each recommendation, such as the reason for the recommendation; the guideline authors' assigned strength of recommendation and their assessment of the quality of evidence that supports it; test characteristics of decision variables; and anticipated benefits, risks, harms, and costs of applying the recommendation.

GEM Cutter is an XML editor we developed to facilitate markup of a guideline text document into GEM format. The main window (▶) consists of three vertical panels. When a guideline document is imported into the application, it appears as a scrolling text document in the leftmost panel. In the middle panel, an expansible tree-view of the GEM hierarchy appears. A user classifies guideline contents by selecting text in the leftmost panel and clicking the insert button to place this text in the appropriate position in the GEM hierarchy displayed in the middle panel. GEM Cutter's rightmost panel provides definitions of elements and allows for text editing. Markup with GEM Cutter produces an XML file, the contents of which can be reused in a variety of ways.²⁸

Figure 2.

GEM Cutter is an XML editor that facilitates guideline markup.

Precise Specification of Guideline Knowledge (Semantic Refinement)

Atomization

Atomization is the process of extracting and refining single concepts from the recommendation's natural language text. It involves removing unnecessary words, changing verb phrases from passive to active voice, reducing decision variables to prototypic nouns with descriptors occupying the 〈value〉 element and stating actions and directives as verbs in active voice with associated direct and indirect objects and modifiers.

The NHLBI guideline states: “It is the opinion of the Expert Panel that, in general, infants and young children consistently requiring symptomatic treatment more than 2 times per week should be given daily anti-inflammatory medication.”

The concept “infants and young children” can be operationalized by substituting an appropriate age range. The atomization process changes the passive should be given to a verb in active voice. The appropriate verb (give/administer/prescribe) is determined by the setting in which the recommendation is likely to be applied and by the persons involved in carrying it out (e.g., patient/parent, nurse, clinician–pharmacist).

Deabstraction

Frequently, guideline recommendation statements are published at an abstract level that makes implementing them difficult or impossible. Deabstraction is the process of adjusting the level of generality at which a decision variable or action is described to permit operationalization.

If the patient's asthma is not optimally controlled with the initial therapy, and medications are used correctly, additional step-3 therapy is recommended.

Medications are used correctly is an abstract concept that may be difficult to operationalize. It requires assessing that the patient adheres to the prescribed medication regimen and uses good inhaler technique. Good inhaler technique, in turn, means that the patient uses a spacer, takes slow inhalations, and repeats the inhalation after 1–4 minutes.²⁴

There is a tradeoff between the level of abstraction and expected practice variation. Since diminishing unacceptable practice variations is a prime motivation for guidelines, careful attention to deabstraction is critical in the process.

Once concepts have been defined at an appropriate level of generality, they may require reatomization. Therefore, the process that achieves deabstracted and atomized concepts from guideline text is iterative.

Disambiguation

Disambiguation is the process of establishing a single semantic interpretation for a recommendation statement. Ambiguity can be introduced when values of decision variables are not mutually exclusive.

The NHLBI guideline provides a table for classification of asthma severity that includes criteria based primarily on symptom frequency. The proposed classifier also includes an ambiguous set of descriptors for “asthma exacerbation” that are poorly defined and not mutually exclusive. Analysis of these descriptors showed that they addressed 3 different dimensions: frequency, severity, and duration of exacerbations. For example, duration was described as “frequent” in one instance and its alternative was “≥2 times per week.” Severity was described using three nonexclusive values: “may affect activity”, “affect(s) activity”, and “intensity may vary.” Finally, duration could take on values of “may last days” or “brief (from a few hours to a few days).” The semantic overlap inherent in these descriptors for exacerbations indicated that “exacerbations” would not be useful for classification of asthma severity.

Ambiguity is sometimes introduced intentionally into guideline statements by the author to reflect limited supporting evidence or lack of consensus, using “weasel words” that do not clearly describe a decision variable or prescribe an activity. If uncorrected, ambiguity will lead to inconsistent application of the guideline recommendation.

Verification of Completeness

Completeness verification assures that each recommendation provides guidance in all situations that a clinician is likely to face, i.e., that all logically possible combinations of condition states are addressed. A guideline recommendation that is not comprehensive will lead to potentially avoidable practice variation by not describing appropriate actions in all circumstances.

Comprehensiveness can be analyzed formally using decision table techniques.²⁹ (Likewise, ambiguity can be recognized in a decision table analysis when the same combination of conditions triggers conflicting actions.) In the case of conditional recommendations with a small number of decision variables, formal verification of completeness may be unnecessary. At the very least, however, implementers should assure that all possible values (states) for each decision variable have been considered, since inattention to this specification is a cause of many incomplete recommendations. Missing combinations of decision variables should be resolved by local domain experts with an audit trail indicating the local source of this knowledge.

The guideline contains the following recommendation:

The patient's response to therapy should be monitored carefully. When benefits are sustained, a step down in therapy should be attempted. If there are no clear benefits, treatment should be stopped, and alternative therapies or diagnoses should be considered.

The guideline describes “sustained” and “no clear benefits” as potential alternative values for the decision variable “benefits” but fails to address the predictable situation in which benefits are present but temporary.

Explanation

A facility to describe the reasoning behind recommendations has long been considered important for clinical decision support systems.³⁰ Often, text extracted directly from the guideline can be used to achieve this purpose. In a guideline that has been marked up according to the GEM standard, information in the 〈reason〉 element is useful to justify the proposed service. It can be supplemented with information categorized in 〈objective〉 and 〈rationale〉 elements as well as information that might be contained in 〈decision variable description〉, 〈test parameter〉, 〈action description〉, 〈action benefit〉, and 〈risk-harm〉 elements.

To support its recommendation for prolonged use of inhaled corticosteroids in children with persistent asthma, the guideline includes the following text:

A recent meta-analysis of the influence of inhaled beclomethasone in the attainment of expected adult height did not find any significant effects regardless of dose, duration of asthma, or disease severity.

Five additional studies were cited. This information would likely be of value to clinicians and patients who are hesitant about prescription of inhaled steroids and looking for additional scientific support for its safety.

Build Executable Statements

The next step is to arrange the atomized, deabstracted, and disambiguated decision variables and actions into logical statements that can be translated readily into computable statements. Using a limited number of logical operators (conjunction, disjunction, negation, conditional, and parentheses for grouping), guideline recommendations can be expressed in statement logic.³¹ Although this set of operators is elementary, it has proven sufficient for representing individual guideline recommendations. Encoding complex relationships, e.g., temporal relationships between individual statements, is an area of current investigation. We are exploring the use of components of the current Arden syntax as a richer set of semantic relations.

IF

Reduction in school/play activities = true OR

Missed school days > 0  OR

Exacerbation frequency ≥ 2 times per week OR

PEFR Variability > 20%   OR

…

THEN

Conclude: Level of control is suboptimal

The guideline notes that in categorizing a patient's severity classification “an individual should be assigned to the most severe grade in which any {symptom} occurs.” The translation of the asthma guideline classification logic would have been facilitated if a “maximum” function existed to encode the transition from asthma symptoms (e.g., wheezing frequency, frequency of nocturnal symptoms) to severity classification (e.g., mild intermittent asthma, moderate persistent asthma). Nonetheless, this mapping was accomplished using the elementary syntactic elements.

Workflow Integration

In addition to precise knowledge specification, the other critical activity for successfully bridging the guideline implementation gap is integrating the guideline's knowledge with clinical workflow. Workflow support is a critical factor in the acceptance and use of computer systems^32,33; automation is unlikely to be successful unless it produces a net benefit for users to offset the costs of its use. The following steps address this process.

Identify Origins and Insertions

The implementer must identify a source or origin in the clinical environment for each decision variable and an insertion point in the care process for each recommended action and directive. This is a critical step for workflow integration. Unfortunately, we have been unable to identify an existing standard description of the care process that can meet this requirement. Therefore, we have described origins and insertions at a high level that we expect will be further refined.

Although not universal, the following sequence is common enough in clinical encounters—inpatient and ambulatory—to offer a rudimentary framework for description of workflow:

1. Registration: In most instances, patients first register with the health care system, making available a number of demographic attributes (e.g., name, address, a unique numeric identifier, telephone numbers) and high-level clinical variables (e.g., age, sex, race).

2. Clinical history is elicited.

3. Physical examination, testing, and/or other objective laboratory evaluation are undertaken.

4. Assessment: synthetic interpretation of the findings from steps 2 and 3 occurs.

5. Plan: A strategy for further diagnostic, therapeutic, counseling, and/or dispositive activities is formulated.

The potential origins of decision variables and the potential insertion points for guideline-recommended actions can be mapped to this framework.

Patients with moderate-to-severe-persistent asthma should learn how to monitor their peak expiratory flow (PEF) and have a peak flow meter at home. Implementation of this recommendation requires an asthma severity classification, which would most commonly occur during the Assessment phase of the encounter. The recommendation prescribes actions (learning/teaching) most commonly performed after the history has been taken and the physical examination completed. Support for educating the patient about peak flow monitoring and actual prescription of the peak flow device are therefore likely to be most useful during the Plan phase of the encounter.

	ORIGIN	INSERTATION
Moderate-to-severe persistent asthma	Assessment
Educate: PEF monitoring		Plan
Prescribe: peak flow meter		Plan

Another example demonstrates capture of decision variables during the History phase. When the patient requires continuous oral corticosteroid therapy or high-dose inhaled corticosteroids or has required more than two bursts of oral corticosteroids in 1 year…referral for consultation or care to a specialist in asthma care…is recommended.

	ORIGIN	INSERTATION
Continuous oral corticosteroid therapy	History
High-dose inhaled steroids	History
More than 2 bursts oral corticosteroids in past year	History
Refer: To asthma specialist		Plan

Define Action Type and Associated Beneficial Services

Actions are the critical components of guidelines that prescribe appropriate clinical behaviors. We have empirically defined an action palette, i.e., a limited set of action types that comprehensively categorize the activities recommended in a large number of randomly selected guidelines.³⁴ These actions types fall into four major categories: gathering information, interpreting information, performing a task, and arranging for or organizing additional care (▶).

Table 1.

Guideline Action Types

Gather additional information
Test	Obtain or collect additional data through inquiry, examination, laboratory testing, imaging, or other investigative procedures whose intent is not curative.
Monitor	Make serial observations according to specific criteria and schedule.
Interpret information
Conclude	Determine a diagnosis, prognosis, or clinical status.
Perform a task
Prescribe	Order a treatment requiring medication or durable medical equipment.
Perform therapeutic procedure	Order activities that are therapeutic in nature.
Educate/Counsel	Inform the patient about means to improve/maintain health, or instruct on how to perform specific activities.
Document	Record one or more facts in the patient record.
Advocate	Argue in support of a policy.
Prepare	Make ready for a particular guideline-directed activity by training, equipping, or gaining new knowledge.
Organize care
Dispose	Initiate an activity to direct the flow of patients, such as admit, discharge, follow up, transfer, etc.
Refer/consult	Direct a patient to another clinician for evaluation and/or treatment.

Categorizing guideline-recommended activities according to these predefined action types can help implementers prepare for operationalization. We anticipate that certain action types will reuse clinical data and procedures in a predictable way. Action types can be linked to associated beneficial services that offer design patterns for facilitating clinical care. It then remains for the implementer to instantiate specific components appropriate for local circumstances.

The NHLBI guideline recommends use of a variety of pharmacologic agents for management of chronic asthma. Operationalizing the prescribed action type in an ambulatory setting results in the creation of a prescription—a process that can be replicated for any action that stipulates an ambulatory drug order. Prescriptions will require predictable data (patient name, physician name, drug name, drug strength, drug quantity). In addition, there may be a need for computable procedures that record this prescription in the patient's medication list and transmit the completed prescription via fax or electronic data transfer to a pharmacy. Each of these activities can use replicable modules, which can be selected whenever a prescribed action type is encountered.

Choose Interface Components

Finally, design elements for the user interface must be selected and grouped for optimal usability. Screen mockups can be created to guide information systems personnel in the design of actual operational systems. In selection of appropriate elements of the desktop interface (e.g., checkboxes, radio buttons, dropdown boxes), colors, or wording that appears in dialog boxes, principles of effective interface design should be followed.³⁵ Involvement of users at this phase is critical.

Requirements Specification

The output of the above processes is a requirement specification that can be operationalized by information systems personnel. Such individuals often have high levels of expertise in programming local systems, but have more limited knowledge of clinical domains and informatics skills. The document serves as a starting point for an iterative development process.

In implementation of the asthma guideline in the Logician system, the requirements were specified as lists of atomized, deabstracted, disambiguated decision variables and actions. The logical form of the recommendations was described using statement logic. In addition, origins and insertions of guideline decision variables and actions were identified. Mockup drawings of interface elements were supplied in the documentation. Ongoing meetings among the guideline processing team (informatics), the clinical users (pediatricians, nurse practitioners, pediatric pulmonologists), and the information systems personnel iteratively defined improvements to the evolving asthma decision support system. The IS group then proceeded to generate code to implement the guideline logic, create a detailed interface design, encode all decision variables and actions in Logician codes, and perform both routine testing and safety testing of the system.

The optimal content and format of a generic requirements specification is a topic of ongoing investigation. One or more use cases may be used to document functionality of each guideline recommendation that is to be implemented. A high-level structural view of the static concepts and concept attributes that define the structure of the guideline domain and an activity diagram that depicts the passing of information among stakeholders may be useful for implementers who are familiar with the Unified Modeling Language (UML).³⁶ Finally, a glossary that defines critical concepts is valuable.

Discussion

Guidelines provide an important source of up-to-date clinical knowledge about best practices. We have described a series of steps that take place in the process of extracting knowledge from published guidelines and implementing them in a decision support system. Processes that have been largely tacit, such as atomization and deabstraction of critical decision variables and actions and determination of sources of information and appropriate insertion points for advice, are addressed explicitly in this approach. We believe these are generic activities that must be undertaken any time a published guideline is implemented in a CDSS. Our development of an operational decision support system for chronic asthma management validates the model and demonstrates the feasibility of the approach.

This work parallels that recently reported by Maviglia et al.³⁷ who described an approach for implementing a complex multistep guideline for cholesterol management. This report extends that work into another chronic disease domain. In contrast to the Maviglia et al.³⁷ report, we describe use of data not generally found in coded form in electronic health records. Also, we built the decision support into a commercially available electronic system.

A considerable number of alternative knowledge representations exist, some of which were recently reviewed by Peleg et al.,⁸ including Asbru, EON, GLIF, GUIDE, PRODIGY, and PROforma. We describe a model that applies the GEM framework. GEM markup facilitates implementation by explicitly categorizing the clinical knowledge according to a standardized system. However, most of the steps in operationalizing guideline knowledge are similar regardless of whether GEM markup and tools are used.

An inferencing mechanism is not prescribed intentionally in this framework. Rather, parameters that are to be passed to and returned from the inferencing system are described. A group working within the HL7 Clinical Decision Support Technical Committee is creating a virtual medical record to facilitate transfer of information generically to a variety of inferencing engines.³⁸

Knowledge maintenance is critical for any knowledge-based system. As new knowledge is discovered, guideline recommendations may require modification. The modularity encouraged by this model should facilitate knowledge updating. Entirely new recommendations will require the complete process. On the other hand, modification of individual decision variables and actions in a recommendation can likely proceed along a fast track that is simplified by the modular nature of the model. Potential interactions among statements will require careful attention of the implementation team.

The Institute of Medicine recognized that adaptation of guideline recommendations may be necessary in some cases to respond to local circumstances, objectives, and constraints.³⁹ It is important for implementers to protect against modifications that are made to protect habit and self-interest. Ideally, carefully developed guidelines might set bounds on adaptation by offering accepted options of practice. Implementers can and should give users greater flexibility of action (optionality of adherence) in controversial situations, i.e., when the evidence base is weak or the anticipated levels of benefits and harms to be derived from adherence are relatively balanced.⁴⁰ In this implementation model, adaptation is most likely to occur during deabstraction, specification of origins and insertions, and defining associated beneficial services. The explicit nature of the model and its intermediate outputs permit safeguards to be put in place to diminish the likelihood of inappropriate adaptation.

This document-centric approach to guideline translation presumes a finished guideline as a starting point. In some organizations (e.g., Kaiser Permanente) and in some other countries (e.g., the United Kingdom), both guideline authoring and implementation are directed by the same enterprise. In such cases, it is reasonable to consider whether authoring tools could be extended to the guideline domain experts to facilitate development. We are currently exploring the creation of such a guideline-authoring tool.

One limitation of this model is that it is underspecified in many areas. We have taken an initial step at workflow integration and highlight its importance, but considerable additional work remains in this area.

Another limitation of the current approach is that its product is a requirements specification that must be encoded and implemented further rather than a working decision support system. With the plethora of information systems currently in use, we believe it is currently impractical to carry the generic components of the translation task beyond a detailed requirements specification. As we gain further experience in document-centered implementation at our own institution, we expect to develop tools and techniques that will operate within the Logician system to directly use products of the translation process. As external standards converge, it may be possible to devise cross-platform tools in the future.

A well-recognized problem in software engineering is that complications may arise when one goes from a set of specifications to an actual system implementation. Our goal has been to create specifications that will reduce the chance of implementation errors. We hypothesize that application of this systematic approach may lead to less variability in the development of guideline-based clinical decision support systems.

Conclusion

We have described a process for translation of guideline documents into computer-mediated clinical decision support systems that systematize a set of vague and tacit activities. Using the guideline document as a knowledge source promotes authentic translation of domain knowledge. The overall complexity of the implementation task is reduced when these subprocesses are considered. From this framework, we believe that a better understanding of activities involved in translation will emerge, and tools will be created to facilitate the process. Additionally, reuse of software components should be possible as repeated high-level activities are identified and concretized.