Diabetes Mobile Care: Aggregating and Visualizing Data from Multiple Mobile Health Technologies

Abstract

As the appeal and use of mobile health (mHealth) technologies continues to grow, where does mHealth fit into clinical practice? This article explores the approach and obstacles encountered when integrating mHealth data into existing clinical frameworks and explores data visualization design tradeoffs. Specifically, this paper discusses the successes and challenges that arose when using commercial mHealth technologies, synthesizing multiple mHealth device data, and tailoring visualizations based on iterative feedback from type II diabetes mellitus patients. This research aims to influence the development of patient portals within electronic health records by understanding and addressing the challenges involved in acquiring, interpreting, and displaying this data set. In particular, we need to ensure that the presentation of these data is accessible and understandable by diverse populations.

Introduction

Patients with chronic illnesses, including type 2 diabetes mellitus (T2DM), and their care providers are burdened with monitoring complex health data to manage illnesses effectively¹. Patients with T2DM and their providers must monitor blood glucose and HbA1c, laboratory values, blood pressure, weight, medication adherence, and lifestyle behaviors for successful disease management². Because T2DM is an illness that requires daily management, the majority of care must be performed by patients themselves. Patients with uncontrolled T2DM may see providers every three months and sometimes as infrequently as every six months, which makes self-management of the disease state imperative. When T2DM is not well controlled, the blood sugar and related complications can escalate dangerously in the periods between patient-provider contacts. These issues contribute to poor patient outcomes and are costly to the healthcare system.³ Mobile health (mHealth) technologies have the potential to revolutionize self-management and personalized care for T2DM patients by reducing the risk of escalations through constant data monitoring via smartphone apps and other mobile technologies.

Because nearly 80% of the U.S. population are now smartphone owners⁴, smartphones are the ideal means to capture and transmit diabetes-related data from patients. Additionally, devices such as Bluetooth glucometers, wrist-worn accelerometers, and wireless scales, are readily available and are becoming more affordable. These devices enable patients to transmit data via Wi-Fi, cellular, or Bluetooth to health care providers for analytics and integration into electronic health records. Moreover, the aggregation of data allows health care providers to give patients feedback⁵ that can help them adjust behaviors and environmental exposures. mHealth technologies enable patients to transmit health data to and from their health care providers regardless of their socioeconomic status (SES) or geographic location. It also gives providers a more holistic view of what a patient’s health is like between office visits and enhances clinical decision-making⁶.

Nevertheless, the addition of mHealth technologies increases the amount of complex health data that patients and providers have to synthesize and interpret meaningfully. User-centered visualizations simplify the interpretation process by presenting information in an accessible way. However, when assessing a typical electronic health record, basic patient data is rarely visualized. There is a particular lack of intensive longitudinal data akin to the data generated by mobile health devices. Even when patient data visualizations are available, they tend to be provider-oriented rather than patient-accessible. To date, there are few existing guidelines and little precedent for how to optimize user interfaces for patients, providers, or both. Methodological approaches are needed to learn how to best present data back to patients with the goal of influencing the development of patient portals. Well-designed user interface features foster healthy patient decisions and positively influence the social determinants of health⁷.

The purpose of this article is to describe our efforts in creating patient-centered data visualizations for multiple mHealth technologies as part of an observational trial called “Diabetes Mobile Care”. In particular, we focus on the advantages and disadvantages of two data visualization software packages: Tableau and R ggplot2. We also describe how we presented patient data and corresponding visualizations back to patients in an iterative fashion to understand what visualizations would be most useful for them. Feedback from participants will be used to optimize visualizations for integration into the EHR and patient portal interface.

Methods and Results

We obtained institutional review board approval and recruited 60 patients (age ≥ 18) with T2DM. Of the participants, 47 (78%) had uncontrolled diabetes defined as an HbA1c >7.0 (mean 8.18). Demographics indicated that 43 (72%) were female, 36 (60%) identified as Black or African American, 21 (35%) identified as White; and 46 (60%) did not have a college degree. Informed consent was obtained. Participants were provided with a Fitbit Alta® (wrist-worn activity tracker), a wireless glucose monitor by iHealth®, and a cellular scale by BodyTrace®. Participants were also asked to participate in short bi-weekly text message-based surveys on their medication adherence. The Fitbit was bundled with a smartphone app and collected data on the number of steps taken in a day, distance travelled, level of activity, and sleep duration, all with a time-date stamp. Participants were instructed to wear the Fitbits 24 hours a day and remove the device only to re-charge the battery when indicated. The glucometer was bundled with a smartphone app, which logs and stores blood glucose readings and user notes, the date and time of readings, and whether the readings were before or after a meal. Patients were given a six-month supply of test strips for the glucometer. Patients were asked to measure their blood glucose as prescribed, which entailed at least once a day. The BodyTrace Scale sent the weight reading, time of reading, and date of reading to our database via cellular connection. Patients were asked to step on the scale daily while the Fitbit automatically tethered to their phone. Finally, the medication adherence surveys were scheduled at baseline and automatically texted to participants as a web link every other week.

There is a noticeable lack of infrastructure in the clinical world for the integration, aggregation and visualization of device data. Thus, our team used a custom-engineered software platform called Prompt©. Prompt is used by many studies that query Application Programming Interfaces (APIs) and store data in a usable database. Prompt was customized for this study to interface with each device’s API and store collected data in a single location. The research team is then able to view data across all participants (rather than having to log into each participant’s respective device to retrieve the information) or to view each participant’s device data separately.

We then used two different data visualization software packages and beta-tested their use via phone interviews with patients. The interviews were key to our iterative design process aimed towards discovering how to present each patient their visualizations and to refine those visualizations based on their feedback.

Data Quality

The mobile devices presented significant challenges to users and made data collection and interpretation difficult. For example, Fitbit designates different levels of activity as “Sedentary,” “Lightly Active,” “Fairly Active,” “Moderately Active,” and “Very Active”. But Fitbit does not provide adequate definitions of these terms, rendering them clinically ambiguous. While Fitbit accurately measures steps and is an explicit indicator of activity level, it does not always present data in a timely fashion. While participants can see their real-time data, the Fitbit relies on a phone or a computer as a tether to the server to report data to the API. The necessary syncing between device and server is unreliable. So, most of the time daily scans attempt to retrieve the data, but often fail because the device is not synced by the designated scan time. Weekly scans are then performed to patch the missing data from the previous seven days. Because this data retrieval is not in real time, it does not always provide the desired immediate report and timely daily feedback.

The iHealth glucometer also relied on a phone to tether to the server to report data to the API. Again, the unreliability of real-time syncing between device and server poses a significant barrier to producing timely feedback from our servers or an electronic health record. Thus, weekly scans of the data are more useful for patching missing data and more reliable because hourly or even daily feedback is frequently not possible. Additionally, because participants are not required to indicate if the blood sugar value was taken before or after a meal, this creates limitations in the type of clinical feedback we are able to give to patients. For example, if blood sugar is high following a meal the recommended behaviors or prescribed medication is different than if blood sugar is high before a meal.

There were also challenges with the BodyTrace Scale. The scale is sensitive and requires some trial-and-error in set-up (i.e., incorrect measures are reported if the scale is on an uneven surface). Consequently, the first weight reading a participant takes on the scale is often nonsensical. Another complication was that participants were supposed to be the only individuals using the scale. However, participants reported that other members of their households had stepped on the scale, and their readings were automatically reported. On the data cleaning side, we could not truly know which readings accurately captured the participants’ weights. To remedy this, a data-cleaning algorithm was applied to the BodyTrace Scale data. If the current weight recorded by the BodyTrace Scale was not within 5% of the participant’s baseline or previous week’s average weight, it was replaced by that weight. The cleaning algorithm also corrected all measures repeated in a single day likely due to issues with device set-up. Cleaning kept the replacement of the repeated data point within 5% of the previous weight reading or if they were all within 5% of the prior weight reading, the data point was replaced by the average of the repeated measures.

Throughout data collection and visualization, data cleaning issues arose. The Fitbit sometimes reported zero steps for times when the Fitbit was on; either it detected no movement or was not synched to the phone app. The Fitbit reported “NA” steps for times when the Fitbit was powered off. There were numerous instances in which the Fitbit reported less than 500 steps in a day, indicating an incomplete reading. Either the participant failed to wear the device the entire day or the device did not function the entire day. Thus, values below 500 were deemed clinically meaningless and discarded as were the zero and NA values. Device time stamping also required data manipulation. The time zone setting for the iHealth glucometer is not a user-defined setting and defaults to PST. Participants in this study were most often located in the EST time zone, necessitating time stamp conversion. Meanwhile, the Fitbit API sets a better precedent for time stamping, writing all timestamps in UTC and allowing users to convert to the correct time zone where the query for data is conducted.

Data Visualization Process

After initial data cleaning was completed, data visualization experimentation began. Two visualization software tools were employed: Tableau and the R ggplot2 package in conjunction with R Shiny. Tableau is drag-and-drop software that creates interactive data visualization and requires little programming experience (Tableau Inc., Seattle, WA). The R ggplot2 package is a static data visualization tool that requires more programming experience and familiarity with the R programming language⁸. R Shiny is an application builder that allows for creation of data visualization with flexible user-specifications and interactive functions (R Studio, Boston, MA).

Customizability becomes increasingly important as visualizations are created with the patient instead of the provider in mind. Visualizations were considered for their accessibility and instructive value to patients and their utility for providers, as exemplified by the below Figures. We chose initial visualizations by examining the data type, looking at examples and best practices in the literature^9,10, and group consensus for what we believed made the most intuitive sense. For example for the number of average steps by day of the week, we chose bar graphs instead of line graphs (Figure 1). We chose this because we felt it was easy to understand and the data we obtained from the Fitbit was daily counts of activity. A provider may find a distribution of blood glucose values on an infographic useful in understanding how often patients are falling in certain blood glucose ranges. At the same time, a T2DM patient may not understand what such a graphic indicates, nor would they necessarily need to. In certain patient populations, the emphasis is more on how often their blood sugar values are in a range specified by their providers rather than the numbers. A similar conclusion was reached when showing participants a plot of their Body Mass Index (BMI) over time against a plot of their weights over time. BMI was a meaningless value to patients, even with visual cues indicating the “Normal Weight,” “Overweight,” and “Obese” ranges¹¹.

Figure 1.

(A) Tableau average steps per weekday vs. (B) R ggplot2 average steps per weekday

Figure 1 presents an interactive Tableau and R ggplot2 visualization depicting a participant’s average steps broken down by weekday. A bar graph was chosen to represent the cumulative nature of each data point. The average steps per weekday measure was emphasized for participants to understand where they have gaps in activity. During interviews, some participants were able to provide reasons for why one day of the week might have a lower step count than another and confirmed the utility of such a measure. For example, one participant said that on Sundays they go to church and they spend much of the day sitting at service and with family.

To compare the visualization software, in Figure 1 the Tableau visualization has a default interface that displays further details when a user hovers over a data point. The averages presented above the R visualization serve a similar function. With intensive programming, the R ggplot2 package is more customizable than Tableau. For example, the placement of averages above the bars in the R plot would not have been possible in Tableau.

Figure 2 shows the two platforms’ versions of blood glucose values plotted against a range band. The scatter plot was chosen to represent single data points and to avoid implications that the blood glucose readings are entirely dependent on one another. The range band was initially chosen as the best way to indicate “good” vs “bad” readings.

Figure 2.

Panel A shows blood glucose in Tableau. Panel B shows R ggplot2

When comparing the visualizations, the Tableau visualization has interactive capabilities allowing a user to select specific dates to evaluate. Users are also able to select discrete data points to retrieve more information about a particular blood glucose reading. Meanwhile, the R ggplot2 visualization is a static graph with no user interface.

Figure 3 displays the Fitbit daily steps over time with an average or moving trend line. These plots were designed as line graphs to best represent the long-term longitudinal data with some sort of trend line.

Figure 3.

Panel A Fitbit daily steps in Tableau and Panel B in R ggplot2

The comparison between Tableau and R ggplot2 visualizations in Figures 3 and 4 demonstrates that visualizations created in R are far more customizable than visualizations created in Tableau. While Tableau has easy-to-use statistical analysis tools, they are not as meaningful as statistical analysis tools in R. In R, moving and weighted averages can be custom programmed into the visualization.

Figure 4.

Blood Glucose Breakdown in Tableau

Aesthetically, the figures are similar. However, the Tableau aesthetics are optimized by the software and very little customization is required. The R ggplot2 package¹² requires specific programming for every feature of the plot to reproduce Tableau’s clean aesthetic. At first, this made Tableau far more appealing as a data visualization tool. However, the merits of the ggplot2 package became more obvious as visualization features needed more customization.

Figure 5 reinforces the fact that R allows for significantly more personalized visualizations than Tableau. This graphic was designed in Adobe InDesign® and integrated into visualizations using simple code in an R Shiny application. The Shiny code sets number ranges for each of the six categories displayed and adjusts the graphic accordingly, giving users a colorful meter to read rather than numbers. This was designed as an option for participants more interested in the summary of their health rather than getting bogged-down by the detailed depiction of data points.

Figure 5.

Blood Glucose Animated Visualizations in R

As we began exploratory patient interviews (n=13), we discovered the level of accessibility participants would have to each visualization software. Although participants indicated that they had smartphones, many did not have home computers, even if they indicated that they had Wi-Fi at home. In one interview, the participant viewed interactive Tableau visualizations on an iPhone 5C screen, like the one depicted in Figure 6. Figure 6 depicts the same visualization as the one in Figure 4, but on an iPhone 5C screen. On the smartphone screen, the participant was not able to zoom or navigate as he would have on a computer. This pointed out a need for the visualizations to be adapted for smartphone use rather than for larger screens.

Figure 6.

Tableau Visualization on iPhone

Due to the inaccessibility and impracticality of Tableau, as well as the customizability of visualizations in R, the final data visualizations were created in R using ggplot2 and R Shiny. To ensure access to the visualizations during the interviews, we decided to mail participants a printout of the visualizations rather than a computer file. This prevented challenges with speaking to participants on the same device that they were using to look at visualizations. These visualizations were used as a talking point during phone interviews to discuss both the design and interpretation of the visualizations as well as the social determinants that might be affecting their diabetes self-management.

A main purpose of this study was to determine what kind of data should be presented to participants and how the data should be presented. These considerations included the granularity of time variables, colors, shapes, and data formats. Before creating smartphone-accessible visualizations, we first focused on what information should be presented and how. After participants received printed versions of the data visualizations, they became more engaged in the interview phone calls. The interviews focused on questions about health, what the visualizations meant (colors, shapes, etc.), visualization time frames (e.g., 1 month data vs. 3 months of data), and how patients would prefer to receive health data in an electronic health record.

As we iteratively changed the visualizations based upon feedback, we found that participants prefer simple visualizations that show what is “good” versus “bad”. In other words, when blood sugar is too high or too low, participants would prefer the colors to indicate this. Thus as shown in the above visualizations, a green, yellow and red coloring is acceptable and all participants seem to make sense of this, regardless of socioeconomic or educational background. Participants have indicated a desire to have the visualizations focus mostly on data within the past week or month and to have an option to view historical data over the past 6 months. Moreover, participants have expressed interest in predictive analytics embedded into the visualizations. Participants want to see what will likely happen based upon current health data. For example, participants want to know how daily blood sugar predicts their next HbA1c. They would also like data to be combined into a simple presentation of what their health will be like in a specified future time frame. We are still determining what that future time frame should be, but we believe patients’ “next doctor’s appointment date” is likely the best target. The accountability assumed from what their doctor is going to see at a future appointment appears to be a significant motivator.

Limitations

This observational study consisted of a sample size of 60 participants, thus clinical changes due to the self-management aspects of the devices cannot be concluded. A larger sample of participants, including clinicians, warrants interviews in which additional and interactive visualizations are presented. Moreover, an implementation science trial is needed to discover how to optimally integrate these visualizations and data into an electronic health record (EHR). Despite these limitations, we are able to successfully retrieve near real-time data from diverse participants with a diagnosed chronic illness. Our future plans include interviewing clinicians in a similar manner and integrating these tools and data into the EHR to examine clinical utility in larger sample sizes.

Discussion

As electronic health records advance to incorporate data from emerging technologies such as wearables and smartphones, we need to understand how to optimally use these near real-time data tools¹³. This research aims to influence the development of patient portals within electronic health records by understanding and addressing the challenges involved in acquiring, interpreting, and displaying this data set. In particular, we need to ensure that the presentation of these data is accessible and understandable by diverse populations.

Our team had to discover how to merge mHealth data streams and visualize results in aggregate. Platforms for data integration do not readily exist yet in clinical practice; thus, custom development is still needed. Data streams often include non-deterministic gaps and contextual variables that may or may not be related to health. As this research demonstrated, the volume, variety, and velocity of streaming data facilitated by mHealth technologies contained significant errors, necessitating data cleaning and statistical algorithms to assure reported data accuracy. There are also limited guidelines on how to present these data back to diverse patients with chronic illnesses to inform their health decisions and behaviors.

This is one of the first studies to collect these streaming data from diverse patients with T2DM, providing us the opportunity to identify how to return these data back to patients in a manner meaningful to them. We began this study with a priori assumptions about how to present data yet needed a systematic approach to test our assumptions. Experimenting with data visualization creation and adapting interfaces to this patient population were key to the study. Most importantly, we learned it is essential to engage the end user from the beginning of the design process to understand the data in context and to appreciate the user experience.

Since usage of smartphones as a primary access point for mHealth data will continue to grow, our future research will focus on creating tailored smartphone visualizations and improving underlying algorithms. Emerging data science, including machine learning approaches, applied to mHealth data will better guide patients in making positive health decisions and behavioral changes. Additionally, predictive data analytics will inform clinical practice by characterizing the medical and social determinants¹⁴ of patient outcomes on a large scale, enabling timely, targeted provider interventions as needed for individual patients.