Keywords

1 Introduction

The broad availability of mobile devices and wearables has fostered such trends as mHealth, the increasing use of mobile devices in the health context [12]. At first many applications addressed fitness and well-being. Due to the increasing possibilities concerning sensors and data processing assistive technologies are more commonly used. This allows integrating health monitoring and rehabilitation training into everyday life. But despite the potential benefits people often stop using mHealth applications after a few times [31].

It is important to find approaches to motivate regular usage of mHealth applications and long-term commitment, to achieve the underlying health objectives [16]. Mechanics used in games motivate users to change their health behaviors and to stay engaged with the application [26]. Especially younger people are used to motivational concepts used in computer games. The derived concept of gamification tries to shape the activity itself to be motivating [25] and has a huge potential [18]. But to integrate such elements as e.g. badges, daily goals and leaderboards in mHealth applications personal data and usage data has to be processed. Since security and privacy of mHealth applications are crucial [22, 23], privacy risks need to be considered also for gamification elements.

To this end typical examples are selected based on a categorization of archetypes of applications [27], motivational aim of these elements is summarized and it is explored to which extent privacy aspects are already considered. Applications focused on specific illnesses are still in the process of development. To consider a broad range of users, who will sooner or later also be part of the target group of medical programs, fitness and well-being applications are as well evaluated as mHealth applications for rehabilitation and other health-related therapies. Further the usages of the gamification elements are investigated from a privacy perspective. Approaches for a privacy-preserving realisation are proposed.

2 Gamification

Gamification is defined by Deterding as the use of design elements characteristic for games in non-game contexts [6]. A gamification concept is typically based on a variety of elements, as e.g. points, leaderboards and daily goals, that foster the motivation of users. The variety of game elements employed in gamification is broad. Different sources discuss and differentiate varying elements. Garett and Young identified 14 different elements [8] whereas Sardi et al. focus on only four elements and sum up “others” [26] for additional elements. Based on an investigation of literature reviews concerning gamification elements, the following ten elements are stated as the most common and most used elements which are directly visible to users [4, 7, 14, 25, 26, 28]: avatars, badges, daily goals, leaderboards, level, performance graphs, points, progress bars, storytelling and teams (see Table 1 for an overview).

Table 1. Gamification elements

Typically, a combination of elements is used in a specific context. An avatar of a user or a team can be for example integrated in a narrative context and combined with storytelling [25]. As an example an application in which users have to run regularly could draw a narrative context by embedding this activity in a story about a zombie apocalypse. Within the storytelling multiple users could form a group of survivors doing the health-related activities together as a team.

Avatars and storytelling can furthermore be linked with rewards [26, 28] or with badges, level or daily goals while unlocking new content. Expending the previous example in the context of running and the story of surviving, levels could be represented as different forms of survivors e.g. from “fearful newbie” to “survival artist”. Leaderboards, level, progress bars and performance graphs are representations of a users performance based on defined metrics. Therefore these elements are typically combined with points as a basis to make metrics transparent. Performance graphs can also render the fulfillment’s of daily goals over time transparent for users.

To describe the motivational aim of gamification elements, the psychological background needs to be briefly summarized. The effect of gamification is according to the self-determination theory based on basic psychological and intrinsic needs for competence, autonomy and social relatedness [16, 25]. Competence is experienced in events with positive feedback that imply effectiveness. Autonomy is achieved by providing choice and acknowledging experience. Relatedness is combined with social acceptance and recognition. The satisfaction of these needs fosters intrinsically motivated behaviour and can be integrated in extrinsic motivations [5]. Providing feedback on a users performance is a way to evoke the feeling of competence [25]. Additionally other psychological effects like curiosity [4], self-identification [25] and self-confidence [24] can lead to the interaction with gamification elements.

Furthermore the elements can be sub-classified according to the context they are typically used in. Elements which can be seen in a social context drawing a narrative context and representing the users themselves as well as their role in the narrative or application are avatars, storytelling and teams. These elements create representations and frames within the application. Through different psychological effects, e.g. personalizing and cooperation, they satisfy the needs for autonomy and social relatedness. Daily goals and badges can be described as specific goals with clear conditions and the possibility of fulfilling. Whereas points, level, progress bars and performance graphs have a continuous background. They mostly provide different forms of feedback and satisfy with that the need for competence. Leaderboards are a combination of continuous goals in a social environment and for that are complementary to the other elements.

3 Related Work

The use of gamification in mHealth is already investigated in several contexts. For an overview of gamification research in general and an investigation of effectiveness see Koivisto and Hamari [16]. An example is The Heart Game [7], a prototype with daily challenges and additional gamification elements to motivate users like badges, leaderboard, levels and a point system. Other Examples are the prototypical applications Sana [17], Fitrust [29], bant [3], More Stamina [9] and Regain [1].

Cheng et al. [4] investigated applications of gamification for mental health and well-being. They considered which elements are most commonly applied, which domains are most commonly targeted and what reasons are given for using gamification in these applications. An overview of gamification elements employed in an healthcare context is presented by Garett and Young [8]. Especially employed gamification strategies in e-Health as well as the benefits and the most encountered challenges are analyzed by Sardi et al. [26]. There the potential of gamification for health application is broadly investigated.

Disregarding privacy and effectiveness Schmidt-Kraepelin et al. [27] investigated different archetypes of gamification approaches and their relationship to the targeted health behavior. Furthermore independent of the gamification context Pires et al. [24] constructed a classification of mobile health applications by their functionality.

Mavroeidi et al. [20, 21] investigated potential conflicts of specific elements with privacy requirements like anonymity, pseudonymity, unlinkability, undetectability and unobservability and categorized different game elements in harmful and non-harmful elements but without considering the context of the application. The categorization is amongst others based on the differentiation whether users information or actions are recorded and constrained by time.

Although gamification can introduce additional privacy risks by acquiring and recording a huge amount of personal data [11], in the description of gamified applications privacy issues are often not discussed. Several examples which are investigates as The Heart Game [7], Sana [17] and Fitrust [29]. Sardi et al. [26] mention the importance of privacy and security in general in the context of the protection of personal health data, but do not provide a deeper analysis.

Bilbey and Sandikkaya [2] studied the effects of gamification on privacy in a gamified context. They concluded that users of gamified environments are less careful protecting their private information especially when participants are already lured into the gamified environment and enforced to disclose personal information to continue. Therefore the investigation of privacy in gamification applications is an interesting field for further investigation in the conflict between fostering the important aspect of motivation of users to enhance usage times on one hand and the consideration of privacy risks on the other hand.

4 Methodology

Mavroeidi et al. [20, 21] already investigated privacy in gamification on a general basis. But in an health context especially in the area of mental health and cognitive deficiencies already the use of an app contains the risk of stigmatization. For example a person using a mobile device at work is often considered a distracted worker, although the used application actually might help the person to stay focused.

To provide a broad overview of gamification in mHealth the archetypes of Schmidt-Kraepelin et al. [27] are used and examples for mHealth apps for the considered types are provided. Using these archetypes ensures that the examples are selected from different fields of mHealth applications which pursue different objectives and use the concept of gamification in various forms. For these examples the employed gamification elements and their motivational aim is summarized and it is investigated whether in the context of the application itself and the additional gamification elements privacy is directly mentioned. In addition it is investigated whether the data needed for gamification elements is justified by the intended effect from the point of view of the users and which opportunities exist to reduce privacy risks.

5 Analysis

5.1 Selection of Examples

Based on the archetypes of Schmidt-Kraepelin et al. [27] examples of mHealth applications targeting patients were selected which employ gamification. Archetype 7 Positive and Negative Reinforcement Without Rewards and Archetype 8 Progressive Gamification for Health Professionals were both disregarded since they solely target health professionals. In the following the examples and their classification according to the archetypes are described. For an overview see Table 2.

Table 2. Selection of examples of mHealth applications based on the archetypes of Schmidt-Kraepelin et al. [27]

Fitrust is an application integrating Fitbit’s and Nutritionix web API to gain and analyse information like users steps and heart rate time series as well as record food and exercise calorie information to help the users to lose, maintain or gain weight [29]. This can be assigned to Archetype 1 Competition and Collaboration which contains competitive and collaborative gamification elements helping the users reaching externally and self-set goals while the gamification approach is independent of the underlying health activity. To the same archetype another application The Heart Game assisting heart patients in their telerehabilitation process can be allocated. It uses several gamification elements presenting each day exercises as daily goals for a team of two, a patient and a companion, while offering the use of a point system, badges, a leaderboard, a progress bar, level and performance graphs [7].

Archetype 2 Pursuing Self-Set Goals Without Rewards exclusively draws on goals that are set by the users themselves and does not offer any type of explicit rewards for specific health-related activities like badges. An example that can also be seen as a serious game but is still a good example to represent this archetype is Zwift. This application enables virtual sports while recording real-world athletic performances [32].

The Sana system and the Regain App are both developed for increasing engagement and improving rehabilitation programs. Sana imitates real-life physiotherapy sessions for post-operative anterior cruciate ligament reconstruction patients simplifying the exercises to the goal of reaching a green circle [17]. Regain helps stroke patients in rehabilitation at home by providing exercises with animated self-avatars in a familiar environment like a garden or living room [1]. Both systems belong to Archetype 3 Episodical Compliance Tracking targeting amongst other therapy adherence where the narrative is always episodical.

Another application concerning stroke patients is Let’s Farm transferring and embedding recovery exercises as various farming activities [19]. This is an implementation of Archetype 4 Inherent Gamification for External Goals where the health-related activity is partially or fully embedded in the gamification approach and therefore it is impossible to execute this without interacting with the gamification elements.

Archetype 5 Internal Rewards for Self-Set Goals describes the use of gamification evoking users’ behavior and attitude to change by experiencing positive and negative reinforcements for decisions concerning self-set goals. For that solely internal rewards like points and badges are used without any form of competition. More Stamina tries to help persons with multiple sclerosis to manage their energy by transferring it to a point system. The users spend these points on self-set activities and achieve badges for example for continuous usage and correct energy assessments [9].

An application consistent with Archetype 6 Continuous Assistance Through Positive Reinforcement is the bant app for the management of type 1 diabetes in adolescents [3]. This archetype targets patients requiring continuous assistance and therapy adherence not containing any competitive elements or negative reinforcements and offering no rewards like badges.

5.2 Investigation of the Examples

As a first step of the analysis it was investigated whether privacy was already addressed in the description of the examples. Table 3 shows the results. Five of the examples, Fitrust, Heart Game, Zwift, Sana and Let’s farm, did not discussed privacy at all. For Regain a requirement for security was defined, but no privacy issues were addressed. More Stamina and Bant addressed some privacy considerations. However, while these considerations refer to privacy concerning the functionality of the application, the gamification elements were not considered.

Investigating possible privacy risks, all examples were analysed which data is needed or shown by the ten different elements presented in Sect. 2. The results for elements with social focus are summarised in Table 4a, for elements for continuous monitoring in Table 4b and for elements for specific goals as well as the complementary element in Table 4c.

Table 3. How privacy was addressed in the examples
Table 4. Analysis which data is needed or shown

The investigated examples needed for elements with social focus primarily to record customization choices. Only the progression of the storyline in Let’s Farm or the individual engagement based on the users improvement in Sana needed additionally a small amount on user-specific performance data.

In contrast for gamification elements for continuous monitoring the choices of the users have hardly influence on the recorded data. Points were given for activities needed to use the application as intended. For example bant is an application for management of type 1 diabetes. To manage diabetes it is important to do blood glucose testing. Points are given and recorded for each test the users perform and for that only depend on the choice to use the application itself. In every example the points were recorded accumulated.

For the implementation of level two of three applications did not need any other data and could calculate the level based on the points. Similarly four of five applications used the progress bar only as additional display and reuse the data already recorded by other elements. All examples using a performance graph recorded the shown data per day.

The gamification elements for specific goals were mostly described exemplarily. Especially the badges could have needed far more data than shown. However the daily goals were significantly simpler than the badges. In The Heart Game they were solely used as daily suggestion and therefore did not need any personal data at all. Further in Fitrust only simple data like steps and glasses drunk were needed. The leaderboard as complementary element did not need specific data itself but rather combined other gamification elements and thus needed the data they record.

When multiple users are linked together as in case of teams and leaderboards a centralized component for data processing is needed. If the teammates share the usage data locally as for example in The Heart Game, since they both use the same device, this is not necessary. The actual connection of users within a leaderboard can be avoided by using virtual opponents which in addition can be adapted to the users performance. The other elements like points, level, progress, performance graphs, badges, daily goals, avatars and storytelling could be processed locally.

In summary the elements with social focus needed some customization choices but recorded only a small amount of performance data. Elements for continuous monitoring on the contrary did not need customization choices, instead constant performance data had to be collected. Points were always accumulated and the performance graphs displayed data per day. Level and progress bars were mostly solely used as additional displays. The elements for specific goals were only described exemplary. However the daily goals were simpler than badges. Finally the leaderboard does not record data itself but needs other elements (e.g. points) which record data. The privacy issues concerning the used gamification elements were not discussed in the investigated examples and should be evaluated further.

6 Addressing Privacy Risks of Gamification Elements

Since gamification is an important mean to foster motivation for continuous use of mHealth apps [18], it is not the main aim of the mHealth app but nevertheless supports the corresponding goals. Therefore, these additional elements should not include additional privacy risks. Hence the principle of data minimisation should be a central design criteria and since in some cases (e.g. mental health) already the use of an mHealth app may result in stigmatization of patients, anonymization or at least a strong pseudonymization of patient data and the privacy protection goal of unlinkability [15] are important. To realize these central goals beside data minimization, decentralization [30] as a guiding principle is important. Data for gamification elements should be processed only on the device of the user where possible. In the following it is analyzed how these principles could be applied in the context of the gamification elements employed in the context of the examples for mHealth applications.

Based on the classification of the gamification elements in Sect. 2 in the following the privacy risks are further investigated. Regain, More Stamina and bant used in each case only two gamification elements while in addition for More Stamina and bant the level and progress bar was only a further representation. The Heart Game and Fitrust are both applications of the archetype 1 (see Sect. 5.1). Because of this as leading examples the applications Fitrust, Sana and Let’s Farm are used. None of these already addressed privacy risks (see Sect. 5.2). All three applications use elements with social focus and will be compared for the investigation. The elements with a focus on continuous monitoring will be further described by the examples Let’s Farm for points and level as well as Sana for the progress bar and the performance graph. The elements for specific goals and the leaderboard as example for complementary elements are investigated based on the example Fitrust.

Fig. 1.
figure 1

Avatars

6.1 Elements with Social Focus

Elements with social focus offer many opportunities for personalization. The more options are available, the more information about the user might be revealed. In Let’s Farm the users can upload an individual user picture (see Fig. 1b). These pictures can reveal a lot about a person especially when interconnected with other users like in a leaderboard or in a team context. For example a user could upload a picture that shows the person itself in the living room. This reveals on the one hand the person behind this user. On the other hand the background shows how this person lives and for example possibly the wealth status or some clues about the location. In contrast in Fitrust users can choose from a given selection of abstract pictures. Additionally the users can choose and arrange different titles describing themselves and provide a freely choosable name (see Fig. 1a). Although the options of pictures and titles are limited, the same issue of revealing personal aspects might occur. Since this privacy issue is mostly based on users choices, it is advisable to use a privacy awareness panel. In such a panel the users can be warned about the consequences of specific shared data and which data are visible to others and to whom [10].

Fig. 2.
figure 2

Storytelling

The more adapted a story is to a specific user the more information about the person is needed. Fitrust only provides a short story at the beginning independent of the users interests (see Fig. 2c) creating a frame the users can draw further in their minds while using the application. This implementation does not lead to privacy issues. However personalization can be desirable because a story is particularly inspiring and motivating if it is in line with the personal interests of the user [25]. For that Sana simulates a physiotherapist encouraging the user to create a familiar environment. Only expressing encouragement by cheering up users during an exercise with motivational messages like “A little bit more” (see Fig. 2b) does not need permanent storage of data, only the current progress within the exercise. To personalize this encouragement without recording data over a longer period, it is possible to solely store the performance of the last time. Saying that the user have done better than yesterday as an additional motivation factor. Furthermore Sana additionally encourages users outside the exercises by messages which for example address the decrease of users average pain score. For this feedback the recording of the pain score is needed. Personalized feedback like that is based on processing of personal data. Even though the adjustment of feedback appropriate to the level of the patient is crucial [26], it is important to investigate for each context which amount of personalization and data is needed for a meaningful feedback.

As noted before gamification elements should not include additional privacy risks. However to effectively simplify a complex matter within a story, it is often necessary to process additional data. As example in Sana the users have to train their knee. The application wraps this activity in the simple goal of reaching a green circle instead of only specifying a specific angle the knee shall reach (see Fig. 2b). This can be implemented in two ways. On the one hand the users can be provided with this goal but still have to monitor the position of their knee themselves. On the other hand, if the users should get specific feedback so that they do not have to monitor the angle themselves, it is necessary to measure the performance of the users leg. How much the user is embedded in the wrapping story and for that is motivated by simplification depends on the implementation. To this end it is important to discuss for each context what level of personalization and simplification is actually needed.

Fig. 3.
figure 3

Elements for continuous monitoring and teams in Let’s Farm [19]

Fig. 4.
figure 4

Elements for continuous monitoring in Sana [17]

6.2 Elements for Continuous Monitoring

Gamification elements for continuous monitoring often need to record data for longer periods. Points based on a reward system like in Let’s Farm (see Fig. 3b) and level persist, though the raw data needed to earn a level or a specific amount of points does not have to be stored permanently when aggregation is applied and data storage is limited. Let’s Farm rewards the users after an exercise with coins per execution. After each exercise the earned coins can be aggregated and added to coins a user already earned so far such that only the sum of coins and the actual level needs to be stored.

However, the direct conversion from one execution of an activity to a specific amount of coins might lead to the issue of deriving additional information, like how many activities were executed. To avoid this issue differing amounts of points per specific activity can be chosen or the data can be perturbed by adding random points. Nevertheless these principles depend on the attacker model and which information is available to the attacker. Even if aggregation is always recommendable an attacker who can observe the changes could reveal which kind of activities a user did or reduce the possibilities if different amount of points per activity were chosen.

A progress bar is another typical element for visualizing progress. As mentioned in Sect. 5 most of the applications use the progress bar as additional visual element and use data already needed by other elements like for example points. As of that aggregation and storage limitation shall be applied in this case as well. Two data points are needed for each progress bar, the current status and the intended goal (see Fig. 4a). Recorded data can be aggregated to one current progress point. After reaching the goal, all information about the progress and the specific goal can be deleted and at most the information about the completed goal needs to be saved.

In a performance graph the data is time-related and aggregation is limited. These graphs provide information about the users performance compared to their preceding performance over a fixed period. The users focus on improvements by evaluating their own performance over time [25]. The recorded data can still be minimized by recording and saving only relations between data points and not time-stamps. In Sana for example the users can check their accuracy over the days using the application without any precise dates (see Fig. 4b).

Fig. 5.
figure 5

Elements for specific goals in Fitrust [29]

6.3 Elements for Specific Goals

A relatively comprehensive set of data is needed in case of defining specific goals. The more goals are provided and the more complex and diverse these goals are, the more corresponding specific progress data is needed and has to be captured. To render it more difficult to combine or correlate this data it might be useful to separate it by isolating the data in different databases. In Fitrust for example all data needed for badges concerning the exercise mode could be stored in a different database than data referring to the monitoring of intake (see Fig. 5).

A badge consists of its visualisation, the achievement and the condition for fulfillment (see as example Fig. 5b). The condition defines which data and what amount of data is needed. The achievement of a badge can be recorded via a single data point. After completing the condition of a specific badge, the related data is not necessary anymore and can be deleted. Only the information about the achieved badges has to be stored.

Fig. 6.
figure 6

Complementary element (Leaderboard) in Fitrust [29]

6.4 Leaderboard as Complementary Element

The main issue concerning a complementary element like a leaderboard, that shares information with other users, is the possibility of deducing additional information. In Fitrust the leaderboard shows to other users generally the picture and the name of the avatar and the earned points of a user. By clicking on a specific user the chosen titles as well as all earned badges of this user are revealed. In Fig. 6 for an explanatory example, the leading place in the leaderboard is actually a user with an avatar name “Johnny Gh”. Furthermore this user has earned all badges regarding the leaderboard as well as two badges for using the exercise mode. As title the user has chosen “Enthusiast and Runner”. With this information it can be assumed that this user is male and actively involved in sports, mainly in running activities. He is not monitoring his intake since he has not got any badges regarding the option of recording intake (see Fig. 5, 6). Since the badges suggest that he is using the application only for doing workout but still got a lot of points, this user is doing a lot of workout and is probably using Fitrust for a longer period than most of the others.

Because of this issue of deduced information, it is important to inform users about potential risks and to be careful with the decision to connect multiple users and elements. An important factor is that the more elements are visible to other users the more information about a specific user can be deduced. Furthermore it should be possible to hide personal data by for example restricting the access to this information.

7 Conclusion

The investigation of privacy risks of gamification elements in mHealth applications is often not considered. Especially in an healthcare context motivational aspects are important but should be integrated in a privacy aware manner. Privacy risks should be taken into account for developing a gamification strategy in the context of a privacy by design process. Gamification elements could be clustered according to their focus. As central goals data minimization, unlinkability and decentralization should be considered as central principles.