Recently, I participated in a series of emails about creating teaching materials for a course on clinical software design. This may come as a surprise, but there are no books on the topic of clinical software design. Of course, there are plenty of books about clinical software systems, especially EHR systems, but none that describe in detail how to design and build clinical care systems.
One reason for the lack of books is that most clinical software is designed and built by commercial entities. The resulting systems are proprietary and the processes used to build them, trade secrets. In light of the recent statements from the AMA (1) and ACP (2) regarding EHR usability and support for clinical documentation, obviously more needs to be done. A general picture of desirable clinical care system features emerges from those reports and other sources. The ideal systems are modular, recognize that one size does not fit all, have explicit support for workflows, allow for a degree of end-user configuration, support collaboration and communication, and can easily share data. As I have said many times, requirements are wishes until rendered in code. So how do we turn wishes and user complaints into next-generation products? Guess what? No one knows for sure…
Vendors are not withholding features or deliberately building systems that underwhelm users. There is no conspiracy. They are building exactly what has been requested—electronic replacements for paper charts (see Is the Electronic Health Record Defunct?). Meaningful use, while a distraction for sure, does not explain why pre-HITECH EHR systems lacked workflow support or collaboration tools or could not readily share information. Those functions were simply not considered compelling at the time.
Consider current EHR products from another angle. A few major academic systems spent years and a lot of dollars developing in-house clinical systems. Yet many of those centers are abandoning their homegrown systems for commercial products. Why? VistA, an enterprise-level EHR system developed for VA Medical Centers, is free. Why has it not been widely adopted? VistA was built over years and could be readily customized, but still evinces many of the same issues seen in commercial systems (3, 4, 5). I am not knocking anyone. However, if, after years of effort, the brains and money at the VA and top academic centers were not enough to build the type of systems that are being demanded, then something more than commercial vendors listening to their clients is required. But what???
We need more experimentation with computerization of clinical concepts, and the details of those experiments need to be shared. While there are many papers available that discuss the EHR systems from the VA and academic centers, few papers discuss the nuts of bolts of coding the systems, object models, data models, or why specific designs were used or abandoned. Publications lack the information needed to extract design principles, engineering hints, or coding best practices. As more homegrown systems are replaced with commercial ones, it becomes less likely that this information will ever be shared. So how do we develop scientific and engineering principles for clinical care systems if no information is shared?
Simple EHR: a reference clinical care system
Perhaps creating a simple EHR system that could act as a reference clinical care system (RCCS) that anyone could download and work with is a good starting point. “Simple” means that the RCCS would begin with a few basic attributes (a user interface, standard data set, and clinical work models). Most problems articulated by clinicians involve one or more of these components, which is why I think they should be first. Starting with these basic components, researchers, hobbyists, entrepreneurs — anyone — would be invited to create a working implementation of a clinical care system that could be used to document visits. Such an approach would attract more minds while making it easier for all involved to share ideas, frustrations and breakthroughs using a common set of terms, concepts, and code.
An RCCS should NOT be constrained by trying to make it fit current informatics standards (e.g., SNOMED, CDA, etc.). Those standards are from a different era with a different view of clinical care systems. We are not trying to renovate the past, but invent the future.
There is no need to try and build a complete software system in a few months. The goal is promoting experimentation, which requires the ability to ask questions and challenge the conventional wisdom.
Clinical work models
Experts in usability, cognitive engineering, socio-technical theory, and human factors recognize the importance of workflow and information needs, but there is no standard way of annotating or describing clinical work concepts across these domains. (I’ll discuss clinical work models in detail in upcoming Clinical Workflow Center articles). Fortunately, clinicians are making clinical work support a high-profile concern (1, 2, 6, 7). Working with clinicians to build clinical work models is the next logical step. Again, experimentation is the key. Models must be testable, and testing should not be delayed for years. Starting with a basic notion of clinical work, a few models could be built, vetted, and tested with all the details and lessons learned made public.
Standard data set
A standard data set (SDS) defined for key patient record elements would provide a good foundation for experimenting with data exchange and data quality issues. A SDS would set standards for element names, codes, data formats, types, etc. Compliant data schema could be created from the SDS specification, allowing everyone to use the storage system of his/her choice while maintaining a standard information model. Every provider organization would have a unique SDS code and sharing data would consist of sending data in SDS format along with provider provenance information. Using SDS as described would simultaneously constrain meaning (semantics) while making data origin and movement explicit.
Years have been spent trying to create a system that could export an arbitrary set of data elements from one EHR system’s proprietary data model, encode them within a rich semantic framework, then have them imported into a second arbitrary EHR system, which then decodes the semantic information and inserts those data into its proprietary model. This approach has not worked. HL7 V3 RIM, the exemplar of this approach, could have been designed by Immanuel Kant, and it would have been less obtuse. There is a reason FHIR is eagerly anticipated.
Sharing data is much easier if everyone shares the same definitions. Why not focus on the definitions instead of trying to build a universal translator? The purpose of data exchange is making clinically-relevant information available to support clinical work. Exchange standards should focus on getting information to humans who are interacting with patients and making decisions; that is what clinical care is about. Period.
Data quality cannot be overlooked. Poor quality data is a safety issue. Where are the metrics for clinical data quality (8)? A standard data set could provide the basis for developing data quality assessments (see Wrestling with EHR Data Quality ).
Two types of user interface issues seem to be dominant: documentation creation and clinical work support. Being very different issues, the solutions will be different.
Documentation support is driven by billing and regulatory issues as much as it is by the need for clinicians to keep a record of what they do. Getting rid of E & M coding would certainly help. Meaningful use has contributed to documentation woes as well. In cases where the problem is a need to check off specific items, a solution might be to move data capture to another job role.
Supporting clinical work means understanding what is being done, the information required, and in what form that information must be. Generally speaking, clinical work support has been addressed by putting every possible piece of information on the screen, which makes locating and reading a specific item difficult. Models of clinical work would offer more specific guidance on information displays. In addition, models would make it easier to test display layouts and compare results.
Targeted training and research
Obviously, clinical software design cuts across many domains and each domain has its own professional societies and academic journals. Most formal work on business processes and workflow does not appear in PubMed, though it is readily applicable to clinical software design. Progress, at some point, absolutely requires a common literature, conferences, textbooks, and courses so that a shared vocabulary and conceptual framework can gel.
It is time for the First Annual Conference on Clinical Software Design, the first edition of Clinical Software Design Book of Knowledge, and the first issue of the Journal of Clinical Software Design. Further, that journal should devote space to case studies in application design, user interface tweaks, and other practice-focused articles. A few trade publications, a la Dr. Dobb’s Journal, would be nice, too.
Creating the next generation of clinical software requires new thinking and new approaches. Everything must be questioned—rounding up the usual suspects will not do…
- Improving Care: Priorities to Improve Electronic Health Record Usability. American Medical Association, 2014. Accessed at https://download.ama-assn.org/resources/doc/ps2/x-pub/ehr-priorities.pdf
- Kuhn T, Basch P, Barr M, Yackel T; for the Medical Informatics Committee of the American College of Physicians*. Clinical Documentation in the 21st Century: Executive Summary of a Policy Position Paper From the American College of Physicians. Ann Intern Med. 2015 Jan 13. [E]
- Saleem JJ, Russ AL, Justice CF, Hagg H, Ebright PR, Woodbridge PA, Doebbeling BN. Exploring the persistence of paper with the electronic health record. Int J Med Inform. 2009 Sep;78(9):618-28.
- Flanagan ME, Saleem JJ, Millitello LG, Russ AL, Doebbeling BN. Paper- and computer-based workarounds to electronic health record use at three benchmark institutions. J Am Med Inform Assoc. 2013 Jun;20(e1):e59-66.
- Saleem JJ, Flanagan ME, Wilck NR, Demetriades J, Doebbeling BN. The next-generation electronic health record: perspectives of key leaders from the US Department of Veterans Affairs. J Am Med Inform Assoc. 2013 Jun;20(e1):e175-7.
- Sinsky CA, Beasley JW, Simmons GE, Baron RJ.Electronic health records: design, implementation, and policy for higher-value primary care. Ann Intern Med. 2014 May 20;160(10):727-8.
- Krist AH, Beasley JW, Crosson JC, Kibbe DC, et al.Electronic health record functionality needed to better support primary care. J Am Med Inform Assoc. 2014 Jan 15. [E]
- Weiskopf NG, Weng C.Methods and dimensions of electronic health record data quality assessment: enabling reuse for clinical research. J Am Med Inform Assoc. 2013 Jan 1;20(1):144-51.