THCB

Is the Electronic Health Record Defunct?

flying cadeuciiWhen 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.

Jerome Carter is the author of Electronic Health Records, 2nd Edition published by the American College of Physicians. He blogs at EHR Science where this post first appeared.

Livongo’s Post Ad Banner 728*90

28
Leave a Reply

15 Comment threads
13 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
17 Comment authors
electronic medical record softwaresaveyourlungsAdam Rothschild, MD, MASteve_O'_Hank C Recent comment authors
newest oldest most voted
electronic medical record software
Guest

Software for Assisted Living Facilities and Long Term Care Providers. Features include eMAR, Care Plans, Nurse Assessments, Interoperability,Medication Management and many more.
click here

Steve_O'_
Guest
Steve_O'_

“I like your Christ, I do not like your Christians. Your Christians are so unlike your Christ.” M.K. Gandhi

Hank C
Guest

Admittedly, there are a lot of issues with the processes that have been taking shape, but managing data is going to be a keystone in health care course correction. Thanks for the article!

Wayne Belling
Guest
Wayne Belling

As a practicing physician, I’m amazed at the lack of perspective that EMR designers have had for the Physician (and their staff). There are hundreds of little things that a practitioner comes across routinely that could be done more efficiently. For example screens that call for input after which 99.9% of the time we would hit an “OK” or “Accept”. Those options should be available by hitting “Enter”; NOT by leaving the keyboard, finding the mouse, moving the mouse and THEN left clicking the “OK” or Accept” option. This is a small part of why it takes so much longer.… Read more »

Jerome Carter, MD
Guest

Hi Wayne, thanks for your comment. I am glad to hear of your enthusiasm for improving EHR systems. For a long time, providing such input could only be done via product user groups or through the technical contacts at one’s practice site. However, recently more clinicians are asking to have their voices heard, a trend I find very encouraging. Professional societies are looking for ways to influence system designs (http://ehrscience.com/2014/08/11/building-clinical-care-systems-part-v-supporting-clinical-work/). The AMA has joined in with its recently announced initiative (http://www.ama-assn.org/ama/pub/ama-wire/ama-wire/post/pushing-better-ehrs-physicians-taking-lead). You may wish to investigate the opportunities available through your professional society of choice. Perhaps the growing interest in… Read more »

MEDSEEK
Guest

Well-written article and you make some good points. This is certainly an important healthcare topic. Consumers/patients have high expectations and engagement with them is key.

Andrew
Guest
Andrew

Perhaps I missed it as I skimmed this (apologize in advance) but I thought it was generally being recognized that the purpose of these systems was really to gouge patients and insurers by making it far easier to bill for things that can’t easily be captured in a paper system?

This is really part of a neo-feudal plan from rent seeking monopolists who feel that they are entitled to $X a month for every citizen. If you aren’t paying at least $1000 a month for healthcare (the government “approved” one) you aren’t a good “citizen” and will be punished accordingly.

Christine
Guest
Christine

What a completely thoughtful and lovely written article. I do feel like it is important to keep the ehr software that we DO have and build upon it and make it more patient based.

Granpappy Yokum
Guest
Granpappy Yokum

“Users of electronic systems must give due consideration to how their data are used and by whom”

Do physicians really have the ability to determine this and/or any ability to control it?

Jerome Carter, MD
Guest

At present, perhaps not. However, only recently have I a general awareness concerning matters related to data ownership and use.

Jerome Carter, MD
Guest

At present, perhaps not. However, only recently have I noted a general awareness concerning matters related to data ownership and use.

William Palmer MD
Guest
William Palmer MD

Look up IMS Health Holdings in the SEC. It has many of the health records of 500 million people , and it sells these to all kinds of businesses. It’s a valuable process for us–docs, nurses, and all providers–to document a health care encounter. Drug firms, insurers, durable equipment makers, life insurers, medical schools and educators, researchers, hospitals, medical groups like the AMA, policy people and government planners…and dozens of other interested parties will pay for this data. The naive primary etiology of the EHR was to clean up drug errors and to allow care coordination. This means that you… Read more »

Jerome Carter, MD
Guest

Data ownership and usage are important issues that must be addressed in a substantive way. Users of electronic systems must give due consideration to how their data are used and by whom.

Security is a major concern, and I wonder how many healthcare organizations place appropriate emphasis on not only unauthorized access, but also disaster recovery and business continuity.

John Irvine
Guest
John Irvine

Interesting points. I disagree.

You’re a market force.

As are the docs I hear forcefully advocating for better usability, smarter tech policies and better integration of the practice of medicine into their clinical workflow.

That may not make a difference now, but it will.

Talos
Guest
Talos

Currently, the tail of technology continues to wag the dog of medicine and patient care. There are no forces in the market to require EMR vendors to change. When EPIC has a market share of almost half of the market for enterprise EMR (41 or more providers) and the cost of mapping old data into new systems (due to “incompatibilities”) is prohibitive to new vendor system adaptation, along with increased regulatory demands which serves to protect current EMR vendors, there is little interest for other vendors to enter this market with a different product due to the prohibitive cost.

Jerome Carter, MD
Guest

Innovation is about seeing the current problem as it really is. Cars were a solution to the problem of more efficient transportation for small groups. The iPhone was a more efficient way to manage communication of any kind of information, not just voice and texts, but also images, sounds, and documents. Once the actual problem at hand is understood, solutions follow. Electronic records are easier to access, and easier to share than paper records. Back in the late 1990s’, before the Internet and mobile computing, doctors who sought my advice on buying EMRs offered four reasons for why they wanted… Read more »

Granpappy Yokum
Guest
Granpappy Yokum

Slap an MU requirement on every cell call, and people will hate their iPhones.

The current problem is doctors being required to do MU, ICD, CPT, P4P, PQRS, and CYA busywork. They mistakenly think that switching EHR systems will address this. Will the next generation of EHRs be able to solve this problem?

Jerome Carter, MD
Guest

The items that you listed pertain to data semantics (ICD, CPT) or care processes (MU, P4P, PQRS). There is no standard data model for EHR systems even though they are, first and foremost, systems for managing patient data. Absent a standard data model, every EHR company creates its own data model. As a result, every EHR system has its own internal representation (element names, tables, relationships, etc.) for storing patient data. All of the required standards (ICD, SNOMED, RxNorm, CPT , etc.) and reporting requirements are layered on top of this. Every time either a standard or a product’s internal… Read more »

Granpappy Yokum
Guest
Granpappy Yokum

“If every vendor used a standard data set for storing patient data, it would make many of these issues moot, and thereby lessen the burden of owning a system”

From the practicing physician’s point of view, I’m not so sure. But thank you for the reply.

Adam Rothschild, MD, MA
Guest

I attempted to start a company a few years ago to build precisely the kind of software that you call for. Back in 2010, I even coined a term very similar to yours: a clinical command system (blogged about here http://blog.doctrelo.com/category/electronic-health-record-systems/). Alas, building such ambitious software is expensive, and the market forces make it nearly impossible to break in. I had to throw in the towel in order to feed my family. I, of course, agree that even the best of the current EHR software is bad. Alas, I fear that we’re destined for more of the same: an informatics… Read more »

Jerome Carter, MD
Guest

Sorry to hear that you had to pull the plug. MU has caused what I hope is a temporary damper on new products by providing piecemeal system requirements. Fortunately, that is slowing down and there are many more EHR buyers looking for good products. Have you considered a mobile-first strategy?

Whatsen Williams
Guest
Whatsen Williams

The vendors have not any accountability as do vendors of other medical devices because they have been provided a pass from FDA surveillance.

Systems that are safe, effective, and usable will not happen sans oversight with enforcement power.

sribe
Guest
sribe

“Systems that are safe, effective, and usable will not happen sans oversight with enforcement power.”

Bullshit. What we need is LESS federal interference, not MORE.

LeoHolmMD
Guest
LeoHolmMD

“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.”

Brilliant.

Granpappy Yokum
Guest
Granpappy Yokum

Health care big data is the greatest gold rush since, well, the California gold rush. Does anyone think that those who stand to profit from the electronic data stores we are creating will allow the requirements to be changed?

saveyourlungs
Guest
saveyourlungs

good question…only 2 factors drive any action in this capitalistic country…$$$$$$ or fear of the lawsuit/ a lawyer;

Don't Go Back to Rockville
Guest
Don't Go Back to Rockville

Great post. So blindingly obvious and yet so hard to get people to understand. Data isn’t the answer, data is the problem – at least for now.

Our confusion over what to do with our electronic records systems – how to build them – reflects our uncertainty over data.

Loved this line:

Ironically, the EHR incentive programs have simultaneously driven EHR system purchases and exposed their design flaws.

Granpappy Yokum
Guest
Granpappy Yokum

“Is the electronic health record defunct?”

Well, that implies that at some point it was funct . . .