Paradigms Are Local, Paradigm Shifts Are Personal (Part I)

The idea that one's thinking and actions with regard to EHR are guided by paradigms may be a bit abstract. I spent about 10 years (1981-1991) building EHRs the way most developers do it today but I began to appreciate its shortcomings. The goal was and is to capture encounter information as discrete items so that the data content of each item can be retrieved and reused for other purposes. If an encounter note is primarily composed of unstructured narrative, it is difficult, if not impossible to use the notes as a source of discrete data. So what do developers do?

They identify some data elements that are absolute essential and that cannot be left to the vagary of a doctor's typing or dictation and devise a database to store those data elements. Even if doing os duplicates information that happens to be contained in the narrative, there simply isn't a reliable way to collect it short of creating data-entry forms to collect the essential data. In order to accommodate additional specialties, more essential data elements must be added to the database and more data-entry forms must be developed.

It became clear that the process was becoming endless. The number of data elements that could turn out to be essential is not simply large, it is infinite. The approach of identifying and capturing each element would not scale-up if additional specialties were to be accommodated. Clearly, a different approach was called for.

In 1991, I came across an article by Steve Newcomb on HyTime (Hypermedia/Time-based Structuring Language), a markup language designed for representing the information needed to document things like musical or dance performances in enough detail that they can be used in the future to recreate or reproduce the original performance. For me, reading this article was like watching God part the Red Sea. Here was a direct analog of the problem of documenting medical encounters.

Every encounter, like every performance, has great structural similarity; they all start, end, have acts, chapters or movements, etc. The HyTime language does not aim to specify the content of a performance - what good would that be? What provides is a flexible structure in which the content of virtually any type of performance or artistic creation can be represented - in other words, HyTime is content-neutral.

This is precisely what is needed for medical records. In fact, the problem is even easier because the structure of a typical encounter is much simpler that the potential structure of a piece of multi-media performance art.

But what about the “essential” data elements? The answer is that they ARE essential, but the typical approach has been backwards. Development typically starts by focusing on the essential data and then addresses the capture and storage of narrative as an after-thought, sort of a rumble-seat. Using a structural markup, it would be possible to subdivide the content of the narrative into small, discrete units and attach attributes to carry the quantitative data. This data could then be extracted, either at the time the note was created, or any later time, and replicated into a database as needed to support processes such as ordering, reminders, generating problems lists, etc. Additional specialties could be accommodated at any time because virtually any medical content can be organized to fit into the structural framework provided by the markup language.

This was my personal paradigm shift. I could never again think about EHR the same way. To test the new paradigm I designed and built a new EHR. In the years since 1995, it has been deployed in a wide variety of specialties, including dentistry. Dozens of requests from users have been accommodated without ever needing to change the basic markup structure. A patient's chart can be read sequentially regardless of how many specialties have made entries. Notes from any installation can be transferred to another site and are immediately viewable. No translation or modification of databases is necessary. To the typical user of this product, it merely appears to be another EHR. It does what they expect, when they expect it. The difference comes from the longevity of the information in the patient's charts and the ease of accommodating new specialties and new requirements without being forced to redesign or restructure the database.

The number of “workarounds” that are required to allow a system to meet the needs of its users is a good indication of the degree to which the design has internal flexibility – when the system can't be changed, the user are forced to change. The flexibility that comes from using the content-neutral markup approach minimizes the number of “workarounds,” keeping cost down and satisfaction up.

In next week's post, I'll explain why my own personal paradigm shift has not been shared by others.

For more on Daniel Essin and our other Practice Notes bloggers, click here.