Building software, like building a 50-story skyscraper, takes planning. One has to determine functional objectives, technical specs, settle on an architecture style, and other concerns. Start work without sufficient planning, without a blueprint, and failure will be the result. Knowing what goes into developing software systems helps to inform how one addresses a problem using software.
I spent the morning thinking about this after reviewing the AMA’s recent document on EHR usability. In Improving Care: Priorities to Improve Electronic Health Record Usability, the AMA lists eight usability priorities as outlined below.
- Enhance Physicians’ Ability to Provide High- Quality Patient Care. Effective communication and engagement between patients and physicians should be of central importance in EHR design. The EHR should fit seamlessly into the practice and not distract physicians from patients.
- Support Team-Based Care. EHR design and configuration must: (1) facilitate clinical staff to perform work as necessary and to the extent their licensure and privileges permit and (2) allow physicians to dynamically allocate and delegate work to appropriate members of the care team as permitted by institutional policies.
- Promote Care Coordination. EHRs should have enhanced ability to automatically track referrals and consultations as well as ensure that the referring physician is able to follow the patient’s progress/ activity throughout the continuum of care.
- Offer Product Modularity and Configurability. Modularity of technology will result in EHRs that offer flexibility to meet individual practice requirements. Application program interfaces (APIs) can be an important contributor to this modularity.
- Reduce Cognitive Workload. EHRs should support medical-decision making by providing concise, context sensitive and real-time data uncluttered
by extraneous information. EHRs should manage information flow and adjust for context, environment and user preferences.
- Promote Data Liquidity. EHRs should facilitate connected health care—interoperability across different venues such as hospitals, ambulatory care settings, laboratories, pharmacies and post-acute and long-term care settings. This means not only being able to export data but also to properly incorporate external data from other systems into the longitudinal patient record. Data sharing and open architecture must address EHR data “lock in.”
- Facilitate Digital and Mobile Patient Engagement. Whether for health and wellness and/or the management of chronic illnesses, interoperability between a patient’s mobile technology and the EHR will be an asset.
- Expedite User Input into Product Design and Post- Implementation Feedback. An essential step to user- centered design is incorporating end-user feedback into the design and improvement of a product. EHR technology should facilitate this feedback.
I am happy to see the AMA tackle the issue of EHR usability. It is wonderful to see doctors taking an active interest in software design and functionality. The AMA framework seeks significant changes in clinical care systems, and the issues raised in this document are good starting points for improving EHR systems. The question, of course, is how to move from a list of desirable features to a buildable blueprint. And, as the Bard might say, “…there’s the rub…”
Creating software is never easy. Even when a detailed blueprint is available, coding and testing take time for complex systems. However, when the blueprint itself has to be created, the path to the final system is much less straightforward. Some problems are simply hard, requiring experimentation and creative insights to arrive at solutions. Success cannot be mandated, and adding more developers does not necessarily help. I make this point because there seems to be an underlying assumption in discussions about EHR systems that building usable, interoperable systems is pretty much a matter of vendors simply deciding to do so. Few seem to appreciate that no one really knows how. Let’s look at a few of the AMA’s eight points to see what is involved in building software to address them.
Support Team-Based Care
Given the changes in healthcare delivery, support for team-based care is desirable in an EHR system. Notice that one function mentioned by the framework is facilitation of clinical work. Now, in order for an EHR system to facilitate clinical work, there must be some computable model of clinical work available for the system to consult. The model need not be complex, but one must exist. Unfortunately, no standard model of clinical work exists. As a result, every vendor that attempts to offer support for team-based care will have to invent its own model, and doing so requires research and experimentation.
Reduce Cognitive Workload
The framework states, “EHRs should support medical-decision making [sic] by providing concise, context sensitive [sic] and real-time data uncluttered by extraneous information.” Like support for team-based care, supporting information needs requires models of clinical work; but not generic clinical work—everything must be role-based and context-sensitive. How should the screen for an endocrinologist differ from that of a general internist when seeing a patient with hypothyroidism? Should they be the same or different? What does concise mean exactly? Which data elements should be displayed? These are research questions.
Product Modularity and Configurability
What are the basic EHR modules? How is such a thing determined? Is it based on chart functionality (e.g., problem list, med list), data categories (e.g., medications, labs, notes), or software components (e.g., user interface, data access layer, report generator)? Should modules be plug-and-play like WordPress plugins or more like iOS apps?
I am not trying to put a damper on the AMA’s efforts or those of anyone else who wishes to join the dialog about improving EHR systems. What I am trying to get across is that building complex clinical software systems requires far more basic research than is being acknowledged.
Consider how much difficulty EHR vendors have had meeting MU certification requirements. The changes required by MU were neither conceptually difficult nor did they require creative thinking or basic research to determine how to code them. They were difficult for vendors because they changed the blueprints of standing buildings. And, like any renovation, changes to standing buildings are more difficult than starting from scratch.
Building systems with features in line with the AMA framework requires knowledge about clinical work and models of how information is used by clinicians, neither of which currently exists. The same is pretty much true of clinical systems architectures. Yes, EHR systems exist, but no one knows the ideal architecture or component design strategy to achieve robust, secure, interoperable, collaborative systems. In other words, there is no blueprint, and there is no source to consult that explains how to create such blueprints. To anyone who thinks that tweaking current systems is the way to go, I say: Remember what happened with MU Stage 2 certification.
Alteration of current products is not likely to result in systems that reflect the AMA’s framework. The time, money, and effort required to convert current EHR systems into clinical care systems that support clinical work is likely greater than most companies would care to expend (see Is the Electronic Health Record Defunct?). Therefore, I expect the next generation of systems will come from new companies and not current market leaders (see Disruption in the EHR Market: Will Anyone See It Coming? ).
Building usable, interoperable systems that intimately support clinical work will require creativity, research, patience and, I imagine, some amount of luck (or serendipity if you prefer). In other words, the road from here to there is not on a map. There are a lot of challenges, so let’s acknowledge this and get going. Those blueprints will not design themselves.