There is no standard method or process for creating clinical software, and this bothers me – a lot. There is no information model that everyone agrees on, no object names or properties or methods. Even though clinical care is a collection of processes, we have no standards for naming those processes, the steps that comprise them, nor any standard way of demarcating process boundaries. Despite the years and dollars that have been dedicated to creating clinical software, little has been done in the way of saying how clinical software is best designed and built. It is now time to take up that challenge.
When HITECH went into effect in 2009, EHR systems were seen as the ultimate in clinical software and the centerpiece of HIT. Six years later, we realize that care coordination and patient engagement require much more than an electronic chart, that data exchange must occur between a range of computing devices, that data can arise from any number of sources, and that influencing clinical processes requires software support. The range of processes, users, and data that clinical care systems must support is growing, resulting in new requirements that no one imagined 10 years ago.
When I started blogging four years ago, one of my main goals was to try out new technology. The idea was to get a feel for what had changed since I last did any serious programming. Having discovered that the development world had thoroughly embraced object-oriented methods, I took the OOP plunge–first with C#, then OO-PHP and, lately, with Swift. Document and graph databases were tour stops as well. Along the way, I studied design patterns and software architecture.
Petri nets and workflow patterns led to a much deeper understanding of process issues, and demonstrated how the lack of explicit process support decreases the usability of clinical software. Most recently, human factors research has become a focus of study. Now, on the verge of building a clinical iOS app, I am faced with the same issues that have always arisen when starting a clinical software project: How to account for processes? Which processes, and how many steps? What roles are involved? How to name and format data elements?
I have learned plenty about software development, but it is all generic – everything. Nothing learned has been specific to clinical software. Having to adopt generic concepts, methods, and tools to a specific domain amounts to inventing a wheel for that domain. Of course, once the wheel has been built, reuse is possible, but why should it be necessary to build a new wheel after all of the years clinical software has been around? Forcing every vendor to independently solve the myriad problems that arise during clinical software development is an exercise in futility. Clinical software is simply too complex and that complexity is continually increasing.
Imagine how biomedical research would have progressed if every researcher had to invent assay techniques from scratch, or if new research methods were never published for review and critiquing. I am not advocating that vendors share their code. Rather, I am suggesting that public funding for clinical software research should borrow from the biomedical science model. If clinical software is to be a major component of care delivery, research and development cannot be overwhelmingly proprietary.
The need for software engineering methods and principles that are specifically adapted for clinical systems is not a theoretical or philosophical issue. The safety and well-being of patients make the quest for better clinical software design methods an obligation for every developer. User-centered design is a good thing. Done properly, it can help to make a particular product better. However, UCD is a generic process. UCD still requires each developer/vendor to figure out how to convert clinical concepts into code.
Clinical software has to manage the dynamic relationships between users, data, and processes. Every software project has to account for each of these entities. While it may seem okay to limit any one of them for a specific project those limits are likely to cause trouble later on. Workarounds exist because of hard-coded limits on processes. Interoperability issues are due to limits on data. Collaboration/coordination problems are limits on users. Designs that compromise by including limits will eventually hit a wall, as we have seen.
Software is born as a solution to one or more problems. Creating software to solve problems requires understanding the problem well enough to know how software might help to address it—and so starts the search for requirements.
Requirements come in two basic flavors—functional and non-functional. Functional requirements tell what a system must be able to do (e.g., add a problem, send a message, retrieve a medication list). Non-functional requirements are unseen, but still important –reliability, performance, security are good examples. Clinical systems obviously have different requirements than those dedicated to other domains, but what are they, and how are they special?
Clinical care consists of processes and most of those processes require clinicians to make decisions either alone or in concert with other clinicians or patients. Paper charts, as well as current EHR systems, are primarily designed to capture the results of those decisions. Consequently, key features of paper and electronic charts are lists—medications, problems, and labs being the most obvious examples. These lists record what clinicians have done or decided; they do not participate in the process other than by passively offering information. However, the dynamic changes if, say, one wants the software to advise the clinician on what diagnostic test should be ordered when a problem is added to the list or help to manage a pool of abnormal results. Software that offers assistance joins itself to the decision-making process, and in doing so, radically alters the underlying requirements.
Software that assists must be aware of the active process, the steps involved, the information needed, the allowable branches, terminations and iterations. Likewise, the software must be aware of who or what (in the case of equipment or other computer systems) must be notified and consulted to allow the process to successfully complete. Process support also requires flexibility, which means that some user-configurable capability is necessary. Clinical processes make clinical software special.
Without explicit process knowledge, decision support, usability and safety issues are more difficult to address because there is no explicit sense of “before,” “after,” “when,” and other process concepts to which information flows may be tied. Of course, these concepts can be (and have been) hard-coded into software and, when they have been, adjusting them requires multiple iterations of the product.
We need a standard way to capture clinical process requirements during software design–ideally to program workflow engines. Frequently, business process modeling notation (BPMN) is offered as the solution for capturing process information. Yes, BPMN is designed for this; however, like all the other methods and tools mentioned, it is generic—wheel inventing is required. There is no BPMN-based standard library of clinical process descriptions.
Requirements are only part of the story. Requirements must be turned into working code. Here again, the tools are generic. There are no standard libraries of clinical design patterns or clinical workflow patterns or clinical object models. What counts as quality assurance for clinical systems? Clinical software has always been treated as a product, but as a result of national policy, it is now an integral healthcare delivery component. This change in status has created two problems — one mundane, the other grand.
The mundane problem is helping vendors of current EHR systems retrofit their systems to match current ideas of usability, safety, and process support. User-centered design (UCD) can help here, but changing process-agnostic repositories to process-aware assistants will require more than a mature UCD process. There are simply too many fundamental differences – conceptual and architectural – between these two approaches to clinical software.
Adaptation of current tools and software engineering practices with the goal of creating methods specifically for clinical software design is the grand problem. In addition to new methods and tools, solving the grand problem requires a much closer look at clinical care processes at the level of individual steps and what those steps produce and consume. Addressing the grand problem starts with questions such as: What are the essential user interface elements for primary care physicians, and how do they differ from those of nurses in a neonatal ICU? How are they the same, and why? Answers to these questions require a look at the processes these clinicians are part of. In addition, it requires a means of encoding processes so that the similarities and differences can be analyzed.
The best way to solve a grand problem is to start with a smaller one and work from there. Since gathering requirements is one of the most basic software development activities, I suggest we start with the way we think about requirements for clinical systems.
As I mentioned earlier, I am in the early stages of building a clinical iOS app, which means the problems encountered during software development are now my problems. With this in mind, I have been thinking about how to capture requirements in a way that could be shared with others who might join the project while also addressing the concerns discussed above. For the moment, there is only a basic outline of what I intend to try. It is something I refer to as informatics analysis—more about it in the next post…