Fei Song & R. William Soukoreff (1997). Graphical Interface to a Semantic Medical Information System. Journal of Foundations of Computing and Decision Sciences, 22(2).

A Graphical Interface to a Semantic Medical Information System

Fei Song & R. William Soukoreff

Department of Computing and Information Science
University of Guelph
Guelph, Ontario, N1G 2W1, Canada
Abstract
This paper reports an electronic implementation of medical problem lists for the Ontario Veterinary College (OVC) at the University of Guelph. Our main objective is to improve the acceptability of the system by directly supporting a high-level semantic domain model, along with an innovative graphical interface.

Our semantic model has three useful features: a taxonomy of problem classification that supports efficient retrieval of patient information; a hierarchical organisation of problems that shows the explicit relationships between low-level problems and high-level diagnoses; and a set of time labels for indicating the changes of a problem over time. The model seems to capture the way medical problems are used by physicians, allowing them to describe their opinions at a natural level of abstraction, to an arbitrary level of detail, or even with the context of their observations.

We implement our semantic model on an object-oriented framework, since we need to represent not only the explicit relationships between problems, but also free-format text for extended problem descriptions and time labels for the different versions of a problem. We further provide a graphical interface for the ease of input and access of patient information. The interface supports direct manipulation and full-view display, allowing a user to change search parameters by simply manipulating the corresponding icons and see all the effects immediately in a full-view display. We are currently implementing a prototype to study the feasibility of our system, and the initial feedback from our domain experts and a small number of potential users has been encouraging.

1. Introduction

Electronic medical records are becoming increasingly important in medical practice and research because they improve the efficiency, quality, and availability of patient information. Although considerable work has been done in this area (Rector, et al. [5]), many systems fail to be accepted and used by the real people they were designed to benefit. Simply applying usability techniques is often not enough, since if the underlying domain model is too complex or difficult to learn, users may still reject the system. Our solution is to ease the interaction between a user and the system by directly supporting a high-level semantic domain model, along with an innovative graphical interface.

Our focus is an electronic implementation of medical problem lists for the Ontario Veterinary College (OVC) at the University of Guelph. A problem list is considered to be the core component of a medical record in the framework of Problem Oriented Medical Record [9], since it helps organise other medical information such as examination results and treatment plans. To test our implementation, we have chosen the specific domain of canine heart disease, with the intention of expanding to a wider range of medical problems in future.

1.1. Problems and Problem Lists

As defined in Walker [9], a problem can be anything that calls the attention of a clinician: an illness, a medical condition, or any other condition that requires diagnosis or medical management or that interferes with the quality of a patient's life. A problem list is simply a list of medical problems.

The current practice at the OVC is to record patient information on paper and organise problems into a number of linear lists. The most important of them is the master problem list, which is completed last and is intended to be a comprehensive listing of all the problems that have affected or are affecting a patient. Although physicians are required to write down the problems each time they examine a patient, there are many forms to fill in so that the master problem list is often not properly updated. As a result, it becomes difficult to traverse, read, and understand the patient records.

1.2. Usability

By storing problems electronically, it will be possible to retrieve relevant information quickly. Problems only need to be entered once and can be organised properly, making it easy for the physicians to produce any detailed records.

However, like many other computer solutions there are potential pitfalls that must be avoided in order to achieve success. Many researchers have attempted to apply the latest database and usability techniques (see Brown [1] and Shneiderman [7]) to produce systems which were capable of storing and retrieving the necessary information. Unfortunately, most of the systems failed to be accepted by real users. One important reason is due to the heavy cognitive load which the physicians incur as they first use these systems. Anyone who uses a computer system, whether knowingly or not, must map "cognitively" what they know and what they want to a form that is acceptable to the computer. However, physicians are often not interested or too busy in learning the details of a computer system, especially, in learning how to translate their understanding of a patient's medical conditions into a form that the computer can digest.

We believe that the key to the success of a medical information system is to reduce the semantic distance between the way physicians think and how the computer stores and processes patient information. The difference of semantic distance can be clearly illustrated by considering the description of an arithmetic expression. It is far simpler to write such an expression in a high-level computer language than in a low-level assembly language. A good indication for a low-level domain model is that after intensive training and practice, the users continue to make many mistakes. To avoid this as much as possible, a high-level semantic model that reflects how the user perceives and processes the necessary tasks is required. Such a high-level model forms the basis for an intelligent interface (Chignell and Hancock [2]) and when used with other usability techniques will greatly help us to produce an acceptable system.

2. The Semantic Model

Through a series of interviews with our domain experts, we have found that physicians typically follow two steps in dealing with patients. The first step is to form one or more diagnoses based on the signs and symptoms reported about the patient. The second step is to provide an appropriate treatment for the possible diagnoses. Accordingly, physicians also consider problems in two different ways. When diagnosing a patient, they think of problems in terms of related groups, and it is by considering different groupings of problems that different possible diagnoses are uncovered. Once a reasonably small set of possible diagnoses are made, they then consider the diagnoses themselves, devising tests to determine the likelihood of diagnosis, and eventually applying the appropriate treatment.

Relating problems into groups is an integral part of the mental process for physicians. This suggests that our semantic model would not be effective if we failed to provide support for recording and retrieving of the groupings that physicians use. Our investigation has shown that physicians use two major criteria to group problems:

In a different vein, we have seen that problems are dynamic in nature: while the current state of a problem may change over time, the previous (or outdated) states of the problem must also be recorded, both because it is a legal requirement and because the history of a problem can be a useful clue to physicians.

In response to the different ways physicians seem to use in grouping problems, and to the needs of capturing the changes of data over time, we have proposed a semantic model that has the following useful features:

The readers are also referred to Song and Soukoreff [8] for the discussion of our early work on the semantic model.

2.1. The Problem Taxonomy

As defined previously, a problem is a dynamic entity which corresponds to a condition that requires medical attention. There are several classes of problems which may be observed, such as major versus minor problems, active versus completely cured problems, and so on. We found in our investigation that many physicians had personalised notations which they used to impart some of this information into their problem lists. Additionally, problems could be usefully delineated according to whether they were currently being treated or not. Lastly, there is a need (both legal and administrative) to mark those problems which are uncertain or have been found to be incorrect. Thus, as the first feature of our semantic model, we provide the following taxonomy as a recommended standard for categorising different problem descriptions:

Status:
Resolved, Active, Inactive

Severity:
Major, Minor, Inconsequential

Activity:
Being-Treated, Not-Being-Treated

Sureness:
Verified-Correct (≥90%), Likely (≥50%), Unlikely (≥25%), Verified-Incorrect (0%)

The taxonomy consists of four independent axes, each of which is assigned one of the set of mutually exclusive labels. All of the four axes should be used to describe a problem. For example, a problem may be labelled as Active, Major, Being-Treated, and Verified-Correct. A Resolved problem refers to the condition that used to affect a patient, but does not any more. An Unresolved (or On-Going) problem is either Active (currently affecting the patient), or Inactive (in remission with the possibility of appearing again in the future).

In addition, we add percentage ranges to the sureness axis to further quantify the degree of uncertainty for each of the labels in that category.

The taxonomy allows us to apply common database techniques to search efficiently all the problems which satisfy some general criteria. For example, finding all the Active problems, all the Major problems, or all the Major and Active problems. In particular, it should be possible to build dynamically a list of the current problems that a patient is suffering from, or any other subset of the problem list required by a physician.

2.2. Hierarchical Organisation of Problems

One of the major drawbacks for the linear organisation of problems is that it fails to indicate explicitly the relationships between problems. Our investigation has revealed that physicians rarely view each problem in isolation; instead they naturally group certain problems together through abstraction relationships. More specifically, they attempt to find a reasonable set of diagnoses which explains the symptoms exhibited by the patient, by relating initial problems to general problems, which are further related to even more general problems, and eventually to diagnoses. Thus we propose that a hierarchical organisation should be used for representing the set of problems that comprises a patient's problem list.

A typical hierarchical organisation for a problem list is shown in Figure 1. Each node corresponds to a medical problem, and each link from right to left represents an abstraction relationship. At the lowest level on the right are the most fundamental description of the problems, such as signs and symptoms. Higher levels of problems are added as the physician continues the investigation of the patient. Ideally, the leftmost nodes should be some very general problems or perhaps diagnoses. Note that Figure 1 is actually a directed acyclic graph, not quite a tree structure, since some low-level problems can be related to more than one general problem. There is no limit to the number of levels that can be put in a problem hierarchy, but we have found that three to four levels are usually adequate for most records.

Figure 1: A typical hierarchical organisation for a problem list.

A hierarchical organisation is directly useful because by making the relationships between problems explicit, we are able to capture the way a problem list is actually used in practice. A hierarchical organisation is flexible in that it reflects multiple levels of resolution concerning the condition of a patient. As a result, physicians are able to describe their opinions at a natural level of abstraction, to an arbitrary level of detail, or with the context of their observations. All of these requirements are absolutely essential to ensure a faithful and efficacious recording of patient information.

2.3. Time Labels

Since a patient's conditions and a physician's understanding often change over time, updates of problem descriptions are almost inevitable. However, it is sometimes useful to the physician to see past (out of date) information. Walker [9] suggests that two essential requirements of any Problem Oriented Medical Records are permanence and completeness; so it seems that old problem descriptions cannot simply be deleted. Although a hierarchical organisation helps to show the relationships between problems, the intuitive appeal will be decreased or even lost if it is cluttered with too much outdated information.

Thus, as the third feature of our semantic model, we distinguish between the multiple versions of a problem by applying a set of time labels so that any changes to either the problems within the problem list, or to the interrelationships between the problems can be explicitly recorded and time-stamped.

A typical version graph for a heart murmur problem is shown in Figure 2. The concept of a version of a problem is similar to that of a version of an object in modern object-oriented database systems (Kim [3] and Sciore [6]). Each problem is associated with an abstract version, which contains time-independent properties. All other versions are time-dependent and are labelled by the dates and/or times they are created. Changes from one version to the next version are indicated by the derived-from relationship. The current data concerning a problem is contained within the version with the most recent time label. No information is ever "thrown away"; it is instead retained in the form of previous versions of the problem. Essentially, a version graph records the evolution process of a problem description. For example, the version graph in Figure 2 depicts the transition of a patient's systolic heart murmur as it is monitored over three visits, increasing in magnitude from a Grade 1 murmur to a Grade 5 murmur.

Figure 2: A typical version graph indicating the changes to a heart murmur problem.

In summary, our semantic model for problem lists includes a collection of patient records; each patient record contains a series of snapshots of the patient's conditions at different times; each snapshot is a hierarchy of problems and their relationships; and each problem is identified by labels along four different axes, status, severity, actions, and sureness. Any implementation of our model should support retrieval of information at these different levels, as well as an easy-to-use interface.

3. Implementation and the Graphical Interface

3.1. Object-Oriented Implementation

We implement our semantic model on an object-oriented framework, since the popular relational approach does not allow multi-level organisation of and explicit relationships between problems; nor does it provide the time-stamps needed for indicating different versions of a problem. An object-oriented implementation also supports free-format text fields and other useful features that are beyond what is offered by the current relational method.

3.2. The Graphical User Interface

In order to compete with paper records, any implementation should provide a user-friendly interface for easy input and access of patient information. Current research has shown that computer record keeping is often not much quicker than that of paper records. As described by Nygren and Henriksson [4], a paper record consists of a set of documents that are arranged in a specific order. These documents usually have different shapes and colours, which allow physicians to overview and browse through a large number of pages very quickly. The speed with which the relevant parts of the file can be found is staggering, and the amount of information covered in a glance is enormous.

We propose that a graphical interface that supports direct manipulation and full-view display (as described in Shneiderman [7]) is best suited for our implementation. Such an interface allows the users to change search parameters by simply manipulating the corresponding icons and see all the results immediately in a full-view display.

3.2.1. Screen Design for Patient Selection

It is illuminating to consider what an implementation of a problem list should look like in a graphical interface. Recall that our semantic model organises patient information into multiple levels. At the highest, database-wise level, we have a collection of patient records, each corresponding to a patient object in our object-oriented implementation. The typical search at the this level is to look for those patients that satisfy a set of search constraints. This lead us to design the first screen "OVC - Patient Selection" in figure 3.

Figure 3: A Linear view at the database-wide level.

As can be seen, the screen is divided into two panels: the one on the left is the search panel, where the user enters or selects a set of parameter values, and the one on the right is the output panel, where all the search results are displayed.

To accommodate different groups of users, we provide three separate modes for the search panel. The BASIC mode supports patient-oriented searches, and can be used by physicians to quickly locate the record of a particular patient. The INTERMEDIATE mode supports problem-oriented searches, and can be used by researchers to find all the patients who are suffering a particular problem during a particular time period. The ADVANCED mode supports command-line queries, and allows users to perform the most sophisticated searches.

Further, depending on different interests of users, we provide three separate views for the output panel. The LINEAR view shows a list of the searched patients, each on a separate line with a brief description about the patient. The SPATIAL view shows the distribution of the searched patients, each as a lighted spot on the map of a particular geographical region. The TEMPORAL view shows the searched patients as a sequence of vertical bars, each for a time interval with the height of the bar indicating the number of patients and each slice of the bar representing a particular patient. (Shown in figure 3 is the "OVC - Patient Selection" screen with BASIC mode and LINEAR view). All the views allow us to see the quantity of the searched patients, and at the same time, to locate a particular patient (either as a separate line, or as a lighted spot, or as a slice of a bar).

3.2.2. Screen Design for Problem Lists

By clicking the icon for a particular patient in the "patient selection" screen, we can get to the middle, patient level of our semantic model. At this level, the typical search is to gather all the problems about the patient, determine how they are related to each other, and examine how they are changed over time. Figure 4 shows our screen design for "OVC - Problem List". Near the top of the screen is a summary of the patient profile, including such information as the patient ID number, the owner's name, and the patient's name. In the middle is the display area showing a hierarchy of the problems that the patient is suffering at a particular time. This roughly corresponds to the current problem list in the OVC domain, with the time explicitly indicated in the date control near the top of the screen. Users can change the date in the date control to see the current problem list at the different times. They can also browse through the entire hierarchy by adjusting either the scroll bars to see the different parts or the zoom control to reduce or enlarge the size of the hierarchy. Finally, at the bottom of the screen is an explanation of the colour code used for indicating the status of a problem (either active, inactive, or resolved). Users can also point the cursor to a particular problem for a brief summary of the other attribute values such as severity, activity, and sureness.

Figure 4: A Hierarchical view at the patient level.

The above screen design shows a SPATIAL view for problem lists, since it allows us to see a series of snapshots about a patient, and for each snapshot, a hierarchy that explicitly indicates the relationships between the problems at a particular time. To view the changes over time, we also provide two other views for the problem list. Shown in figure 5 is the LINEAR view, which displays all the problem descriptions and their updates in the order they are entered into the system. This roughly corresponds to the master problem list in the OVC domain, and the updates for each visit are separated by different lines. The last view (not shown here) is the TEMPORAL view, which displays a chronological sequence of nodes for different visits, and further for each visit, displays a list of problems that are newly entered or updated.

Figure 5: A Linear view at the patient level.

3.2.3. Screen Design for Problem Descriptions

Note that for all the views of problem lists, we can locate a particular problem or its update, and by clicking its corresponding icon, we can get to the lowest, problem level in our semantic model. At this level, we want to see all the details of a particular problem. Shown in figure 6 is our screen design for "OVC - Problem Description", which displays all the information about a problem at a particular time. Similar to the previous two screens, we also provide two other views. The LINEAR view shows a list of updates over time in the order they are entered into the system, and the TEMPORAL view shows a chronological sequence of those visits, for which the problem is updated.

Figure 6: A Specific Problem.

3.2.4. Switching between Different Screens

As described above, each screen design allows us to see the big picture and at the same time to locate any next-level component. Thus, moving between different levels of our semantic model is as easy as clicking the mouse. For example, we can move into the "Problem List" screen by simply locating and clicking a patient icon in the "Patient Selection" screen. Similarly, we can move back to the "Patient Selection" screen by closing the "Problem List" screen.

Our interface design is an innovative application of the direct manipulation and the full-view display techniques (Shneiderman [7]). Direct manipulation allows users to enter their search requests by directly manipulating certain icons in a graphical interface, and a full-view display requires the system to produce instantaneous results upon each search request. These two techniques, when used together, provide a natural support for human-computer interaction in that they give users the feeling that they are in direct control. Although the screens above are specifically designed for the OVC domain, we believe that the underlying principles can be applied to the interfaces of other medical information systems.

4. Conclusions and Future Work

We proposed a new solution to the electronic implementation of medical problem lists by directly supporting a high-level semantic domain model and a graphical user interface. Our semantic model has a multi-level organisation: the top level includes a collection of patient records; each patient record contains a series of snapshots of the patient's conditions at different times; each snapshot is a hierarchy of problems and their relationships; and each problem is identified by labels along four different axes, including status, severity, activity, and sureness. Our model seems to capture the way the problem lists are actually used by physicians and thus can form the basis for an acceptable system.

To help explore the multi-level organisation of our semantic model, we designed a graphical interface that supports both direct manipulation and the full-view display. The users are allowed to change the search parameters by simply manipulating the corresponding icons and see all the results instantaneously in a full-view display. Three access modes (BASIC, INTERMEDIATE, and ADVANCED) are provided at the top (database-wise) level to accommodate different groups of users. Furthermore, three different views (LINEAR, SPATIAL, and TEMPORAL) are supported at all levels, depending on the interests of different users. Each view allows the users to see the quantity of the information involved, and at the same time, to locate any next-level component. Thus, switching between different levels is as easy as clicking a mouse.

We are currently implementing a prototype problem list for a restricted domain at the OVC. Once the prototype is complete and functioning, we will conduct a formal evaluation to study the feasibility and acceptability of our semantic model and the graphical interface. The initial feedback from our domain experts and a small number of potential users has been positive and encouraging.

Our research could be further expanded in several directions. We could follow the current model but extend the prototype to cover the entire OVC domain. We could also expand our model to incorporate other medical information such as examination results and treatment plans so that complete medical records can be computerised. Finally, we could add a decision support module to actively assist physicians in making better judgements and decisions.

Acknowledgements

The authors would like to express their thanks to the domain experts Dr. Brenda Bonnett and Dr. Frank Pollari for their invaluable expertise, and to Sheena Bamsey and Wendy Woodhouse at the OVC computer group for their continuing support.

References

  1. C. M. L. Brown, Human-Computer Interface Design Guide-lines (Ablex Publishing Corporation, New Jersey, 1988).

  2. M. H. Chignell and P. A. Hancock, Intelligent Interface Design, (in) Handbook of Human-Computer Interaction, ed. M. Helander, (Elsevier Science Publishers, North-Holland, 1988).

  3. W. Kim, Introduction to Object Oriented Databases, (MIT Press, Cambridge, Mass., 1990).

  4. E. Nygren and P. Henriksson, Reading the medical record I, Computer Methods and Programs in Biomedicine, 39 (1992) 1 - 12.

  5. A. L. Rector, W. A. Nowlan, and S. Kay, Foundations for an electronic medical record, Yearbook of Medical Informatics (1992) 59 - 66.

  6. E. Sciore, Using annotations to support multiple kinds of versioning in an object-oriented database system, ACM Transactions on Database Systems (1991).

  7. B. Shneiderman, Designing the User Interface: Strategies for Effective Human-Computer Interaction, Second Edition, (Addison-Wesley, Reading, Mass., 1992).

  8. F. Song and W. Soukoreff, A Cognitive Model for the Implementation of Medical Problem Lists, Proceedings of the First Congress on Computation Medicine, Public Health, and Biotechnology (1994), in press.

  9. H. K. Walker, The problem-oriented medical record: an introduction, (in) Applying the Problem-Oriented System, ed., H. K. Walker, (Medcom Press Incorporated, New York, 1973).