With EHR, Vision is the Art of Seeing What is Invisible to Others

The Short Version

(Title courtesy of Jonathan Swift)

The last couple of articles have established a more "scientific" basis for understanding that narrative notes are complex, information-bearing objects that should be treated as "first class" objects by EHRs. Is this a radical new idea or a familiar concept?   

Many computer applications are devoted to creating and manipulating complex, interrelated sets of information. Examples are plentiful: Microsoft (MS) Word and all other word processors, Excel and other spreadsheets, PowerPoint, webpages (HTML 4 and HTML 5), TurboTax, and Photoshop, to name but a few. These applications use documents (files), with complex internal structures.

Each application stores a representation of the information entered by the user along with the internal state of the application (metadata). In the case of Word and PowerPoint, for example, the nature of the representation depend on decisions made by Microsoft for their convenience - not yours - and are not necessarily based on any theory derived from computer science research. As Microsoft's needs have changed, so has the representation. You may have discovered, as I have, that current versions of MS office will not open PowerPoint files created in the early 1990s.

Theory has had more influence over the structure of other documents such as HTML webpages. The results are more enduring. HTML is based on agreements reached within a standard-setting body. Early versions of the standard were created before the theory was well understood and, not surprisingly, those early versions are now considered to be suboptimal representations of Web content. Version 5 effectively wipes the slate clean by defining a representation that is more general, more flexible, and which conforms better to theoretical principles and to the underlying SGML standard. Theoretically, a representation based on simple rules of structural arrangement is more general and hence more flexible over the long-haul than is one based on content-specific details.

Practically everyone has had the experience of being unable to open an e-mail attachment (document) or of opening one only to find the formatting distorted (due to differences in how different applications interpret the metadata). On the other hand, as one browses from webpage to webpage across industry and international boundaries, the pages only rarely fail to render in a usable way.

So in reality, complex information-bearing objects are in widespread use today. Healthcare is the exception for not having recognized and understood these concepts and for failing to implement them. Fifty years worth of efforts to build computerized medical records coupled with the knowledge about representing complex information-bearing objects (reinforced by the experience with XML and HTML 5) suggest that there is a theoretical basis for choosing a representation; the choice need not be made capriciously. Indeed, the goal of a lifetime medical record will be difficult to realize as long as EHR vendors ignore theory and instead persist in using proprietary representations of an encounter note.

My experience tells me that it is possible to devise a representation that is sufficiently general so that it can accommodate the needs of a computerized record now, and in the future, with little or no change being required. This should result in EHRs minimizing the dissatisfaction that is so common today. However, it will be difficult to achieve until there has been wide discussion and general agreement on the vision of what a computerized medical record should be, how it should perform and the details of the representation. 

The Long Version

Before creating a computerized medical record, and certainly before designing a full-blown EHR that will either be based on, or incorporate a computerized chart, one should be clear about the reasons for doing so and what one expects to achieve. Looking at today's EHRs, we know that some have simply tacked "a "charting module" onto a business-oriented hospital information system and others give the appearance of having done exactly that. People in business know that without a clear, long-range goal an enterprise is like to lose its way and run aground short of its destination (assuming the destination has been identified.)

Virtually every business plan begins with a vision statement and a mission statement. One "business" that has a lot in common with medical records is the National Archive and Records Administration (NARA). In their 2004 vision statement, NARA declared that their Electronic Records Archives would "authentically preserve and provide access to any kind of electronic record, free from dependency on any specific hardware or software, enabling NARA to carry out its mission into the future." As a vision of a computerized medical record archive, this can hardly be improved upon. Do you know of a certified EHR that has published its vision of a computerized medical record?

"A mission statement defines what an organization is, why it exists, its reason for being." In "Principle-Centered Leadership," Stephen Covey explains that, for a mission to be a real tool and not mere window dressing, it should act as a compass that can guide any member of an organization to make an appropriate decision when confronted by a situation for which there is no established policy or procedure.

In 1994,Tom Lincoln and I published a paper that described the performance characteristics required of a computerized medical record. It began:

"An Electronic Medical Record (EMR) must provide a secure, permanent archive for an individual's medical records and also function as a multi-purpose database that supports the complex, varied activities of patient care. Meeting these objectives requires unusual flexibility in how data are retrieved and processed. Semantic and referential integrity must preserved both over time and as chunks of information are exchanged with other systems. Relationships between data entries must [be] determined dynamically based on actual events, rather than statically through application design. Distributed data requires that new forms of system security be incorporated into an EMR at a structural level, with an emphasis on the labeling of elements to be secured behind a security barrier, with audit trails to document necessary overrides and monitor for suspicious use."

This brief statement, I believe, satisfies Covey's concept of a mission statement. Do you know of an EHR vendor that has published, or even has, a mission statement for their computerized medical record?

While a vision and a clear mission are prerequisites for building a robust system, they provide only the direction and the compass but not the navigational details of the best route. This series of articles aims to provide those details. So far, the discussion has made the following points:

•The encounter, and its follow-on activities, are the source of most information and data about the patient. The challenge, whether using paper or a computer, is to faithfully capture everything that is (or might be) relevant to understanding the patient's condition, planning and managing treatment and assessing the outcome.

• If all of this is incorporated in a well-crafted encounter note, the result is a complex information bearing object that manifests an internal organization (structure) and which contains enough context to enable a reader to appreciate its meaning.

• If the narrative note is represented in the computer as a blob of free (unconstrained) text, the computer will be unable to unerringly locate and use data which may be plainly visible to a human reader. This forces developers to create alternate, duplicative mechanism of capturing the "data."

• If, on the other hand, the narrative note were represented as a complex datatype with a defined structure, one that provides for the inclusion of quantitative elements and contextual metadata, the computerized note could not only be read by humans but reliably "understood" and used by the computer.

• If EHR design centered on the documentation created by the practitioner during a visit, and if that documentation contained all of the necessary data and information, the all-important first step would be to choose the "best" data structure - "best" in terms of its ability to further the vision and mission. Many representations can be imagined but will not all perform equally well over the long run.

What should influence the structural chosen to represent narrative notes? As datatypes go, a narrative note is complex when compared to an integer or a short string of characters. Its complexity has several aspects:

• There is often a hierarchical arrangement of sections and subsections which allows subsections to "inherit" the context established by its parent.

• Notes include quantitative data which, if set off by delimiters, would allow a computer program to isolate and extract the data reliably.

• Qualifiers (metadata) applied to various elements of the note to record units of measure, establish links to standard nomenclatures, etc.

• Notes contain referential links to other sections of the note, to other notes and to other data sources such as lab results or the medical literature.

•Notes include contextual metadata such as the note's author(s) and the time and location of the event being documented.

•The representation must allow the electronic chart to satisfy the following performance requirements:

From my paper with Lincoln:

"1.) It must provide a rich method of representing information so that content, meaning and context are not obscured, insuring that the raw data is not prematurely replaced by interpretation or conjecture.

2.) It must be 'open' so that a wide range of information management … applications…, each with its own set of functional requirements, can use the information as a resource.

3.) It must inform users about the nature of the information that it contains.

4.) It must be able to selectively retrieve information, either for human viewers or to serve as knowledge sources for automated process-control and decision-support systems.

5.) Since different groups of users each have their own agenda and preferences, there must be great flexibility in rendering the information for presentation.

6.) It must store the data in ways that meet permanence regulations [and remain accessible throughout the patient's lifetime].

7.) It must structurally address the issues of privacy, confidentiality and security."

As decisions are made as to how notes will be represented within the computer and what technology will be employed, preference should be given to the representation that addresses the requirements in the most general way. Once defined, it will determine what the resulting system can do, and if not sufficiently general, what it cannot do; some functions later deemed essential may prove to be impossible to implement. In short, it will determine whether the resulting system is, in fact, a true computerized medical record or simply another purpose-built data system.

There has been, and is still, a major obstacle to building a system that will satisfy these requirements. As we learned last time, general-purpose computers do not provide a built-in, pre-defined encounter-note datatype that developers can simply reference. The only types that are built-in are variations on number, date and character string. So, instead of working in an environment that "understands" the data model of a note, each project, and perhaps each developer, must invent their own. Predictably, projects rarely, if ever, invent the same data model. The wide variation in encounter-note data models between EHRs is one of the root causes of the much bemoaned lack of interoperability.

The take-home message today is that the use of complex information-bearing objects is commonplace but that Healthcare is the exception for not having recognized and understood this concept and for failing to implement it. Although it's relatively easy, using appropriate computer techniques, to capture and embed "data" in notes in a way that does not disturb the practitioner, very few EHR developers seem to have figured this out.

Fifty years of experience with computing and 30-plus years of experience trying to computerize medical records have laid the groundwork for the theory needed to make the necessary design decisions. The design of a computerized medical record no longer needs to be based on guess work or on the methods used to capture data for business, manufacturing, banking and retailing. The goal is a lifetime medical record that contains the data needed to satisfy the needs of billing and healthcare operations in addition to patient care.

My experience tells me that a representation can be selected that is sufficiently general to accommodate the needs of a computerized record now, and in the future, with little or no change being required. This goal will remain difficult to achieve as long as EHR vendors ignore theory and persist in using simplistic, proprietary representations of an encounter note. It will also be difficult to achieve until there has been wide discussion and general agreement on the vision of what a computerized medical record should be, how it should perform and the details of the representation.