Developing Clinical Care Systems from the Outside-In

Since the electronic health record is defined primarily as a patient data repository, it is natural to begin development of EHR systems with a data model.  As I noted in Is the Electronic Health Record Defunct?, this approach creates obstacles for building systems that optimally support clinical work.  Naturally, this leads to the question of what would be a better development approach.

Standard software development practices start with a requirements analysis and move forward through successive stages until a production system is ready.   The Waterfall Model is the classic example of this approach. Recently, Agile approaches have caught on.   One aspect of more recent approaches that I am liking more every day is the emphasis on prototyping user interfaces at the beginning of the software development cycle.     Clinical care software development could benefit substantially from an early emphasis on user interfaces and user work behaviors, as opposed to data models.

Clinical care systems that intimately support clinical work require a detailed understanding of what clinical professionals do.   Of course, this knowledge is not easy to come by.

Expertise is internalized.  Experts do not pay attention to what they do, and when asked, they usually relate what they believe they do.    Observation must always be used in conjunction with interviews to tease out process information.  However, even observation plus interviews becomes less useful over time (say two or three interview/observation cycles) because people change their behaviors when they know they are being observed.  Using prototyping tools, it is possible to create mockups of interfaces that can be used to directly test clinical work behaviors.   Moving UI development to the early part of the software development cycle seems like a good adjunct to interviews and observations for capturing work behaviors and process details.   Having experimented with prototyping tools for my personal software development efforts, I say they hold a lot of promise for clinical software.

Workarounds have become an active research area (1, 2, 3) (also see EHR Design and Personal Work Habits).  And, even though there is not a consistent taxonomy for workarounds, the available data provide useful information concerning what doesn’t work in clinical software systems.    Cognitive disruptions caused by information availability issues are common.  Below is a list of information availability issues that arise from user interface design choices.

  • Relevant information not grouped together
  • Too many clicks required to reach needed information
  • Difficult to read screens
  • Information outdated
  • Information not in system
  • Inability to easily use information as cognitive cues

Of the items listed above, note how many would not show up as issues from interviews.   While many would be evident with observation, determining exactly how they fit within the task at hand (in the user’s mental map) may not be straightforward.

When analyzing processes a distinction must be made between tasks that can have inputs and outputs that are fully-specified in advance (pre-set)  versus  those where inputs and outputs are situation-dependent (contextual).   The differences between the two types of tasks are very important for clinical care system design.

Pre-set tasks
Procedures such as check-in/registration and making an appointment are pre-set.   They have well-defined inputs and business rules that dictate what information is required and how the collected information is processed.   It is easy to design software for pre-set tasks.  Fortunately, health care has many such tasks.

Contextual tasks
Contextual tasks have varying inputs and outputs.   A dietician interacting with a patient to account for food allergies is a good example of a contextual task.   The dietician receives input from the patient and through a back-and-forth discussion arrives at an output.  Generally speaking, the simplest way for an information system to support contextual tasks is by keeping a record of the inputs and outputs.   However, what if the goal is supporting the dietician while he/she is making decisions?  What should the system do?   A nurse creating a care plan or doctor deciding a diagnostic workup are both examples of contextual tasks.   Getting software support for either is not a straightforward software design problem.

In many cases, it seems that having the ability to rapidly access a knowledge base or make quick electronic notes would be helpful.    For example, for a diagnostic workup, if right-clicking on a problem in the problem list launches a diagnostic checklist with links to knowledge resources, then that might be as much support as desired.   The takeaway here is that contextual tasks are knowledge-based and information-intensive.   Supporting contextual tasks can be as simple as providing a check list or as complex as an automated guideline.   Obviously, the level of support desired depends on the user and the task.  Contextual tasks are so important that they should be addressed in the earliest stages of software development.  Design choices should be revisited and tested frequently as the project moves along, which is where prototyping comes in handy.

Contextual tasks are highly individualized.  Since they are not one-size-fits-all, task support should be under the control of the user.  This can be provided in the form of user-configurable workflows and interfaces.     The smaller the discrete components of the user interface are, the easier it is to customize the interface for each user.  For example a medication display may show any or all of the following:

  •  Complete medication history
  •  Allergies
  • Side effects
  • Adverse reactions
  • Prescription history
  • Current medications only
  • Failed medications
  • Chronic medications
  • Medications from other facilities/providers

In addition, the display may be sorted by date, alphabetically, prescribing provider, or other order.   Building a display that permits each clinical professional to see what they deem useful would be more process-friendly than either putting everything on the display or burying information behind a series of screens.

Dealing with process issues early in software development puts them front-and-center where they belong.  Instead of starting with a data model and building out from there, perhaps the best approach for clinical care systems is starting with processes and an interface prototype and building in.  Maybe creating software that intimately supports clinical care requires designing from the outside in.

  1. Saleem JJ, Russ AL, Justice CF, Hagg H, Ebright PR, Woodbridge PA, Doebbeling  BN. Exploring the persistence of paper with the electronic health record. Int J Med Inform. 2009 Sep;78(9):618-28.
  2. Flanagan ME, Saleem JJ, Millitello LG, Russ AL, Doebbeling BN. Paper- and computer-based workarounds to electronic health record use at three benchmark institutions. J Am Med Inform Assoc. 2013 Jun;20(e1):e59-66.
  3. Friedman A, Crosson JC, Howard J, Clark EC, Pellerano M, Karsh BT, Crabtree B, Jaén CR, Cohen DJ. A typology of electronic health record workarounds in small-to-medium size primary care practices. J Am Med Inform Assoc. 2014 Feb;21(e1):e78-83

Leave a Reply

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