Creating software is hard. The entire process, from deciding that a piece of software is needed to implementation, requires analysis and problem-solving–every step. I was reminded of this reality anew when I began the latest round of coding for my seemingly mythical startup. There are so many decisions to make that affect the final product, even though I consider what I am trying to build to be fairly straightforward in design and features. Building a good clinical care software system is many times more difficult.
Given the troubles that are plaguing EHR vendors in meeting MU stage 2 requirements, this seems like a good time to talk about what goes into building a system that supports clinical care. “Tweaking” a complex software system is not a good approach for adding features. It is sort of in the same category as knocking down a wall to enlarge a room. Sometimes it’s okay, and sometimes there is a cave-in and a lot of noise. Complex software systems are designed holistically; they have an architecture and are designed to meet a specific set of requirements. Once a system is built, changing the requirements too much, too quickly, or both can cause problems. Imagine what happens when a third floor is added to a building that was designed to support only two.
Creating clinical care systems that support clinical work requires not only a huge up-front effort to determine what the system should do and how it should be structured, but it also requires a design that can accommodate change gracefully (or at least as gracefully as possible). In the case of clinical care systems, this means examining in detail a range of issues from the highest level, such as users, the work they do, and the environments they work in, down to low-level matters, such as data element names and audit trail designs. As I have stated in previous posts, there is not enough public discussion on clinical software design principles, methods, techniques, etc. Public discourse concerning EHR systems needs to move beyond who likes their system and who does not. It is time to acknowledge the inherent complexity of systems that support clinical work and approach their design and implementation accordingly.
As an exercise, I decided to jot down a list of factors that must be taken into account when building clinical software. Here is what I came up with.
How to represent values
Origin and reliability markers
|Process Issues (including decision support)||How to represent processes
State (patient and/or system)
|Interface/ Usability Issues||User configurable features
Workflow (process support)
Color, size, typography
|Internal Software Design||Design patterns
Computable clinical concepts
Clinical data structures
Obviously, this list is far from exhaustive. Even so, it provides an idea of what makes designing clinical care systems challenging.
In the post, Is the Electronic Health Record Defunct?– Part II: An Architecture for Clinical Care Systems, I suggested a four-component architecture for clinical care software systems as a means of organizing, into functional blocks, the hard problems encountered in clinical software creation.
Briefly, here is a summary of each component.
The lowest level component, the patient information component, is a service that provides required patient data to the higher-level components. It manages data access, security, and semantics.
Electronic Health Record
The legal patient record used for business, legal, regulatory and administrative requirements. This is the electronic equivalent of the paper chart. It is used for disclosures, public health reporting, etc.
This is a service, to some extent, as well. Process support requires an execution engine, modeling tools, an API, etc. all of which are covered in this component.
Clinical Care System
Direct support for clinical work is located here. It provides the interface and features needed for direct patient care.
In this series of posts, I will try to illustrate some of the hard problems encountered in building clinical care software systems. By doing so, I hope to expand on the current dialog on clinical care systems and show that these systems present real scientific and engineering challenges that make them worthy as objects of study. One post will be dedicated to each component, starting with the lowest-level component, patient information.
Creating clinical software requires a wide range of skills and viewpoints. Working together requires discussion, collaboration and sharing of experiences and information to a degree far greater than is currently occurring among healthcare professionals, software engineers, usability experts, process specialists, database designers, and others. Let’s talk…
(And now back to debugging…)