Cell phones made telephone technology much more useful–no more searching for a phone booth or waiting at home for a call. Cell phones quickly evolved, eventually bringing us the much-loved Blackberry. Blackberry smartphones moved beyond calls to encompass a range of communication modes. However, despite the gap in features and utility between the Blackberry generation of smartphones and the bricks that started the mobile craze, pre-iPhone smartphones remained true to their origins, physical keyboards and all. Phone manufacturers were competing in trying to build the best telephone. They created products that people loved, but they (and their products) were trapped within the telephone paradigm.
EHR systems seem to be following the Blackberry evolutionary path. Designed around the idea of an electronic chart, EHR systems, post MU, are hitting their evolutionary peak. Data-centric thinking is deeply ingrained in all current EHR systems, and vendors are diligently maxing out that paradigm.
Office-based EHR systems are improving. They are, for the most part, better charting tools than they were 10 years ago. More vendors are discussing workflow openly, and usability is widely acknowledged as something to be addressed. However, I sense a lull–the kind that comes before everything changes, when companies are refining refinements and not coming up with new ideas. Just as smartphone vendors did not foresee an iPhone in their futures, the same thing will happen with EHR vendors.
Blackberry-esque smartphones were cell phones that allowed one to surf the web, message, email and perform other communications functions. However, they never strayed too far from telephone basics of exchanging messages (written or spoken). The iPhone on the other hand was a portable computer that allowed one to communicate a wider range of information (photos, video, geo-location, movement, audio, music) as well as the usual computer stuff. The iPhone was a really a programmable information toolkit that one could adapt to suit one’s needs. Adaptability won.
Now, bring this thought into the realm of EHR systems. We have electronic charting systems that are being improved to better support clinical work and clinical workflows. But, what if, evolution-wise, those designs are maxed out? How many usability problems are simply the results of asking repositories to become workflow assistants?
In the past, I have spoken of having a clinical software platform onto which one could build whatever functionality one desired. That was the basic idea behind the Building Clinical Care System posts. Having gotten my hands deep into iOS programming, I see the world in terms of specialized apps more than monolithic software systems. Every major EHR vendor is opening up its main product and calling it a “platform.” However, just as a Blackberry could not simply morph into an iPhone, a system designed 15 years ago to be an electronic record cannot simply shake off its origins and suddenly become something else. Database schema that underlie current ER systems have captured a certain way of thinking, a view of care delivery that cannot be easily set aside. Products can allow add-ons, but they do not become platforms simply by being called that. Dress them up as you might, but EHR systems are still charts.
Thinkertoys is a great book that offers a variety of creativity exercises. Reversal is one of them that seems apt for rethinking clinical care systems. Using reversal, one states an assumption, then reverses it to generate a new view of the problem. The author offers a few restaurant examples. For example, restaurants are places with menus that one visits to obtain a meal. Reversing these assumptions one asks: what is a restaurant that brings a meal to you? That does not have a menu?
Going back decades, the goal of clinical care software design has been focused on creating an electronic record. The computer-based patient record was all the rage before being eclipsed by the electronic health record. Both cast support for patient care in the form of a charting/record system. The long unchallenged assumption is that charting systems are the best tools to support clinical work. Was this assumption based on years of studying the full range of activities in which clinicians are engaged on a daily basis? Nope. The medical record is a file that contains the outcomes of clinical work—notes, results, problems, meds, etc. The actions that led to those outcomes—reviewing results, calling patients, interacting with colleagues, reading guidelines—that is, the actual work clinicians do, goes largely unnoted. Charting systems are not flexible tools that one can readily adapt to fit the work at hand, which is something a true clinical care system should be able to accommodate.
Let’s look at the underlying assumption that seems to be prevalent among EHR vendors: A clinical care system is a longitudinal repository of patient information that allows add-ons to support clinical work. Now let’s reverse that assumption: A clinical care system is a software system that supports clinical work and clinical processes and keeps a longitudinal record of patient information. Which type of system is most likely to have the best support for clinical work as part of its base architecture and functionality profile?
Much of what clinicians do every day takes place outside of patient encounters. Care coordination, results management, and patient communications outside of direct encounters account for a good chunk of clinician time, yet EHR systems are only now beginning to have these features. And even then, they are mainly glued on. One must ask why these functions, which significantly impact care quality and clinician workloads, are only now getting much attention? The answer is simple: The focus has always been on data, not processes.
Interestingly, whenever I discuss making processes a primary design focus, everyone assumes I am speaking of automating guidelines and such—nope. Automated guidelines are, like semantic interoperability, one of the Holy Grail quests of informatics that have seen years of work and research dollars with limited practical returns. No, I am talking about providing process support that will help clinicians get home an hour earlier or manage a population of patients more safely and with fewer errors. That doesn’t require smart computers or complex ontologies. It does require paying attention to the little things that happen hundreds of times each day and making them easier for clinicians to manage.
Process support for results management, care coordination, and other everyday clinical processes is doable with workflow technology available today. The data management components needed to build flexible, process-focused clinical care systems are quietly maturing, largely unnoticed. However, looking at the literature and commercial products, it is obvious that few are working on that approach. Meanwhile, EHR vendors are absolutely insisting that they are building workflow support into their EHR systems, even though those systems continue to have hard-coded workflows and lack explicit process support.
Looking at a problem in a different light leads to innovation. Smartphone makers learned that lesson in 2007. Clinical software vendors don’t have long to wait.