From Data to Data + Processes: A Different Way of Thinking about EHR Software Design

Do perceptions of what constitutes an electronic health record affect software design?  Until recently, I hadn’t given much thought to this question.   However, as I have spent more time considering implementation issues and their relationship to software architecture and design, I have come to see this as an important, even fundamental, question.

The Computer-based Patient Record: An Essential Technology for Health Care, the landmark report published in 1991 (revised 1998) by the Institute of Medicine, offers this definition of the patient record:

A patient record is the repository of information about a single patient.  This information is generated by health care professionals as a direct result of interaction with the patient or with individuals who have personal knowledge of the patient (or with both).

Note specifically that the record is defined as a repository (i.e., a collection of data).   There is no mention of the medium of storage (paper or otherwise), only what is stored.   The definition of patient health record taken from the ASTM E1384-99 document, Standard Guide for Content and Structure of the Electronic Health Record, offers a similar view—affirming the patient record as a collection of data. Finally, let’s look at the definition of EHR as it appears in the 2009 ARRA bill that contains the HITECH Act:

ELECTRONIC HEALTH RECORD —The term ‘‘electronic health record’’ means an electronic record of health-related information on an individual that is created, gathered, managed, and consulted by authorized health care clinicians and staff.  (123 STAT. 259)

Even here, 10 years later, the record/archive/repository idea persists.  Now, back to the issue at hand: How has the conceptualization of the electronic health record as primarily a collection of data affected the design of software systems that are intended to access, manage, and otherwise manipulate said data?

Repository-oriented thinking results in an emphasis on software system designs that primarily optimize data-centric functionality such as capture, validation, retrieval, and storage.      Such systems are built to ensure that all required data are captured while paying less attention to users’ needs for support of patient care processes.   Current complaints of too many mouse clicks, too many screens, the difficulty of finding the “patient’s story” in the midst of tons of structured data, and the outcry for more usable systems are likely the result of data-centric designs.  We have spent far more time thinking about what data a patient record should contain than we have spent thinking about how software systems that provide access to that data might best support patient care.   We have not paid sufficient attention to processes and workflows.

The HL7 EHR System Functional Model is an attempt to define the functionality that a software system should have in order to support care delivery.   This standard provides requirements for a range functions that can be used to guide software development–and that is a good thing. However, one can build a system that contains all of the required functions, and yet, is not process-aware.  My goal is not to downplay the value of the ASTM and HL7 standards; rather, it is to demonstrate that, collectively,  we are still thinking far more about data than about processes when designing software.

Health care is a dynamic activity involving many interacting individuals.   Any software system purporting to support clinicians as they care for patients must be aware not only of the data required at any given point of a care process, but also of the process itself.   The question, of course, is how to do that.

For me, the turning point in thinking about processes as software design elements occurred when I began studying workflow systems.    I have to credit Will van der Aalst for this.  The concept of a discrete dynamic system, which I first encountered in his works, has been particularly compelling.   Discrete dynamic systems are systems that at any given moment exist in a particular state. Further, states may change or transition within a finite set of discrete states.     Marrying data to discrete dynamic systems provides a means for describing systems that are both process and data aware.

Let’s look at an example of a patient visiting a doctor’s office.   While at the doctor’s office, we identify the following states that the patient can assume: in the waiting area, checked-in, with the doctor, in the lab, and checked-out.  Aalst refers to the set of possible states as the state space, denoted:

S = {waiting, checked-in, doctor, lab, checked-out}

Changes in state can be rendered using ordered pairs.    The ordered pairs listed below illustrate the order of states that might occur during a typical visit.

(waiting, checked-in), (checked-in, doctor), (doctor, lab), (lab, checked-out), (checked-out, waiting)

When rendered graphically, these ordered pairs create a directed graph in which states are represented as nodes, and the transitions between states, as edges (see Workflow Analysis—Doing the Math).

Aalst champions Petri nets (a modeling tool based on graph theory) as an ideal tool for modeling processes and workflows, and, thus far, I must agree.  For me, this is a big deal! Why? Because Petri nets provide a mathematical representation of a system’s behavior that I can: 1) tie directly to data, algorithms, and programming code, and 2) use to create a human-readable diagram!  Expect to see much more about Petri nets, directed graphs, processes, and workflows in future posts.

Current EHR definitions tend to focus first on the EHR as a repository, then as a system providing a range of data-centric functionality. However, these perspectives, while important, do not provide the richness needed to guide the design of clinical systems that intimately support patient care processes.

Relying mainly on data and functionality-oriented EHR definitions to guide software development makes it too easy to fall into the trap of designing systems that provide clinicians the data they need and the required functionality, but that are difficult to learn and use.   Process-aware systems are the key to reducing training times, enhancing productivity, implementing CDS, and other issues.   It is time to revise our definition of what constitutes an EHR system so that it encompasses, in addition to data and functions, awareness of processes and workflows.




  1. Chuck, thanks for your comment.

    I totally agree with you regarding EHR designs based on structured workflows. Many of the problems clinicians complain about could be solved using process-aware system designs. Why do you suppose this idea has been so slow to catch on with clinical systems?

    I am eager to see WF technology become mainstream in clinical systems. However, for me personally, the biggest discovery has been graph theory and how it allows clinical events to be represented mathematically. The scientist in me finds this to be a much bigger deal.

Leave a Reply

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