An OWL Meta-Ontology for Representing the Clinical Element Model

Abstract

The Clinical Element Model (CEM) is a strategy designed to represent logical models for clinical data elements to ensure unambiguous data representation, interpretation, and exchange within and across heterogeneous sources and applications. The current representations of CEMs have limitations on expressing semantics and formal definitions of the structure and the semantics. Here we introduce our initial efforts on representing the CEM in OWL, so that the enrichment with OWL semantics and further semantic processing can be achieved in CEM. The focus of this paper is the CEM meta-ontology where the basic structures, the properties and their relationships, and the constraints are defined. These OWL representation specifications have been reviewed by CEM experts to ensure they capture the intended meaning of the model faithfully.

1. Introduction

The rapid adoption of electronic health records (EHR) provides new opportunities to create semantically interoperable healthcare applications and solutions for evidence-based medicine. One prerequisite for meaningful use of heterogeneous EHR data is a common unified clinical model to ensure unambiguous data representation, interpretation, and exchange within and across heterogeneous sources and applications^[1].

The Clinical Element Model (CEM)^[2,3] was designed to provide a consistent architecture for representing clinical information at EHR systems. The goal of its developers has been to create a model that is robust enough to represent any clinically relevant information in a manner that is approachable by clinicians, friendly for developers, and longitudinally maintainable.

The current CEM model is represented in the Clinical Element Modeling Language (CEML) which is represented in eXtensible Markup Language (XML)^[4]. While XML-based CEML has a formal syntax and grammar that is consumable by computer programs, its specification is based on a collection of naming and design rules that carry implicit assumptions about the intended semantics and has limitations on expressing the “machine-understandable” semantic meanings of domain knowledge^[5,6]. The Semantic Web and its associated recommended specifications^[7], on the other hand, provide standard mechanisms with explicit and formal semantic knowledge representation, and automated reasoning capabilities. The Web Ontology Language (OWL)^[8] is built on formalisms that adhere to Description Logic (DL) and therefore allows reasoning and inference. The Semantic Web Rule Language (SWRL)^[9] can be used to add rules to OWL and enable Horn-like rules that can be used to infer new knowledge from an OWL based ontology and reason about OWL individuals. The Resource Description Framework (RDF)^[10] provides the basis of interoper-ability between applications that exchange machine-understandable information. Different previous efforts have been focused on representing general clinical models or EHR standards such as HL7 v3, openEHR, or ISO 13606 in the Semantic Web environment^[11,12,13].

The main objective of this study is to represent the CEM model in OWL, so that the enrichment with OWL semantics and further semantic processing can be achieved. Figure 1 shows the system overview. We envision a three-layer clinical data representation model in OWL: (1) a meta-level ontology that defines the abstract meta representation of the CEM, where the basic structures, the properties and their relationships, and the constraints are defined; (2) OWL ontologies for representing each individual detailed clinical element model; and (3) patient data represented in RDF triples with respect to the ontologies on layer 2. After representing the CEM as well as patient data in OWL/RDF, we can utilize Semantic-Web tools to check for semantic consistency on both the ontology and the instance levels, and to reason over these data for extracting new knowledge.

Figure 1:

A Graphical View of the Three Layers of CEM OWL Representations

In this paper, we discuss our efforts on the OWL representation of the first layer: the CEM-OWL meta-ontology. These OWL representation specifications have been reviewed by CEM experts (Parker & Oniki) to ensure they capture the intended meaning of the model faithfully. The meta-ontology can be downloaded from the SHARPn web site (http://informatics.mayo.edu/sharp/index.php/CEM_OWL_Project).

The rest of the paper is organized as follow. We first introduce the abstract models in CEM, which define the structure of all the detailed clinical element models. We then discuss the OWL representation of the abstract instance model, by introducing (1) the semantic definitions of different properties in the model, and (2) the semantic definition of each clinical element category as an OWL class. We also illustrate our vision on representing detailed clinical element models in layer 2 with a few examples. We then discuss problems and challenges we encountered during the meta-ontology generation, and summarize conclusions and future directions.

2. CEM Abstract Models Overview

The Clinical Element Model is the combination of an abstract instance model and an abstract constraint model^[3]. The abstract instance model defines the structure of how to represent each clinical model and abstract constraint model defines constraints on values in the abstract instance model. The abstract models provide fundamental structure, relations, and constraints to represent detailed clinical element models. Table 1 shows the abstract instance model specification. The first column contains the properties of the model. The second column describes the types. And the third column defines the cardinality constraints.

Table 1:

Abstract Instance Model Specification from Clinical Model Reference^[2]

Property	Type	Cardinality
type	CNE	1
key	CNE	1
data	CHOICE<CWE, CO, ST, PQ, IVLPQ, RTOPQ, TS, II, INT, REAL, ED>	0–1
atts	SEQUENCE<CEInstance (Attribution)>	0–1
items	SEQUENCE<CEInstance>	0–1
quals	SEQUENCE<CEInstance (Component)>	0–1
mods	SEQUENCE<CEInstance (Modifier)>	0–1
alt	CHOICE<CWE, PQ, ED, ST>	0–1

3. Representation of the Abstract Instance Model

In this section, we introduce how we proposed to represent the abstract instance model as well as the constraints in OWL, which compose the CEM-OWL meta-ontology.

Clinical Element Categories

We defined a root class as the parent class for all the clinical element classes: CEInstance.

Each clinical element may be classified into several structural categories such as statement, panel, component, attribution, and modifier. For each category, we defined an OWL class. We declared that these category-classes are mutually disjoint to each other. Section 4 discusses the detailed OWL representations of these category classes.

For each detailed clinical element model, we can also specify a semantic type, such as physical measurement, lab order, medication, procedure, demographical data, diagnosis, and sign/symptom. We created an OWL class for each semantic type too. This set of OWL classes is also defined as disjoint to each other, so that one detailed clinical element model can only belongs to one semantic type.

Type and Key

A type in the abstract instance model defines the unique name of the corresponding clinical element. In the meta-ontology, we use the type value as the URI for the corresponding class (i.e., “BloodPressurePanel”).

A key for each detailed clinical element model is a coded value which refers to what the model is attempting to describe. Many models in the CEM have key codes from standard terminologies or ontologies, such as LOINC^[14] and SNOMED CT^[15]. We have created an OWL annotation property key to represent the key property in CEM.

Data and Items

The data property in CEM is adopted from HL7 version 3 data types and is used to represent values such as numbers, strings, and codes^[3]. In the OWL meta-ontology, we defined data as a datatype property. The domain of the data property is either SimpleStatement or SimpleComponent (see Section 4 for details). Although the model specification in Table 1 defines the allowed data types for the data property, it basically includes all the data types in allowed the CEM. Since the focus of this paper is the meta-ontology for CEM structures, how to semantically define these HL7 data types using OWL is out of scope of this paper.

The original CEM definition in Table 1 defines that each CEInstance could have zero or one sequence of CEInstances as its items. In OWL, we defined an OWL object property item to associate a clinical element class with its associated sub-clinical-element item nodes. The domain of item is either Panel, CompoundStatment, or Compound-Component(see Section 4 for details). The range of item is CEInstance. An example of a clinical element instance that uses item is “BloodPressurePanel”, which has two sub-statements associated with the item property: “SystolicBlood-Pressure” and “DiastolicBloodPressure”. We also declared an inverse property of item, itemFor, to declare the reverse relation from a sub-clinical-element item node to its parent node, such as “DiastolicBloodPressure” itemFor “Blood-PressurePanel”.

Atts, Quals, and Mods

The Abstract Instance Model uses atts to declare the who, where, why, and when information regarding an action. For example, the model BloodPressurePanel has an attribution called Observed, which describes when, who, where, and why the blood pressure measurement was obtained. In the OWL meta-ontology, we defined an OWL object property, att, for the atts property in CEM. The domain of att is CEInstance and the range is Attribution, We also declared an inverse property attFor to declare the reverse relation from an attribution to its parent node.

The abstract instance model defines qualifiers (quals) and modifiers (mods), to alter or annotate the meaning of the corresponding instance. A modifier alters the meaning of the instance that “one can never use the instance data without considering the effect of the modifier”^[3]. For example, Subject of model HeartRateMeas is a modifier. In this model, the subject (whether it is for fetus or for patient of record) changes the semantic interpretation of the measurement. A qualifier is used to add useful information to an instance but does not change the meaning of the data or items of the instance. For example, the BodyPosition of HeartRateMeas is a qualifier. In this case, whether the patient was sitting or standing during the measurement does not affect the meaning of the measurement itself. In the meta-ontology, we defined two OWL object properties, qual, for connecting a clinical element class with its qualifiers, and mod, for connecting a clinical element class with its modifiers. The domain of qual is CEInstance and the range is Component. The domain of mod is Statement or Panel and the range is Modifier. We also declared two inverse properties modFor and qualFor to declare the reverse relations respectively.

Although the definitions of modifiers and qualifiers seem to coincide with OWL object properties and annotation properties respectively, we believe that it is more appropriate to define qual as an OWL object property instead for the following reasons: (1)the distinction between qualifiers and modifiers sometime might be arbitrary in real use cases, and (2) we can define qualifiers, modifiers, and attributions in a consistent way, which makes it easier for querying and consistency checking in the future.

Alternative Data

The abstract instance model uses the property alts to allow the collection of unexpected or alternatively represented data in an instance. For example, suppose that the data type of SystolicBloodPressure data is defined as numeric values, but the actual value for a particular patient reported to the system is “HIGH”, as a coded value. In this case, the coded value can be placed with the alt property. In the meta-ontology, we defined an OWL datatype property to represent alt.

4. Representation of Category Classes for Clinical Element Type

We have defined five category classes: statement, panel, component, attribution, and modifier. Each category class is designed for representing different kinds of clinical elements. In this section, we introduce the semantic definition of these OWL classes. These semantic definitions can be leveraged by reasoners to ensure the categories are used consistently with what they were designed for and to facilitate clinical modelers to use the right category when defining detailed clinical element models. Table 2 summarizes the semantic definition of each category class.

Table 2:

Semantic Definition of Category-Classes

	Category Class	Description	Semantic Definition
1	Statement	The definition defines a complete assertion	super (SimpleStatement, CompoundStatement); DisjointClasses (all the other category-classes)
2	SimpleStatement	The meaning is conveyed by a single clinical value; defines a complete assertion	subClassOf (restriction (data max 1)); DisjointClasses (all the other category-classes)
3	CompoundStatement	The meaning is conveyed by multiple clinical values (components); defines a complete assertion	subClassOf (restriction (item some Component and item only Component)); DisjointClasses (all the other category-classes)
4	Component	Used only within another constraint type, cannot be persisted alone in the EHR	super (SimpleComponent, CompoundComponent); subClassOf (restriction (itemFor some CEInstance or qualFor CEInstance)); DisjointClasses (all the other category-classes)
5	SimpleComponent	The meaning is conveyed by a single clinical value; cannot stand alone	subClassOf (restriction (data max 1)); DisjointClasses (all the other category-classes)
6	Compound-Component	The meaning is conveyed by multiple clinical values (components); cannot stand alone	subClassOf (restriction (item some Component and item only Component)); DisjointClasses (all the other category-classes)
7	Panel	represents a common grouping of clinical observations	subClassOf (restriction (item only (Panel or Statement)) and (item some (Panel or Statement)); DisjointClasses (all the other category-classes)
8	Modifier	Similar to Component, except can only used with property mods	subClassOf (restriction (modFor some CEInstance)); DisjointClasses (all the other category-classes)
9	Attribution	Similar to Component, except can only used with property atts	subClassOf (restriction (attFor some CEInstance)); DisjointClasses (all the other category-classes)

Statement

A statement in CEM is defined as “a complete assertion about a particular aspect, a characteristic or condition of a patient”^[3]. It can stand on its own in a patient’s medical record. Two types of statements exist: simple statements and compound statements. In OWL, we declared three OWL classes for statements: Statement, SimpleStatement, and CompoundStatement. The Statement class is defined as the superclass of SimpleStatement and CompoundStatement as Row 1 in Table 2 shows. Figure 2 shows the comparison of a simple statement and a compound statement. A simple statement is a statement whose meaning is conveyed by a single clinical value. It associates with data values such as numbers, strings, and codes, rather than items such as other statements, components, or panels. “DiastolicBlood-PressureMeas”, for example, is a single statement model, where it captures the value of the diastolic blood pressure measurement. Row 2 in Table 2 shows how we defined SimpleStatement class in the CEM-OWL meta-ontology. Each instance of SimpleStatement can only have maximally one value associated with its data property. A compound statement is a statement whose meaning is conveyed by multiple clinical values and is dependent on a set of elements with values being interpreted together within the context of the collection. The “Alert” model in CEM, for example is a compound statement, which has multiple components such as alert status, alert event, alert severity, and etc. Row 3 in Table 2 shows how we defined the CompoundStatement class in the meta-ontology. Each instance of Compound-Statement class can only connect to Component instances through an item property, and must have some Component associated with each item property.

Figure 2:

A Simple Statement vs. A Compound Statement

Component

A component is similar to a statement in CEM, except that it can only be used within another CEInstance. A data instance with Component type cannot be persisted alone in the EHR, but must be persisted as an internal part of another data instance with type Statement or Panel. In the OWL ontology, we declared Component as a class, which has a restriction that each instance of the Component class must be either itemFor or qualFor another CEInstance (Row 4 in Table 2). Two types of components exist: simple components and compound components. We declared two additional OWL classes for components: SimpleComponent, and CompoundComponent. The Component class is defined as the superclass of SimpleComponent and CompoundComponent. The definitions of SimpleComponent and CompoundComponent are very similar to the definitions of SimpleStatement and CompoundStatement, with a further restriction that it must be itemFor or qualFor another CEInstance instance (inherited from the Component class).

Panel

A panel represents a common grouping of clinical observations. It is a collection of other statements or panels. For example “BloodPressurePanel” can contain items such as “DiastolicBloodPressure” and “SystolicBloodPressure”. Figure 3 shows a comparison of a panel and a compound statement. Both panels of compound statements can stand alone independently. By definitions, panels are associated with either statements or other panels; but compound statements can only associate with other components. In the OWL ontology, we declared an OWL class Panel with the semantic restriction: for any instance of the Panel class, it must associate some Panel instance or Component instance through the item property; and all the instances associated with its item property must belong to either Panel or Component (Row 7 in Table 2).

Figure 3:

A Panel vs. A Compound Statement

Modifier and Attribution

A modifier is similar to a component, except that it can only be associated with the mod property. We declared an OWL class Modifier with the restriction that it must be associated with some CEInstance through the modFor property. We also declared that the range of the mod property is Modifier.

An attribution is similar to a component, except that they can only be associated with the att property. We have created an OWL class called Attribution with the restriction that it must be associated with some CEInstance through the attFor property. We also declared that the range of the att property is Attribution.

With these semantic assertions we defined above for each category-classes, the reasoner can automatically perform consistency checking to ensure these category-classes are properly used.

5. Example Detailed Clinical Element Models

After the meta-ontology has been specified, we can represent each CEM detailed clinical element model in OWL on top of it. Any detailed clinical element model that belongs to a category should be declared as a subclass of the corresponding category-class. It, therefore, inherits all the semantic definitions of its parent classes. Figure 4 shows examples of “BloodPressurePanel” and its associated elements¹.

Figure 4:

Example Detailed Clinical Element Models Represented With Respect to the CEM Meta Ontologies

The left box in Figure 4 shows an example of Panel. Class “BloodPressurePanel” has a key “BloodPressurePanel KEY ECID”. It is a subclass of Panel and PhysicalMeasurement. We specified that each “BloodPressurePanel” can have maximally one attribution as “Observed”, one modifier as “Subject”, one item as “DiatolicBloodPressure” and one item as “SystolicBloodPressure”. The representation shown in Figure 4 does not enforce the permissible elements of the properties. If preferred, we can also further specify the permissible elements. For example, we can declare the “BloodPressurePanel” class as a subclass of “item only (DiatolicBloodPressure or SystolicBloodPressure). This way we ensure that any instance of “BloodPressurePanel” can only connect to instances of either “DiastolicBloodPressure” or “SystolicBloodPressure” through its item property. With these semantic assertions, a reasoner can performance automatic consistency checking. For example, if an instance of BloodPressurePanel has more than more items has SystolicBloodPressure, the system would throw an error.

The right two boxes in Figure 4 show one example of attribution (upper right) and one example of simple statement (lower right). Similarly, they each are declared as a subclass of the corresponding category-class. Further semantic assertions are also defined based on the specific definitions of the two elements.

6. Discussion

In section 3, we introduced how we use OWL annotation properties to define keys for each clinical element. A new annotation property called key has been defined for this purpose. There has been a debate, however, on whether to use annotation properties or object properties to represent a referenced code of a given class^[11]. OWL annotation properties simply serve as human-readable labels. It does not provide semantic assertions for reasoners. If we choose to use object properties to represent key, on the other hand, we can leverage the semantic definition of the referenced concepts (i.e., a SNOMED CT concept). In the current meta-ontology, we use the annotation property option as a simple solution. But we can choose to switch to the object-property option in the future if it is preferred. In addition, to ensure semantic harmonization with W3C recommendations, we need to further specify the relations between the key property and W3C specifications. skos:related ^[16], for example, is designed to assert an associative link between two concepts. We can specify that the CEM key property as a sub-property of skos:related.

In the meta-ontology, we have defined a set of OWL properties to connect parent nodes with their items, qualifiers, modifiers, and attributions. The example in Figure 4 shows one way to represent detailed clinical element models in OWL with respect to the meta-ontology. We use the properties defined in the meta-ontology themselves to connect any class and its description nodes (i.e. “BloodPressurePanel” item max 1 “SystolicBloodPressure”, or “DiastolicBloodPressure” att max 1 “Observed”). Another option is to create customized properties for each different kind of description nodes. For example, we can create an object property called hasSystolicBloodPressure, which is a sub-property of item. We then can define the connection as “BloodPressurePanel” hasSystolicBloodPressure max 1 “SystolicBloodPressure”. The benefits of doing so are: (1) better human-readability, and (2) more straightforward for querying. But it will also bring interpretability and performance issues because it requires creating more customized properties.

We use subClassOf relations when asserting the semantic definition of each class in the meta-ontology. A statement ClassA subClassOf (restrictionB) indicates that any instance of ClassA must satisfy restrictionB, but not the other way around. Alternatively, we could use equivalent class ClassA equivalent (restrictionB) to define the assertions. In that case, the restriction becomes a necessary and sufficient condition of the class (any instance satisfying restrictionB belongs to ClassA too). We believe the “equivalent class” option makes the definition too strict and sometimes may lead to semantic definitions which are not necessarily true. Therefore, we chose to use subclass in the meta-ontology to define the assertions.

For properties item, mod, qual, and att, we also defined their inverse properties (itemFor, modFor, qualFor, and attFor), respectively. OWL’s formal semantics are defined on a set-theoretical foundation, in which an inverse relation cannot be logically inferred between the domain and range of a given relation. For example, A item B does not necessarily mean B itemFor A, although item is defined as the inverse property of itemFor. Therefore, when defining each detailed model, we need to specifically state assertions in both directions, to ensure the semantics are captured. An OWL reasoner would not infer them automatically.

7. Conclusion and Future Work

In this paper, we introduce our initial efforts on representing the Clinical Element Model (CEM) using OWL. An OWL meta-ontology has been created to represent the structure, properties, and constraints described by the CEM abstract instance model. This ontology has been evaluated by CEM experts to ensure that it can represent the model faithfully. After representing the CEM as well as patient data in OWL/RDF, we can utilize Semantic-Web tools to check for semantic consistency on both the ontology and the instance levels, and to reason over these data for extracting new knowledge.

Several directions remain to be pursued. We will work on representing the HL7-based data types used by the CEM using both OWL 1.1 and the new OWL 2.0 data range definition features. We will implement a convertor which can automatically convert the current detailed clinical element models definitions to OWL ontologies with respect to the meta-ontology specifications. We then can represent patient instances in RDF and develop applications on top of this data to leverage the semantic-web reasoning and storage mechanisms. In addition, we will also investigate the possibilities of aligning the meta-ontology with existing top ontologies in the domain such as the Ontology for General Medical Science (OGMS, http://code.google.com/p/ogms/) and the Vital Signs Ontology (VSO, http://code.google.com/p/vital-signs-ontology/).