Now Here Is A Wonderfully Provocative Article On EHRs That Makes A Lot Of Sense To Me.

This appeared a little while ago.

Is the Electronic Health Record Defunct?

by Jerome Carter on April 28, 2014

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.

Lots more, and some recommendations on how to move forward are found here:

http://ehrscience.com/2014/04/28/is-the-electronic-health-record-defunct/

The last paragraph is just key and totally relevant it we are to really make a difference with e-Health going into the future.

Very important reading for all interested in the area.

David.