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.

I've been playing around with a business process platform called thingamy lately. It's an impressive piece of work. As with all software, it has a long way to go, but the path is fairly clear. I'm looking forward to the day when it is interoperable enough that I can use it as an everyday tool.

For me, the really interesting thing about thingamy is not so much the tool or the technology (Java, semantic, etc.) as the thought behind it and the difference of approach to a well-known problem, which has gotten me thinking (yet again) about process design and some of the problems in that area. Thingamy is built around the concept of a barely repeatable process (BRP), a concept that almost immediately causes one to recognize that the cost of instituting processes is too high and current process platforms are not sufficiently robust.

What's a process?

A process is a set of tasks and decisions that is part of the daily work of getting the job done. If you work in the average office, you deal with processes on a daily basis - checking out a conference room, asking a question of a colleague, getting a new keyboard to replace your broken one. If you don't work in an average office you deal with process too, but it might not be as recognizable as such. Some of these processes are more human than others, some are more repeatable than others, some more useful than others, but they all share the trait of being steps that result in getting something done.

In many organizations there is a belief that processes like those described above should not range free through the organizational structure as in the days of yore. Rather, they should be corralled into technology systems where they can be properly monitored and maintained. The efficacy of this approach to process is debatable, but it is not much debated. It is these organizations and these types of processes that I'm talking about below.

The cost of process

One of the largest hurdles to turning an organic process in a business into a technology-supported process is the time and money involved in doing so. In most medium and large companies with current ERP systems a person who sees an opportunity for improvement in a process or for the creation of a new process is faced with the daunting task of justifying an expense that totals in the $20,000 - $500,000 range.

That's a big number. Let's back that up:

This is an example of a workflow/process build estimation tool tailored to SAP's workflow technology. For the simplest possible workflow (5 steps), it provides an estimate of 32.5 person-days for the technical build. This does not include a myriad of things that require significant effort, like business process design and testing, or ongoing maintenance. I use this example not to pick on SAP (estimates on a similar order of magnitude hold for most process development environments) but to show the magnitude of the problem. (Hat tip to Jim Spath for making this available and Susan Keohan for blogging about it on SDN.)

Those who read the BRP link above will now say, "that makes it nearly impossible to justify the creation of processes that will only be used by one person or by a small department." Those people are right, but it's worse than that: this cost also stunts the ability of an organization to conceptualize, test, and grow processes. A lot of process growth that occurs naturally is organic, starting with one or a few people as a trial and then spreading out to the rest of an organization once benefit is realized. The high initial cost of process mostly precludes this sort of organic, exploratory process-building.

Thingamy certainly takes aim at the difficulty and cost of creating a new process and maintaining existing processes. Process creation is surprisingly easy and robust (we'll get to this later). Check out the video on creating an expert consultation process in under 20 minutes. The flow isn't complete, but it would be conceivable to iterate development on this flow 3-4 times in a single day; more if the person building the flow is also the person who will be using the flow.

Robustness of the process tool

Thingamy is also a robust process building tool, once you figure out what the heck all the pieces are doing. This is important because a lot of no-code business process modeling tools trip up on branching, looping, or interfacing problems and end up requiring code. Additionally, they have often so over-loaded their visual representations of processes that it is next to impossible to model anything but the most simple process.

For a basic example of this complexity, take a look at these "Email voting process" outlined here. The email voting process itself is made up of a several other processes such as the "Collect Votes" process, each of which are of similar complexity and is completely invisible from the overall process view. Thingamy's textual representation, focus on robustness of process description, and process re-usability is an example of another, apparently better, approach.

Onward and upward

Those are some gripes about the current state of business process systems where I see some light at the end of the tunnel. There are also areas like personalized processes and exploratory process-building where I think the hurdles above exist but the tools haven't even begun to attempt to address the problem.

What areas do others see where improvements could be made? What interesting tools haven't I seen?

Michael Krigsman blogs at his IT Project Failures in response to a Robert Scoble post asking why enterprise software isn't sexy. Vinnie Mirchandani also responds on his Deal Architect blog. Scoble is asking why enterprise software doesn't get more press, and Krigsman and Mirchandani hold that it doesn't get press because it's doing important things. More likely it doesn't get press because your everyday blog reader doesn't really want to know about the software that processes invoices and manages supply chains, nor should they.

But I think this misses the point. It's not just your person on the street that doesn't care. The people that use this software every day don't care about it. A lot of people use software from SAP, Oracle, and Microsoft but very few of these people view the software as anything other than a necessary evil. I don't think it's unreasonable to attribute this lack of interest on the part of actual users to a lack of sexiness, usability, humanization, etc. on the part of the software.

So back to Scoble's question: Why the lack of sexiness?

I believe it comes down to a tendency to discount aspects of software that encourage use because in the case of enterprise software we can require use. This, of course, despite the fact that you can both require and encourage use.

Because of this mentality, and the resulting software (or vice versa), people don't care about the software they use every day. Not caring results in resignation and a cycle develops under which individual employees don't have and don't expect to have control over their software, their business processes (enshrined in the software), or their workflow (also increasingly in the software). This begins to shape up into a recruiting and retention issue because people who care won't want to work with software that they can't control. But it's also a issue because we leave a huge amount of business and user interaction expertise on the table when designing enterprise software for resigned users.

Now, that's money on the table, but I think the amount of money on the table here is dwarfed by the loss of whole areas of enterprise software. Companies are just starting to try to figure out social software and the jury is still out on this area, though there are some positive signs. How about user-controlled business process modeling, even just for analysis processes? Most people are still using Excel for this.

One area of enterprise software that has been an unmitigated failure is the knowledge management arena. A big part of problem is the fact that people have to be able to integrate the KM software into every aspect of their workflow in order to achieve the necessary level of information transfer into a knowledge management environment. Enterprise software traditionally doesn't enable this type of user control, so failure ensues. Sure, documents show up in KM repositories, but a working knowledge management system isn't really about the documents, it's about ideas and knowledge diffusion.

This is all especially concerning when we have Gartner analyst/VP Jeff Mann holding that "social interaction is the way most value is delivered in the modern work environment" and that "by 2012, the primary role of business networks will be to support social interactions, not routine business transactions." (Yes, I really love this quote.) I assume that Mann includes social knowledge creation in his calculus.

I think we can agree that un-sexy software probably doesn't do a very good job of enabling social interaction. And that's a big problem.