AMIA’s EHR 2020 Task Force Report has joined the chorus of those calling for better EHR systems that can act as smart clinical care assistants. As with similar reports, there is a call for improved usability and workflow support. Now that AMIA’s voice has been added to the list of organizations acknowledging the need for significant changes in EHR systems, the key question, of course, is how to bring about the desired changes.
Software functionality always boils down to architecture and design. Current EHR systems are conceptualized and designed to be repositories of patient data, which is very different from the smart clinical care assistants with the workflow support everyone is demanding. Creating smart clinical care assistants will require more than simply tweaking current EHR systems and new, more robust, data models. There are four major functional areas that must be addressed to deliver the capabilities being called for by AMIA and other groups.
Every current EHR system has a proprietary data model. Interoperability requires the complex task of translating between two arbitrary data models. Interoperability would be more tractable if there were a shared information model that everyone could reference.
The legal health record
The legal and administrative roles that the paper charts filled (e.g., subpoena, release of information, etc.) have to continue for the foreseeable future. Clinical systems must take these needs into account.
Process support is important for every aspect of clinical work. Decision support, collaboration/coordination, results management, patient engagement, and note creation, to name a few, are processes that require workflow support. Next-generation systems must have deep support for workflow technology. The report identifies many workflow issues, but oddly fails to mention in its recommendations the substantial amount of workflow research that has been done over the last 20 years in the BPM community and the maturity of current workflow technology.
User control of the user interface
Finally, there is the matter of the user interface. It should be adaptable by each user. Providing end-user configuration ability is yet another significant architecture/design challenge.
The task force recommendations are certainly safe, and hard to argue with. After all, who could possibly be against more end-user involvement in product design, more innovation, and less onerous certification processes? However, the basic problem is being ignored: the electronic health record—a repository of patient information—is the wrong model for building smart clinical care assistants. Until this fact is acknowledged, we will continue to waste time trying to retrofit the electronic health record into something other than what it was conceived to be – the electronic successor to the paper chart. Charts are not active; they do not assist.
Electronic records faithfully replicate problem lists, medications lists, lab reports, and other paper chart features but fail to offer workflow support. The absence of true workflow support in EHR systems pre-dates MU and its requirements. Thus, the lack of workflow support is due to the paper chart being used as a design metaphor, not MU or its certification burden.
Looking optimistically to the future without addressing the basic design issue of EHR Systems is unlikely to lead to real progress. One can ascribe as many future features/functions to EHR systems as desired. However, requirements and feature lists are simply wishes until implemented in real-world code. There have been two very detailed IOM reports on the computer-based patient record that listed many desirable software features and functions. Yet, tellingly, in the 24 years since the initial IOM report was released, no one has ever managed to build the computer-based patient record imagined by the IOM. Data models are not a good basis for designing process-aware systems.
I have spent a lot of time thinking about EHR design and how to create better ones. Those of you who read EHR Science regularly, are well aware of my suggestions for how we should approach the design of next-generation clinical software, which I refer to as clinical care systems. For those visiting for the first time, listed below are posts that offer my suggestions for how to move forward.
Why the electronic health record is not the best way to support clinical work
Is the Electronic Health Record Defunct?
Is the Electronic Health Record Defunct? – Part II: An Architecture for Clinical Care Systems
An architectural starting point for clinical care systems
Building Clinical Care Software Systems, Part I: Issues and Challenges
Building Clinical Care Software Systems, Part II: Patient Information
Building Clinical Care Software Systems, Part III: The Electronic Health Record
Building Clinical Care Software Systems, Part IV: Process Information
Building Clinical Care Software Systems, Part V: Supporting Clinical Work
Does care coordination require a special architecture?
Blackboard: An Architectural Pattern for Supporting Care Coordination?
Care Coordination and Clinical Care Systems: A Look at Clinical Work Support Needs
A philosophical look at clinical software design
Precepts for Clinical Software Design
Market forces as innovation drivers for clinical care systems
Disruption in the EHR Market: Will Anyone See It Coming?
Thinking about clinical data…
What is the Smallest Viable Unit of Clinical Data?
It is time to move beyond 1990s concepts of clinical software rooted in data models. Now that we have a consensus that something must be done, let’s try doing something different…