A Guide to User-Centered Healthcare Software Design and Development

Putting User Research Data Into Context

Your research is complete and you’ve gathered all the information you can about your user’s experience. You’ve laid out storyboards and customer journey maps. Your decisions have been made on your user’s potential use of your application. But there is one last piece to consider: How do you now put it all together and design your application in a way that matches your users’ mental model and context? Odds are, you’re going to use data in your application. And there’s one problem with that: it’s too easy to collect data! From wearable devices to population health patterns, we have no shortage of data to scour for insights that can inform our decisions, views, and plans. What is lacking, however, is the ability to effectively mine, analyze, and interpret this data.

Digital health software makers need to cut up big data into small data. We need to identify what insights are being sought, then bite off a piece of big data that can feed these insights, and then trim, mold, and polish that data into a visualization method to highlight that insight most effectively. In healthcare especially, there is so much data documented for each patient at each visit that it’s critical to carve out all but the essential information so that a situation can be quickly understood and responded to. To build a successful application for healthcare, we need to scope and design the data visualization to suit the user and their needs.

TIP: What Size is Your Data?

As much as we love to talk and think and dream about big data and its potential, most of the data we consume is small. Small data has more relevance in our day-to-day lives. To make the transition from big to small, we rely on tools, processes, and data experts to convert our big data into small data so that we can understand it and use it to inform our decisions. Want to learn more about moving data from big to small for your users? Check out our technology section: Small Data vs Big Data.

For example, if your application is addressing a need to display a patient’s vitals, how does one know what data to carve out and which variables to fix? Simply, this depends on how the clinicians plan to use the data.

In healthcare patient vital signs are probably the most frequently captured data element. Irrespective of the diagnosis, facility, or reason for encounter, vital sign values are captured as the most fundamental check of a patient’s current condition. Despite the vast volume of vitals data collected for an individual patient — not to mention an entire facility and all the patients it has ever treated — at any single point of patient care, the data presented to a clinician must answer a single question: Are the most recent vitals in a normal range for this patient?

Most electronic health record (EHR) vendors strive to answer this question at a glance. In practice, there’s often a second (or third) question that needs answering. The initial choices made to display vitals will not work to answer those questions. To answer these questions, you need to combine the current vitals with data from a different part of the EHR. In effect, carving out a new slice of small data from the full patient record. And with a new slice of data often comes the need to select a new representation of this data.

Many fierce battles have been waged between groups of clinical advisors with different roles or specialties when deciding how to design a vitals feature in an EHR software application. That’s because there isn’t a one-size-fits-all vitals screen design. Let’s look at two different user contexts in which a patient’s vitals may be accessed, and two different proposed ways of representing them, each optimized to their own context.

Example 1

The following graph represents a patient’s most recent vital signs as well as the last eight instances of vitals captured in four-hour intervals, with any values falling outside of the normal range highlighted. This graph would be relevant in a post-op situation, where a patient’s vitals are closely monitored to watch for infections or other complications.

A nurse or doctor can look at this graph and know instantly if the patient is in crisis

The data shown is selected and presented due to its relevance to the clinician. A nurse or doctor can look at this graph and know instantly if the patient is in crisis and if his/her condition is improving or deteriorating. This ‘small data’ visualization effectively answers the question “Are the vitals in a normal range?” and “Are they increasing or decreasing?”.

What this graph doesn’t effectively tell us is:

  • What are the actual values that were captured?
  • Who / what captured them?
  • Was there anything else going on that I should know about? For example, any change in the meds administered a patient’s physical exertion during the same time period as the vitals capture, or anything else that may have been documented in a progress note.

Although that information is probably collected, (assuming it’s a decent EHR used by a care team who documents thoroughly) it has intentionally been carved out of this picture. By doing this, the remaining data has been given maximum emphasis due to its perceived value and relevance to the questions being asked in a specific clinical context.

Electronic health record data example 1

Example 2

Let’s look at a completely different context for utilizing vitals data.
What if a family physician was seeing a patient who had come into the clinic with an acute problem, like an earache? The physician would primarily want to know as much as possible about the current situation. This probably means today’s vitals, likely captured just moments before along with any patient- reported details that had been captured. Then, of secondary relevance, are historical vitals readings (both from regular checkups and other acute illnesses) as well as any historical instances of similar symptoms to what has been reported today. The questions being asked of the data would be different:

  • What are the patient’s most recent vitals and are they in a normal range?
  • What other symptoms or history did the patient report?
  • Has this happened before?

As you can imagine, the previous seven vitals readings are far less valuable in informing the current situation than the narrative surrounding this particular episode, as well as any history of similar episodes and their comparable vitals. With that said, we could take the same visualization shown previously and add additional information to answer the physician’s questions. One option could be the ability for users to tap on any reading to display that additional information:

  • Was it a routine visit, or a sick visit?
  • Had any medication been taken?
  • What other symptoms did the patient report?

By tapping or clicking through a number of vitals readings and assorted patient records, the physician could get a sense of this current situation and how it compares to the patient’s vitals during previous instances of health and wellness. The information could be obtained, but perhaps it would not be the ideal way to view it. Given that the physician is looking at a different slice of data, to answer different questions, perhaps there’s a different way to visualize it? Could we shift the emphasis from visualizing a trend over the last eight readings to communicating additional information and previous illnesses?

Our interface now has changed from a simple graph clearly showing trends and highlighting changes, to one that is context-based and displays symptoms for a particular situation.

Electronic medical record data example 2

Now the physician can look at the current vitals readings, accompanied by all information captured about this particular episode. Where previous instances of these vitals or symptoms have occurred, the physician is alerted, and can easily drill down to get the full picture of those historical episodes. At a glance, the physician has the information necessary to make a preliminary diagnosis and plan treatment or further testing based on the information displayed.

These examples clearly illustrate that the context influences what data is displayed, and how it could be made as efficiently usable as possible. The way in which data is presented must be carefully chosen to answer the questions being asked. It’s this combination of selecting the right small set of data, and visualizing it the right way that makes it accessible, informative, and actionable.


PDF Download Button

Download The Complete Guide to Engaging Digital Health Software

Get the PDF