Currently, there is a thread on the AMIA Clinical Information Systems Workgroup Group listserv that focuses on the problems/issues encountered during EHR/CIS implementation. One commentator insightfully pointed out that, over the years, there have been many efforts to understand and alleviate the problems that plague software implementations. As I have mentioned in previous posts, implementation success (or the lack thereof) has been an ongoing interest of mine for years. In fact, What Constitutes a Successful EHR Implementation?, one of my earliest posts, addressed this issue.
Every EHR implementation should begin with detailed objectives that specifically address how the organization should be different in terms of clinical outcomes measures (e.g. quality, errors), economic measures (e.g. ROI, revenues, profits), and operational improvements. Absent a list of detailed objectives, it is difficult to tell at any point during the process how well an implementation is proceeding. Of course, this is old news (see Software Runaways and Why Do Healthcare Information Systems Succeed or Fail, two of my favorite introductions to implementation issues).
Obviously, software architecture/design also plays a role in how easily EHRs are implemented and used. My recent foray into software design and architecture has helped solidify my understanding of the problems encountered in clinical software design. A surprising idea came to mind while mulling over these issues: Do some aspects of poor software design arise, not from inattentive or inadequate software engineering, but rather from an unchallenged belief that software is complex and implementing it must necessarily be complex as well? Such a mindset presupposes that EHR projects must necessarily require selection committees, project managers, multiple varieties of consultants, and be disruptive. What do you think? Is EHR software (or any major software system) difficult and costly to select and implement because its design and deployment are unavoidably and irreducibly complex OR do EHR designers, assuming the presence of a cadre of consultants, IT personnel, project managers and trainers, (consciously or unconsciously) forego the extra design steps required to make implementation and optimization easier?
I am not trying to assign blame here; rather, I am trying to sort out “the way things have always been” from “the way things have to be.” This is a valid question because of what we have seen on the consumer side of computing.
Let’s go back to the 1980s and look at the consumer PC market. When buying software and hardware required extra knowledge or specific expertise, uptake was slow. Anyone remember WordStar and trying to remember a slew of cryptic key combinations? What about trying to configure a sound card by flipping DIP switches? I certainly provided advice to my share of people desperate for help. However, when GUIs and Plug-and-Play hardware arrived, the questions stopped.
The same pattern repeated with local area networking. Remember when getting a five-station LAN up and running required the services of a Novell Netware engineer? My wireless card detects 16 networks on my block, and my neighbors are not network engineers! What do these examples have in common? In each case, hardware and software were specifically redesigned in ways that eliminated the need for special expertise in order to utilize them.
There are plenty of current examples of software design choices that might make implementation and optimal use of EHRs easier.
Detailed data dictionaries and reporting engines – Software users should not have to wonder where/how their data are stored, nor have to jump through hoops in order to perform useful queries.
Programmable workflow engines — Workflows are hardcoded into most EHR systems, and clinical decision support (CDS) is best integrated within clinician workflow patterns. Programmable workflow engines could make CDS easier to test, implement, and deploy.
Modular design (software plug and play) — We have seen this concept explode on mobile platforms and in content management systems in the form of apps, widgets, plugins and themes. There is no reason not to bring these ideas to clinical systems. (The Smart Project advocates this type of platform-based approach).
Configuration tools – Complex software systems should provide extensive configuration capability for key features without programming (i.e., configuration instead of customization).
Software products that feature the four design elements mentioned above should require less time and cost less to implement than systems requiring significant programming in order to attain equivalent functionality. It’s time to rethink EHR design, keeping in mind the specific goal of making implementation easier. After all, when was the last time you sought the help of a Novell engineer? Just sayin…