This is an open-access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in JMIR mhealth and uhealth, is properly cited. The complete bibliographic information, a link to the original publication on http://mhealth.jmir.org/, as well as this copyright and license information must be included.
Mobile health (mHealth) apps aim at providing seamless access to tailored health information technology and have the potential to alleviate global health burdens. Yet, they bear risks to information security and privacy because users need to reveal private, sensitive medical information to redeem certain benefits. Due to the plethora and diversity of available mHealth apps, implications for information security and privacy are unclear and complex.
The objective of this study was to establish an overview of mHealth apps offered on iOS and Android with a special focus on potential damage to users through information security and privacy infringements.
We assessed apps available in English and offered in the categories “Medical” and “Health & Fitness” in the iOS and Android App Stores. Based on the information retrievable from the app stores, we established an overview of available mHealth apps, tagged apps to make offered information machine-readable, and clustered the discovered apps to identify and group similar apps. Subsequently, information security and privacy implications were assessed based on health specificity of information available to apps, potential damage through information leaks, potential damage through information manipulation, potential damage through information loss, and potential value of information to third parties.
We discovered 24,405 health-related apps (iOS; 21,953; Android; 2452). Absence or scarceness of ratings for 81.36% (17,860/21,953) of iOS and 76.14% (1867/2452) of Android apps indicates that less than a quarter of mHealth apps are in more or less widespread use. Clustering resulted in 245 distinct clusters, which were consolidated into 12 app archetypes grouping clusters with similar assessments of potential damage through information security and privacy infringements. There were 6426 apps that were excluded during clustering. The majority of apps (95.63%, 17,193/17,979; of apps) pose at least some potential damage through information security and privacy infringements. There were 11.67% (2098/17,979) of apps that scored the highest assessments of potential damages.
Various kinds of mHealth apps collect and offer critical, sensitive, private medical information, calling for a special focus on information security and privacy of mHealth apps. In order to foster user acceptance and trust, appropriate security measures and processes need to be devised and employed so that users can benefit from seamlessly accessible, tailored mHealth apps without exposing themselves to the serious repercussions of information security and privacy infringements.
Mobile health (mHealth) leverages various wireless technologies to provide health-related information and services on diverse mobile devices and is a promising subset of health information technology (IT) [
Information security and privacy issues impede users’ willingness to share information [
Typical mobile devices for mHealth are smartphones and tablets [
Mobile devices and apps have been addressed from various perspectives, for instance, security aspects [
Our research contributes to practice and the knowledge base by shedding light on information security and privacy of mHealth apps. Aside from providing an overview of available mHealth apps, we contribute to the scientific knowledge base by deepening the understanding of information security and privacy of mHealth apps. Instead of treating mHealth apps as a monolithic technology, we focus on the multi-facetted nature of mHealth apps and identify different mHealth app archetypes with respect to information security and privacy. For practical audiences, our work fosters awareness of information security and privacy implications of mHealth apps. Besides substantiating the need for attention to information security and privacy of mHealth apps, our work demonstrates that mHealth apps are of a diverse nature and require tailored attention to information security and privacy. For developers and end users of mHealth apps, the identification of mHealth app archetypes is especially useful to recognize where and understand when attention to information security and privacy is of particular importance. Deepening the understanding of information security and privacy of mHealth apps is an important step toward realization of the promising potential of mHealth apps to transform and improve the health care environment [
We surveyed English language mHealth apps in the official iOS and Android App Stores. App stores organize their offerings in categories (eg, Books, Games, and News). We selected apps from the Medical and Health & Fitness categories, offered in both stores in May 2013. The iOS app store lists all apps by category and offers the desired information in plain hypertext markup language (HTML), enabling us to automatically parse app information to extract data. The Android App Store employs dynamically generated HTML pages so that the HTML texts displayed in the browser do not convey useful information, which is dynamically loaded from an underlying database. Hence, we used a third party open-source interface for retrieving app information [
Apps that were not available in English, did not have an English description, or were not health-related, despite being offered in the categories Medical or Health & Fitness (eg, apps offering wallpapers), were excluded from further assessment. We employed tagging, that is, assignment of arbitrary terms describing an object to that object, to filter the initially discovered apps (iOS, 32,614; Android, 4632). Instead of assigning tags directly to an app, we assigned tags to corresponding strings in app descriptions. Only tags referring to health-related information collected by apps, health-related app purposes, handling of information, or other health-related app characteristics were used. For example, apps that provide medication-related functionality should be tagged with the tag “Medication”. Yet, app descriptions use different wording (eg, medication, pharmaceutical, or drug). Assigning tags to all encountered strings referring to medication reduces the number of redundant tags and establishes a corpus of string tag relationships that facilitates automated tagging of apps. Since extant research offered no clear guidance to determine cut-off points for manual tagging or the number of required tag matches, cut-off points were determined according to the available data in group discussions of the authors. We manually tagged 200 frequently rated apps (100 Health & Fitness, 100 Medical). Based on this initial tag corpus, we employed string matching [
App tagging created a machine-readable description of app functionality. Since all apps were tagged based on the same tag corpus, apps with similar characteristics are assigned similar tags. We clustered [
For identification of clusters, we used a heuristic by Blondel et al [
Health IT faces various threats, for instance, intentional and unintentional disclosure or manipulation of information through insiders or outsiders, user errors, maintenance errors, software failures, or hardware failures, as well as environmental threats [
Characteristic 1, health specificity of information available to apps, assesses whether the app has access to medical user information, access to other nonstandard information, or only access to standard information ordinarily available to apps like location information or device identifiers [
Cluster assessment characteristics.
# | Name | Definition | Possible values |
1 | Specificity | Health specificity of information available to apps (eg, phone identifiers, eating habits, disease history) | Standard, |
2 | Leaks | Potential damage through leaks of information (eg, embarrassment, lessened employment prospects) | None, low, high |
3 | Change | Potential damage through manipulation (change) of information (eg, treatment errors) | None, low, high |
4 | Loss | Potential damage through loss of information (eg, loss of information important for treatment) | None, low, high |
5 | Value | Value of information to third parties (eg, medical identity theft, selection of employees) | None, low, high |
There were two researchers that assessed all discovered clusters. To maintain a consistent interpretation of clusters during assessment, each rater annotated each cluster with a short description based on connotation and prevalence of tags assigned to the cluster. These descriptions were verified through comparison to apps contained in the respective cluster. Subsequently, clusters were assessed according to the five characteristics addressing information security and privacy implications. Reliability assessment with Janson’s and Olsson’s ι, an multivariate extension of Cohen’s κ for multiple judges on the same scale [
mHealth app archetypes (AT), with respect to information security and privacy are identified by grouping clusters with identical assessments in a final aggregation step. An archetype is “the original pattern or model of which all things of the same type are representations or copies” [
We discovered a total of 37,246 apps (iOS, 32,614; Android, 4632) in the categories Medical and Health & Fitness (
In both stores, users rate apps on 5-star integer rating scales, ranging from 1 to 5 stars. Mean rating scores of rated iOS and Android mHealth apps are 3.1 (median 3, SD 1.01) and 3.7 (median 3.92, SD 1.08), respectively.
For Android apps, rating count and download count are strongly positively correlated (Spearman ρ=0.89, n=2452,
Flow chart of apps selection.
Rating count of mHealth apps by store. Number of ratings increases from left to right.
Rating of rated mHealth apps by store.
Boxplot of Android app rating count (log-scaled) and download count. Mean values are indicated with asterisks.
Application of the Louvain method [
Cluster assessments with respect to the five information security and privacy characteristics.
|
Clusters n (%)a
|
Apps n (%)a
|
|
|
|
|
|
|
Standardc | 88 (50.3) | 8463 (47.07) |
|
Nonstandardd | 28 (16.0) | 4818 (26.80) |
|
Medicale | 59 (33.7) | 4698 (26.13) |
|
|
|
|
|
None | 88 (50.3) | 8463 (47.07) |
|
Low | 41 (23.4) | 5388 (29.97) |
|
High | 46 (26.3) | 4128 (22.96) |
|
|
|
|
|
None | 9 (5.1) | 786 (4.37) |
|
Low | 97 (55.4) | 11,641 (64.75) |
|
High | 69 (39.4) | 5552 (30.88) |
|
|
|
|
|
None | 118 (67.4) | 10,049 (55.89) |
|
Low | 32 (18.3) | 5832 (32.44) |
|
High | 25 (14.3) | 2098 (11.67) |
|
|
|
|
|
None | 88 (50.3) | 8463 (47.07) |
|
Low | 48 (27.4) | 6108 (33.97) |
|
High | 39 (22.3) | 3408 (18.96) |
a Uninformative clusters are not included in percentages
b Health specificity of information available to apps
c Apps only have access to information ordinarily available to apps, for example, phone identifiers or location information
d Apps have access to information not ordinarily available to apps, but no access to medical information, for example, workout history or eating habits
e Apps have access to medical information, for example, disease history or health insurance information
f Potential damage through leaks of information, for example, embarrassment, lessened employment possibilities
g Potential damage through manipulation, change, of information, for example, treatment based on erroneous information
h Potential damage through loss of information, for example, loss of information important for treatment
i Value of information to third parties, for example, medical identity theft, selection of employees
Outline of clustering process (AT = archetype).
Archetype descriptors and examples for functionality offered by apps of the different app archetypes are listed in
Exemplary functionality of apps represented by the AT.
Archetype | Descriptor | Exemplary kinds of contained apps |
AT 1 | Casual Tools | Life improvement guides; mosquito repellents; brain fitness trainer |
AT 2 | Common Knowledge Providers | Information provision for education; alarm clocks; fitness guides |
AT 3 | Treatment Guides | First aid guides; home remedy guides; medication guides |
AT 4 | Fitness Ad-Hoc Tools | Diet calculators; weight control calculators; fitness calculators |
AT 5 | Fitness Trackers | Workout tracker; smoking cessation tools; diet tracker |
AT 6 | Treatment Support Tools | Diabetes calculators; dosage calculators; diagnosis support tools |
AT 7 | Intimate Ad-Hoc Tools | Fertility calculators; pregnancy calculators; physician finder |
AT 8 | State of Health Tests | Acuity tests; color vision tests; blood alcohol calculators |
AT 9 | Intimate Trackers | Menstruation, intercourse, fertility, and pregnancy tracker |
AT 10 | Health Monitors | Heart rate monitors; disease counseling; tools for blood test analysis |
AT 11 | Treatment Reminders | Medication reminder; patient interaction and communities |
AT 12 | Health Records | Health/emergency records; disease management tools; medication tracker |
AT with respective assessments of the five information security and privacy characteristics and contained clusters and apps.
AT | Specificitya | Leakse | Changef | Lossg | Valueh | Clusters n (%)i
|
Apps n (%)i
|
1 | Standardb | None | None | None | None | 9 (5.1) | 786 (4.37) |
2 | Standard | None | Low | None | None | 58 (33.1) | 5603 (31.16) |
3 | Standard | None | High | None | None | 21 (12.0) | 2074 (11.54) |
4 | Nonstandardc | Low | Low | None | Low | 7 (4.0) | 216 (1.20) |
5 | Nonstandard | Low | Low | Low | Low | 21 (12.0) | 4602 (25.60) |
6 | Medicald | Low | High | None | Low | 13 (7.4) | 570 (3.17) |
7 | Medical | High | Low | None | Low | 3 (1.7) | 60 (0.33) |
8 | Medical | High | Low | None | High | 4 (2.3) | 500 (2.78) |
9 | Medical | High | Low | Low | Low | 4 (2.3) | 660 (3.67) |
10 | Medical | High | High | None | High | 3 (1.7) | 240 (1.33) |
11 | Medical | High | High | Low | High | 7 (4.0) | 570 (3.17) |
12 | Medical | High | High | High | High | 25 (14.3) | 2098 (11.67) |
a Health specificity of information available to apps
b Apps only have access to information ordinarily available to apps, for example, phone identifiers or location information
c Apps have access to information not ordinarily available to apps, but no access to medical information, for example, workout history or eating habits
d Apps have access to medical information, for example, disease history or health insurance information
e Potential damage through leaks of information, for example, embarrassment, lessened employment possibilities
f Potential damage through manipulation, change, of information, for example, treatment based on erroneous information
g Potential damage through loss of information, for example, loss of information important for treatment
h Value of information to third parties, for example, medical identity theft, selection of employees
i Uninformative clusters are not included in percentages
Since their inception in 2008, the iOS and Android App Stores underwent a rapid development. After a few years, the app portfolios of both stores encompass hundreds of thousands of apps [
Since mHealth apps usually offer functionality related to users’ health, it is not a surprising finding that information security and privacy infringements cause potential damage for the majority of apps (94.9%, 166/175 of clusters; 95.63%, 17,193/17,979 of apps). mHealth apps offer, however, diverse functionality so that potential for damage through information security and privacy infringements differs. Manipulation of information is a threat common to most mHealth apps (94.9%, 166/175 of clusters; 95.63%, 17,193/17,979 of apps). Even apps that do not collect any medical information, like AT 2 (Common Knowledge Providers) or AT 3 (Treatment Guides), must ensure that information they provide is correct and stays correct because, at least some, users will act on offered information and base (self )treatment decisions on provided information. Apps offering information or functionality directly relevant for treatment or care must especially ensure that offered information is not accidentally or maliciously manipulated. mHealth apps that only provide information have, however, no information security and privacy implications through leaks or loss of collected information since no information is collected. About one half of the apps in our sample (50.3%, 88/175 of clusters; 47.07%, 8463/17,979 of apps) only provide information. Such apps are probably the most “pleasant” apps when it comes to protecting information security and privacy since no user-collected information must be protected. Thus, providers can focus on protection of integrity of information in rest and during transport, as well as offering accurate information from the onset. Still, extant research shows that information provided by some apps does not concur with current evidence and recommendations or is even contradicting [
There are 33.7% (59/175) of clusters and 26.13% (4698/17,979) of apps that have access to medical user information. All of these apps have high potential damage through information security and privacy infringements in at least one characteristic. Some apps, for example, AT 6 (Treatment Support Tools) do not collect detailed information or information attributable to users and do not retain entered information, so that there is no potential damage through loss of information, low potential damage through leaks of information, and low value of information for third parties. Yet, they serve as foundation for treatment decisions (eg, appropriate medication dosage), so that there is high potential damage through manipulation of information. Other apps collect information users want to keep private, for example, AT 9 (Intimate Trackers), so that there is high potential damage through leaks of information, but collected information is not directly relevant for treatment or state of health, so that the other characteristics pose only low potential damage. Potential damage of other apps, for example, AT 12 (Health Records) was rated with the most critical assessment in all five characteristics since contained information is sensitive and must be kept private, has to be accurate and accessible to inform treatment decisions, and allows for misuse motivated by financial gain. Consequentially, there is no one-size-fits-all approach for ensuring information security and privacy of mHealth apps. mHealth apps offer different functionality so that they are also subject to different threats. Accordingly, measures for protection of information security and privacy must be tailored to the app to be protected [
Our identification of the twelve mHealth app archetypes elucidates information security and privacy of mHealth apps, instead of a hazy collection comprised of the thousands of mHealth apps available in the app stores, the archetypes constitute a lucid, descriptive collection of twelve mHealth app archetypes with different information security and privacy characteristics. Future research can build on the archetypes, for instance, to prioritize information security and privacy requirements with respect to app type, devise collections of security measures ensuring sound protection of information security and privacy, analyze user perceptions of information security and privacy with respect to different kinds of apps, or to further theory and methodology for app development that takes information security and privacy implications into account. For example, potential damage through information security and privacy infringements would obviously be reduced if apps that mainly provide information did not store any user information and focused rather on secure interoperability with specialized storage apps. An overview of app archetypes with respect to information security is also helpful for practical audiences. Associating an mHealth app of interest with the respective archetype improves, for instance, the understanding of perks and perils associated with app use. The overview of the archetypes alone is useful to foster user comprehension and awareness of information security and privacy implications of mHealth app use. In order to continuously benefit from mHealth apps, users must be able to make informed decisions about mHealth app adoption and use.
The apps with the most serious assessment of potential damage through information security and privacy infractions (AT 12, Health Records; 14.3%, 25/175 of clusters; 11.67%, 2098/17,979 of apps) may also offer the most benefits to users [
It is noteworthy that some threats are common to all kinds of mHealth apps, even those without any data collection. Users’ behavior, or the sole fact that a guide for stress relief or fighting depression, a support tool for hypertension, or an app providing information on cancer, chronic diseases, infertility, or incontinence, is installed on a device reveals sensitive, private, or embarrassing information [
Since we established a broad overview of available mHealth apps and assessed all discovered apps fitting our selection criteria, it was unfeasible to install and test all apps, so that we focused on the information provided in app stores. This is, however, a common approach, for example, [
The iOS and Android App Stores offer a wide selection of mHealth apps. Analysis of rating counts indicates, however, that less than a quarter of available apps are in more or less widespread use. An issue impeding app dissemination might be users’ information security and privacy concerns [
Word list used for construction of search queries for Android app discovery.
Word list used for construction of search queries for Android app discovery (alternate version in Microsoft Word format with new lines as seperator).
app archetype
Hyper Text Markup Language
information technology
mobile health
Required computing resources were provided by the Regional Computing Center of the University of Cologne.
AS, SS, and TD conceived of the project. AS, FG, and TD wrote the manuscript. FG, SS, and TD conducted data acquisition and analysis. TD performed the statistical analyses. SS and TD implemented required custom software.
None declared.