Building Clinical Care Software Systems, Part I: Issues and Challenges

 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.

Data Data elements
How to represent values
Missing/unavailable data
Origin and reliability markers
Security Data integrity
Access control
Process Issues (including decision support) How to represent processes
State (patient and/or system)
Temporal traits
Concurrent events
Sequence dependencies
Interface/ Usability Issues User configurable features
Workflow (process support)
Color, size, typography
Alerting strategy
Safety/error prevention
Decision support
Training time
Internal Software Design Design patterns
Clinical algorithms
Computable clinical concepts
Clinical data structures
Architecture Issues Communications
Data exchange
Platform Web

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.

Clinical Care System 4 Component Architecture

Briefly, here is a summary of each component.

Patient Information
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.

Process Information
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…)



  1. I think too much in EHR and even HIE technology is not goal-oriented. There are probably many goals by many stakeholders, but which are important for the task you’re trying to accomplish? And maybe you’re not being transparent – are you designing something that can properly bill and document a brief encounter but then say you’re trying to support good care? Or are you saying you are looking for “patient centered” and “patient engagement” without asking or even thinking about what the patient wants or would use? There are many types of data and many ways that data are used, but let’s not mixed them all up. I like your table, but I think you should add a “patient needs” factor. I think that adds a perspective that isn’t represented in the other identified factors.

    1. Thanks for your comment.
      I agree that patient needs are important. The table was just a brief listing of factors illustrating the issues faced in building clinical systems. There are so many possible goals for clinical systems that being focused is, in itself, a challenge. The future belongs to platforms and applications with limited scope working together to delivery needed functionality.

      1. I agree, Jerome. Maybe we’re finally getting to a point where we really understand what’s needed to support good clinical care and an understanding of how the parts can work together. Hopefully, the financial side will catch up sooner rather than later and make it worthwhile for care providers to deliver care in a cost effective yet financially sustainable way.

  2. Not being IT, I really like the way you broke this down. I agree the dialog needs to shift to clinical software design and it’s components. I work as a risk manager at a professional liability company. Many experience challenges with the EHR, especially with building functional templates to capture data (documentation). The risks seem to center on what to document, where/how to document and redundant documentation. Workflow for the end-user is also problematic. Many try (and fail) to keep the same workflow processes utilized when the medical record was paper. Looking forward to your posts!

    1. Thanks for your comment. Building better systems requires understanding the problems that need to be solved. As you mentioned, workflow issues are important and only recently have they received much attention. Fortunately, there is a growing awareness that clinical care systems are (must be) more than just front-ends to data stores.

Leave a Reply

Your email address will not be published. Required fields are marked *