Lately, I find that I am spending much more time thinking about clinical software design–not so much about a specific product, but clinical software as a genre. While going through all the EHR-related files I have collected over the years, I realized that there are many lists of features or proposed functions for EHR systems such as the IOM reports or HL7 Functional profiles. All such feature lists presume that the ultimate goal of clinical software design is the production of an electronic chart. While the paper chart is the final collection point for patient data and acts a clinician’s diary of patient interactions, it is not what clinicians actually do. Why then should a paper chart be the main design inspiration for clinical software that supports clinical work?
Representations of the many types of interactions that characterize clinical care are notably absent from paper charts and their electronic cousins. Clinical care covers a lot of territory, and clinical software should be able to handle the full range of activities. Major interaction/process types that occur during care delivery appear below:
|Patient-clinician||During and outside of face-face encounters|
|Clinician data management||To-do lists, results management|
|Clinician knowledge management||CDS, access to information sources|
|Clinician-software||Use of clinical care software, CDS|
|Clinician-clinician||Referrals, collaboration, care coordination|
|Patient-software||Portal use, health education|
Table1. Clinical work interactions and processes
With the above in mind, here are two questions I have been pondering: 1) “What are the underlying principles that tie all clinical systems together within a common theoretical and computational framework?” 2) “How can those principles be applied to determine optimal designs for clinical care systems?
Too often within the context of clinical systems the word “design” is used to apply mainly to the user interface, which undermines the complexity inherent in clinical software. User interfaces are very important, but they are constrained by the systems they front.
Design is described in the Software Engineering Body of Knowledge (SWEBOK) as:
Design is defined as both “the process of defining the architecture, components, interfaces, and other characteristics of a system or component” and “the result of [that] process”…
Software design is generally considered a two-step process:
Architectural design (also referred to as high-level design and top-level design) describes how software is organized into components.
Detailed design describes the desired behavior of these components.
The output of these two processes is a set of models and artifacts that record the major decisions that have been taken, along with an explanation of the rationale for each nontrivial decision.
Given the above terms and concepts, is it possible, reasoning from a set of principles, to create a conceptual framework for clinical software design that can then be iteratively developed into models, architecture styles, and finally specific components? I am not asking if it is possible to create clinical software; obviously that has already been done. The question is whether clinical software has design principles that separate it from other software types aside from patient data.
The Patient Data Misdirection *
Access to patient data is essential for clinical care, but clinical care consists of much more than patient data access and storage. It is the disproportionate focus on data access and storage that has resulted in EHR systems that do not support clinical work in all its many forms.
The Missing Processes Conundrum
The lack of process-awareness limits the ability of EHR systems to support activities that occur over time and among groups. Care coordination, CDS, and results management are activities that require both patient data and process-awareness.
Results management is interesting because it requires clinician data management features as well as process information and patient data. For example, user-defined alerts, to-do lists, priority queues and other examples of prospective memory are very much a part of keeping track of abnormal labs or just regular preventive care. The design question for these types of clinical tasks is whether they are sufficiently specialized in a way that warrants full sub-system or component status.
The Model Formation Hypothesis
Moving from principles to working code requires a modeling phase. Modeling is the best way to see how the principles match the real world. They provide a more concrete means of communicating that can help all involved arrive at a shared conceptualization. Abstract discussions can quickly veer off into semantic debates where every participant is wed to some idea that exists mostly in his/her own head. Models help to cut down on these types of time-wasting discussion. This is why I have come to love math models so much.
Models can take on many forms. The current software development standard for creating models is Unified Modeling Language (UML). Along with Business Process Modeling Notation (BPMN), which is for workflows, UML provides a generic set of modeling tools that can be used to model a range of states, processes, interactions, or whatever. I find BPMN too verbose and noisy, and UML simply has too many diagrams. However, if they are your cup of tea, more power to you.
Thomas Beale makes the point that models may be the most important and enduring part of any development project. He also makes an excellent point about the need for an underlying theory to guide clinical software design and development.
Okay, models are important, but what to model? What are the best modeling tools? openEHR provides a stellar example of information modeling, but what other models are required? Obviously, I am big on clinical work models, and my love of Petri net-inspired modeling tools is no secret either. But which properties of clinical work processes should be captured in order to design modular, reliable, extensible clinical software?
The Basic Principles Extraction
Last year, I wrote a series of posts about clinical care systems. In that series, I tried to point out factors that affect clinical software design. While I am pleased with those posts, a year’s reflection tells me that a higher-level view is required to truly re-imagine clinical software. I was thinking too much along the lines of creating a product (not that there is anything wrong with that. I think about product design every day) and not so much about understanding what makes clinical software special.
Thus far, in my efforts to completely throw off paper chart thinking and fully embrace clinical software in all of its theoretical and computational uniqueness, I have jotted down a few precepts that will be used to guide my future explorations.
- Mathematics can be used to understand clinical care and to design clinical information systems.
- Information models are the best way to understand and manage data semantics and formats.
- There is no one best way to store data. NoSQL is a complement to RDBMS, not a replacement.
- Besides patient information, information on users, environment, and processes are required to support clinical work.
- Prospective memory support is critical in clinical software.
- All clinical work processes produce and consume data.
- Analyzing processes and modeling workflows are essential skills for clinical software design and implementation
- Models of clinical work are essential for designing process-aware clinical software.
- Usability, patient safety, and decision support have significant process components. Models of clinical work would further research in these domains.
I’ll be writing more about these principles over the coming year, especially in relation to modeling clinical work.
The path to a formal framework for clinical software design is not at all clear. openEHR offers a working information model, so no need to reinvent the data semantics wheel. My next steps: building a few detailed clinical work models, then seeing if those models make mathematical sense.
Clinical software design requires a new approach–one that acknowledges the scope and variety of processes that are peculiar to clinical care–not the paper chart.
*Subheadings are the result of watching, back-to-back, too many episodes of The Big Bang Theory.