Fei Song, & William Soukoreff (1994). A Cognitive Model for the Implementation of Medical Problem Lists. Proceedings of the First Congress on Computational Medicine, Public Health and Biotechnology. Austin, Texas.

A Cognitive Model for the Implementation of Medical Problem Lists


Fei Song and R. William Soukoreff

Department of Computing and Information Science
University of Guelph
Guelph, Ontario N1G 2W1, Canada


Abstract
Although computerized medical records can generally improve the efficiency and quality of retrieving relevant information about patients, the system may not be accepted by clinicians if the underlying domain model is too detailed and complex. This paper presents a new cognitive model for the representation of medical problem lists, the core components of medical records which help organize other information such as examination results and treatment plans. Our model has three useful features: a taxonomy of problem classification that supports efficient retrieval of patient information; a hierarchical organization of problems which indicates explicitly how initial problems are related to more general problems, and further to diagnoses; and a set of time labels for distinguishing different versions of a problem (outdated versions are maintained for legal reasons and the most current version of a problem hierarchy can be easily computed). The model captures the way clinicians use the medical records and thus can form the basis for an acceptable medical information system. It is also intended to ease the interaction between a user and the system so that a high-level intelligent interface can be developed.

Keywords: Problem Oriented Medical Records, Electronic Medical Records, Problem Lists, and Cognitive Model

1. Introduction

Medical Informatics applies computer technology to the field of medicine, and specifically, to the management of medical information. A current area of research is the Electronic Medical Record, which is concerned with the storage of medical records in a computer system so that doctors can retrieve relevant information about their patients more efficiently. Although considerable work has been done in this area (Rector, et al. [9]), the subject remains as one of the major active topics within the field of Medical Informatics.

Motivations for implementing computer medical records are:

Current research in medical record management suggests that for accurate and useful record keeping a problem-oriented approach is the most preferred. In other words, patient records should be organized in such a way as to directly reflect the problems that a patient is currently suffering or was suffering from. This has been shown to be both natural and well suited to the organization of medical records, especially, for an electronic implementation:

"Basically, the POMR [Problem-Oriented Medical Record] is a simple and sensible method of organizing information in [the clinician's] charts so [the clinician] can have ready access to it, and of preserving the logical interrelationships among various data." -- From Walker [15], page 16.
The focus of this paper is an electronic implementation of medical problem lists for the Ontario Veterinary College (OVC) at the University of Guelph. Problem lists can be seen as the core components of medical records, since in a POMR framework, they are helpful in organizing other relevant information such as examination results and treatment plans.

1.1. Problems and Problem Lists

As defined in Walker [15], 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 such problems.

In current practice at the OVC, problem descriptions are often spread over several places in medical records: initial problems (also called the presenting problems) are stated in history and/or examination sections, current problems are recorded in progression notes, and some of the problems are re-stated in the master problem list. The master problem list is supposed to include all the problems, but unfortunately, after going through all the examinations and initial writings, doctors often fail to copy them over to the master problem list. As a result, when a patient comes in for a re-check, doctors may have to look through many pages of the paper file in order to find all the previously-stated problems.

The presenting problems are the signs and symptoms of a patient when he or she first arrives. They can be reported by the patient, by a clinician who has referred the patient to the clinic, or possibly by the owner of the patient in a veterinary environment. The shortcoming with initial problem list is that it lacks format, detail and accuracy, since it is not necessarily generated by a clinician. The initial problem list may exist for only a short time period as it needs to be directly transcribed onto the current problem list by the attending clinician upon the initial medical examination of the patient.

The current problem list contains the problems actively being treated and perhaps ongoing (long term) problems. It is, therefore, a subset of the master problem list. Also, since a patient's conditions change from time to time, a current problem list is better extracted dynamically from the master problem list based on certain selecting criteria. (What exact criteria should be used is not currently well understood, but see section 3.3 for a further discussion.)

By storing problems on-line, we will be able to retrieve relevant information quickly, and more importantly, the problems need to be entered only once, as we can easily pull them together electronically to the master problem list. However, simply emphasizing efficiency can be misleading: if the underlying domain model is too detailed and complex, the clinicians may not accept the system. Our solution is to provide a high-level cognitive model for the representation of problem lists. The model consists of three useful features: (a) a taxonomy of problem classification that can support efficient retrieval of patient information, (b) a hierarchical organization of problems which indicates explicitly how initial problems are related to more general problems, and further to diagnoses, and (c) a set of time labels for distinguishing different versions of a problem (outdated versions are maintained for legal reasons and the most current version of a problem hierarchy can be easily computed). The model captures the way clinicians use the medical records and thus can form the basis for an acceptable medical information system.

2. General Requirements for Electronic Medical Records

An implementation of a medical record system must satisfy a number of general requirements. Two of the important ones are discussed in Rector, et al. [9]:

Attributability

To ensure security and accountability of the information in a medical record, each entry must contain the source of the information (i.e. which clinician or laboratory technician made this specific entry at what particular time).

Permanence

Information in a medical record should not be removed. This is not only a legal requirement, but also a logical one, since a medical record is meant to maintain a list of observations, which once made are no longer retractable.

The above requirements affect the way editing will be supported in an electronic system. Since a medical record will become permanent once entered, clinicians will have to put information correctly the first time. Follow-up cleaning or neatening up is not allowed. On the other hand, it is also necessary for clinicians to have the freedom and flexibility in expressing themselves within medical records. This is important since clinicians who feel burdened by the system will be inhibited from entering the accurate and detailed medical information desired. Thus, clinicians will need to be able to create records in a personal format suitable and acceptable to themselves, and yet formal enough to be permanently recorded. This naturally leads to the following two requirements.

Completeness

A model of medical records should allow clinicians to make a complete account of their understanding without having to formulate unnatural statements. This implies that uncertain and even incorrect statements may need to be recorded, but they should be explicitly labeled as such. In addition, clinicians may choose to describe their understanding at a natural level of abstraction, to an arbitrary level of detail, or even with the context of their observations. Obviously, completeness is an essential requirement to ensure a faithful recording of patient information.

Standardized Vocabulary

While it is desirable for clinicians to create their records in a format that is most suitable to them, accurately recording clinical information and being able to support flexibility under permanence put rigid requirements on the selection and use of medical terminology. Several standardized coding schemes have been proposed for describing medical records in a way that is suitable for computer storage and retrieval (van Ginneken, et al. [14] and Sperzel, et al. [13]). However, none of them has been known to be satisfactory in terms of expressiveness, although some coding schemes have demonstrated promise and success is anticipated eventually (Campbell and Musen [3]).

An implementation of electronic medical records should strive to be flexible so that migration to later evolving standards for coding medical information can be easily accommodated.

User-Friendly Interface

Once completed, an electronic medical record system needs to be tested and used by real clinicians. In order to compete with paper records, the electronic system should provide a user-friendly interface for easy input and access to patient information.

Current research has shown that computer record keeping is often not much quicker than that of paper records. As described in Nygren and Henriksson [7-8], a paper record consists of a set of different documents in a specific order. These documents may have different shapes and can be marked with different signs and colors in the margins. As a result, it is possible to overview several pages at the same time, and to rapidly browse through a large number of pages. The speed an experienced user can achieve in 'zooming-in' to the relevant parts is remarkable, and the amount of information covered by a glance is enormous.

Thus, a successful implementation of medical records should make the user interaction with the system as effortless as possible. User interface design strategies and guidelines should be followed throughout the development process (Shneiderman [11]). In particular, a graphical interface that allows a user to directly manipulate the retrieval requests and rapidly browse through a medical record is strongly desirable. However, simply emphasizing efficiency and user-friendly features is not enough: if the underlying domain model is too detailed and complex, the system may still be rejected by clinicians. A good indication for this is that after intensive training and practice, the users will continue to make a lot of mistakes. In order to avoid as many mistakes as possible, a high-level domain model that reflects how the user perceives and processes the required tasks is required. Such a high-level model can be called a cognitive model, since it forms the basis for an intelligent interface when used together with other user-friendly interface features (Chignell and Hancock [4]).

3. The Cognitive Model

As stated previously, our goal is to computerize medical problem lists for the OVC domain and we intend to base our implementation on a cognitive model that may lend itself to an acceptable system. We approached this task by first conducting a series of interviews with our domain experts, to identify the required properties for electronic problem lists and the shortcomings of the current paper organizations. These are summarized in the following first two subsections. The analysis of these requirements and drawbacks helped us to propose a new cognitive model that supports three useful features: a taxonomy of problem classification, a hierarchical organization of problems, and a set of time labels for distinguishing different versions of a problem. These features are described in detail in the remaining three subsections.

3.1. Desired Properties of Problem Lists

The interviews with our domain experts revealed the following set of desired properties for the implementation of medical problem lists:

  1. The physicians should be forced to use some standardized medical vocabulary to describe the problems, however enough flexibility should exist within the problem descriptions to satisfy the physicians.

  2. There should be a way to associate problems with one another to reflect the relationships between problems.

  3. Dates should be used for all items on the problem list identifying the date the data was entered, or modified.

  4. No replacement or removal of information is allowed on the problem list. Although a user may appear to change records, the original information should persist within the problem list, and still be retrievable. All information within the problem list should be time-stamped to support this.

  5. Whenever any changes are made to a problem list, an identifier should automatically be attached to the new information indicating who made the change.

  6. Errors should be recorded. Problems or diagnoses which are incorrect should be identified as such.

  7. A qualifier should be associated with each problem classifying them according to the aforementioned problem taxonomy.

  8. Different formats of the problem list will be useful to different people, and hence several different views of the problem list should be supported.

  9. The user interface should be productive, easy and efficient to use, flexible, and readily available throughout the hospital.
Compared with section 2, the above desired properties conform to the general requirements, but add further details for the electronic implementation of problem lists.

3.2. Shortcomings of the Current Paper Organization

To the best of our knowledge, most medical record systems assume a linear organization of problems, which is inherently limited by the underlying paper format. A typical form for such a problem list is shown in Figure [1]. Each problem is uniquely identified with a number and the attributability is enforced by the fields of date, time, and clinician. The description is a free-format field, which allows a clinician to specify the name of the problem and its related properties. For example, one could indicate whether a problem is on-going or resolved, and the degree of uncertainty for an observation.

[IMAGE]
Figure 1. A typical paper form for a problem list.

Although a linear organization appears to be simple and also fits well with the existing techniques for database and spreadsheet implementations, it does have several serious shortcomings. First, deletions are not allowed; updates have to be handled by creating new entries and referencing the numbers of the previously mentioned descriptions. Second, it is not easy to see the logical relationships between problems, which are typically hierarchical and directly useful to clinicians. In reality, the abstraction of a set of problems is also dealt with by adding a new entry for the general problem and referencing the numbers of the detailed problems. Finally, with much old information cluttered and hierarchical relationships buried in a linear list, it can be time-consuming to construct a sub-list that shows the set of current problems and their relationships, since clinicians may have to scan through all the pages of a patient's record.

These shortcomings motivated us to propose a high-level cognitive model that supports the following three useful features.

3.3. Problem Taxonomy

By definition, a problem is a dynamic entity which may be resolved by a proper medical treatment. As a result, a problem description should be able to distinguish the different status of the problem. In addition, the requirements of permanence and completeness suggest that a problem description once entered may not be changed, and consequently, it becomes necessary to also record those descriptions that are uncertain and even incorrect. Our investigation found that clinicians often use their personalized labels to distinguish the various aspects of a problem. Thus, as the first feature of our cognitive model for a problem list, we provide the following taxonomy as a recommended standard for categorizing different problem descriptions:

  1. Status
    RESOLVED / (UNRESOLVED) ACTIVE / (UNRESOLVED) INACTIVE

  2. Severity
    MAJOR / MINOR / INCONSEQUENTIAL

  3. Actions
    BEING-TREATED / NOT-BEING-TREATED

  4. Sureness
    VERIFIED-CORRECT (≥ 90%) / LIKELY (≥ 50%) / UNLIKELY (≥ 25%) / VERIFIED-INCORRECT (= 0%)
The taxonomy consists of four different axes, each of which can be marked by one of the set of mutually exclusive labels. Most of the axes and labels are self-explanatory, excepting, perhaps, the status axis. Here, a RESOLVED problem refers to one that used to affect a patient, but does not any more. An UNRESOLVED problem is also called the on-going problem, which can be further distinguished as ACTIVE (the problem that is currently affecting the patient) and INACTIVE (the problem that is in remission and may appear again in 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.

Our classification may not be complete for a general medical setting, but it provides a simple and good standard for the OVC domain. All of the four axes may be used to describe a particular problem. For example, a problem may be labeled as ACTIVE, MAJOR, BEING-TREATED, and VERIFIED-CORRECT. As a result, we can easily apply the existing techniques for a database system and search efficiently for all the ACTIVE problems, all MAJOR problems, or all MAJOR and ACTIVE problems. In particular, it should be possible to build dynamically a list of current problems that a patient is suffering from. At present, we are still unclear about which criteria should be used to select a set of current problems. It may well be the case that several different current lists need to be created depending on the goals and interests of different clinicians. Nevertheless, a reasonable start for a general current problem list appears to be the one that contains all UNRESOLVED (or ON-GOING) problems that are not VERIFIED-INCORRECT, even though other variations of the current problem list should also be supported.

3.4. Hierarchical Organization of Problems

One of the major drawbacks for the linear organization of problems is that it fails to indicate explicitly the relationships between problems. In reality, we found that clinicians do not view each problem in isolation; they naturally group certain problems together through abstraction relationships. More specifically, they intentionally strike to relate initial problems to general problems, which are further related to even more general problems, and eventually to diagnoses. Thus, as the second feature of our cognitive model for a problem list, we directly use a hierarchical organization for representing a set of problems and their relationships.

A typical hierarchical organization for a problem list is shown in Figure [2]. Each node corresponds to a medical problem, and each link from left to right represents an abstraction relationship. At the lowest level on the left are the initial problems such as signs and symptoms. Higher levels of problems are added as clinicians continue their investigation into the patient. Ideally, the rightmost-level nodes should be some very general problems such as syndromes or even diagnoses. Note that figure 2 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 our study with the OVC domain shows that three to four levels are often adequate for ordinary records.

[IMAGE]
Figure 2. A typical hierarchical organization for a problem list.

A hierarchical organization is directly useful to clinicians in that by making explicit the relationships between problems, we are able to capture the way a problem list is actually used in practice. A hierarchical organization is also flexible in that it reflects multiple levels of resolutions about the understanding of a patient. As a result, clinicians are able to describe their opinions at a natural level of abstraction, to an arbitrary level of detail, or even with the context of their observation. All of these requirements are absolutely essential to ensure a faithful recording of patient information.

3.5. Multiple Versions of Problems

Since a patient's conditions and a clinician's understanding often change over time, updates to problem descriptions are almost inevitable. However, for the requirements of permanence and completeness, old problem descriptions cannot simply be deleted. Although a hierarchical organization 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 to our cognitive model for a problem list, we distinguish the multiple versions of a problem by a set of time labels so that the relationships between different versions of some problems can also be explicitly recorded.

A typical version graph for the heart murmur problem is shown in Figure [3]. The concept of version for a problem is similar to that for an object in modern object-oriented database systems (Kim [6] and Sciore [10]). Each problem is associated with an abstract version, which contains those time-independent properties. All other versions are time-dependent and are labeled 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 3 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 4 murmur.

[IMAGE]
Figure 3. A typical version graph indicating the changes to
the heart murmur problem of a patient.

Version graphs provide an economic way for representing time-related information. All the changes are stored at individual problems and only changes are recorded in the new version of a problem. Based on the version graphs, we can easily construct the current problem hierarchy for a particular time (a dynamic entity called the snapshot). As a result, when displaying a snapshot, we can remove all the irrelevant information (either outdated or too new) to avoid any distraction to a clinician. One default assumption we have to make in constructing a snapshot is that a medical condition will remain the same unless it is explicitly changed otherwise.

In summary, our model suggests that an electronic implementation of problem lists should include a collection of patient records; each patient record should contain a series of snapshots of the patient's conditions at different times; each snapshot should be a hierarchy of problems and their relationships; and each problem should be identified by labels along four different axes, including status, severity, actions, and sureness. We believe that our model is closer to the way the problem lists are actually used by clinicians and thus may form the basis for an acceptable medical information system.

4. Implementation Issues

A medical record system is essentially a database problem in that it is also concerned with the storage and retrieval of information. However, the ubiquitous relational model is inadequate for the implementation of our cognitive model, since it does not allow explicit relationships between problem descriptions; nor does it support free-format text for the extended description of a problem and time labels for the different versions of a problem. Fortunately, the object-oriented model provides an alternative that is ideally suited for our purpose. With an object oriented model, problems can be represented as objects and the relationships between them can be represented as the links between the objects. Versions of problems can be directly supported by the versions of the corresponding objects. An object-oriented model is also capable of handling heterogeneous data, which may range from raw text, to the taxonomy labels, to certain standard medical vocabulary. In the first subsection below, we describe the schemas designed for the representation of patient and problem objects. Other issues that need to be considered for an implementation include the input methods and output supports, which are discussed in the following two subsections. Finally, we say a few words about the current status of our implementation.

4.1. Object-Oriented Representation

In an object-oriented model, a database consists of a collection of objects and their relationships. Similar objects can be grouped into a class, which is defined as a schema and can be used to create an instance object. Different classes are organized into a hierarchical structure, showing the relationships between them. The only way objects communicate is by sending messages to each other.

For our cognitive model, all of the patients, problem lists, and problems are treated as objects and their schemas are pictorially shown in Figure [4]. Here, a problem list is an object that contains all the pointers to the top-level problems in a problem hierarchy. Both problems and problem lists are shown as stacked nodes, indicating that they are versionable, since they often change over time. A link from one object to another corresponds to an abstraction relationship. All the links and the versions are to be indexed to facilitate efficient retrieval of a patient information, for example, to construct a list of current problems for a particular time. Separate procedures may also be provided to deal with different kinds of data, either structural or textual.

[IMAGE]
Figure 4. Schemas for the objects: Patient, Problem List, and Problems.

4.2. Input Methods

As shown in Figure [4] above, a problem list consists of problems and their relationships, and each problem is specified with a set of labels and a description of the problem itself, including the standard term and the free-format text. Among these items, the input of the standard term and the free-format text is the most likely part to be criticized and often presents difficulties to the users of an electronic system (Sittig and Stead [12]). Clinicians are used to scribbling quick and incomplete notes onto papers, often resulting in problem descriptions that are cryptic and ambiguous. Any system that requires more details than typical paper records is likely to cost more time of the clinicians to enter the necessary data. For an electronic system to succeed, the clinicians will have to be convinced of the worth of complete and accurate records, and the interface for the input process will have to be streamlined and made very efficient.

The standard term and the free-format text are actually alternative specifications of a problem. The former is based on a standard coding system (e.g., SNOMED III) and the latter, on natural language descriptions. A coding system is getting increasingly important in that it provides a controlled vocabulary for the computer storage and retrieval of patient information. It can be made complete and expressive, allowing the specifications of multiple levels of abstractions. It can also be made unambiguous, enforcing a standard for recording medical information. The major difficulty with a coding system is that clinicians will have to be trained to enter a proper entry, or they will have to select one from a list of over thousands of standard terms. Although some efficient selection methods have been proposed (Huff, et al. [5] and Ahlberg and Shneiderman [1]), it still takes over ten seconds and four to seven keystrokes to select one data entry. On the other hand, natural language descriptions have the advantage that they require no training and are flexible enough to allow personalized descriptions of problems. Unfortunately, they also have the disadvantage that they are highly ambiguous and context-dependent and the current techniques are still not robust enough to provide an accurate analysis. However, if the domain is sufficiently restricted, the ambiguities will be largely reduced so that the existing techniques may provide a feasible solution.

We are currently adapting the existing techniques for selecting a standard term. The coding system assumed is SNOMED III, which covers both human and veterinary medicines. However, in the long run, we believe that natural language descriptions need also be supported. For this reason, we have included both standard term and free-format text fields in our problem representation. The major input method will be the standard term selection, but the free-format text is also provided to allow clinicians a chance to enter their personalized opinions. Such information will be useful for research on converting natural language descriptions into standard terms and vice versa. The need for an effective translation between the natural language and the coding system cannot be over stressed. Clinicians will not be satisfied with a system that requires them to learn an artificial coding system; the more distance that can be placed between the users and the standardized vocabulary, the better the acceptance of the system. Further, modern methods that require less typing such as voice recognition and optical character recognition need also be explored to help reduce a user's efforts in making data entries.

4.3. Retrieval and Output Supports

required for a problem list. In this subsection, we consider how to formulate a retrieval request and its corresponding output supports.

We can divide all the retrieval requests into two classes: within-patient search and across-patient search. The former is commonly required by clinicians whose interests are about various aspects of a particular patient, while the latter is usually needed by researchers who are trying to gather the cases about a particular problem. For a within-patient search, our taxonomy allows us to formulate various kinds of useful requests. For example, we can search for all ACTIVE problems, all MAJOR problems, or all MAJOR and ACTIVE problems. The results can be displayed in one of the several views:

We found that a graphical interface with supports for direct manipulation and full-view display is especially suitable for our application (Shneiderman [11]). Such an interface allows a user to change search parameters by simply clicking the corresponding icons and see all the effects right away in a full-view display. It also allows the user to browse through the display by clicking each item to view its detailed explanation.

One possible interface design for the within-patient search is illustrated in Figure [5]. On the right panel is a set of icons for the major search parameters. They are arranged into several lines. The first four lines correspond to the four axes of our taxonomy: status, severity, actions, and sureness. The last line is a double slide-bar, allowing us to set a time label for a particular year/month (finer distinctions can be supported by expanding such a mechanism). On the left panel is the full-view display for the search results. A global or default setting can be made to determine the view of the output: either sequential, hierarchical, or temporal. The user can click each item in the display to see its detailed explanation or if the display is not over-complex, a brief description of all the items will be shown in the bottom panel on the left. Different colors may also be used to distinguish certain major properties. In figure 5, the search request is about all the problems that are ACTIVE, MAJOR, BEING-TREATED, and LIKELY (over 50% sureness). Further, it is for a particular patient and the time is before April, 1993.

[IMAGE]
Figure 5. A graphical interface for direct manipulation and full-view display.

In addition to within-patient search, across-patient search is also useful for our OVC domain, since there are both clinicians and researchers. Generally, an across-patient search is to locate patients that have been afflicted with a specific medical condition during a specific time interval. For example, we may search for "all the patients who died in 1993" or "all the patients who suffered severe (Grade 4) heart murmurs from 1991 to 1993". Such requests are often difficult to formulate and are typically based on the contents of the terms used. It is expected that the free-format textual descriptions may play an important role and the techniques for natural language processing and information retrieval may provide a possible solution for the interpretation of the across-patient requests.

4.4. Current Status

We are currently working on the design and implementation of a prototype to demonstrate the feasibility and acceptability of our cognitive model. This involves collecting a reasonable set of cases, conducting user and task analysis, finishing an initial paper design, and having it implemented in a programming language. We have already collected about 15 cases in the domain of small animal cardiology, a representative subset in the OVC hospital. Detailed analysis of these cases shows that our object-oriented representation is basically adequate. Considerable efforts are being made for the user and task analysis so that an effective graphical interface can be developed. The interface would allow the direct manipulation of a user and display all the relevant information in a full view. The prototype will be implemented on a personal computer (PC) in the Visual C++ language. The choice of PC is to increase the accessibility of the system so that it can be made widely available in the OVC hospital. The Visual C++ is an ideal tool for our implementation since it provides supports for both the object-oriented representation and the graphical interface. Our top-level goal is to develop an acceptable system to clinicians, and the initial feedback from our domain experts and a small number of potential users has been positive and encouraging.

5. Conclusions and Future Work

Our investigation into the implementation of medical problem lists has motivated us to propose a high-level cognitive model that has the following three useful features. First, the taxonomy of problem classification allows us to specify various aspects of a problem (e.g., status and sureness) so that it is now possible to search efficiently for a set of relevant problems and construct dynamically a list of current problems. Second, the hierarchical organization allows us to specify explicitly the relationships between problems and at the same time the multiple levels of resolutions of patient information. As a result, clinicians can choose to express their understanding at a natural level of abstraction, to an arbitrary level of detail, or even with the context of their observation. Finally, the set of time labels allows us to distinguish different versions of a problem so that when displaying the hierarchy of the problems for a particular time, we can remove all the irrelevant information (either outdated or too new) to avoid any possible distraction to a clinician. We believe that our model is closer to the way the problem lists are actually used by clinicians and thus may lend it itself to an acceptable medical information system.

We are currently building a prototype for a restricted domain to demonstrate the feasibility and acceptability of our cognitive model. Our work presented here may be expanded in several directions. We could follow the current model but extend the prototype to cover the entire OVC domain. We could further expand our model to incorporate other medical information such as examination results and treatment plans so that complete medical records can be computerized. Last but not the least, we could add decision support abilities (or expert systems) so as to actively assist clinicians in making better judgments and decisions.

Acknowledgments

We would like to thank Drs. Brenda Bonnett and Frank Pollari for their help in our understanding of the OVC domain, and Sheena Bamsey and Wendy Woodhouse for their continuing support for this project.

References

  1. C. Ahlberg and B. Shneiderman, The Alphaslider: a compact and rapid selector, Proceedings of Computer Human Interaction (1994) 365 - 371.

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

  3. K. E. Campbell and M. A. Musen, Representation of clinical data using SNOMED III and conceptual graphs, Proceedings of American Medical Informatics Association (1992) 354 - 358.

  4. 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).

  5. S. M. Huff, T. A. Pryor, and R. D. Tebbs, Pick from thousands: a collaborative processing model for coded data entry, Proceedings of American Medical Informatics Association (1993) 104 - 108.

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

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

  8. E. Nygren, M. Johnson, and P. Henriksson, Reading the medical record II, Computer Methods and Programs in Biomedicine, 39 (1992) 13 - 25.

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

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

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

  12. D. F. Sittig and W. W. Stead, Computer-based physician order entry: the state of the art, Journal of the American Medical Informatics Association, 1 (1994): 108-123.

  13. W. D. Sperzel, M. S. Tuttle, N. E. Olson, M. S. Erlbaum, O. Saurez-Munist, D. D. Sherertz, and L. F. Fuller, The Meta-1.2 engine: a refined strategy for linking biomedical vocabularies, Proceedings of American Medical Informatics Association (1992) 304 - 308.

  14. A. M. van Ginneken, J. van der Lei, and P. W. Moorman, Towards unambiguous representation of patient data, Proceedings of American Medical Informatics Association (1992) 69 - 73.

  15. 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).