Unfortunately, little exists in the form of specific guidance for creating clinical software. The paper chart has been the design metaphor used to guide EHR development (see Is the Electronic Health Record Defunct? ). Existing standards focus more on data (terminologies/ontologies) and not the internals of the software itself. Oddly, even with such a strong focus on data, there are no standard data schemas for clinical systems.
Usability issues have made clinical software design a hot topic and brought the matter of EHR design to a wider audience. This is a good thing. However, the word “design” means different things to different people (see What Do You Mean by EHR “Design”– Architectural, Detailed, User Interface, or Process? ). It would be a great if a book existed, say Principles and Best Practices of Clinical Software Design, but it doesn’t, so everyone building clinical software has to start basically from scratch.
Experience has convinced me that data-centric software designs, as typified by current EHR systems, are the source of many usability concerns because design methods that focus on data tend to treat processes as second-class citizens. Accordingly, I have been investigating how to make clinical software development more even-handed. Thus far, I have focused on how to determine when a process-oriented approach is necessary. Here is what I have come up with thus far. If one or more of these rules apply, a process-centric design would likely be better than a data-centric one.
Carter’s Rules for Process-Oriented Design
“Huddle Up” principle for collaboration/communication
Clinical care can entail the need for frequent interactions and communication among groups of clinicians, between clinicians and patients, and across organizational boundaries. If these interactions are one-off and no follow-up is required, then a data-centric design is fine. However, ongoing interactions with many shared decisions require that those involved be able to electronically “huddle up” (football-style) in order to make sure everyone is on the same page.
“A Thousand Times a Day” principle of high-volume processes with recurring decisions
The main goal of automation is making repetitive processes less labor intensive. Clinical processes use/produce information and may require resources and human involvement. Information systems can make processes less labor-intensive by cutting down on the work the humans involved must do. This can be done in a number of ways, such as collecting information, presenting information only within the context it is required, sending notifications, etc.
Principles based on decision type
“Many Paths” rule – multiple branches/alternate paths
Some decisions can be made based on only one or two pieces of information. If so, access to the required information is sufficient to render a decision. However, often decisions must be made over an extended period with each decision giving rise to a new set of choices. Keeping track of the paths and branching rules is easier if the pathways and branches are explicit.
“Big Variables” rule – decisions that require many variables be considered concurrently
Unlike many paths, big variables-type decisions are characterized by having to figure out the best path given a large number of starting conditions. Ensuring that all possible options are considered might require software support.
Treatment decisions in patients with many co-morbidities
“Quantifiable Dependencies” rule – decisions guided by quantifiable conditions
This rule actually applies to any decision in which one wants a computer to be involved. Alerts that fire based on specific lab values or after a specific time interval has passed are examples of this rule. I have included it because if a decision has to be made and the conditions are NOT readily quantifiable, then a human should usually make the decision. Thus, this is a gatekeeper rule for the rest of the decision-type rules.