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.
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.
Categories: Uncategorized
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
good question…only 2 factors drive any action in this capitalistic country…$$$$$$ or fear of the lawsuit/ a lawyer;
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?
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 dystopia… unles you know of a wealthy benefactor who wants to fund such an effort.
“I like your Christ, I do not like your Christians. Your Christians are so unlike your Christ.” M.K. Gandhi
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!
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 software design will result in an increase in articles on topics related algorithms, interfaces, database schema, workflow representation, etc. There really needs to be a more substantive dialog among clinical professionals, software engineers, usability experts, and others if clinical software is going to improve significantly. Maybe professional societies can help to bring this about.
Jerome
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.
My question is “Is there a way my skills could be utilized to consult in improving EMR’s?” I’m an outside the box, right brained physician that can see efficiency issues/key strokes/mouse clicks/voice command options/etc. Appreciate any reply you feel up to giving, public or private. Thanks, very interesting!
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.
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.
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.
“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.
At present, perhaps not. However, only recently have I noted a general awareness concerning matters related to data ownership and use.
At present, perhaps not. However, only recently have I a general awareness concerning matters related to data ownership and use.
“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?
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.
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 want all providers to know what each is doing with re to a given patient encounter. The deeper reason was that digitization allowed thousands of stakeholders to study what is happening in health care and to make money.
The big elephant in the room is going to be patient privacy and security. It’s too easy for an expose like Silent Spring to come along, after the umpteenth hacking incident of patient records, and turn the entire populace against computerization of medical records.
It’s got to happen, unless we have super clever cryptology, and this whole effort will turn out to be a flash in the pan. We will be back to computerizing lab reports, radiology and discharge summaries…as of yore. Folks will see it is in their interest to make the record hard to read. This is how it was with our handwriting, embarrassingly bad but somehow useful.
“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.
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 scheme changes, remapping is necessary. And since each EHR system has a different internal scheme, many changes are specific to that system.
Now consider what this means for data sharing and reporting. Data must be mapped from an internal representation to one or more standards, transferred to the receiving system, and then mapped to the internal representation of the receiving system. Assuring that data contained in any arbitrary internal representation can be packaged and sent to another system with arbitrary internal representation is a hard problem that is grounded in design choices, not the basic nature of healthcare information.
Quality measures and similar care process information must undergo similar mapping/translation issues between standards and internal representations. Obviously, this is a lot of work.
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.
For those who might consider a standard data set to be a step toward commodity products, I offer that usability, features, cost, and any number of other factors would allow for plenty of differentiation between products.
This is all about design. As the number and types of functions clinical care systems are expected to support changes, so must the design principles and choices upon which they are built.
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?
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 to move to electronic records: 1) saving money on paper records storage and support personnel, 2) having remote access to records while on-call, 3) being able to search all patient records efficiently (say for a drug recall), and 4) improving E&M coding. Early adopters found these aspects of EHR systems worth the effort of implementing them long before there was an incentive offered.
Current EHR products solve these problems, but introduce others. Productivity, efficiency, collaboration, security, mobility, data sharing, and care process support are the new problems. Unfortunately, the old designs will not work for new systems, and current market leaders are unlikely to perceive the need for any fundamental change until products demonstrating the new ways of doing things are on the market. Blackberry did not see Apple as a threat, and Amazon wiped out my favorite bookstore. Customers, however, have little trouble recognizing when viable solutions to their problems become available.
EHR vendors are wrestling with MU changes, which will continue for the next couple of years. As a result, they cannot put money into a completely new R&D track. However, companies that wish to build next-generation clinical care systems can safely wait for MU to stabilize then jump into the market. Recent surveys indicate that many providers want to switch EHR systems, so there will be a pool of early adopters for sufficiently innovative products. Products that emphasize provider productivity, ease-of-implementation, intuitive interfaces, seamless security and collaboration will have no shortage of buyers. Market leaders are only as relevant as their most recent product.
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.
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.
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.
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?
“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.
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.
“Is the electronic health record defunct?”
Well, that implies that at some point it was funct . . .