Knowledge Representation

Knowledge Representation is a multidisciplinary subject that combines theories and techniques from Logic, Ontologies, and Computation [14]. Logic rules provide a formal structure to reason about the veracity and compatibility of statements. For example, if we measure the current body temperature of a patient, and the thermometer indicates 100.2°F, we can apply the rule in (1) to determine whether the patient has a fever or not. Sowa [15] provides an excellent introduction to logical, philosophical and computational aspects of Knowledge Representation.

If patient's temperature > 98.6°F then, the patient has fever. (1)

Ontologies are conceptualizations of a specific domain. Without these underlying conceptualizations, it is not possible to develop data models or schemas to represent such knowledge domains. Representation of knowledge is carried out in terms of objects and the relationships between objects within a domain or application. A vocabulary provides the terms necessary to describe objects, their attributes and behavior, and the relationships between objects. An interesting approach for creation and maintenance of structured clinical documentation is presented in [16]. Without ontologies, it is not possible to represent knowledge coherently. A well-defined ontology will support:

- Coherent and cohesive reasoning

- Sharing of knowledge

- Reusability

Thus, the first step in developing an effective knowledge representation and vocabulary is to perform an ontological analysis of the domain at hand, in terms of:

- Objects that exist in a domain

- Objects that have attributes with values

- Objects have relationships with other objects in the domain

- A characterization or enumeration of the potential states of an object. These states may be modeled as values of one or more attributes

- The value of attributes of objects can change over time

- Events can occur at different times

- Events can trigger other events

- Events can trigger transitions in states

- Objects can belong to one or more classes

- Classes can have generalization and specialization relationships with each other

- Classes can have constraints specified on the values of various attributes

- Axioms that enable complex definition of a class in terms of other classes and constraints on various attributes can also be represented in an ontology

The resulting ontology must capture the intrinsic structure of a domain in terms of concepts and their relationships. For example, let us imagine that in a simplistic clinical domain there are four classes of people: doctors, patients, males, and females. A common way to organize such information would be first to define a human class, with both doctors and patients as types-of human. Similarly, both males and females are also types-of human (Fig. 1).

The first problem that arises with the ontology representation in Fig. 1 is that doctors can also be patients, and patients can be patients at times, but not all the time. This indicates that doctor and patient are not types of humans, but actually are roles that humans can play. Further, male and female are values that gender as an attribute of humans can take. A more appropriate ontological representation for our example is depicted in Fig. 2, with two classes: human and role. Gender is an attribute of the human class. The role class can take one of two possible values: doctor or patient. There is



Fig. 1. An ontology representation depicting the class human and the Doctor, Patient, Male, and Female classes as types-of the class Human



Fig. 1. An ontology representation depicting the class human and the Doctor, Patient, Male, and Female classes as types-of the class Human

Fig. 2. An ontology representation depicting two classes: (1) Human, with the attribute gender, and (2) Role, the relationship has-role indicates the roles a human can play: doctor or patient

also the has-role relationship which connects Human with Role. This conceptualization is similar to that used by the HL7 Reference Information Model (RIM). A section is dedicated to the description of the HL7 RIM core classes used to represent a clinical domain.

A sound knowledge representation is vital if we want to preserve consistency and foster reusability and shareability. One of the advantages of ontologies is that the notation used to represent knowledge is not committed to a particular platform, or implementation. The ontology simply represents knowledge in a logical manner, regardless of the means we choose to implement such knowledge.

Computation supports the development of knowledge-based applications. However, ontologies remain independent from whatever means we choose to implement them. For example, the ontology representation in Fig. 2 could be implemented as a relational or object-oriented database. Similarly, we could choose one programming language over another. None of these choices will affect our representation.

3 Clinical Content

As noted previously, the analysis presented herein focuses on the reference content of two CPOE systems currently in use, at two hospitals: BICS OE and MGH OE. CPOE systems have been designed to support clinical processes, by automating the ordering processes, and providing the clinician with relevant, valuable information at the point of decision making. CPOEs provide real-time decision support for medication errors, dosage error, and adverse drug interactions, known patient allergies, calculate dosages based on the patient, and standardized care [1,2]. The Institute of Medicine report on medical errors has also drawn attention to CPOE systems as a means of reducing errors [17]. Several authors have indicated that the use of OSs derived from best-practice standards reduce errors and improve physicians' acceptance of CPOE systems [18, 19]. Also, OSs help organize the ordering process into structured units of work serving as important elements of clinical decision support, time management, and sharing of clinical knowledge.

Partners Healthcare System OSs are organized by clinical discipline as the main criterion, with secondary indexing keys. Our OS Schema is a composite of orders involving multiple items including header, audit data, indication criteria, clinical setting, intention-action-interaction, target specifics, patient data, knowledge rules, notes and instructions, and order specifics.

Our catalog of orders consists of 24 types including admission, monitoring, nursing, medications, tubes and drains, lines and IVs, Imaging and Rx-Dx, laboratory tests, allergy, consults, diet, wound care, patient activity, discharge procedures, blood products, respiratory, patient preparation, immunization, health maintenance, follow-up, consequent orders, corollary orders, transfer, and others. The OS Schema proposed herein will be described in detail in a subsequent section.

0 0

Post a comment