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