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.
- Poor usability
- Hard-to-navigate interfaces
- Difficult to learn
- Not good at sharing information/ poor interoperability
- Poor at population health management
- Not ideal for sophisticated reporting
- Difficult to implement
- Implementation results in decreased productivity
- Workarounds are common
- Poor support for workflow/no user-configurable workflow
- 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.
- Provides a user interface designed to promote ease of learning and productivity –aiding in faster implementation
- Provides real-time decision support for clinical professionals based on mature workflow technology
- Has on-demand population management reporting and functions
- Offers workflow management capability and user-configurable workflows
- Provides user-configurable interfaces
- Has tools that support real-time collaboration between an arbitrary number of clinical professionals
- Keeps detailed records of all activities and provides reporting capabilities that meet clinical, legal research, and regulatory needs
- 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.