Comparing computer-interpretable guideline models: a case-study approach

Abstract

Objectives: Many groups are developing computer-interpretable clinical guidelines (CIGs) for use during clinical encounters. CIGs use "Task-Network Models" for representation but differ in their approaches to addressing particular modeling challenges. We have studied similarities and differences between CIGs in order to identify issues that must be resolved before a consensus on a set of common components can be developed.

Design: We compared six models: Asbru, EON, GLIF, GUIDE, PRODIGY, and PROforma. Collaborators from groups that created these models represented, in their own formalisms, portions of two guidelines: American College of Chest Physicians cough guidelines [correction] and the Sixth Report of the Joint National Committee on Prevention, Detection, Evaluation, and Treatment of High Blood Pressure.

Measurements: We compared the models according to eight components that capture the structure of CIGs. The components enable modelers to encode guidelines as plans that organize decision and action tasks in networks. They also enable the encoded guidelines to be linked with patient data-a key requirement for enabling patient-specific decision support.

Results: We found consensus on many components, including plan organization, expression language, conceptual medical record model, medical concept model, and data abstractions. Differences were most apparent in underlying decision models, goal representation, use of scenarios, and structured medical actions.

Conclusion: We identified guideline components that the CIG community could adopt as standards. Some of the participants are pursuing standardization of these components under the auspices of HL7.

Figure 1.

Arezzo’s graphical view of the cough guideline encoding in PROforma. The top-level cough guideline is shown on the top left. The two inserts show nesting of the two plans of the top-level guideline. The scheduling constraint in the top-level guideline states that the component “Investigations” should not be executed until the component “CXR and initial treatment” has completed.

Figure 2.

Expressing intentions in Asbru. The “hypertension-treatment” plan’s intention is achieving an overall state of normal systolic blood pressure within 1 month of the plan’s execution.

Figure 3.

A Cough data item in GLIF is defined by a concept whose code is taken from UMLS (right) and by an HL7 RIM Medication class (lower part of figure).

Figure 4.

The PRODIGY choice model. Note the rules for and against giving diuretics to a patient who is already on an ACE inhibitor. The “rule in condition” expresses strong preference for an alternative. The “greyed in condition” is a possible argument for the alternative. The “greyed out condition” is an argument against the alternative. The “rule out condition” is a rule excluding the alternative. The rule in and rule out conditions are objects that include formal criteria that can be evaluated against patient data and natural language descriptions of the criteria. The figure shows only the natural language form. If none of the conditions apply, one alternative can be marked “preferred” by default.

Figure 5.

Criteria languages in EON. (a) A template query for a presence criterion that checks for pregnancy in note entries dating up to nine months before the current date. (b) A first-order logic criterion that checks if an ACE Inhibitor is not contraindicated. (c) A temporal query that checks whether four weeks have passed since the administration of an ACE inhibitor.

Figure 6.

Mapping guideline data items to EMRs in the GUIDE model. The description column gives the name of the data item that guidelines use (Guidelines column). The three other columns are related to the EMR; each code is unique for that attribute. If possible, it is the SNOMED code. Data Type is the data type of the attribute, and Table name is the name of the EMR table where the attribute value is stored.