Creating a Sustainable Collaborative Consumer Health Application for Chronic Disease Self-Management

Abstract

As the prevalence of chronic diseases increase, there is a need for consumer-centric health informatics applications that assist individuals with disease self-management skills. However, due to the cost of development of these applications, there is also a need to build a disease agnostic architecture so that they could be reused for any chronic disease. This paper describes the architecture of a collaborative virtual environment (VE) platform, LIVE©, that was developed to teach self-management skills and provide social support to those individuals with type 2 diabetes. However, a backend database allows for the application to be easily reused for any chronic disease. We tested its usability in the context of a larger randomized controlled trial of its efficacy. The usability was scored as ‘good’ by half of the participants in the evaluation. Common errors in the testing and solutions to address initial usability issues are discussed. Overall, LIVE© represents a usable and generalizable platform that will be adapted to other chronic diseases and health needs in future research and applications.

Graphical abstract

1. Introduction

In the past 10 years, advancements in technology, increasing broadband and internet access, and increased ownership of home computers and mobile devices have encouraged designers and researchers to build consumer health applications centered on health promotion and disease prevention and management. These applications provide not only a means to potentially improve health communication and education, but have potential to assist consumers with making changes in health behaviors. With the increased need for services following implementation of the Affordable Care Act, and the ongoing chronic disease epidemic, the demand for new media to help consumers self-manage their disease(s) also increases. In the U.S., about one-half of all adults have a chronic disease (1) and about one-quarter have two or more chronic diseases (2). Diabetes affects 29.1 million Americans, the majority of whom have type 2 diabetes (T2D) (3). Individuals with T2D provide 99% of their own care (4) and thus self-management (physical activity, diet, glucose testing, etc.) is critical to maintaining wellness. To control costs, eliminate barriers to healthcare and assist individuals to self-manage their disease, individuals need not only education on self-management skills, but social support (5), and frequent patient-provider interaction (6, 7). Implementation of the multicomponent Chronic Care Model (8) has shown that patients with chronic disease who have productive and planned interactions with a health care team and who have self-management support augmented by resources in the community have improvements in health outcomes (9).

Resources in the community to augment self-management skills of health consumers include eHealth tools. eHealth tools are health information resources such as mobile apps and internet – based resources which may provide education, online forums, and peer and provider support. Consumers with chronic disease who are actively engaged in their health care through the use of eHealth tools have improved knowledge (10–13), self-management behaviors (11, 12, 14, 15), social support (10, 13, 15) and self-efficacy (10, 11, 15) with regard to managing their disease.

The participatory internet provides new ways to cultivate engagement between consumers, and consumers and providers. Many applications focus on changing health behaviors, yet most are disease specific or track specific health parameters. Due to the pervasive problem of chronic disease, including multiple comorbid chronic diseases, the demand for self-management of these diseases, and the need for cost containment, we need to build consumer health applications that are applicable or transferrable to any chronic disease. An application that utilizes a database as its core structure can meet this goal. Building such an application is cost effective since the main application remains the same and only the contextual information changes.

We developed a theoretically grounded, technologically-based, bio-behavioral virtual environment (VE) to facilitate self-management of diabetes (16). We are evaluating the efficacy of this VE on diet, physical activity, and metabolic outcomes in our current multi-site randomized controlled trial (NHLBI 1R01-HL118189-01) (17). This enhanced version, called LIVE© (Learning in a Virtual Environment), is based on our preliminary work in Second Life (SLIDES) (18). Similar to SLIDES, LIVE© was built as a virtual community for diabetes self-management training and support and was constructed as a virtual 3D community with disease specific information embedded in objects located in virtual stores within the site (17). Participants with T2D enter this environment through a website 24/7 and they self-represent as avatars within the site. While in the site, they can access information located within objects in any of the virtual stores, attend diabetes classes moderated by diabetes educators in real-time, participate in the text only forum, watch previously recorded classes, interact synchronously with other participants or diabetes educators via voice, co-create content on the site, or play interactive games. The goal of this paper is to provide information on how we built this virtual software platform using a 3-tiered Model-View-Controller (MVC) architecture which we describe in detail below. Although the content developed in this VE study focuses on T2D we built the backend of the VE to be disease agnostic where the content could be easily changed in the database and thus could be straightforwardly modified for any chronic disease.

2. Methods and Materials

The LIVE© environment was collaboratively built by experienced game developers, study investigators, diabetes clinicians and educators. This VE was built with Epic Games Unreal^® Engine 3 (Cary, NC), which is the third iteration of the Unreal Engine. Level designers created levels using the Unreal Editor, a suite of tools for working with content in the Unreal Engine and the game logic was created using Unreal Script, a scripting language developed specifically for the Unreal Engine and C++.

2.1 Phases of the Build

2.1.1 Agile Scrum

LIVE© was created using a Scrum development process (19). This process involves rapid iteration with constant communication between developers and the investigator stakeholders. The first part of the process was to determine the requirements of the system with the goal of creating a Game Design Document, which the investigators and the developers could reference during development.

The requirements in the Game Design Document were broken into user experiences known as ‘stories’. All of these ‘stories’ were added to a list called the ‘backlog’. Throughout development, additional stories were added as new functionality requirements arose through iteration and needs of the investigators. The development cycle involved 2–3 week long development iterations known as sprints (20). Each sprint consisted of pulling a set of stories from the backlog to complete each story. For example, one sprint was to create an environment with non-player characters and interactive objects. The team discussed the progress of each sprint each day and resolved any problems associated with a particular sprint. At the end of each sprint, completed stories were removed from the project while incomplete stories were moved to the backlog. Often at the end of the sprint, deliverables were shown to the investigators to obtain feedback about a new feature or modifications of an existing feature.

2.1.2 Build Phases

This project followed the traditional game development phases of alpha, beta, and gold master. The development team worked closely with the investigators, who iteratively reviewed and tested the different phases of the game development and suggested changes to the functionality as needed. The alpha deliverable had functional core systems with placeholder assets and interfaces (characters, props, etc.). Once the core game systems were established, the beta phase refined and improved game systems as well as implemented high quality game assets. The gold master phase addressed final bugs, system refinements, and artistic enhancements to create the final version 1.0 of the game. As this game is a massive multi-player online (MMO) game, continual refinements and enhancements were made to the application with incremental updates and two additional functionality enhancement cycles. Examples of this project’s items in each phase are shown in Table 1. Overall, the cost of creating this environment including the data structures was $415,000. There were additional costs for end-user support over a period of 5 years, which equaled $85,000. However, considering that the application could be reused for other diseases, the costs for reuse would be significantly less.

Table 1.

Game Development Phases

Platform Aspect/Functionality	Alpha (4 months)	Beta (1 month)	Gold Master (1 month)
Environment/Characters	Initial asset creation of avatars and district environments	High-fidelity in-game avatars and district environments	Final art assets (avatars, environments)
User interface	Place holder user interface with basic functionality	Refined user interface art style with enhanced functionality	Final bug fixes and system refinements
Model/controller	MySQL database integrated with VE to allow database queries from the VE and database responses to the VE	VE queries database to know which content to display
Model/viewer	ARA-Virtual Heroes Go framework (immersive VE platform) with multiple districts to allow users to move between districts and start/join seminars	VE logs created to collect user data to database
Modes of user communication	Voice over Internet Protocol (VOIP) to allow voice communication between users	VOIP communications stored on server
	Text Chat created
Controller – administrative tool	Web interface to allow database modifications by administrators	Features such as import, export, filtering, pagination, etc. added to administrative web interface
Synchronous classes	Educator-driven mediaboards to allow shared desktop window content to the participants
Avatar customization	Avatar customization via choosing different clothing and avatar characteristics such as skin tone, hair color, sex	Clothing interface developed to allow avatar clothing to be created by administrators
		Clothing interface developed to allow users to obtain clothing for their avatars

2.2 User-Centered Design

As with Scrum, user-centered design is an iterative process. The main goal in user-centered design, especially applications designed for health care consumers with various levels of computer literacy, is to create an application that takes into consideration not only the characteristics of the users, but the goals and tasks of the users (21). Throughout the design lifecycle, we took into consideration any problematic usability issues in our prior Second Life VE (18). For example, in our previous version (SLIDES), we embedded information into 200 different grocery store items, which required the participants to find each item located in a virtual store, but also click and close each individual item. In our new version (LIVE©), we simplified this process, so that the number of steps were reduced to two and only required pointing at any virtual item in the grocery store, whereupon a tabbed window appeared that allowed participants to scroll through all of the available grocery store items and accompanying information. We employed these easy to use customizations throughout the VE.

2.2.1 Usability Study

We validated our interface design decisions through a small-scale usability study with a convenience sample of our enrolled initial participants (n=10). Small-scale usability studies are a way to discover hidden usability issues (21); 5 to 12 users will identify 80%–90% of the major problems with a system (22–24). Therefore we recruited 10 representative participants. Upon enrollment into the study, participants were asked if they would like to take part in a usability study that would take approximately one hour to complete. With IRB approval, in a controlled lab setting, participants were first informed about the purpose of this study and were then given training on the talk-aloud technique (25) using a simple math problem and scrambled letter technique. Participants were then given a series of 42 frequently used tasks to complete within the VE while talking aloud and were assessed for successful completion of each task. The investigator conducting the usability testing observed the participants logging into the VE and then observed them as they completed a list of tasks such as going to each place in the site, finding items in each place and using the various functionality in each place. For example, participants were asked to find the chat forums, open the forums and make a new post in the forum. Each task was recorded as successfully accomplished or as a failure to accomplish. Upon completion of the tasks, participants were asked to complete the System Usability Scale (SUS) (26). The SUS is a 10-item scale that is scored on a 5-point Likert scale and assesses the general usability of a system (27). There are five positive and five negative statements and the scale provides a single summed score on the system being evaluated. The alpha coefficient was found to be 0.91 based on 2,324 cases (27). We added one open-ended question at the end of the SUS which queried the participants on the top three things that they liked about the VE. We obtained information on what they did not like through the talk-aloud protocol.

2.2.2 Analysis

Descriptive statistics were calculated for participant characteristics and error rates. Error rates for each task were calculated by determining the frequency of errors by task to determine which tasks had the most errors. Additionally, we determined the overall error rates and the percentage of participants who made an error for each task. The SUS scores were calculated as described by Brooke (26). We analyzed the qualitative data obtained through the talk-aloud procedure, observational notes, and the open-ended survey question, using content analysis, a data reduction technique (28), to organize and code these data and identify themes (29), thus describing the meaning of the qualitative data.

2.2.3 Usability Results

The 10 usability study participants from the randomized LIVE© group were predominantly female and Caucasian (60%), average age was 58±10.03 years old, and 60% had some college education (30%) or a Bachelor’s degree (30%). All of the participants were internet literate with 10% spending 3–9 hours per week on the Internet, 60% spending 10–19 hours per week, and 30% spending 20–39 hours per week.

Of the 42 tasks completed per participant, 19 (45%) of the tasks were completed without any difficulty. Overall, participants could not complete without assistance 10% (n=44/420) of the tasks. Two (20%) of the participants completed 100% of the tasks without error. Eight of the participants missed an average of 5.5 tasks with a range of 2 to 9 tasks. The most problematic tasks were: making a post in the discussion forum (n =3); walking in circles with their avatar (n=3); finding the convenience store (n=3); sending a public text (n=3); changing avatar clothes (n=4); and finding a fast food restaurant menu (n = 5).

The SUS scores ranged between 27.5% and 92.5% with an average of 70.2% (SD = 20.32). According to Tullis and Albert, average SUS scores under 60% are considered poor usability scores and scores above 80% are considered pretty good (30). Five of the participants scored the VE on the SUS at 80 or above (range = 80% – 92.5%), whereas two of the participants scored the VE under 60% (47.5% and 27.5%). There was no correlation between the number of errors the participants made on the small-scale usability study and their SUS scores. See Table 2 for error rate and SUS scores per participant.

Table 2.

Error Rates and SUS Scores

Participant	Number of tasks unable to complete out of 42 (% incomplete)	SUS Scores
1	9 (21.4%)	82.5
2	5 (11.9%)	92.5
3	9 (21.4%)	47.5
4	0	87.5
5	6 (14.3%)	60
6	2 (4.8%)	27.5
7	0	65
8	4 (9.5%)	82.5
9	2 (4.8%)	80
10	7 (16.7%)	77.5

2.2.4 Participant Feedback

Four major themes emerged from the feedback received from the participants. The major themes were educational, in-person interaction, fun, and functionality. The majority of the participants (n=9, 90%) found the site to be informative and educational. Participants stated that the site had “lots of information”, “information is extremely helpful”, “finding many new resources” and “a lot of good information in one place.” In-person interaction also arose as a theme. Seventy percent of the participants (n =7) mentioned the interactive live classes with educators as a positive aspect of the site. Three of the participants (30%) stated that the site was “fun” and that they liked the “competitive games” where they could “earn points and compete against other players” and “learn things while playing”. There were aspects of the functionality that caused problems with the participants. There were several aspects of the functionality of the site that the participants stated they had difficulty using. For example, 40% of the participants when asked to find frozen food in the grocery store, began to look for signage for the frozen food on the cold cases. They stated that they could not “find the frozen food”. This issue with the functionality prompted us to add signage in the grocery store, even though the tabbed window would pop-up with all of the food items regardless of where in the store they accessed the food interface. The other feedback we received from the participants regarding functionality and changes that we made to make the site more usable were adding more diverse avatar skin colors and marking non-player characters that had an active game associated with it by adding an exclamation point over the head of these characters. The remaining issues that the participants stated that they had such as finding various menu items were resolved through showing them where to find the items and highlighting or touring these areas during interactive classes. We found with usability testing that one introductory teaching session at enrollment was not enough. Participants often forgot much of the functionality that was taught during the initial introduction to the site. Thus, we found it necessary to make a follow-up phone call after the initial introduction to the site to review the functionality of the site.

2.3 Data Model/Administrative Tool

In this study, the VE gives the participants access to a significant amount of diabetes-related content. Keeping this content up-to-date posed a challenging technical problem. One potential solution was for the investigators to send content modifications to developers, then the developers would make those modifications, create a new version of the VE, and release the modified VE to all users. This approach was good in that there was a very small learning curve for the investigators and the developers could ensure bug-free content updates. However, each content update would take a large amount of effort and time from developers, leaving a delay between when the administrator asked for the modified content and when the users saw the modified content. To solve this problem, the developers implemented a way for the investigators to update content directly in the VE, without developer involvement and without creating or deploying a new build of the VE. This approach was implemented by loosely following a standard Model-View-Controller (MVC) architecture: (1) Model (MYSQL database): maintains data; (2) View (virtual environment): displays data to user; and (3) Controller (Administrative tool: and a website built to view/edit the database): controls interactions between the Model and the View. The administrative tool modifies the database, the database provides content locations in the VE and the VE sends data to the database. Most VE content queries the database to determine what to display in the VE. The Controller website exposed the database such that administrators could modify the database without prior MySQL experience. This approach allowed the investigators to make content and game modifications that immediately showed in the VE. See Figure 1 for an example of the Controller interface. In this example, the backend of the database automatically configures the ids, and the investigators fill in the remaining content, which is shown as text (name, description and comments) and a picture (links to the picture stored on our server) to the participants and additionally contains a link to the Internet to provide the participants with more information about the item. The ‘visible’ field makes the item visible or not to the participants, which allows investigators to rotate content to keep the site dynamic.

Figure 1.

Controller interface

2.3.1 Backend Framework/Data Collection

The backend framework not only involves the administrative tool, but is also collecting data on all user activity including time in the site, objects clicked, and locations visited. Additionally, the site had to be scalable to the number of users on the site. Therefore, the scalable back-end used a combination of Epic Games Unreal^® Engine (UE3) dedicated servers as well as Virtual Heroes, Inc. (Raleigh, NC) proprietary load-balancing component, known as Go platform. Both users and dedicated servers connect directly to the MySQL database. Go is made of three components: (1) Master Server: service running on one machine that manages user connections and requests from users; (2) Satellite Server: service running on one machine that manages UE3 dedicated servers; connects directly to Master Server but not to users; and (3) UE3 Dedicated Servers: one or more servers running on one or more machines; each server is in charge of a VE instance that supports up to 32 users.

When initializing a build for users, the first step is to turn on the Master Server service, then turn on the Satellite Server service and connect it to the Master Server. Part of the Satellite Server service is to initialize a certain number of UE3 dedicated servers and connect them to the Satellite Server. Once the Master Server, Satellite Server, and UE3 dedicated servers are initialized, users can connect to the Master Server and get pushed to the correct UE3 dedicated server. If the number of users exceeds the UE3 dedicated servers’ capacity (~32 users), then additional UE3 dedicated servers are added.

2.4 View: Front-end User Environment

The user environment consists of the viewer (browser plug-in and displays the game window) and a standard web browser (Internet Explorer or Mozilla Firefox). For this project, play occurs inside of a web browser. To accomplish this, the VE is rendered in a browser tab using the Go Plugin, a web plugin created by Virtual Heroes (Raleigh, NC). This plugin handles both updating the VE to its latest version and rendering the VE to a browser tab. When the user navigates to the LIVE© webpage, the plugin is invoked, then launches the VE from its local executable with certain command-line arguments. These command-line arguments direct the VE to render to the browser tab window instead of creating a new render window.

The build of the structural components within this VE was based on the structure from our SLIDES feasibility study (31). Similar to SLIDES, we built the interface as a representation of an island, but changed it from a town to a resort community with four main districts (lobby, food court, plaza, reflection garden) and nine different virtual stores placed within the four locations, where the specific diabetes content resides in interactive objects.

2.4.1 3D Programmed Components

The VE consists of interactive objects such as non-player characters (NPC), tables, chairs, benches, media boards, bookcases, grocery items, fitness equipment, avatar clothing, pharmacy items, and virtual computers. Interaction with these programmed objects through a mouse click serves three purposes: 1) direct communication with the Internet; 2) provide information and feedback to the participant related to the specific object; and 3) encouragement of social networking.

All participant names are anonymized and a password is assigned to each participant. Their login name also becomes their email address for study team communications. Study participants cannot change their user name or password. When participants sign into the VE through the user id and password protected web browser, they are presented with a main menu, an information box to show them who else is in the site and in which location, a game menu, and a mute button for all voice communication (see Figure 2). The main menu is a map that users can click on to choose where to go in the site.

Figure 2.

Main Menu of LIVE

The VE game menu contains features for the participants and the administrators and includes avatar customizations, a quest log to view their current gaming statistics (rank, badge, unfinished quests), clothing creator, audio wizard (set-up for audio component), seminar play-back browser, seminar creator, and join a seminar. Only the administrators access the clothing creator. The clothing creator interface, for example, provides the administrators the ability to create different types of clothing at different prices, which can be bought through the clothing store with tickets earned through participation in the site or through games. All diabetes self-management classes led by diabetes educators held twice weekly in real time are video recorded. The functionality of the seminar creator provides the educators with an interface to create a classroom within any location in the site. The seminar playback browser interface allows the users to view any previously held class. The ‘join a seminar’ interface allows the participants to join a seminar in real time.

2.4.2 Avatars

Each participant self-represents in the VE as an avatar. The VE displays the avatar to the participant from a third person perspective. We designed it this way because we noted that participants in our previous study reported nausea or ‘cybersickness’ if they visualize the environment from a first-person perspective. Participants can personalize their avatar through an interactive interface (see Figure 3). This interface provides a way for participants to choose hair color and style, skin tone, gender, and clothing purchased through tickets earned in the site. Each participant’s anonymous name appears over their avatar’s head within a nameplate while in the VE. In this environment, participant avatars navigate by walking short distances within one location and teleporting between locations. This improved the usability of the VE, since participants do not have to waste time walking longer distances from one location to another. The avatars can additionally sit in chairs or on benches. Participants have the ability to speak to other participants in real time via voice (Voice over Internet Protocol [VOIP]) through a headset with a microphone. When any participant speaks to another participant, an icon appears over their avatar’s head visually displaying to others the source of the voice. This is particularly helpful in classes where there are numerous participants in a classroom and thus it allows the diabetes educator or other participants to immediately identify the source of the voice.

Figure 3.

Character Customization Interface

2.4.3 Stores

The 3D structural components within the VE include a pharmacy (see Figure 4), bookstore, seasonal stores, restaurant (features fast food and chain restaurants), grocery store, convenience store (to teach people how to shop in food deserts), fitness center, clothing outlet, and a reflection garden.

Figure 4.

The Pharmacy

In addition, instances of a classroom can be easily created by educators in any area of the site through a menu interface (See Figure 5). A classroom features chairs, a podium, and a media board for slide presentations or presenting of web content. Using synchronous voice communication, diabetes self-management classes are held twice weekly and videotaped for later viewing.

Figure 5.

Classroom

Within each location in the VE, instead of embedding content within each item, we created a tabbed interface that appears once any object is clicked on within a particular location. The tabbed interface provides information related to a specific location. Figure 6 shows an example of this tabbed interface in the grocery store. It contains information on meat and seafood, dairy, produce, beverages, bakery, packaged and frozen food items. Associated with each item are the nutritional facts from the USDA database, a picture of the item and specific feedback about that food item in relation to diabetes nutrition. The realism in the site is created through photographic and behavioral realism and through ambient sound (32, 33). For example, when the participants enter the lobby area, they immediately hear in the background the distant sounds of many other people talking or different types of music in the stores.

Figure 6.

Grocery Store Interface

The reflection garden was created based on the results from our feasibility study (18), where participants reported that they spent time on the periphery of the island (near the water) for stress management. Thus, we created the reflection garden (See Figure 7), which was specifically designed to be a place of relaxation, where the light is muted (always evening) and the ambient sounds include nocturnal birds and flowing water.

Figure 7.

Reflection Garden

2.4.4 Forums

Virtual computers are displayed throughout the site, so participants can easily access ongoing asynchronous discussion forums moderated by diabetes educators. These discussion forums are used to encourage co-creation by the participants and asynchronous social networking with other participants and diabetes educators. Sharing personal experiences about their disease, posing questions, reading about other’s ability to cope with their disease can help to allay fears and increase self-confidence (34–36).

2.4.5 Games

Throughout the site, we added games (quests) that serve to educate the participants on diabetes self-management and training content such as food choices, exercise, physiology, nutrition, and medications and add an element of fun to the learning process, a key component of game-based learning (37). These games can be accessed by clicking on a non-player character with an exclamation point or question mark over their head or are activated automatically by time or location in the site. Figure 8 shows a quest that provides images for answers.

Figure 8.

Quest Example

There are two basic types of quests; one is a series of three to four questions in multiple formats on various topics; and the other is branching scenarios that present everyday situational problem-solving through a narrative arc. The branching scenarios as compared to multiple choice alone require higher level problem solving (38) to manage situations or events commonly experienced by persons with T2D. These problem-based learning scenarios not only enhance patient engagement, but reinforce self-management behaviors (39). Examples of scenarios include a day at the mall, business travel, parties, or vacation. Each quest is timed, defines the number of allowed incorrect answers, and awards skill points in the form of tickets and a score. Tickets can be redeemed by playing quests or purchasing clothing for the avatar. We utilized game mechanics as an additional method to keep the users motivated and engaged in playing the games (40). As they progress to different levels in the game based on their number of points, they earn badges. As an added incentive to engage in the VE, we feature a leaderboard displaying the most active participants in the site every 30 days and award these participants redeemable tickets.

2.4.5 Use Case

There are several scenarios of how users can potentially use the system. They can enter the site and just play the games, or attend class or enter the forum and read and make posts to other users, or they can visit with other users who are in the site or simply explore food choices in the grocery store or the best food to eat at the numerous fast food and chain restaurants. A typical use case scenario might involve any or all of these uses. For example, the user enters the site via a web-browser with a user name and password on class night 30 minutes prior to the beginning of class. At the main menu, s/he notices two other users in the site, but decides that s/he first wants to explore choices to eat at the posted fast food restaurants, so s/he clicks on the food court icon and teleports to that area. S/he then navigates their avatar to the restaurant and clicks on one of the tables. The menu for the posted fast food and chain restaurants appears and s/he scrolls through all of the menu items until s/he finds some healthier options. After reading through the menu items for several minutes, s/he finds the information s/he is looking for: a Whopper Jr. S/he is able to review the calories, fat content, saturated fat, carbohydrates, protein, fiber, sodium and sugar. Also, s/he is able to view the tip provided by the diabetes educator: “Eat this food item without the mayo or cheese. This is a good choice because it is lower in fat, calories, and sodium that the larger burgers and even some of the chicken or salad options”. After finding the information s/he needs, the user then decides to play some of the games, so looks for avatars within the food court that have exclamation points above their heads. After playing a few games, a message pops up on the screen asking the user if they would like to attend the class that is now open. S/he clicks on this box and teleports to the classroom, where the diabetes educator and other participants are seated. During class this user interacts with other users via voice to discuss the class topic, nutrition. After presentation of the class content, the diabetes educator takes the class to the grocery store within the site and they discuss the nutritional content of various food items. At the end of class, one of the participants mentions a great cookbook she found in the bookstore. So the user decides after class to go to the bookstore to review this cookbook and potentially buy it. The user teleports to the bookstore, reviews the cookbook, and is able to buy it from within the site by linking directly to the American Diabetes Association webpage. The user then logs out of the site.

3. Discussion

As the prevalence of chronic disease increases and self-management of these diseases becomes more critical to decreasing the associated morbidity and mortality, building chronic disease agnostic consumer health applications holds promise for cost containment. Reaching patients with chronic diseases for self-management education and support is difficult, given barriers such as physical distance, transportation, scheduling and lack of sufficient numbers of health professionals (41) eHealth programs such as VEs may be used to address some of these barriers moving forward. We have presented LIVE©, a web-based VE that although currently focused on diabetes self-management is unique in that it could be modified for any chronic disease. Its most critical feature is its MVC architecture, whereby the content through the easy-to-use controller could be easily changed to any chronic disease by someone with minimal computer skills. Updating content involves no programming and is simply data entry and picture archiving. Our application, if proven efficacious, can serve as a model for consumer healthcare applications for self-management of chronic diseases.

One major difficulty consumers often have with consumer health applications is the usability of the application. Applications for health care consumers must not only be useful (domain functions), but must be additionally usable (learnability, efficiency, error prevention) and satisfying (42). We conducted small scale usability studies within a few weeks after the participants had been taught how to use the application. Although in human-centered design, usability tests are generally conducted prior to the release of the application, we wanted to focus primarily on the learnability of the application and if there were aspects of the design that needed to be redesigned for better usability. Virtual environments are very different from traditional web-based interfaces. The navigation, for example is through avatar movement or teleporting. Although there is a fair amount of point and click interaction as with traditional websites, participants have to learn that instead of clicking on text, they must click on virtual objects. However, unlike text that can be underlined or be presented in a different color, interactive objects in VEs are not always obvious unless the participant hovers over the object with their mouse, whereby they receive visual feedback (object turns a different color). One of the most problematic areas we found in usability testing was participants had difficulty finding particular information in the site. Although we provided a map of the site (Fig 2) upon entry into the VE and the users were able to access the map again while in the site, they needed more practice than we anticipated. Therefore, we found that we needed to make a follow-up phone call with the participants while they were at home on their own computers to review the basic functionality. It seemed to take at least two trials before the users began to feel more proficient at using the system. We additionally followed up during the online classes to review the functionality as needed. All of our users were considered novices with relation to using a VE and thus the outcomes from our usability evaluation (especially the SUS scores) showed a fair amount of variability among the participants; 50% thought the application had good usability. Although we designed the system with usability heuristics in mind, we think that the problems the users encountered initially had to do with the novelty of the interface. Introducing consumer health technologies such as VEs, especially to older users (average age of our population was 58+10.03 years old), who may not have gaming experience, requires “more time, practice and technical assistance” (43).

Although VEs are more complex than other eHealth educational sites, they offer a different paradigm where the participants are not only interacting with new information embedded in virtual objects in the context of its everyday use, they are also active participants and contributors to the support and education that occurs in the VE. This support and education occurs through real-time peer to peer interactions and real time diabetes education in the context of representative locations they encounter in their diabetes management every day. Diabetes self-management interventions that have been most effective have included interactive, frequent, and somewhat individualized interactions between educators, providers and patients (6). The online discussion forum and synchronous classes are also ways in which participants can interact asynchronously and anonymously with the educators and other participants. Both types of interaction provide the exchange of both tacit (experiential) and explicit (codified) knowledge (44). The forum also allow the participants to co-create content within the site and through co-creation participants derive potentially different types of support such as informational and emotional support (45). The use of online forums and interactions to exchange tacit knowledge has been cited as important in engaging participants actively in their healthcare and disease management (46). The interactive serious games (“games primarily focused on education rather than entertainment”) (47) pg.1425) not only provide explicit knowledge, but add a fun quotient and the development of critical thinking skills. Finally, these multiple ways of learning enhance the overall effectiveness and generalizability across different learning styles.

4. Conclusion

The LIVE© VE is a dynamic, flexible software platform for chronic disease self-management. It offers multiple modes of education and support for adult health consumers with diverse learning styles, support preferences and motivations for learning and health behaviors. VEs such as LIVE© may require more user practice to familiarize adults who are naïve to gaming environments with the full functionality and interactive nature of the interface. The current efficacy trial will provide data as to how and when users become more facile in the process and what aspects of the VE are most beneficial. The architecture of this consumer health application is easily modifiable and transferable to other health conditions and will be further tested and disseminated in future research.

Highlights.

• Creating a Sustainable Collaborative Consumer Health Application for Chronic Disease Self-Management

• Constance M. Johnson, Steve McIlwain, Oliver Gray, Bradley Willson, Allison Vorderstrasse

• A reusable consumer health application (collaborative virtual environment) for self-management of chronic disease

• Uses a standard Model-View-Controller (MVC) architecture where the model maintains the data; View displays the data to user; and Controller controls the interactions between the Model and the View.

• Utilizing this type of architecture, MySQL database is the Model, the virtual environment is the View, and a website built to view/edit the database is the Controller.