Three considerations led to the decision to start development of the SAGE model in 2002. Past efforts have gone into developing shared models for representing medical decisions and clinical guidelines. However, it takes more than a formalism for medical logic to accomplish sharing of computable medical knowledge. Reuse of a guideline knowledge base also requires that an infrastructure that includes medical record query interface, terminology mediation, and act interface is in place. Further, the emergence of clinical standards such as Health Level Seven’s Version 3 (HL7 v3), Reference Information Model (RIM) and the College of American Pathologists’s SNOMED Clinical Terms, led to the belief that the opportunity existed to build a guideline model from the ground up which could take advantage of these infrastructural standards in a systematic way. Still, making use of standards for modeling guideline is not a straight forward process. Rarely do existing standards completely satisfy the requirements of guideline modeling. Thus the elucidation of the complex relationship between existing standards and requirements of guideline modeling and deployment is one of the themes of the SAGE project.

The second consideration is the SAGE’s approach to integrating guideline-based decision support with the workflow of care process. That the success of clinical decision-support systems (DSSs) depends heavily on how the system is integrated into the care process is widely recognized. The SAGE project takes the approach that, as a provider of decision-support services to CISs, SAGE will not be in control of a host systems’ workflow management. Thus, the SAGE modeling approach does not require detailed workflow to be modeled unlike for example the University of Pavia’s careflow methodology. Instead, the SAGE system will respond to opportunities for decision support in the care process. We need to model enough of workflow contexts to recognize appropriate events that should trigger decision-support services. Upon receipt of such a triggering event, the SAGE DSS will deliver, through existing functions of the CIS, guideline-based recommendations appropriate for members of a care team. The implication of this approach for guideline modeling is that guideline knowledge must support operations in an event-driven reactive system, and it must take into account clinical and organization contexts such as care setting and provider roles. Instead of just creating an electronic version of a clinical practice guideline, guideline modeling in SAGE formalizes guideline knowledge being used in specific scenarios and settings.

The third consideration leading to the decision to develop SAGE is that, in recent years, much interchange and cross-fertilization have taken place in the guideline modeling community. Starting with workshops such as the ones sponsored by Intermed in 1999, the University of Leipzig in 2000 and OpenClinical in 2001 and continuing with a number of comparison papers, workers in the guideline modeling community have gained much better understanding of the commonalities and differences between different approaches and of the design choices made in them. The SAGE project has given us the opportunity to synthesize prior work and, wherever possible, to establish mappings between the SAGE model and other models.

The SAGE project seeks to create a guideline model that:

• uses standardized components that allow interoperability of guideline execution elements with the standard services provided within vendor clinical information systems.
• includes organizational knowledge to capture workflow information and resources needed to provide decision-support in enterprise setting
• synthesizes prior guideline modeling work for encoding guideline knowledge needed to provide situation-specific decision support and to maintain linked explanatory resource information for the end-user

Innovative features of the SAGE guideline model include:

• Organization of guideline recommendations as recommendation sets consisting of either Activity Graphs that represent guideline-directed processes or Decision Maps that represent recommendations involving decisions at a time point.
• Use of a suite of data models and services as interfaces to clinical information systems.
• Systematic use of standard terminologies
• Deployment-driven guideline modeling methodology.

Recommendation sets

We define a recommendation set for a computable guideline as a collection of related recommendations that are applicable in one or more shared contexts and that are organized according to a computable formalism. A context is defined by a combination of a clinical setting (e.g. outpatient encounter in a general internal medicine clinic), the care provider to whom the recommendation is directed, and the relevant patient states (e.g. a hypertensive patient who has been prescribed anti-hypertensive agents). Within each context, a recommendation may describe the preferred choice in a management decision (e.g. whether to increase the dose of a drug or to add another anti-hypertensive agent), or it may recommend a series of actions be carried out (e.g. perform history and physical before ordering certain tests). A recommendation set specifies how decisions and actions are related to each other in a specific context. Separate models of decision making and action taking describe the details of decision-making knowledge and the structure of recommended actions.

An Activity Graph describes the relationships among different activities in terms of a process model. We define an Activity Graph as a specialization of the workflow process model for specifying clinical and computational activities designed to implement guideline recommendations in particular clinical and organizational contexts. A Decision Map, on the other hand, is a collection of recommendations that do not need to be organized and executed as a process. One use of the Decision Map is the encoding of a collection of asynchronous alerts and reminders that are not organized as a connected process of activities. Alternatively, a Decision Map may be used as the decomposition of a high-level action such as “Adjust Medication” in a hypertension guideline. The high-level action involves decisions made by a single provider in a specific clinical context at a single time.

We evaluated this formulation of recommendation sets in terms its ability to reproduce or clarify the structure of guideline recommendations in existing guideline modeling methodologies. So far, we have established mappings from recommendation formalisms of Medical Logic Modules, PRODIGY3, EON, and GLIF3 into the recommendation set structure. We have done partial mapping from the workflow constructs in the HL7 Reference Information Model. In doing so, we have uncovered discrepancies that need to be resolved for the HL7 RIM to provide the semantic basis for guideline recommendations.

Data models and services.

To achieve interoperability of guideline decision-support system (DSS) with vendor clinical information systems (CIS), we make explicit a suite of models and services that together define the interface between DSS and CIS. An organizational model that defines available clinical and administrative events, roles, settings, and resources provides the vocabulary to describe the contexts in which GDSS provides decision-support services. Thus, a guideline may be triggered by a patient check-in event generated at a primary care outpatient clinic where guideline-based alerts are generated for providers who play the roles of clinic nurse and primary care physician. A guideline is encoded using a simplified view of a patient’s medical record data, called a Virtual Medical Record (VMR) that is ultimately based on the HL7 RIM. The VMR classes, by themselves, still allow several degrees of freedom in representing patient information (e.g. the code slot in AdverseReaction may be ‘allergic drug reaction’ (SNOMED CT 74069000) or more restrictive ‘vaccine allergy’ (SNOMED CT 294640001). Detailed clinical models, also called Clinical Expression Models (CEMs), spell out, by placing constraints on attributes of VMR classes, precisely how patient data would be represented.

Standard terminologies.

Terms from terminologies are the atomic units of meaning that we use to make assertions through information models such as VMR and CEMs. However, concepts used in clinical guidelines often do not match precisely the term hierarchies in standard medical terminologies. The concept of ‘pulmonary problem excluding asthma’ in for example, is unlikely to have an exact equivalent in any standard terminology. Thus, the SAGE project has developed several strategies to define guideline concepts from standard terminologies. The first technique is to use the a reference terminology’s own compositional method for defining new concepts. Using SNOMED CT, for example, we can define to terms such as ‘severe wound’ as a {‘wound lesion’ (SNOMED CT 239155007) associated severity ‘severe’ (SNOMED CT 24484000)}. The second technique is to using a notation, which we call Concept Expression, to define a term as Boolean combinations of other terms (e.g. ‘pulmonary disease excluding asthma’ as a {‘disease of lung’ (SNOMED CT 19829001) AND NOT ‘asthma’ (SNOMED CT 195967001)}).

Deployment-driven guideline encoding methodology.

To ensure that the a guideline formalized in a SAGE knowledge base is informed by the usage scenarios of the guidelines in the care process, the SAGE project developed a seven-step deployment-driven guideline modeling methodology. Once the decision to implement a guideline has been made, the SAGE guideline knowledge base development methodology requires that clinicians first create clinical scenarios that are detailed enough to support integration of guideline recommendations into clinical workflow. These usage scenarios identify opportunities for providing decision support, the roles and information needs of care providers, events that may activate the guideline system, and guideline knowledge relevant in these scenarios. In subsequent steps, clinicians distill, from guideline texts, medical literature, and their clinical expertise, the knowledge, logic, and concepts needed to generate these recommendations.. Concepts identified as part of the required guideline logic are instantiated as detailed clinical data models and standard terminologies.In the final stages, clinicians work with knowledge engineers to formalized the guideline knowledge in term of the SAGE guideline model. Finally, before a formalized guideline can be installed and used in a local institution, its medical content must be reviewed and revised (in what we call the localization process) and its data models, terminologies, and organization assumptions (roles, events, and resources) must be mapped to those of the local institution (in what we cal the binding process).

Prototype implementation

The SAGE project is organized around the principle of phased synchronization cycles, where in each cycle of the project, we analyze, encode, and demonstrate simulated implementation of a guideline in a real clinical information system. The project had selected immunization, diabetes, community-acquired pneumonia, and hip replacment as the four guidelines that it will formally encode and demonstrate through simulated implementation. At April 2005, the project has completed the cycle for the immunization and diabetes guidelines and is working on the community-acquired pneumonia guideline.

Plans

After a one-year hiatus, the project (in 2005) has resumed work on implementing guideline-based decision support for immunization, diabetes, and community-acquired pneumonia. The SAGE system is to be tested in simulated environments at Mayo Clinic and University of Nebraska Medical Center. Beyond 2006, the project is seeking funding for actual deployment and clinical trials of the system in selected institutions.