Components of SAGE Guideline Model

A clinical practice guideline (CPG) is contains systematic statements of evidence-based policy rules or principles to assist clinicians and patients make decisions on healthcare alternatives. The SAGE Guideline Model is a computable knowledge representation "format" for encoding the content and logic of executable CPGs.. We conceptualize CPGs as having metadata such as issuing organization, enrollment criteria that defines its target population and recommendation sets consisting of some usage context (specific clinical circumstances) where some course of actions are preferred over others (decisions about appropriate health care).

The enrollment and decision criteria are written in terms of an executable expression language that make use of guideline concepts (linked to standard terminologies) and clinical evidence (formulated as evidence statements) for selecting particular action and that may make queries to external knowledge sources. Guideline actions are defined in terms of a set of action specifications (e.g., order laboratory tests or send an alert message) that are linked to corresponding actions in a clinical information system (CIS).

The executable guideline knowledge is embedded in an event-driven reactive system that takes into account clinical and organizational contexts such as care setting and provider roles. The guideline knowledge has been encoded from the perspective of generating appropriate decision-support behavior. Instead of merely creating an electronic version of a clinical practice guideline, guideline modeling in SAGE formalizes guideline knowledge being used by a decision-support system in specific scenarios and settings.

In the following, we describe some of the major components of the model.

On this web page we highlight some of the major components of the SAGE Guideline Model. A detailed description of the model can be found in the SAGE Guideline Model Specification document.

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 actions 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.

The details of the context, decision, and action nodes are shown in the below.

The clinical context attributes specifies where the recommendations associated with the Context node is applicable. Triggering events and precondition indicate when and for which patients the context should be activated. Automation mode and transition restriction holds flow-of-control information.

Decision nodes support representation of decision knowledge required to recommend a choice among alternatives. The decision model used in SAGE models a set of of alternatives, each which has the following information:

• alternative: an instance of Decision or Action that represent one option at this particular decision point.
• strict_rule_in: A collection of criteria that express strong indications for the alternative.
• strict_rule_out: A collection of criteria that expresses strong contraindications for the alternative. If any of the strict_rule_out criteria is true, then this alternative should not be considered.
• rule_in: A collection of criteria that expresses relative indications for the alternative
• rule_out: A collection of criteria that expresses relative contraindications for the alternative
• recommendation_threshhold: The number of strict_rule_in criteria that, if true, makes this alternative a recommended choice

The Action node holds flow-of-control information (automation mode and transition restriction) and specification of actions to be taken at this point in the guideline. Action specifications are abstractions of clinical information system (CIS) actions that operationalize the guideline actions. They include:

1. Actions that assert and retract conclusions to the VMR. An Conclude action writes inferred patient state and decision-historic data to the Observation, Problem, or Goal VMR classes. A guideline encoder may specify that certain conclusions are transient and should not be written to permanent record, but should disappear after session ends. A Retract action retracts system-asserted Observation, Goal, or Problem instances.
2. Actions that have an effect on the CIS (Display, Inquire, Recommend, and Notify). This set includes communication with some CIS agent (e.g. send message, display information, inquire about data) and acts such as placing an order, making a referral, setting goal, providing education, and issuing a personalized order set.
3. An action to generate events (Generate_Event) in the future Sometimes the implementer of a decision-support system may want to deliver guideline recommendations in the form of order sets. The Recommend OrderSet action specification references the appropriate order set and provide ways to custom-tailor the order set for a patient. See the Order Set section for more details.
   
   

One characteristic of a computable guideline model that set it apart from an unstructured or semi-structured guideline document is that it has a formal representation of eligibility criteria and decision criteria that, given a set of patient information, can be evaluated to generate patient-specific conclusions. The computable representation has three components: (1) a model of patient information that defines the structure of data, (2) codified terminologies that allow matching of concepts between an encoded guideline and patient data, and (3) an expression language that defines the syntax and semantics of the decision criteria. For the SAGE guideline model, we adopt the GELLO expression language being developed by the Clinical Decision Support Technical Committee (CDSTC) of Health Level 7 as the foundation of SAGE’s expression models.

GELLO is a generic expression language that can be used with any object-oriented data model. Furthermore, GELLO is a complex string-based language that is not easy to write for someone who is not trained technically. In the guideline model we introduce a number of classes that organize expressions into subtypes of typed data values, variables, queries, functions, and criteria. Except for data types (which are organized in a type hierarchy), each expression class corresponds to a template of stereotypical GELLO expressions. These classes can be used to generate fill-in-the-blanks forms that are much easier to instantiate. These forms also allow us to develop specialized tools to facilitate the use of standard terminologies while writing expressions. The following figures shows an example of a comparison criterion that specifies that the "number of SubstanceAdministration whose code is DTP vaccine equals 0." The valid window attributes allows specification of the time interval during which the search should be made. Not having a valid-window value defaults to ever in the past.

The processes for selecting, disambiguating, and formalizing recommendations from narrative text to these computer-interpretable rules and algorithms are extremely labor-intensive and require close collaboration between content experts and knowledge engineers. Thus, the resource requirement for developing these computable guidelines remains a serious bottleneck for their wide-spread adoption. The SAGE project experimented with a new approach in guideline representation that We formulate a significant subset of the guideline content in a declarative representation format (1) making statements about concepts and relationships with no flow-of-control or behavioral assumptions, (2) stating relatively simple relationship between patient conditions and possible interventions, and (3) that can be authored and maintained by clinician informaticians with minimal training in the modeling tool. These statements can be used as inputs in more abstract and maintainable rules or algorithms for determining the preferred alternatives in guideline-directed decision-making. Furthermore, these statements can be used independently of guidelines to generate targeted alerting or explanation messages in components of an electronic medical record such as order sets.

The SAGE project defines the concept of Evidence Statement that represents a relationship between clinical conditions and interventions and additional contextual information and supporting references. An Evidence Statement encodes a statement such as "In the context of the management of hypertension, presence of heart failure is a compelling indication for the use of ACE inhibitor, with strength of evidence ‘based on randomized controlled trial’ according to the Seventh Report of the Joint National Committee on Prevention, Diagnosis and Management of Hypertension (JNC 7)" (see figure below). The representation made relationships such as Compelling Indication terminological codes that can be values of the relationship property of Evidence Statements. Patient conditions such as presence of heart failure are encoded as Boolean expressions that represent patient states.

These Evidence Statements are declarative in the sense that there are no implied actions or prescribed behavior. Like records in a database, they can be queried using a structured query language. Unlike a database record, however, using these Evidence Statements to provide guideline-directed care requires that conditions (such as presence of heart failure or potentially more complex conditions) be evaluated in terms of available patient data. To solve this problem, the SAGE project defines a query template that allows the specification of queries that return instances of Evidence Statements for which the patient condition evaluates to either true or false. The template follows the structure of the Evidence Statement very closely. The next figure shows a query that is used to find all instances of Evidence Statement for which the following are true:

1. In the context of managing Hypertension (as seen in the statement subject)
2. The condition (such as the Heart Failure shown in Figure 3) is a condition the patient actually has (Condition Present = TRUE)
3. The relationship type to the intervention is Compelling Indication or any relationship subsumed by Compelling Indication
4. The directed intervention is ACE inhibitor Oral Preparation or any drug preparation subsumed by it

Thus, the SAGE project uses a simple query template that significantly eases the encoding burden. These queries are incorporated into decision criteria for evaluating appropriate guideline-directed decisions and actions.

The decision support envisioned in the SAGE project include the use of order sets that are appropriately modified for specific patient situations. Order sets are “orders linked in sequences that can be invoked to generate many orders quickly.” In a complex clinical enterprise, such as inpatient care, order set may be the vehicle through which patient care is coordinated and delivered. In such an environment, it is highly desirable that guideline-based decision support be delivered as part of the enterprise order sets.

To augment order sets with guideline-based and patient-specific decision support, the SAGE guideline model assumes that (1) there is an external collection of reference order sets, each of which is represented in a standard format and (2) SAGE can reference specific items in an order set by their unique ids and offer decision-support services by modifying the content of the order set. Specifically, a SAGE guideline knowledge base may contain logic to:

• Select among pre-defined order sets
• Pre-select an item within an order set if the item is recommended
• Compute patient-specific annotations for those orders.

SAGE project members are leading an effort in HL7 to develop a standard representation for order sets. In this evolving standard proposal, an order set is not merely a collection of orders, but a collection of proposed acts that have been developed and edited to promote consistent and effective organization of health care activity. An order set consists of a selection (ANY or ONE) of order items that are defined by standard-compliant specification of medical or non-medical Order, Observation or Goal to be set. An order item may also be a pointer to an order set, allowing the nesting of order sets within order sets.

Because of the need to compute annotations and to pre-select order set items based on patient-specific information, the representation of order sets in the SAGE Guideline Model correspond to, but is not identical to the proposed standard representation. Thus, in the representation of an item in the order set, the SAGE order item specifies (1) a Boolean pre-selection criterion that, if evaluated to true, pre-select the item as the preferred item in the order set, and (2) one or more decision-support annotations that are custom-tailored according to the conditions of a specific patient. In the following figure, the order set will have its pre-selection flag checked if the pre-selection criterion (Patient is Stage 1 hypertensive) evaluates to true. Associated with the order set is one order-alerting-or-explanation text. The text is dynamically generated and will advice increasing dose if the patient is taking an anti-hypertensive medication at a dose level before the maximum recommended dose. The Boolean connective OR specifies that any of the drugs in the group body may be chosen.

For the SAGE DSS to be integrated in an enterprise CIS, it should not a requirement that the medical knowledge that is already available be duplicated in the SAGE guideline knowledge base. It is neither practical nor desirable to assume that all applicable medical knowledge is part of a monolithic guideline knowledge base. Effective guideline encoding requires that we have well-defined method for accessing medical knowledge outside the guideline model.

The SAGE Guideline Model does not mandate a particular division between knowledge that should be encoded as part of a guideline knowledge base and that should be externally supplied. The division is likely to depend on the guideline and on the application environment. Thus, for example, the Seventh Report of the Joint National Committee on Prevention, Detection, Evaluation, and Treatment of High Blood Pressure discusses indications of various anti-hypertensive agents. The information contained in a generic drug knowledge base may overlap with those described in the guideline.

For accessing external knowledge sources, we adopt the same approach as what we do with querying patient data. That is, we define an information model, called the virtual knowledge base (VKB), analogous to the VMR, that specifies the structure of external information to be queried. In integrating SAGE DSS to a CIS, queries to the VKB have to be translated into queries to the real knowledge source, just as VMR queries have to be implemented in terms of queries into the CIS data source.

The SAGE project validated this approach for accessing external knowledge sources by implementing the VKB for a drug knowledge base. We adopted the drug model defined in the National Drug File - Reference Terminology (NDF-RT). The model contains entities such as ActiveIngredientPreparation, DrugComponent, and ClinicalDrug, where, for example, ActiveIngredientPreparation (e.g. LISINOPROL PREPARATION) has roles such as may_treat, and CI_with (contra-indication with). We assume that entries in the external knowledge source are indexed by a terminology code. Thus, we model ActiveIngredientPreparation, DrugComponent, and ClinicalDrug as extensions of terminological classes in a SAGE knowledge base.

A virtual knowledge-base query (VKB query) has a very simple structure. It has two main attribute: (1) a partially instantiated instance of a VKB class that constrains the properties that the target instances of VKB classes must satisfy, and (2) a selection attribute that determines whether the query should return, when the selection attribute is absent, instances of the VKB class or, when the selection attribute is specified, the attribute values of the VKB instance. For example, a query where we specify (1) an instance of ActiveIngredientPreparation with code equals LISINOPROL PREPARATION and (2) the selection attribute of CI_with is a query for all contraindications of lisinopril.