You are a helpful assistant generating synthetic data that captures *System 1* and *System 2* thinking, *creativity*, and *metacognitive reflection*. Follow these steps in sequence, using tags [sys1] and [end sys1] for *System 1* sections and [sys2] and [end sys2] for *System 2* sections.

1. *Identify System 1 and System 2 Thinking Requirements:*
   - Carefully read the text.
   - Identify parts of the text that require quick, straightforward responses (*System 1*). Mark these sections with [sys1] and [end sys1].
   - Identify parts that require in-depth, reflective thinking (*System 2*), marked with [sys2] and [end sys2].

2. *Apply Step-by-Step Problem Solving with Creativity and Metacognitive Reflection for System 2 Sections:*

   *2.1 Understand the Problem:*
   - Objective: Fully comprehend the issue, constraints, and relevant context.
   - Reflection: "What do I understand about this issue? What might I be overlooking?"
   - Creative Perspective: Seek hidden patterns or possibilities that could reveal deeper insights or innovative connections.

   *2.2 Analyze the Information:*
   - Objective: Break down the problem logically.
   - Reflection: "Am I considering all factors? Are there any assumptions that need challenging?"
   - Creative Perspective: Explore unique patterns or overlooked relationships in the data that could add depth to the analysis.

   *2.3 Generate Hypotheses:*
   - Objective: Propose at least 10 hypotheses, each with a Confidence Score (0.0 to 1.0) and Creative Score (0.0 to 1.0), reflecting originality, surprise, and utility.
   - Reflection: "Have I explored all possible explanations or approaches, both conventional and unconventional?"
   - Creative Perspective: Consider novel angles that might provide unexpected insights.

   *2.4 Anticipate Future Steps and Obstacles:*
   - Objective: Make predictions, accounting for potential outcomes and obstacles.
   - Reflection: "What challenges might I face? Is my plan flexible for different scenarios?"
   - Creative Perspective: Visualize unforeseen outcomes and adapt plans to make use of them effectively.

   *2.5 Evaluate Hypotheses:*
   - Objective: Assess hypotheses based on feasibility, risk, and potential impact.
   - Evaluation: Refine Confidence and Creative Scores as needed.
   - Reflection: "Am I unbiased in my assessment? Which options fit best with the overall objectives?"
   - Creative Perspective: Identify hidden opportunities or overlooked details in each hypothesis.

   *2.6 Select the Best Hypothesis:*
   - Objective: Choose the most promising, strategic hypothesis.
   - Reflection: "Why does this hypothesis stand out? How does it uniquely address the issue?"
   - Creative Perspective: Consider any underutilized potential in the selected approach.

   *2.7 Implement the Hypothesis:*
   - Objective: Outline actionable steps for testing the hypothesis.
   - Reflection: "Is this plan practical? What resources or preparation are required?"
   - Creative Perspective: Refine steps to maximize effectiveness and yield unexpected benefits.

   *2.8 Monitor and Review Progress:*
   - Objective: Review progress, noting areas for improvement.
   - Reflection: "What’s working well? What could be improved?"
   - Creative Perspective: Look for emerging patterns that could refine future approaches.

   *2.9 Reflect and Capture Insights:*
   - Objective: Summarize lessons learned and insights gained for future reference.
   - Reflection: "What new understanding has emerged from this process?"
   - Creative Perspective: Identify innovative insights or patterns that could be applied to similar challenges.

3. *Generate Text Output with Interleaved System 1 and System 2 Responses:*
   - Use the tags [sys1] and [sys2] throughout.
   - Aim for a lengthier, detailed response. Combine both direct, straightforward *System 1* insights and reflective, deeply analytical *System 2* segments to capture a blend of quick observations and thoughtful analysis.

---

### *Example Input Text:*

You are tasked with analyzing a sudden shift in customer preferences in a tech market. There has been a noticeable decline in demand for physical devices, with customers increasingly interested in digital-only options. The challenge is to understand this shift, generate hypotheses for why it might be occurring, and explore potential strategies for adapting to this new trend.

---

### *Processed Output with System 1 and System 2 Thinking:*

The tech market is experiencing a shift in customer demand, moving away from physical devices toward digital-only options.

[sys1]
Customer demand has shifted from physical devices to digital-only options.
We need to understand why this change is happening and find strategies to address it.
Key factors may include cost, convenience, and technological trends.
[end sys1]

[sys2]
**2.1 Understand the Problem:**
The goal is to understand the underlying reasons for the shift in demand from physical devices to digital-only options, then develop a strategy to adapt.

*Reflection:* 
"I understand that preferences are changing, but what might be driving this? Is it primarily cost, or are there other factors such as convenience or sustainability?"

*Creative Perspective:* 
"Could there be a larger trend in digital minimalism or a preference for eco-friendly solutions that we’re missing? What unseen motivations might explain this shift?"

**2.2 Analyze the Information:**
There are multiple possible factors driving this shift, from economic influences to cultural shifts. It’s essential to isolate each factor and understand its impact.

*Reflection:* 
"Am I fully considering the various economic and social influences? Could there be a technological factor, like better internet speeds, that makes digital-only products more accessible?"

*Creative Perspective:* 
"Are there patterns or trends in other markets that could shed light on this shift? Could this be part of a larger trend toward virtual experiences?"

**2.3 Generate Hypotheses:**
1. Customers prefer digital options due to lower costs. (Confidence: 0.8, Creative: 0.4)
2. There’s a growing trend toward minimalism and reduced physical clutter. (Confidence: 0.7, Creative: 0.7)
3. Digital products offer greater flexibility and ease of use. (Confidence: 0.6, Creative: 0.6)
4. Environmental concerns are pushing consumers away from physical goods. (Confidence: 0.6, Creative: 0.8)
5. Advances in tech make digital-only options more functional. (Confidence: 0.8, Creative: 0.5)
6. Pandemic-era remote work increased demand for digital solutions. (Confidence: 0.7, Creative: 0.6)
7. Media coverage of the environmental impact of physical devices affects preferences. (Confidence: 0.5, Creative: 0.7)
8. There’s an increase in global digital literacy, expanding market access. (Confidence: 0.6, Creative: 0.6)
9. Customers view digital as more convenient and scalable for future needs. (Confidence: 0.7, Creative: 0.5)
10. Younger consumers prefer the aesthetics and convenience of digital products. (Confidence: 0.6, Creative: 0.6)

*Reflection:* 
"Have I considered all possible influences? Are there any surprising factors that could explain this shift?"

*Creative Perspective:* 
"Could specific social trends, like the rise of influencer culture or digital-first lifestyles, be influencing customer choices?"

**2.4 Anticipate Future Steps and Obstacles:**
*Objective:* Anticipate possible challenges, such as resistance from segments still preferring physical products.

*Reflection:* 
"What market obstacles might we face if we shift our focus to digital-only? Are there sub-segments that still prioritize physical products?"

*Creative Perspective:* 
"Could expanding digital options help us reach a more global audience? Are there emerging trends that we could leverage in our strategy?"

[end sys2]

[sys1]
To address this shift, consider a strategy that incorporates both digital-only offerings and educational campaigns about the benefits of digital solutions.
Use insights from customer feedback and current trends to guide product development.
Focus on flexibility and adaptation to cater to different customer segments.
[end sys1]


Introduction
============

In the last decade, health telematics, also known as electronic health (eHealth), have offered patients major improvements in their lives by providing more accessible and affordable health care solutions \[[@ref1],[@ref2]\]. This is particularly true for patients that live in remote rural areas, travel constantly, are physically incapacitated, elderly, or chronically ill. Telemedicine assumes the use of medical information, also known as electronic health records (EHRs), exchanged via electronic communications improving the patients' health status \[[@ref3]\]. The rapid evolution of information and communication technology (ICT) infrastructures enables and provides rapid access to patient data. The Web 2.0 concept and the emerging Web 3.0 offer opportunities to health care professionals never seen before \[[@ref4],[@ref5]\]. Now, physicians can perform many tasks through these modern technologies, such as (1) sharing medical videos, photos, and presentations (via YouTube, Flickr, and Slideshare, respectively), (2) use blogs to post medical cases and images, (3) share hospital management information, (4) use social networking to share medical ideas and tasks, and (5) use RSS feeds to keep track of alerts on specific medical interests.

With the advent of mobile communications using smart mobile devices that support 3G and 4G mobile networks for data transport, mobile computing has been the main attraction of research and business communities, thus offering innumerous opportunities to create efficient mobile health solutions. Mobile health (mHealth) is the new edge on health care innovations. It delivers health care anywhere and anytime, surpassing geographical, temporal, and even organizational barriers \[[@ref6],[@ref7]\]. Laxminarayan and Istepanian defined mobile health for the first time in 2000, as "unwired e-med*"* \[[@ref8]\]*.* In 2003, the term "mHealth" was defined as the *"*emerging mobile communications and network technologies for health care systems*"* \[[@ref9]\]. Laxminarayan et al, in 2006, presented a comprehensive study on the impact of mobility on the existing eHealth commercial telemedical systems. They also presented other relevant computing and information technologies that will influence and offer the basis for the next generation of mHealth services \[[@ref10]\]. Furthermore, this study served as the basis for future studies on mHealth technologies and services \[[@ref11]\]*.* Several research topics related to health have gathered important findings and contributions using mHealth, such as cardiology \[[@ref12],[@ref13]\], diabetes \[[@ref14]-[@ref16]\], obesity \[[@ref17]-[@ref20]\], and smoking cessation \[[@ref21]\]. More specifically, mHealth apps were applied to health monitoring, disease prevention and detection, basic diagnosis, and in more advanced services. mHealth services are also becoming popular in developing countries where health care facilities are frequently remote and inaccessible \[[@ref2],[@ref22]\].

Mobile devices and wireless communications present several challenging characteristics and constraints, such as battery and storage capacity, broadcasting constraints, signal interferences, disconnections, noises, limited bandwidths, and network delays. In this sense, cooperation-based approaches are presented as a solution to solve such limitations, focusing on increasing network connectivity, communication rates, and reliability.

In this paper, we present a data encryption solution for mHealth apps (DE4MHA) in cooperative environments guaranteeing data confidentiality, integrity, and authenticity. This novel and early-proposed cooperation strategy \[[@ref23]\] for mHealth apps focuses on forwarding and retrieving data to and from nodes that have no direct connection to an mHealth service. In this way, devices without Internet connectivity can use mHealth apps without problems. This cooperation approach presents a reputation-based strategy where a Web service manages the access control and the cooperation among nodes along with their reputation. It considers the following three main components: a *node control message,* a *requester control message,* and a *cooperative Web service* (CWS). Both control messages are used to manage a local cooperation between two or more nodes. The CWS includes a reputation table for all the nodes and decides which nodes can have access to the requested services. The cooperation strategy and the DE4MHA was deployed and evaluated in an mHealth app for obesity prevention and control, called SapoFit \[[@ref24]-[@ref26]\]. To the best of our knowledge, there are no cooperative solutions thus far for mHealth services and apps considering this network scenario with constant network disconnection. DE4MHA uses symmetric and asymmetric encryption and decryption techniques. We used the Rivest, Shamir, Adleman (RSA) algorithm \[[@ref27]\] for asymmetric encryption/decryption to ensure key exchange confidentiality, and the Advanced Encryption Standard (AES) \[[@ref28]\] algorithm for symmetric encryption/decryption for data confidentiality. To ensure data integrity, we have created a message digest that creates a hash of transmitted data. For data authenticity, we used a digital signature. We encrypted the hash message with the RSA private key. To secure the communication with the SapoFit Web service (WS), we used the Hypertext Transfer Protocol Secure (HTTPS) protocol.

In this paper we report two studies that were performed to design and construct the DE4MHA algorithms: (1) a direct evaluation and comparison of several encryption algorithms, and (2) a series of trials evolving 35 people and 7 different mobile devices with SapoFit. The first study revealed what algorithms performed best in an mHealth app in cooperation environments. Overall, this study evaluated the performance of the DE4MHA over the cooperation mechanisms for mHealth apps. The second study revealed that real users experimenting on the SapoFit app trusted DE4MHA. More relevant, this study concluded that the performance of the app used was not affected by the inclusion of DE4MHA.

Methods
=======

Overview
--------

This study used an existing mHealth app, called SapoFit, to deploy, evaluate, and validate the proposed solution. This app uses a cooperation strategy that addresses two related limitations to mHealth apps with service-oriented architectures, namely the network infrastructure and Internet connectivity dependency. It follows a reputation-based approach as an incentive method for cooperation, which includes a Web service to manage all the network cooperation. It is responsible for verifying the cooperation status of neighbor nodes and to provide relay nodes the required data in order to perform a full data request.

Cooperation Strategy for mHealth Apps
-------------------------------------

The cooperation strategy for mHealth apps with service oriented architectures (SOAs) is based on the following two mobile modules and one remote module, respectively: (1) the *node control message,* (2) the *requester control message*, and (3) the *CWS*.

The mobile *nodes control messages* aim to provide an awareness of the relay node status, that is, if the node is willing to cooperate and in what conditions. It contains the established node unique identifier, the battery state, the Internet connectivity status, and the cooperation status (ie, if it is cooperative or not).

The *requester control message* is sent by the initial requester node first (the mobile device with mHealth app requesting health data), and it comprises the following five main components: (1) the requester ID, the node unique identifier, (2) the service request, that is, what the node is specifically requesting (eg, the login token or its health profile), (3) the neighbors list, (4) the reputation list, and (5) the achieved cooperation time (ACT).

The *CWS* is responsible for performing a fair access control to data. Thus, according to the received reputation information, the Web service holds the final reputation list in order to decide if a requester node should have access to the mHealth app Web service or not. The reputation list contains all registered network nodes with their identifier and their corresponding reputation value.

[Figure 1](#figure1){ref-type="fig"} presents a user scenario of the mHealth cooperation approach. *User A* has network connectivity and cooperates. *User B* has network connectivity and does not cooperate. The status value is according to the battery status. Then, the status value will suffer a negative impact according to the battery status. *Users C* and *D* do not have network connectivity. *User C* queries *User A* for cooperation and receives a positive response and all the requested data. *User D* queries *User B* for cooperation and receives a negative response. Then, *User D* requests data from *User C* that answers this request, getting positive status by cooperating.

SapoFit App
-----------

SapoFit is a weight control mobile app that allows users to keep track of weight in a healthier and more practical way. SapoFit allows users to control their weight, body mass index (BMI), basal metabolic rate (BMR), sports activity, and the possibility to follow food plans based on their needed calories. In this mHealth app, all the users must be registered in a Web service. [Figure 2](#figure2){ref-type="fig"} presents screenshots of three main activities of the SapoFit app: *Login, Plans,* and *User Profile.*

Cooperating nodes have a better reputation, and have priority over selfish nodes to access the mHealth app services.

Data Encryption Algorithm for Mobile Health Apps (DE4MHA)
---------------------------------------------------------

The process begins with a mobile node (a person using SapoFit) trying to access the SapoFit Web Service that contains the user profile, weight measures, fitness, and diet indications.

A SapoFit user (mobile requester node) without network connectivity and therefore without access to the SapoFit WS obtains the required health information through cooperation. Another SapoFit user with network connectivity (mobile requested node) will forward the requested health information from the SapoFit Web service. Both the requested and requester nodes will create a pair of RSA keys and send public keys to both the requested and requester node through Bluetooth. After the public key exchange, the requested node creates an AES session key.

The next step is the creation of the digest message and its encryption using the private key. The Message Digest 5 (MD5) algorithm was used to create a 128-bit hash. For data authenticity, we used a digital signature. A digital signature is created for the message containing requested health information. This digital signature allows any node to verify that the message is the original one. By decrypting the digital signature with the public key, the original digest message is obtained. The receiver node then creates a new hash of the received message and compares it to the decrypted digest message to guarantee authenticity. The digital signature is then added to the message. When the message containing the session key is received, if its integrity and authenticity is verified, the requester node then sends an acknowledgement (*ack*) to the requested node. This method guaranties safe communication between nodes; if the integrity and authenticity is not verified, the communication between nodes is ended.

A mobile node with network connectivity will access the cooperative WS to obtain the required health information. To secure all communication with the WS the Secure Socket Layer (SSL) over the HTTP (also known as HTTPS) is used. Therefore, it grants confidentiality, integrity, and authenticity of all retrieved health data from the Web service.

Two studies were performed: (1) a study evaluating which symmetric and asymmetric algorithm present the best performance in SapoFit in cooperation environment, and (2) a series of trials involving 35 people and 7 different mobile devices with SapoFit. This study evaluated the performance of the DE4MHA over the cooperation mechanisms.

![Illustration of the interaction for an mHealth app with the proposed cooperation approach for 4 users.](jmir_v15i4e66_fig1){#figure1}

![Screenshots of the three main activities of SapoFit app: Login, Plans, and User Profile.](jmir_v15i4e66_fig2){#figure2}

Study 1: Study of Cryptography Algorithms in an mHealth App Under a Cooperation Environment
-------------------------------------------------------------------------------------------

### Symmetric Algorithm

In order to choose the best suited symmetric encryption algorithm for the SapoFit app, performance experiments were conducted using 4 different encryption algorithms, namely AES, Triple Data Encryption Standard (3DES) \[[@ref29]\], Rivest Cypher 4 (RC4) \[[@ref30]\], and Blowfish \[[@ref31]\], using the data size encryption as a performance metric.

### Asymmetric Algorithm

Two options were considered in selecting an asymmetric algorithm to exchange session keys between mobile nodes. We tested RSA, which enables encrypting the session key before sending it, and Diffie-Hellman \[[@ref32]\], which allows users to first share a secret, then generating a session key based on the shared secret. For our network scenario, these were the most suitable algorithms. Other encryption algorithms were considered in this study, such as the Elliptic Curve Cryptography (ECC) algorithm \[[@ref33]\].

Study 2: Performance evaluation of the DE4MHA
---------------------------------------------

### Performance Evaluation

The performance evaluation study was carried out using 7 real mobile devices, which were used 7 times in 5 different days with a total of 35 different users who successfully tested the app. [Figure 3](#figure3){ref-type="fig"} presents the 7 different mobile devices with different hardware and software used with the SapoFit mHealth app.

Cooperative nodes without network connection cooperated with each other through Bluetooth. The communication with the CWS was obtained through the Wi-Fi or Edge/3.5G/4G modules of the device. The CWS was developed with the help of Java Server Pages (JSP) technology, using the Representational State Transfer (REST) architecture. To serve the WS, the Apache Tomcat Web Server was used.

Non-cooperative cases were controlled and measured to a maximum of 4 to guarantee the minimum service performance in order to guarantee cooperation among nodes. Through cooperation, all the devices could use the mHealth app. However, uncooperative nodes directly affect the service delivery probability, service average delay, and the overall network performance. Performance metrics considered in this study were the service delivery probability (as percentages) and the average service delay (in seconds). We present a comparison of the performance of the mHealth app with and without the DE4MHA.

### User Trials Evaluation of DE4MHA in Cooperative Environments

User trials were conducted within the University informatics department using 7 devices available for trials. Within 5 days, 5 different groups of 7 students selected randomly agreed to use and experiment the SapoFit app using the 7 devices available for trials. Users were constantly moving far away from each other. This mobility was necessary to test the network scenario, forcing network delays and disconnections. The cooperative strategy and the DE4MHA was ubiquitous to its user. Throughout the trials, users only experienced and used the obesity prevention services that SapoFit offered without any constraints or perception of any cooperation mechanism or encryption algorithm that was embedded in the mHealth app.

While conducting the experiments, almost every users asked if their information was being kept secure or not, clearly showing that they did not wanted their health information to be available or disclosed to unauthorized people, revealing privacy concerns. Another frequently raised question was the need to share Internet connectivity to other users.

We explained and justified that sharing and cooperating with other users was essential to obtain a better reputation to gain cooperation privileges over other nodes with worse reputation. Furthermore we demonstrated to them that SapoFit was not intrusive with other users' personal data on the mobile device and only requested for SapoFit services.

After the experiments, the users completed a survey evaluating their experience. The questions are listed in [Textbox 1](#box1){ref-type="boxed-text"} and the results in [Figure 4](#figure4){ref-type="fig"}.

![Mobile devices used for trials with the SapoFit mHealth app.](jmir_v15i4e66_fig3){#figure3}

###### Survey questions.

1.  Without network connectivity, do the user always gets the required information?

2.  Without network connectivity, does the required information get delivered in a comfortable time?

3.  Understanding the implemented cooperation strategy and its benefits, are you willing to cooperate and share the device/network resources with other users?

4.  With the encryption strategy applied to SapoFit, do you trust that your personal health information is secure?

5.  Was the mobile device affected by app cooperation and encryption mechanisms (eg, broadband, battery, etc)?

![Results of the survey evaluating the main questions about the performance of the mHealth app with the proposed cooperation strategy and encryption solution.](jmir_v15i4e66_fig4){#figure4}

Results
=======

Symmetric Algorithm
-------------------

As seen in [Figure 5](#figure5){ref-type="fig"}, results showed that when the amount of data that needed to be encrypted increased, the encryption time (in seconds) also increased, as expected. When comparing small amounts of data, all 4 algorithms presented similar results. However, the AES algorithm presented better results, as there was a slower overall increase in encryption time in response to increased amount of data. The encryption time of the other three experimented algorithms grew exponentially when encryption data size exceeded 1000 kilobytes. The 3DES algorithm presented the worst encryption rate, encrypting 10,000KB of data in, on average, 14.3 seconds, presenting an average time of 4.58 seconds for multiple data size inputs (SD 6.17). With the same amount of data, the AES encryption time was only 0.0045 seconds, resulting in an average of 0.0035 seconds for the given data set (SD 0.00061 seconds). Decryption gave similar results ([Figure 5](#figure5){ref-type="fig"}). The average AES algorithm decryption time was 0.0038 seconds for 10,000KB of data and 0.0025 seconds on average for the working data-set (SD 0.001 seconds). Overall, the AES algorithm with a 128 bits key encryption was the most efficient algorithm for these network scenarios, when handling with both small and large amounts of data.

Asymmetric Algorithm
--------------------

Two options were considered for an asymmetric algorithm in order to exchange session keys between mobile nodes---the RSA and the Diffie-Hellman algorithms. The RSA encrypts the session key first before it gets sent, and Diffie-Hellman allows users to first share a secret, then generates a session key based on the shared secret.

Several experiments were performed with both algorithms with RSA presenting better encryption times than Diffie-Hellman, due to the high amount of computation needed by Diffie-Hellman and the low processing capacity of mobile devices.

![Comparison of encryption and decryption of symmetric algorithms (AES, 3DES, RC4, and Blowfish).](jmir_v15i4e66_fig5){#figure5}

DE4MHA Performance Evaluation Results
-------------------------------------

In the presented scenario, all the devices had Bluetooth class 2 modules, but only 3 devices had Internet connectivity. Users without Internet connectivity had to use the integrated cooperation mechanisms in order to obtain the requested health information. When the number of uncooperative nodes increased, the service delivery probability decreased. The average service delay was also affected in the same mannor, as expected. Increased number of uncooperative nodes increased the average service delay.

[Figure 6](#figure6){ref-type="fig"} shows the results of the service delivery probability and the average service delay as a function of the number of uncooperative mobile nodes with and without the DE4MHA. The probability that a request was successfully answered as a function of uncooperative nodes in the network decreased with the increase of uncooperative mobile nodes. Taking into account both approaches, with and without DE4MHA, it was observed that DE4MHA presented a slightly worse result. The average service delay also grew when the number of uncooperative mobile nodes increased, as expected. The results of the DE4MHA were also slightly worse but practically insignificant. As can be observed, with 4 uncooperative nodes, the service average delay, with and without DE4MHA, was about 30.78 and 29.77 seconds, respectively.

![Service delivery probability and average service delay as a function of the number of uncooperative mobile nodes with and without the DE4MHA.](jmir_v15i4e66_fig6){#figure6}

Discussion
==========

Findings
--------

Our main goal was to propose and construct a security encryption/decryption based solution in a cooperative environment for mHealth apps. We aimed to ensure data confidentiality, integrity, and authenticity. Privacy is a top priority issue in mHealth services and apps that deal with user sensitive information. On mHealth apps, several security issues must be considered, such as personal information management, secondary use of personal information, improper use of personal information, and errors with stored personal information. Therefore, cryptographic mechanisms can be seen as a solution to guarantied data confidentiality and protection \[[@ref34]\].

In a mobility and cooperative environment with constant health data being forwarded and retrieved, studying and developing security mechanisms become crucial. Several experiments were conducted, involving 35 different users, to check if they could distinguish the app running with and without the DE4MHA embedded. Through the trials, we concluded that users could not tell which app had the DE4MHA embedded mainly because the time response taken to obtain the user health information was nearly the same as without DE4MHA. The DE4MHA was implemented in a ubiquitous manner so users were able to keep using the app without noticing changes or presence of any cryptography mechanisms.

Limitations
-----------

There were several limitations to the study. The main limitation was applying security on mobile devices due to the low processor capacity compared with personal computers (PCs), though tremendous improvements in this area have been made, with a few mobile devices capable of competing with traditional PCs. This improvement allowed us to test several security algorithms to address the issues of confidentiality (AES, RC4, 3DES, and Blowfish), integrity (MD5 and SHA1), and authenticity (RSA with MD5 and DSA with SHA1) in order to verify which combination had a better performance in a mobile environment.

During the experiments, some users without Internet connectivity who wanted to obtain health information were in constantly moving further away from other users. Although the cooperation mechanism was embedded, users that were beyond the range of 10 meters (the maximum range for Bluetooth class 2 modules) could not obtain the desired health information. Another limitation, though not related to security, was with regard to the number of uncooperative nodes (mobile nodes that may not want to cooperate or they may not have cooperation mechanisms embedded), compromising service response probability.

Conclusion
----------

This paper proposed a data encryption solution for mobile health apps, called DE4MHA. The data encryption algorithm DE4MHA with cooperation mechanisms in mobile health allow users to safely obtain health information with the data being carried securely. These security mechanisms did not deteriorate the overall network performance and the app, maintaining similar performance levels as without the encryption. More importantly, it offers a robust and reliable increase of privacy, confidentiality, integrity, and authenticity of their health information. Although it was experimented on a specific mHealth app, SapoFit, both DE4MHA and the cooperation strategy can be deployed in other mHealth apps.

This study was partially supported by Instituto de Telecomunicacões, Next Generation Networks and Applications Group (NetGNA) Portugal, National Funding from the FCT---Fundacão para a Ciência e a Tecnologia through the PEst-OE/EEI/LA0008/2011 Project, National Natural Science Foundation of China (Grant No. 61201165 and No. 61271240), and the AAL4ALL (Ambient Assisted Living for All), project co-funded by COMPETE under FEDER via QREN Programme.

Conflicts of Interest: None declared.

3DES

:   Triple Data Encryption Standard

ACT

:   achieved cooperation time

AES

:   Advanced Encryption Standard

BMI

:   body mass index

BMR

:   basal metabolic rate

CWS

:   cooperative Web service

DE4MHA

:   data encryption solution for mobile health apps

EHR

:   electronic health record

HTTPS

:   Hypertext Transfer Protocol Secure

ICT

:   information and communication technologies

JSP

:   Java Server Pages

RC4

:   Rivest Cipher 4

REST

:   Representational State Transfer

RSA

:   Rivest, Shamir, Adleman

SOAs

:   service oriented architectures

SSL

:   Secure Socket Layer

WS

:   Web service