Is the Electronic Health Record Defunct?

by Jerome Carter on April 28, 2014 · 10 comments

When building software, requirements are everything. And although good requirements do not necessarily lead to good software, poor requirements never do.   So how does this apply to electronic health records?   Electronic health records are defined primarily as repositories or archives of patient data. However, in the era of meaningful use, patient-centered medical homes, and accountable care organizations, patient data repositories are not sufficient to meet the complex care support needs of clinical professionals.   The requirements that gave birth to modern EHR systems are for building electronic patient data stores, not complex clinical care support systems–we are using the wrong requirements.

Two years ago, as I was progressing in my exploration of workflow management, it became clear that current EHR system designs are data-centric and not care or process-centric. I bemoaned this fact in the post From Data to Data + Processes: A Different Way of Thinking about EHR Software Design.   Here is an excerpt.

Do perceptions of what constitutes an electronic health record affect software design?  Until recently, I hadn’t given much thought to this question.   However, as I have spent more time considering implementation issues and their relationship to software architecture and design, I have come to see this as an important, even fundamental, question.

The Computer-based Patient Record: An Essential Technology for Health Care, the landmark report published in 1991 (revised 1998) by the Institute of Medicine, offers this definition of the patient record:

A patient record is the repository of information about a single patient.  This information is generated by health care professionals as a direct result of interaction with the patient or with individuals who have personal knowledge of the patient (or with both).

Note specifically that the record is defined as a repository (i.e., a collection of data).   There is no mention of the medium of storage (paper or otherwise), only what is stored.   The definition of patient health record taken from the ASTM E1384-99 document, Standard Guide for Content and Structure of the Electronic Health Record, offers a similar view—affirming the patient record as a collection of data. Finally, let’s look at the definition of EHR as it appears in the 2009 ARRA bill that contains the HITECH Act:

ELECTRONIC HEALTH RECORD —The term ‘‘electronic health record’’ means an electronic record of health-related information on an individual that is created, gathered, managed, and consulted by authorized health care clinicians and staff.  (123 STAT. 259)

Even here, 10 years later, the record/archive/repository idea persists.  Now, back to the issue at hand: How has the conceptualization of the electronic health record as primarily a collection of data affected the design of software systems that are intended to access, manage, and otherwise manipulate said data?

Repository-oriented thinking results in an emphasis on software system designs that primarily optimize data-centric functionality such as capture, validation, retrieval, and storage.

Conceptually, EHR systems are, first and foremost, patient data repositories.  Now, if one sets out to build a repository, in the best of all possible worlds that is exactly what will be built.   The question, of course, is whether repositories are the ideal systems to assist in complex patient care tasks.  Ask any clinical professional struggling with an EHR system this question and the answer will be a resounding  “No.”

Paper records are passive and do not participate in care processes.  Rather, they are accessed as needed for information and documentation purposes.   This is both a blessing (no troublesome alerts) and a curse (no helpful alerts).   Where did the idea arise that records should inject themselves into care processes?  The answer to this question is critical to designing the next generation of clinical care systems, because if paper records were never active clinical care participants, why should one assume their electronic cousins should be?

Efforts to improve EHR systems to support complex clinical care needs have not resulted in significantly better systems.  Instead, it has only led to systems with kludged-on and slapped-together features. Workflow engines, clinical decision support, interoperability, and user configurable interfaces – in fact, the very idea of usability—are features one expects in productivity software, not patient data repositories.    Look again at the definitions of the electronic health record that have been offered over the years. Care quality, clinician productivity, and patient safety are never mentioned as part of the core definition.  This is fitting because paper and electronic records were never intended to be anything other than what they are defined as being—data archives.  We have been working from a requirements mindset that is focused on producing records/archiving systems and not clinical care systems.

Look at the types of criticisms lodged at current EHR systems.

  1. Poor usability
  2. Hard-to-navigate interfaces
  3. Difficult to learn
  4. Not good at sharing information/ poor interoperability
  5. Poor at population health management
  6. Not ideal for sophisticated reporting
  7. Difficult to implement
  8. Implementation results in decreased productivity
  9. Workarounds are common
  10. Poor support for workflow/no user-configurable workflow
  11. Decision support clunky

These complaints arise because EHR systems are being used as clinical care support systems, which means they should enhance the productivity of clinical professionals and support their information needs, not hinder them.

Why not take a new approach to clinical software systems?  Why not go back to the drawing board and this time say exactly what we want—systems that support the work of clinical professionals.  Software systems conceived primarily as clinical care support tools have design goals and requirements that differ significantly from systems conceived primarily as record systems, and they should be defined accordingly.

The advent of the clinical care system
The most fundamental aspect of clinical care is the ongoing interaction between patient and clinician.   These interactions are a series of processes that involve the sharing, review, collection, analysis, interpretation, and production of information.   The information required by clinicians is comprised of more than patient data; it also includes detailed information on drugs, diseases, terms/codes, guidelines, etc. Productivity requires that the right information be presented at the right time, and that clinical professionals be able to adjust processes and information consumption/production.  Clinical care is also collaborative. As such, systems that support clinical care must support collaboration between any number of clinical professionals.    Finally, clinical care systems must be easy to learn and use.  Weeks of training should not be required to learn how to use a system that purports to help with the things one does numerous times each day.

Definition:  A clinical care system is a software system designed to support role-based clinical processes at the point of delivery while maintaining a legal record of the patient’s data as well as clinical actions and interventions.  Clinical care systems must be able to adapt to end-user needs (for example, by offering user-configurable workflows and user interfaces).  Collaboration between clinical teams or individuals must be easy to initiate and manage.   Cross-cutting issues (e.g., security, interoperability, performance, etc.) should be optimized for clinical environments.   Properly designed clinical care systems promote and assure safe, effective care.

 Consider this definition/description of a clinical care system. Notice how much it focuses on patient care process support.  At this point, you may be thinking that the distinctions being made are subtle and unlikely to result in much of a difference between systems that start with a records/archive definition versus those that begin with the above definition.  If so, consider how starting from the concept of archival software differs from starting with the concept of process-oriented software.

System development based on an archive paradigm usually starts with a data model that focuses on nearly exclusively on patient data (e.g., labs, demographics, radiology, problems, and medications). Next, software is created to populate that data model.  Notice that the data are the most important story here, not clinical care.  This approach is seen in most modern EHR systems that have very poor or zero support for workflow/processes (with attendant usability problems). Yet, these systems purport to help clinical professionals do their everyday work.

Here are a few characteristics of systems primarily designed to support clinical care processes.

  1. Provides a user interface designed to promote ease of learning and productivity –aiding in faster implementation
  2. Provides real-time decision support for clinical professionals based on mature workflow technology
  3. Has on-demand population management reporting and functions
  4. Offers workflow management capability and user-configurable workflows
  5. Provides user-configurable  interfaces
  6. Has tools that support real-time collaboration between an arbitrary number of clinical professionals
  7. Keeps detailed records of all activities and provides reporting capabilities that meet clinical, legal research, and regulatory needs
  8. Offers modular components that address security, interoperability, and other key needs

Designing systems to support processes and workflows must start with those processes and workflows as a foundational paradigm, not with a data model.  Process focus starts with what clinical professionals do, the information they need, and the roles they perform in delivering care.  Processes must be accorded a level of importance equivalent to that historically given to data.

Yes, today’s EHR systems can be retrofitted, renovated, or otherwise altered to better support clinical care.  However, as with renovating a home, it costs nearly twice as much (time and money) to renovate as it does to build from scratch, and even so, the constraints imposed by the original design never go away.   The angst on the part of vendors that resulted from the imposition of MU measures, and accompanying certification requirements, illustrates this principle quite well. Ironically, the EHR incentive programs have simultaneously driven EHR system purchases and exposed their design flaws.

Transforming health care through the use of information technology requires systems that intimately support healthcare processes and clinical work.  It is time for a new approach to software systems that support clinical care.  The answer to current electronic health record problems is not newer, more innovative electronic health record systems; it’s clinical care systems.

Facebooktwitterpinterestlinkedinmail

Leave a Comment

{ 10 comments… read them below or add one }

Ron May 19, 2014 at 1:28 PM

“Why not take a new approach to clinical software systems? Why not go back to the drawing board and this time say exactly what we want—systems that support the work of clinical professionals.”

Unfortunately, because the money’s all spent.

Ron

Reply

Jerome Carter May 19, 2014 at 4:20 PM

Yes, the incentive programs have hit a snag, and vendors are having a hard time with certification. However, the incentive programs and certification are time-limited. Electronic systems are in place and will need to be replaced and upgraded. What is needed is a path forward for electronic system development that makes sense. Here is my suggestion: http://ehrscience.com/2014/05/19/is-the-electronic-health-record-defunct-part-ii-an-architecture-for-clinical-care-systems/

As for MU misery… http://ehrscience.com/2012/09/17/ehr-certification-2014%E2%80%94darwinian-implications/

Reply

Ron May 20, 2014 at 10:03 AM

The question isn’t whether the EHR systems that providers have bought (in anticipation of HITECH funds / Medicare penalties) are the right systems (they’re not).

The questions are:
– How long will it take to replace them with something that actually addresses healthcare providers’ needs?
– What sticks and/or carrots will it take to get them (healthcare providers) to (re-) invest the funds necessary to make this happen?
– Will the health IT marketplace offer systems in line with what you describe (and will providers make good choices)?

Ron

Reply

Jerome Carter May 20, 2014 at 10:59 AM

It will certainly take time before systems are available to meet providers needs because building better systems requires a new approach to clinical system design. Current vendors are not likely to be the ones who create the next generation systems. The new system will come from vendors that are just entering the market. There is a reason why Nokia, Blackberry, and Motorola did not invent the iPhone…

Reply

Thomas Beale May 13, 2014 at 2:00 PM

For many reasons including some you state here, we left the standard ‘classical’ software development approach behind in 1998 in order to develop openEHR.

In the classical approach, the domain semantics are trapped in software code and relation (or maybe other) database schemas. That’s not scalable or adaptive. So we don’t do it.

You do need an EHR repository, but to connect it to real world workflows, the content models of the data need to exist in a clinically managed modelling space. We’re not completely there yet on workflow of course, because the semantics of even simple things like _shared_ care plans and single source of truth medication lists are non-trivial. But we can deal with them, because they are not in the data model or DB, they are in the content models and service layer.

– thomas

Reply

Jerome Carter May 13, 2014 at 3:31 PM

Thomas, thanks for your comment. I agree that we need an EHR repository, and I like the work you are doing with openEHR and archetypes.
My issue with current EHR systems is that they are repositories at heart while trying to be something else—and not succeeding. These systems tend to be front-ends to relational databases, which as you state, ends up with domain semantics entangled with software code and data schemas—a mess.

Looking from a high level, I see a four key divisions that arise in trying to build clinical systems, and unfortunately, thus far, they have been confused and co-mingled. Failure to clearly separate and optimize each is, I believe, the root cause of difficulties in designing next-generation clinical systems. Here are what I see as being the main divisions:

1. Patient information – this is data about the patient–problems, labs, histories, meds, etc.. This requires semantic controls and algorithms for managing this information set. My impression is that this is what openEHR/archetypes are about. Terminologies are located here as well, as are the tools required to manage them.

2. Patient information management system – this is a production-quality software system that is designed to manage and provide access to patient information. In my view, this is the electronic health record. This is where functions required for a legal health record reside.

3. Process support information – this data set captures task sequences and information required to support tasks. It includes resources (people, software), task input/output data requirements, environmental info (location, active processes, etc.) and role information at a minimum. In my view, clinical decision support lives most naturally here.

4. Process support management system – this is a production quality system that clinical professionals use at the point of care. It uses process information to support clinical work. This is what I now refer to as a clinical care system.

Each of these areas presents hard problems that require research, and progress necessitates that each be recognized for the intellectual challenges it presents. I am convinced that there is sufficient commonality between these areas such that is it possible to create a mathematically-based theory that ties them all together. Time will tell…

Jerome

Reply

Scott Bower May 7, 2014 at 10:05 AM

I whole-heartedly agree.

The analogy of constraints around renovating a house or building from scratch couldn’t be more illustrative and very useful. Many people outside of the space wonder then why disruptive systems have not gained a foothold. In fact, there is quite a bit of momentum on reporting on this in the larger media outlets. The status quo, for a number of factors, will remain for awhile.

It is interesting to see that the big players in technology have shifted to China, where, there are no patient rights or protection, and no legacy tools or business models based on security first rules. They see a playground ahead. In presentations from the large research school, institutions, and companies I sense a restrained gleeness about that. They say that what is learned can be brought back to the United States and Europe. So, the systems imagined here, are in fact, built and and running in China. The troubling side of this,is in the quasi-public well funded ethnographic studies of the people interacting with health services there.

I would also say that the industry is primed for compartmentalization, specialization, and a need to strictly control definitions of things. Systemic concepts such as “Clinical Decision Support” is a separate “product”, should be thought of as a separate thing, with separate teams of people. Seeing this applied to the old systems is only adding to the mountain of complexity. Rather than “loosely-coupled” approaches we see in Wolfram services where analytical structures are the heart of the system, we have repositories that do not even have the concept of tagged data.

It is unfortunate that the true nature of User Centered Design criteria in MU is really misunderstood. I see “process centered” mentioned alot. It is really unfortunate that “Activity-Centered Design” was not socialized and mainstreamed as it also plays a huge role in emerging agile development practices. I think some tool makers see the word “user” and say to themselves… “that must mean that hiring a doctor or a nurse to define and run a solution, the way we have been doing things for decades, is the right way.” That is not at all what the process itself prescribes.

Reply

Jerome Carter May 7, 2014 at 11:02 AM

Scott, I agree that there must be more specialization, compartmentalization, strict definitions etc. In the last year or so, I have begun to completely rethink how clinical care software is designed. Loosely-coupled, modular software with an up-front emphasis on clinical work is the way to go.

Reply

Baby Djojonegoro April 29, 2014 at 6:16 PM

“Ironically, the EHR incentive programs have simultaneously driven EHR system purchases and exposed their design flaws.”
Exactly. Only after using the product can one fully understand its flaws–then design a better one.

Reply

John Sharp April 28, 2014 at 9:40 AM

This fits with many of the ideas from the JASON report from AHRQ: A Robust Date Infrastructure http://www.healthit.gov/sites/default/files/ptp13-700hhs_white.pdf

Reply

Previous post:

Next post: