Good software designs help users become more efficient and productive. Often, determining what constitutes a good design is not straightforward. While wearing my entrepreneurial hat, I came across a great book that has given me a new perspective on product development and, unexpectedly, EHR design.
Thinkertoys, Second Edition, by Michael Michalko, focuses on business creativity in a way that is both fun and effective. My OneNote workbook is filled with ideas that resulted from performing exercises in this book. One key lesson that I learned from Thinkertoys is that one should learn from past experiences without being trapped by them. From the standpoint of EHR systems, it raises the question of how much current EHR design is hindered by paper-based thinking. By paper-based thinking, I mean the unconscious (or conscious) use of the essential properties of paper records when considering electronic record designs. Perhaps the best way to explain what I am getting at is with a personal anecdote.
While in college, I had to take the usual liberal arts courses in the humanities and social sciences. Every course seemed to require at least one book report or paper, which terrified me–not because I feared writing, but because I could not type. My choices were either begging professors to accept handwritten papers or finding someone to type them for me. My dread of typing ended when a friend convinced me to buy a copy of Bank Street Writer to go along with my new Apple IIe.
My past encounters with typewriters had always involved a lot of white-out, balled-up sheets of paper, and angst. Bank Street Writer did not improve my typing skills; it made mistakes easy to change. I have been typing ever since. Bank Street Writer was, in essence, an electronic typewriter that eliminated what irked me most about real ones.
Once I began to write more complex documents, the limitations of Bank Street Writer became obvious and irritating. Whereas initially I was happy to be able to easily correct errors, soon I longed for spelling help and more formatting control. Now, I cannot live without features such as spellchecking, track changes, grammar hints, and access to add-ins. Modern word processors are much more than electronic typewriters because they have conceptual underpinnings that differ significantly from early software such as BSW. They make use of computable concepts such as documents, sentences, versions, dictionaries, etc. and make them accessible via an application programming interface (API). The point here is that BSW was designed using a typewriter as its inspiration (i.e., typewriter-based thinking). In contradistinction, modern word processors model the data and processes involved in writing, document creation and management. The former is an electronic typewriter; the latter, a writing assistant.
How does this relate to EHRs? Paper records are passive archives that capture information about patients and their interactions with healthcare providers. The post, From Data to Data + Processes: A Different Way of Thinking about EHR Software Design, noted the continued sway of paper-based thinking on EHR designs and public discourse. This is old news. The challenge that we currently face is re-envisioning what EHR systems are, and what they should do. As with the typewriter-to-word processor evolutionary path, the key is realizing that the ultimate goal is creating systems that truly assist caregivers, not building electronic paper records.
What is today’s EHR equivalent of Bank Street Writer? It is an application designed with the idea that the repository is the most important system feature, and one in which the user interface is geared primarily toward data entry and validation–what I refer to as a data-oriented system. Such systems maintain the traditional mindset that, as with paper records, recording data is the main goal of those using the system, not being more productive and efficient. Systems designed in this manner lack computable internal representations of clinical concepts. They accept information from users, validate it, and submit it to the database. They contain no explicit representations of workflow, patient state, temporal progression, or other concepts critical to clinical care. As a result, adding functionality such as decision support, which encompasses all three of these factors, is problematic.
Please don’t misunderstand my position. I am not saying that data-oriented systems have no value. Data-oriented systems are quite useful. They can provide remote access to records, improve charge capture/billing, eliminate the storage requirements that accompany paper records, and decrease the need for medical records staff–no one can argue with these benefits. However, as a rule, data-oriented systems perform better as administrative assistants than they do as patient care assistants, and therein lies the problem.
Obviously, I believe computable representations of clinical concepts are essential for creating innovative EHR designs. Traditionally, informatics researchers have focused on big issues such terminologies, ontologies, and guidelines automation, while paying less attention to codifying concepts that may be more mundane, yet computationally critical for EHR designs. Workflow is a good example. There has been a lot of work on guideline representation, but not nearly as much on identifying and quantifying basic units of work in clinical settings. Moreover, there is no agreed upon representation of clinical workflows for either analytical or computational purposes. Patient state is another example of a concept that is critical for EHRs that assist in care processes and advise on interventions, but for which there is no agreed upon representation or definition.
In an earlier post, The Informaticist-Programmer Interface: What Do You Mean By That…?, I suggested that better software designs required closer collaborations between informaticists and software developers. I would like to take that idea one step further and suggest that we need a group of clinical informaticists who focus specifically on the analysis and modeling of clinical concepts for computational purposes. They will require training that differs significantly from current approaches because they will need a better grounding in discrete mathematics, domain analysis techniques, and programming. Programming skills are essential because researchers who can readily test their conceptualizations would likely avoid wasting time on ideas that sound great on paper, but cannot be implemented in real systems.
Creating EHRs that actively and reliably assist in patient care requires rendering an array of clinical concepts in computable form. This, in turn, will require a cadre of specially-trained informaticists from a range of health professions who draw design inspiration, not from paper records, but from the everyday challenges that arise in clinical care.