esjewett.com

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

Problem listing is a way to organize the myriad of medical information compiled in charts and medical records. It was originally conceived in a paper-based medical records system but the linked article discusses the adaption of the technique to a system using electronic medical records. The article itself is a bit out of date, having been written in 1994, but the state of the art today in many areas (medical records, information storage and retrieval, library science, cataloging, ERP systems used in businesses) is surprisingly similar to that described in the paper.

Because of this the paper can serve as a useful prompt for discussion and criticism of the current state of the art. I've spent some time discussing this area with my father as he has a particular interest in the area, so hopefully this is somewhat useful as a summary and continuation of our discussions.

On the activity of problem listing

The paper tends to take the tack that if problems can be properly entered into a well-designed computer system then the computer can handle much of the task of categorizing and relating problems to each other. This is fair enough and in the intervening years since '94 several techniques for establishing these sorts of relationships have matured in the data mining (relation through coincidence of terms or other statistically relevant coincidences) and semantic modeling (relation by way of a manually or automatically maintained model of relationships between terms) spaces.

One interesting point that came up in our discussion is that problem listed patients have been shown in some studies to receive better and more predictable treatment. We theorized that a reason for this difference may be the engagement of the physician in the review of the medical record and the creation of the problem list. This activity may help the physician to take the current encounter with the patient in the context of the overall medical history. If the computer takes care of building the problem list then some of this benefit may be lost.

On the permanence of the record

An overarching concern throughout the article is with maintaining the permanence of the record. This is one area in which the article shows its age. In 1994 the only widely deployed examples of systems I'm aware of that maintained versioned, audit-worthy record of changes to a document were source control systems used in software projects. Even these had not gained wide adoption.

Today various wiki-like patterns are available that meet the requirements for permanence and audit-worthiness outlined in the article. These systems also maintain a very robust ability to make edits and changes over time and to easily see the differences between a document and two different times as well as the people responsible for the changes.

Today, permanence is not as much of a concern or a technically interesting problem. It is a problem that has been largely solved and examples of this solution (like Wikipedia) exist on a scale that dwarfs that of almost any individual medical records system.

On standardized vocabulary and taxonomies

In contrast to the previous area, this is an area where information sciences (unfortunately) hasn't changed much in the past decade-plus. The article espouses the need for a standardized vocabulary for describing medical problems as well as standardized taxonomies for categorizing problems. This type of approach is peppered throughout the article, but especially on pages 4 - 6, with the concise statement being that

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.

There are a lot of problems with this demand for standardization and I should write more about it. Problems mostly center around a probable lack of expressiveness and the threat of obsolescence.

Granted, demanding standardization significantly reduces the complexity of these types of systems on the technical side. But in my experience over-standardization can (and often does) make systems unusable. At the very least it significantly increases complexity on the user-interface side of the house by presenting UI designers with the problem of creating flexibility and expressiveness while enforcing adherence to a very confined taxonomy or vocabulary.

My main objection to the "standardization" approach to taxonomy is that it is rarely justified, and this article is no exception. If a standard taxonomy is really better in a particular area in the medical field, then this can and should be shown in a properly controlled study. A medical records system is as much a part of the medical approach to patient care as a drug or a hospital procedure and as such it should be subject to the same scrutiny through scientific study. In a non-medical and potentially less scientific discipline, I would at least like to see an argument for standardization, but the benefits of a standard approach are usually assumed.

What are the alternatives?

The article mentions the possibility of free-form input fields while holding that the technology to support this type of input as the primary input mode has not yet arrived. Today the handling of unstructured text in database applications has improved considerably from 1994, especially in the area of indexed search. Coupled with modern data mining techniques or a reasonable semantic model, unstructured input might be usable.

Another option is semi-structured input like what we see in tagging systems. Semi-structured input is often not as onerous in its limits on expression and is less of an obsolescence threat than a totally structured taxonomy because the semantics of the tagging system are user generated and can easily change with the times. (Of course, it remains a challenge to link up old terms with newer ones, but the common practice of over-tagging with redundant terms can help ease this problem.)

Predictably, semi-structured input delivers some of the advantages of structured data and taxonomies such as simple processing and matching, fast access with limited need for indexing, and a somewhat predictable semantic structure that allows programs to make assumptions about the data that could not be made with unstructured input. For example, in the tagging situation, a program could make the assumption that tags are atomic terms that directly describe the object being tagged.

I've got a draft blog post laying around somewhere that outlines some alternatives to standardized vocabularies and taxonomies but haven't gotten around to digging it out and posting yet. Oh well.

On user interface

The article gives a nice description of the strength of paper-based systems in the user interface area, mentioning that in a paper-based medical charting system

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.

The article then goes on to talk about a "graphical interface that allows a user to directly manipulate the retrieval requests and rapidly browse through a medical record". Keep in mind that this is 1994 and graphical interfaces that do much of anything are still pretty few and far between. This is an apt description of a problem that the information visualization community is still working through today.

Another one of the most insightful points in the article is in the user interface area. This is the requirement that

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

This requirement is spot on and should be a requirement for any information storage and retrieval system. Moreover, we are learning today that it is important to provide not only multiple views or interfaces to the data, but a system for accessing the data directly for the purpose of building custom views and interfaces that the designers of the software might not have envisioned. This type of system is usually referred to as an application programming interface, or API, and is a key component of the explosion of creativity and interoperability that is occurring right now in the web-based application space.