Embedding the Guideline Elements Model in Web Ontology Language

Abstract

The Guideline Elements Model (GEM) uses XML to represent the heterogeneous knowledge contained in clinical practice guidelines. GEM has important applications in computer aided guideline authoring and clinical decision support systems. However, its XML representation format could limit its potential impact, as semantic web ontology languages, such as OWL, are becoming major knowledge representation frameworks in medical informatics. In this work, we present a faithful translation of GEM from XML into OWL. This translation is intended to keep the knowledge model of GEM intact, as this knowledge model has been carefully designed and has become a recognized standard. An OWL representation would make GEM more applicable in medical informatics systems that rely on semantic web. This work will also be the initial step in making GEM a guideline recommendation ontology.

Introduction

The current healthcare environment is characterized by substantial practice variation [1, 2, 3] - much of which is inappropriate - and by serious deficiencies in the delivery of recommended care [4]. Practice guidelines constitute an important modality that can reduce the delivery of inappropriate care and support the introduction of new knowledge into clinical practice [5]. Moreover, since guideline knowledge represents a distillation of research findings combined with the judgement and experience of clinical experts, guidelines can serve as an up-to-date knowledge source for clinical decision support tools. As part of the ERGO project (Effective Representation of Guidelines with Ontologies) we are working to develop efficient systems whereby valid medical knowledge - such as that contained in practice guidelines - can be operationalized in systems that support decision making by clinician.

The Guideline Elements Model (GEM) aims to better represent the heterogeneous knowledge contained in practice guidelines [6]. GEM has been the subject of considerable interest and applications and has become the leading exemplar of document-centered guideline knowledge representation [7]. Important applications of GEM are in the areas of computer aided guideline authoring and clinical decision support systems [8, 9, 10, 11, 12, 13]. GEM has been standardized as an ASTM E2210-06. GEM was designed to be comprehensive, expressive, flexible, comprehensible, sharable, and resuable. GEM is conceived as hierarchy with more than 100 elements. Top level elements relate to a guideline’s identity, developer, purpose, intended audience, method of development, target population, knowledge components, testing, and review plan (Figure 1). Knowledge components in guideline documents include recommendations (which in turn comprise conditionals and imperatives), definitions, algorithms and background information.

Figure 1:

Top level of GEM hierachy

Semantic web ontology languages are becoming major knowledge representation frameworks in medical informatics. Ontological languages are more expressive than XML, particularly in capturing relationships between knowledge elements. An ontological representation of guideline elements would further enhance the model’s expressiveness, flexibility and reusability. Thus there is value for putting GEM in an ontological modeling framework such as OWL [14]. A good example of such application can be seen from the works by Abidi and colleagues [11, 12]. These authors used GEM to represent clinical guideline knowledge in their decision support system. Since GEM had been designed and is available only in XML formalism [15], they had to come up with an adhoc conversion of GEM into OWL.

In this work, we present a translation of GEM into OWL, which will be named GEOWL (for Guideline Elements in OWL). This work is intended to be an initial step in making GEM a guideline elements ontology. We aim to keep the knowledge content of GEM as intact as possible in GEOWL, since GEM is now an ASTM standard. By having GEM in OWL, we hope to faciliate further application of this knowledge model in state-of-the-art medical decision support systems.

Guideline Elements in OWL

GEOWL can be considered as a simple ontology. This ontology defines the concepts in the clinical guideline domain and the relationships between them. In the following, we describe the content of GEOWL, namely its classes, their properties and relationships.

Classes and properties

The classes of GEOWL are intended to represent the same concepts embodied in GEM elements. Detailed descriptions of the GEM elements can be found in [6, 16]. Let us consider an example of a GEOWL class - the GuidelineDocument class. The properties of GuidelineDocument represent the sub-elements of the corresponding root GuidelineDocument element of GEM. The element Identity is a sub-element of the element GuidelineDocument, thus the class GuidelineDocument has a property named identityOf. The property identityOf maps from the domain GuidelineDocument to the range Identity (Figure 1 and 2).

Figure 2:

Slot structures of the class GuidelineDocument (drawn with Ontoviz plug-in of Protege editor).

There are usually constraints (such as cardinality constraints) on class properties. However, GEM was designed to be as general as possible, thus there exists no constraint on GEM elements, except for the top level elements. As GEOWL aims to be as close as possible to GEM, we have not defined additional constraints on the properties in GEOWL. In future development, we intend to define additional constraints to better capture the knowledge content of classes. For example, we may enforce that a GuidelineDocument must have unique Identity.

Relationships

In the XML formalism, the relationships between the GEM elements are primarily represented as part-whole relationships. Most of these relationships can be translated into properties in GEOWL. However, there are exceptional cases where they are better characterized as is-a relationships in GEOWL. We now discuss these cases in detail.

Exception 1. Conditional and Imperative is-a Recommendation.

The most interesting and important case is the relationship between Recommendation and Conditional or Imperative. The is-a nature of these relationships is evident from their GEM description [6], which states that:

• Recommendation is a “statement of appropriate practice and the conditions under which it is to be undertaken. The statement is intended to influence practitioners’ behavior and/or patient outcomes. A number or brief title for a specific recommendation should be stored in this element”.

• Conditional is a “recommendation applicable under circumstances specified by an if-then statement. The complete text of the conditional statement should be stored in this element”.

• Imperative is a “recommendation directed at the entire target population without limitation. The complete text of the imperative statement should be stored in this element”.

Moreover, the GEM hiearachy suggests that an Imperative element can be considered as a Conditional element without a Decision Variable. Particularly, we observe that in the GEM hierarchy:

• Conditional and Imperative elements both contain the following elements: Reason, Evidence-Quality, RecommendationStrength, Flexibility, Logic, Cost, Goal, Link, Reference, RecommendationEvidenceLinkage, Certainty.

• Conditional contains the Action element, while Imperative contains the Directive element. These two sub-elements actually represent the same concept, which is further described by information about benefit, risk and harm, description, cost, value and type.

• Conditional contains the additional DecisionVariable element.

Thus we have merged the common knowledge contents of Conditional and Imperative into the content of Recommendation. Imperative is now a Recommendation without additional attributes. Conditional is now a Recommendation with an additional attribute DecisionVariable.

Exception 2. PatientResource, TechnicalReport and QuickReferenceGuide is-a CompanionDocument.

According to the GEM definition:

• CompanionDocument is a “concise document that summarizes guideline recommendations for clinicians”.

• PatientResource is a “patient-oriented summary of guideline content or a resource intended to assist patients with guideline application”.

• TechnicalReport is a “document or document component that describes in detail the method of guideline development”.

• QuickReferenceGuide is a “concise document that summarizes guideline recommendations for clinicians”.

Exception 3. EvidenceQualityRatingScheme and RecommendationStrengthRatingScheme is-a RatingScheme.

According to the GEM definition:

• RatingScheme describes “criteria for rating quality of evidence and/or strength of recommendation”.

• EvidenceQualityRatingScheme describes “criteria for rating quality of evidence”.

• RecommendationStrengthRatingScheme describes “criteria for rating strength of recommendation”.

Exception 4. InclusionCriterion and Exclusion-Criterion is-a Eligibility.

According to the GEM definition:

• Eligibility describes “the population that the recommendations are intended to affect; identifies restrictions on guideline use such as within a managed care organization or geographic region”.

• InclusionCriterion is “a criterion whose presence is necessary for the guideline recommendations to be applicable”.

• ExclusionCriterion is “a criterion whose presence excludes the applicability of the recommendation”.

Exception 5. Recommendation, Definition, BackgroundInformation, ResearchAgenda and Algorithm is-a KnowledgeComponents.

In GEM, the element KnowledgeComponents does not come with a definition. It was designed as a technical element, acting as a wrapper for its sub-elements. Thus the conversion from XML part-whole relationships to is-a ones is appropriate in this case.

Exception 6. Sensitivity, Specificity and PredictiveValue is-a TestParameter.

According to the GEM definition:

• TestParameter is “information about the quality of a decision variable”.

• Sensitivity is an “indication of the probability of the decision variable being present under specific clinical circumstances”.

• Specificity is “an indication of the probability of the decision variable being absent under specific clinical circumstances”.

• PredictiveValue is “an indication of the probability of an outcome occurring when a particular value of the decision variable is present”.

Note that we do not have complex hierarchy of inheritance in GEOWL. Our main goal in this work is to transform GEM into ontological framework. GEM has been designed specifically to model the textual content of guideline documents, not their high-level knowledge content. Naturally, one can expect only simple inheritance relationships between these textual contents. Nevertheless, GEOWL is an essential first stept towards the construction of an ontology of guideline documents that supports representation and inference with high-level guideline knowledge.

Translation Procedure

General translation rules

We call a guideline element of GEM complex if it contains at least one other guideline element. If a guideline element contains no other element, it is called atomic. GEOWL is constructed from GEM by the following rules.

• Rule 1. For each guideline element in GEM, there exists a class in GEOWL with the same name.

• Rule 2. Let a complex guideline element Some_Complex_Element contain an element Some_Sub_Element in GEM. Then the class Some_Complex_Element of GEOWL has a property named some_Sub_Element_Of. The domain of this property is the class Some_Complex_Element. The range of this property is the class Sub_Element.

• Rule 3. The class of an atomic element does not have any property.

• Rule 4. The cardinality of a GEOWL properties of the class GuidelineDocument is 0 or 1.

Importation of GEM element definitions

Most of GEM elements come with a precise definition. For example, the definition of GuidelineTitle is represented in the XML schema as follows.

<xs:element name="GuidelineTitle"

type="GemBasicType">

  ...

  <xs:annotation>

    <xs:documentation>

      Complete title of the guideline

    </xs:documentation>

  </xs:annotation>

  ...

</xs:element>

In GEOWL, GuidelineTitle element is translated into class GuidelineTitle and a property guidelineTitleOf. The definition can be stored in GEOWL using <rdfs:comment>

<owl:ObjectProperty

rdf:ID="guidelineTitleOfIdentity">

  ...

  <rdfs:comment rdf:datatype= ...

    Complete title of the guideline

    </rdfs:comment>

    ...

  </owl:ObjectProperty>

Discussion and Conclusion

As we have learned from previous work on GEM, the building of a full scale guideline elements ontology, even with GEM as the starting point, would be a major research challenge. We have decided to follow an incremental approach. This work is aimed to be the first step in transforming GEM into a complex ontology of clinical guideline knowledge.

The knowledge model of GEM has been translated into GEOWL as faithfully as possible. As XML is not a knowledge representation formalism, certain XML-based aspects of GEM needed to be modified in the course of translating them into better OWL constructs. Particularly, some part-whole relationships between GEM elements would be better represented as is-a relationships. Such refinements illustrate multiple values of this ontological design effort.

In terms of future work, we plan to extend GEOWL with an ontology of action-types. The action-type ontology will expand recommendation classes to a stand-alone ontology and will serve as a backbone for our guideline authoring tools. We also plan to support more rigorous validation of guideline modles using ontological constraints.

Figure 3:

Isa relationships of Recommendation

Figure 4:

Isa relationships of CompanionDocument

Figure 5:

Ontological relationships of RatingScheme

Figure 6:

Ontological relationships of Eligibility

Figure 7:

Ontological relationships of KnowledgeComponents

Figure 8:

Ontological relationships of TestParameter