Introduction

In March 2020, the World Health Organization declared the coronavirus outbreak as a pandemic, which is continuing at the time of writing. As a result of this pandemic, healthcare systems have been overwhelmed and stressed, resulting in various patients having their appointments cancelled and being told to stay home in order to limit the spread of the infectious disease. Owing to overcrowding in urgent care clinics, emergency departments and primary care clinics, the implementation of mHealth systems can be used as a solution to provide care to patients with chronic illnesses as well as reduce in-person clinic visits (Rockwell and Gilroy 2020).

The emergence and rapid development of mHealth has the potential to play an important role in the transformation of healthcare and increase its quality and efficiency. mHealth solutions cover various technological solutions that allow their users to measure vital signs such as heart rate, blood glucose level and blood pressure (European Commission 2014). Sensors and mobile applications are used to collect medical, physiological, lifestyle, daily activity and environmental data that could serve as a basis for evidence-driven care practice and research activities, while allowing patients access to their health information at any given time or place. mHealth can also support the delivery of high-quality healthcare and enable more accurate diagnosis and treatment. It can support healthcare professionals in treating patients more efficiently as mobile apps can encourage adherence to a healthy lifestyle, resulting in more personalised medication and treatment. It can also contribute to patient empowerment as they would be able to manage their health more actively whilst still living more independent lives in their own home environment due to self-assessment or remote monitoring solutions (European Commission 2014; Conroy 2015). mHealth enables a broad range of health-related applications to share data with health providers (as in a traditional doctor–patient relationship) and with insurance companies (Steinhubl, 2015).

According to the World Health Organization (2017), non-communicable diseases (NCD) or chronic diseases, such as diabetes and obesity, have been found to be one of the largest challenges to worldwide healthcare systems. These diseases were responsible for over 40 million global deaths each year. The use of mHealth systems such as mobile applications and wearable technologies can assist users with prevention of chronic diseases as well as improve the treatment prescribed to patients with chronic diseases based on their daily habits (Estrin and Sim 2010). According to Watkins et al. (2018) chronic diseases require consistent self-care and monitoring in order to examine their regression or progression as well as provide one- or two-way communication between practitioners and patients. A study carried out by Yi et al. (2018) concluded that out of 13 studies, 11 found that mHealth provided patients with a statistically beneficial effect.

Safeguarding personal data and addressing privacy concerns is an important aspect of mHealth. In the context of mHealth, managing privacy is a complex issue: patients need control over the collection, recording, dissemination and access to their mHealth data (Kotz et al. 2009). Generally, patients can regulate who has access to their personal health information through the giving of informed consent. Informed consent gives patients appropriate knowledge of what data are being collected, how they are stored and used, what rights they have to the data and what the potential risks of disclosure could be. However, technological literacy limits users’ understanding of the true threats and advantages of technology. Because of users’ limitations on technological literacy, it is necessary to develop mHealth systems that allow patients added control over their data such as, what data is collected and who has permission to access it (Arora et al. 2014).

This study focuses on investigating privacy concerns in mHealth especially in the context of managing chronic diseases. It also focuses on developing a solution to these privacy concerns by the development of a privacy framework for mHealth.

Methodological approach

The methodological approach adopted for this study is a modified version of the engineering design process (Khandani 2005), and consisted of the following processes:

Definition of the problem

The problem was defined to identify and establish the need for a new privacy framework for mHealth in the context of monitoring chronic diseases.

Information gathering

Review of relevant literature was carried out which focused primarily on (i) identification of privacy threats and concerns from previous research studies and (ii) an analysis/comparison of current regulatory frameworks for privacy.

Analyse, select and generate solution

Framework requirements were specified after (i) an analysis of regulatory frameworks for privacy, to determine relevant privacy principles; (ii) a gap analysis was undertaken in order to identify and determine which privacy concerns and threats were addressed by existing regulatory frameworks for privacy; (iii) a framework was generated, implemented and evaluated.

mHealth and privacy problems

Although the use of mHealth supports and facilitates the provision of high-quality healthcare and enables more accurate diagnosis and treatment, numerous previous studies (some cited below) have shown that mHealth poses privacy threats and concerns. A study by Dehling et al. (2015) concluded that 95% of 17,979 mHealth apps surveyed posed some potential damage (information leaks, manipulation, loss, access by third parties) due to privacy and security infringements. A feasibility study on privacy risks of 298 mHealth apps by Brüggemann et al. (2016) found various privacy risks, including that 40% of 70 apps (where data transfer could be identified) transferred personal data without encryption. According to Hussain et al. (2018), mHealth apps are vulnerable to privacy threats which include identity theft, disclosure threats, leakage of information, storage of unencrypted data and the use of data by third parties. In a study by Hutton et al. (2018) assessing privacy in 64 mHealth apps, they found that the majority of the apps performed poorly on privacy, including not allowing users sufficient access to their data, not allowing sufficient control of the granularity of data shared and having inadequate consent mechanisms. Iwaya et al. (2019) carried out a privacy impact assessment of the GeoHealth system, a large-scale mHealth data collection system used in Brazil to deliver community care. They discovered 97 different privacy threats relating to issues such as data quality, informed consent, legitimacy of processing, data security and accountability. They also classified these threats as 89% likely to happen and only 11% unlikely to happen.

In addition to studies on the actual privacy risks of mHealth systems, some studies have concluded that perceived privacy risks of mHealth services by patients make them less likely to trust and adopt mHealth services. Zhang et al. (2014) conducted a study consisting of 491 participants which concluded that privacy can indirectly influence mHealth adoption because privacy negatively impacted participants attitudes and perceived usefulness of mHealth. Guo et al. (2016) surveyed 650 subjects on mHealth services and concluded that privacy concerns had a negative association with trust and adoption of such services. In a study of 388 patients, Deng et al. (2018) concluded that trust correlated positively with patients’ intention to adopt mHealth services, and that privacy risks correlated negatively with trust and hence adoption intention.

The studies cited above are a few examples demonstrating that privacy threats and concerns in mHealth services pose actual or perceived risks to patients, they violate commonly accepted privacy requirements/regulations (e.g. data security, informed consent, accountability) and impact negatively on the adoption of mHealth services. These privacy threats and concerns provide a rationale for further research into finding solutions to prevent or mitigate their consequences. The work carried out in this study is one such research project which focuses on proposing a solution, by developing a suitable privacy framework to better develop mHealth systems so that privacy threats and concerns can be more effectively addressed.

Privacy threats and concerns for mHealth when managing chronic diseases

A privacy concern is an emotional state that may leave someone distressed with regard to their personal information. On the other hand, a privacy threat is something that may or may not happen but has the ability to potentially cause harm to a patient (e.g. unlawful access to and use of a patient’s personal information). It is important to implement safeguards to counteract privacy threats and ensure that patient privacy is preserved. However, it is also important to address privacy concerns in order for patients to have an improved sense of trust and confidence in mHealth systems.

Previous research studies have concluded that mHealth used in any context raises many privacy threats and concerns as described in Table 1. Table 1 lists the various processes that a typical user would undergo in order to monitor their chronic disease with the support of mHealth. Each process has different privacy threats and concerns associated which were gathered from various sources of literature. This is necessary in order to understand what users go through and to have a better understanding of the possible threats and concerns associated with the processes. It must be noted that there can be more than one threat associated with some processes.

Table 1 Identification of privacy threats/concerns – mHealth and monitoring chronic diseases
Full size table

Figure 1 illustrates various events in an mHealth scenario where data is processed (e.g. inputted, collected, transmitted, used). It also highlights the key areas that give rise to privacy threats and concerns (indicated by letters in circles).

Fig. 1
figure 1

Stages of processing mHealth Data

Full size image

The events as shown in Fig. 1 include: manual input of data from a patient (P); the collection of data from body sensors (C); the transmission of data between different stages (T); the management of data on a smartphone app (M); the storage of data in the cloud (S); and the use of data by various types of users (U). The privacy concerns associated with each of the events are further discussed below.

Table 2 summarises the privacy concerns/threats at different events in an mHealth scenario.

Table 2 Privacy threats/concerns at each stage of data processing
Full size table

Comparison of relevant existing regulatory frameworks for privacy

The authors conducted a previous study comparing relevant existing regulatory frameworks for privacy and how they address privacy concerns in mHealth (Jusob et al. 2017). These frameworks included: Health Privacy Project (HPP) Best Practice Principles of 2007 (Kotz et al. 2009); Markle Common Framework of 2008 (Markle Foundation 2008); Office of the National Coordinator for Health Information Technology (ONC) Nationwide Privacy and Security Framework for Electronic Exchange of Individually Identifiable Health Information of 2008 (ONC 2008); Generally Accepted Privacy Principles (GAPP) of 2008 (Prosch 2008); A Privacy Framework for Mobile Health and Home-Care Systems (MHHCS) of 2009 (Kotz et al. 2009); Organisation for Economic Co-operation and Development (OECD) Principles of 2013 (OECD 2013); General Data Protection Regulation (GDPR) (EC 2016).

The study identified at least 23 privacy principles collectively addressed by all frameworks namely: accountability; assignment of proxy; chain of trust; choice and consent; collection and data minimisation/limitation; correction (accurate data); data anonymisation and pseudo-anonymity; data management; data quality and integrity; education; enforcement and remedies; fair and lawful processing; individual access; individual choice; individual participation and control; medical sensing devices not made observable by other parties; notice; openness and transparency; portability; purpose specification of data collection; security safeguards and encryption; storage limitation; use limitation.

The study found that no single framework addressed all of the 23 privacy principles. The study also concluded that no existing privacy framework adequately addressed all privacy threats and concerns (identified in existing literature) when using mHealth to manage chronic diseases.

Proposing a new privacy framework for mHealth

Framework requirements

Based on an analysis of (i) existing regulatory frameworks for privacy and (ii) privacy threats and concerns identified in previous research, the following requirements were specified for a new framework.

  • The new framework must be underpinned (i.e. have a fundamental base) by a body of literature on privacy obligations and guidelines of existing regulatory frameworks and the need to address privacy threats and concerns identified from previous research.

  • The new framework should specify high level privacy principles to reflect the privacy obligations and guidelines of existing regulatory frameworks and the need to address privacy threats and concerns.

  • The new framework should specify privacy requirements for each privacy principle in order to implement the principle into a functional software system.

  • The new framework should specify what mechanisms and technologies are to be used to implement the privacy requirements derived from the privacy principles.

  • The new framework should be capable of being implemented into a working software prototype.

  • The new framework should be capable of being illustrated in a diagrammatic form.

Framework development

After the framework requirements were specified, several brainstorming activities (involving experimenting with various diagrams) were conducted to determine how best to illustrate the framework concept to meet the specifications. After several iterative attempts, a diagrammatic format was generated and selected to best represent how various specification requirements should be combined to create the new framework. A multi-layered structure was selected consisting of each layer building upon the previous layer. The contents of the base layer were selected to ensure that the framework could be implemented at any time in the present or future. In order to implement privacy principles, specific privacy requirements for a prototype needed to be developed using syntax based on the work of the Mitre Corporation (2015) and Raimundas (2017). Furthermore, the mechanisms and associated technologies to implement the privacy requirements were identified.

The proposed framework in this work is illustrated in Fig. 2 and attempts to comprehensively address known privacy obligations and threats/concerns in existing literature. It consists of five layers namely (1) regulatory frameworks for privacy and privacy threats and concerns (2) privacy principles, (3) privacy requirements, (4) mechanisms and associated technologies, and (5) prototype.

Fig. 2
figure 2

Proposed privacy framework

Full size image

Framework layer 1 – regulatory frameworks for privacy + privacy threats and concerns

This layer starts with (ii) identifying existing regulatory frameworks, together with (ii) identifying privacy threats and concerns based on existing research. These provide a future-proof applicability of the framework, since the framework will be based on regulatory frameworks and research existing at any point in time (current or future) when the framework is implemented. For this study, as discussed previously, relevant regulatory frameworks were identified and compared. Also, privacy threats and concerns when using mHealth in the context of monitoring chronic diseases were identified from existing research (see Table 1).

Framework layer 2 – privacy framework principles

This layer outlines the various privacy principles that are developed from an analysis of the information gathered in layer 1. The principles address privacy obligations and threats/concerns in the context of managing chronic diseases using mHealth. Some of principles developed in this study address privacy concerns that existing frameworks have not adequately addressed such as invisibility, continuous monitoring and surveillance. A total of 22 privacy principles were developed in the study as shown in Table 3 below.

Table 3 Privacy principles developed in layer 2 of the framework
Full size table

Framework layer 3 – privacy requirements

Privacy requirements (PR) are statements that reference privacy principles and describe the necessary capabilities and functions that are essential for a system to achieve these privacy principles. They are created based on privacy principles in layer 2. When developing privacy requirements, it is necessary to ensure that they are actionable, measurable, testable and traceable. They are also implemented in systems to ensure that the system is compliant with an organisation’s privacy policies and principles as well as laws and regulatory frameworks (Mitre Corporation 2015). The laws and regulations that govern privacy enunciate privacy requirements at an abstract level which is why it can sometimes prove challenging to developers to interpret and implement them into systems and applications (Mitre Corporation 2013). In this layer, privacy requirements are listed to ensure that privacy principles are addressed and implemented into the design of an mHealth system that implements the proposed framework. The implementation of these privacy requirements will be at the mobile device where data will be processed and at the cloud where data will be stored and accessed by health professionals or third parties such as researchers. In this study, 65 privacy requirements were created based on the privacy principles in layer 2. They are not given in this paper due to the length of the list. However, as an example, for the principle regarding accessibility of data, the following three requirements were created: (i) The system shall allow patients to see what information the system holds about them; (ii) The system shall allow patients to restrict access to their information by third parties; and (iii) The system shall not allow unauthorised access to patient data.

Framework layer 4 – mechanisms and associated technologies

The fourth layer of the proposed framework consists of mechanisms and associated technologies that can be used to implement the privacy requirements (given in layer 3). Hence layer 4 is developed based on layer 3. The mechanisms and associated technologies chosen for the purpose of this study include: (i) Access control mechanisms (ACM): to control access to patient data; (ii) Device and storage security (DSs): to enable data to be kept secure for unauthorised use; (iii) Blockchain (Bch): to store patient data as well as implement access control; (iv) Encryption (Enc): to protect patient data during transmission and storage; (v) Anonymisation and pseudo-anonymisation mechanisms (AnP): to allow patient data to be shared with third parties whilst still preserving patient privacy; (vi) System programs (SPr): to implement various system functions. These mechanisms and associated technologies will be used to enable various technical functionalities when developing a prototype to implement the framework and are further discussed below.

Access control mechanisms

Access control mechanisms are essential to an mHealth system as they are crucial to ensure that: mHealth data is protected; there are restrictions to access patient data; and vital resources are protected. Access controls are a crucial mechanism which can be used to counter security and privacy threats in mHealth systems. They ensure that access to data is restricted by placing limits on who can access data and therefore only allowing legitimate users to access data. In order to implement an access control mechanism, it is necessary to implement an identification system for both health care practitioners and patients. It is essential that the system is transferable between the various entities that are allowed access to patient data. For the purpose of this study a Role-Based Access Control (RBAC) was chosen. This is appropriate as it will limit data access to third parties such as researchers and allow full access to data for patients and doctors as a means to prevent privacy violations. It can also limit user access based on the user’s role within an organisation (Gusmeroli et al. 2013; Rodrigues et al. 2013; Alramadhan and Sha 2017).

Device and storage security

mHealth apps and systems face numerous device and storage threats. These include: The susceptibility to privacy threats such as disclosure threats and identity theft; the sharing of data with third parties; and devices storing and transferring unencrypted data. Additional threats include the external devices that mHealth systems utilise to enhance the mHealth system’s functionality since these devices may put their users’ data at risk as permission systems and protections on mobile platforms do not apply to external sensors devices (Hussain et al. 2018). Based on the threats mentioned above it is necessary to ensure that mHealth systems and their devices are adequately secure because the data stored and produced are sensitive in nature. In order to ensure adequate device and storage security the Advanced Encryption Standard (AES) to safeguard users’ confidentiality of data was chosen. It is a successor to Digital Encryption Standard (DES) which used 56 bits for its key size compared to the 128, 192 or 256-bit key sizes used by AES; therefore, making AES much more secure and harder to decrypt (Robertazzi 2012).

Blockchain

The combination of mHealth and blockchain technology provides an effective solution that allows for both data accessibility and transparency. A study done by Ichikawa et al. (2017) showed that blockchain can be utilised as a tamperproof system for mHealth. The Hyperledger Fabric blockchain (an open-source permissioned distributed ledger) was chosen as a suitable blockchain in the context of this study. It will be implemented in a prototype as part of the mHealth system for patient records as well as to create access logs to enable detection of privacy violations. As a private blockchain, it can enable the restriction of who can participate in its network as well as which transactions take place (Pirtle and Ehrenfeld 2018). The benefits of using Hyperledger fabric include: modularity, enabling functionalities to be altered to best suit systems; enabling smart contracts written in java; enabling restricted data access and data confidentiality; and being open-source.

Encryption

Data encryption is a mechanism whereby an algorithmic procedure converts user data into a form in which there is a reduced probability of allocating meaning to data without use of a confidential process or key. Encryption can be applied granularly, such as to an individual file containing sensitive information, or broadly, such as encrypting all stored data (Snell 2017). The implementation of encryption is also necessary to comply with data protection regulations, including integrity and confidentiality.

Anonymisation and pseudonymisation mechanisms

Anonymisation works by permanently removing personally identifiable data (such as surnames, addresses) from datasets. It allows patient data to be shared (especially with third parties) whilst still preserving patient privacy. Pseudonymisation, however, involves stripping direct identifiers from personal data and substituting them with pseudonyms. This is a reversable process whereby the data can be re-identified if necessary (e.g. by an authorised user such a medical professional). The General Data Protection Regulation (GDPR) mandates the use of pseudonymisation as an appropriate safeguard to reduce risks to data subjects and to enable better compliance with data protection obligations.

System programs

System programs perform operations that will ensure that there is appropriate data quality, user opt-in controls to certain system features and the provision of various reminders among other system functions. The system programs will be coded using Java and will be implemented on an SQL database as well as on the mobile application. The system programs chosen for this study facilitate functions such as: remote wipe; consent; data quality; reminders; opt-in controls; system audits; permission controls; data transparency; access logs and audit logs (Table 4).

Table 4 Mechanisms and associated technologies and the privacy principles they implement
Full size table

Framework layer 5 – prototype

The fifth layer of the proposed framework brings together the mechanisms and associated technologies discussed in layer 4 to develop a prototype as illustrated in Fig. 3.

Fig. 3
figure 3

Prototype implementing the proposed new framework

Full size image

Figure 3 gives an overview of how the mHealth system prototype will implement the proposed framework.

The prototype will be developed to test and evaluate the implementation of the proposed framework in an mHealth system. The prototype consists of mechanisms and associated technologies to implement the privacy requirements specified in the framework. Access control mechanisms (ACM) will be used when stored data is accessed by the users. Device and storage security (DSs) will be used on the mobile device as well as in storage. Blockchain (Bch) will be used when data is stored and accessed. Encryption (Enc) will be used when data is being transmitted from a sensor or wearable to the mobile device and when data is being transmitted to and stored on the cloud. Anonymisation and pseudo-anonymisation mechanisms (AnP) will be used when data is shared with third parties such as researchers. System programs (SPr) will exist throughout the whole mHealth system but will be predominantly found on the mobile device which performs system management.

Comparison of proposed framework to existing frameworks

Table 5 compares the proposed framework to relevant existing privacy frameworks to demonstrate how privacy threats/concerns are addressed. As shown, unlike the new proposed framework, no single existing regulatory frameworks addresses all privacy concerns identified (from existing literature) when managing chronic diseases using mHealth. Furthermore, no existing relevant framework covers some privacy threats and concerns namely: continuous monitoring, invisibility and surveillance.

Table 5 New framework and existing relevant privacy frameworks and the threats/concerns they address
Full size table

Conclusion

The high cost of healthcare, limited medical resources and incidences such as the Covid-19 pandemic have highlighted the importance of mHealth as an essential technology to facilitate healthcare at a distance. The increasing global rise of chronic diseases also presents a challenge that can in part be mitigated by the use of mHealth technologies, especially for monitoring, treatment and support. Use of many of these technologies, however, pose potential damage to patients due to privacy infringements. Furthermore, the perceived privacy risks of these technologies may negatively impact trust and adoption intention among patients. The privacy framework developed in this study makes an important contribution to the healthcare domain by directly addressing mHealth privacy threats and concerns identified in previous research. The framework also builds upon existing privacy frameworks but also incorporates new technologies such as blockchain, mechanisms such as encryption and anonymisation, and capabilities such as access controls in order to ensure that data and bodily privacy are addressed. It also allows users to have better control and transparency over how their data is processed, stored and shared. Ongoing work involves the development and evaluation of a functional prototype (layer 5) to fully demonstrate the implementation of the framework. This work hopefully will make a valuable contribution to a post-Covid-19 world, where mHealth technologies will play an integral part in global healthcare, with patient privacy as an integral part of any widespread implementation.