AMA's Ideas for EHR Overhaul are Laudable, But Wrong

The AMA president-elect asks, in a recent AMA Viewpoints post, "Which EHR improvements would help you most?"

He suggests eight possibilities:

• Enhance physicians' ability to provide high-quality patient care

• Support team-based care

• Promote care coordination

• Offer product modularity and configurability

• Reduce cognitive workload

• Promote data liquidity

• Facilitate digital and mobile patient engagement

• Expedite user input into product design and post-implementation feedback

If you think about this list, you will realize that these are touchy-feely items like mom and apple pie. None of them describe a specific change in an EHR that would be sure to actualize the dream because they are not functional requirements (specifications). What does it take for an EHR to be considered enhanced or better? What change, exactly, would reduce a doctor's cognitive burden or facilitate/expedite something?

Statements calling for things to be made faster, cheaper, or better are called non-functional (I prefer the term "performance") requirements. They are characteristics that might be ascribed to a completed systems (or not); things to strive for during development. They do not, however, inform a developer about what constitute a great design nor do they provide specific criteria that a physician can use to select a system with some assurance of success. Being forced to buy and implement an EHR in order to discover if it's the right one (the current approach) is rarely successful and totally unacceptable. It's why 23 percent of practices are looking to switch EHRs. But switch to what?

There are reasons why existing EHRs fall short in the areas described by the list above. They involve the difference between a capability and a feature (the name given to functions a system can perform).

A capability is the facility or potential to do something. A function is a procedure that performs a specific calculation or task. Functions can only be implemented if the background environment offers the requisite capabilities. In the case of computers that means things like how data can be represented, whether contextual metadata is accommodated, and whether the desired operation is supported by the hardware and developer tools.

Each platform (EHR) offers certain native capabilities; others may be created by developers (within the constraints of the platform) to extend that native set. Once the platform is in place, some extensions are easy to add, some are hard, and others have been precluded.

Satisfying non-functional requirements requires implementing functions with appropriate performance characteristics. Developing those functions depends on existing capabilities or the ability to extend the platform. In the absence of functional specifications, most developers haven't got a clue as to exactly what it would take to morph their product from its present state into a future state that behaves in the way people hope for. Attempts are made all the time and yet the dissatisfaction persists.

The Paleolithic, rigid, data-oriented, context-poor, 50-year-old architectures of today's EHRs leads (forces) them to behave the way they do. They are the end result of developers creating myriad functions all of which are hampered by the nature of the platform's capabilities or the lack of a critical capability. It accounts for why they are so difficult to modify.

The fundamental capability that an EHR requires is to be able to quickly capture rich narrative including quantitative elements and contextual metadata and preserve it for subsequent access now and into the far distant future. That should be the singular focus of an EHR. With that information, in the form of documents conforming to an orderly, internal, content-neutral structure, other applications targeted at performing specific healthcare-related tasks can be created, modified, or replaced without disturbing either the process by which documentation is created or how it is stored. Systems can come and go and requirements can change but none of that need affect the basic structure of the informational unit - the note.

It seems almost too obvious. With 50 years of systems that fail to satisfy, or simply fail as evidence, that the problem is not simply having neglected to develop one critical function. Thousands have tried. If the existing platforms offered the proper set of capabilities, success would be routine; failure would be the oddity.

The right capabilities are, in general terms:

• An internal architecture based on structured documents rather than discrete data elements;

• Software applications that connect to the internal structures in ways that put the needs of physicians and patients ahead of data collection; and

• Physicians who are sufficiently motivated to embrace a new practice style.

Doctors should document, not act as data entry clerks. Computers should assist the doctor as he documents and later they (the computer) can read the notes (if properly structured) and gather data to their little silicon heart's content.

Ask not what you can do for your EHR, ask what its capabilities are and what it can do for you.