User Control of Personal mHealth Data Using a Mobile Blockchain App: Design Science Perspective

Introduction

Background

Data is the new oil.
[Clive Humby]

This quote by Clive Humby epitomizes the reality of today’s internet-connected society, wherein private firms collect, distribute, store, analyze, and monetize user data. An important but understudied challenge facing the health care industry, users, and service providers of health care apps per se is the dichotomy of standards pertaining to user health care data. On the one hand, there are stringent data requirements such as the Health Insurance Portability and Accountability Act (HIPAA) and the General Data Protection Regulation (GDPR), which assure patient confidentiality, privacy, and security of user data, with most of the burden of data privacy and data security transferred to the provider. On the other hand, there are numerous pervasive devices collecting mobile health (mHealth) data such as height, weight, heart rate, electrocardiograms, sleep patterns, oxygen saturation levels, eye scans, blood pressure parameters, and real-time blood glucose levels with such data stored on devices and later transmitted to private clouds of equipment manufacturers and service providers at scale. Very little oversight or legal protection is provided to users of such devices and mHealth apps to prevent third parties from monetizing such personal data. An illustrious example is when Google recently released a machine learning algorithm that can actively predict a patient’s heart condition by applying deep learning to retinal photographs [1]. In addition, user data are often harvested for research and analysis purposes, which often claim the anonymity of user data.

Although on the periphery, given a choice, >90% of the users surveyed in a recent study chose to keep their data private, and a significant number of them trusted to keep their health data on a blockchain [2]. A challenge facing health care providers, governments, and law enforcement is the cost of enforcing stringent requirements as per the HIPAA [3], GDPR, and the Public Health Emergency Privacy Act. For example, although HIPAA provides requirements for data privacy, the enforcement, monitoring, and penalizing of violators are practical difficulties [4]. The premise of supporting data privacy and access to personal health care data is limited when users sign onto health care apps under terms and conditions that prevent unauthorized access without the users’ ability to share the data with their provider.

In this paper, we present a novel blockchain-centric approach to pervasive mHealth data by designing and deploying mobile apps that transmit and store data on a configurable blockchain optimized for storing, retrieving, and accessing internet of things (IoT) data. We summarize the blockchain architecture and how it supports IoT transactions using web services. We then develop 2 separate mHealth apps, one on iOS and the other on Android, and demonstrate the novelty of the blockchain-centric pervasive health care apps. We show how users of mHealth apps built atop the blockchain control their data while the blockchain supports access control, privacy, anonymity, and decentralized storage (not in the control of a single firm) [5].

Objective

To satisfy the challenges of user privacy and data access, combined with the need to maintain high security, speed, and availability of pervasive mHealth data, we propose using a configurable blockchain architecture such as the consensus, hasher, storer, miner (CHASM) architecture [6]. In this paper, we investigate the following research questions:

1. Research question 1: What and how do pervasive mobile apps interface with a configurable blockchain to provide users privacy, security, and control over their mHealth data?
2. Research question 2: How and can pervasive mobile apps adhere to stringent HIPAA compliance?

To our knowledge, this is one of the earliest researches to present a configurable blockchain architecture that combines elements of private and public blockchains and is compatible with the requirements of pervasive mHealth data, which caters to the highest plausible security and privacy requirements as prescribed by HIPAA. Access control is provided at multiple layers, that is, at the wallet layer, at the app layer, and at the blockchain layer. Similarly, prior research has not addressed how such pervasive health care data, which are generated by devices, can be made compatible with IoT blockchain data stores with significant security, high throughput, and expectations of low-synchronization times.

In the following sections, we describe the Design Science Research Methodology (DSRM) and then follow each step in the DSRM to implement a viable solution.

Methods

Overview

We used the DSRM, which is commonly used by researchers in information systems and computer science [7]. The main steps in the DSRM are listed in Textbox 1.

Following these principles, we executed the following steps for our solution: first, we defined the research problem and justified both our solution and the value of our solution; second, we defined the design goals for our system as the objectives that we intended to accomplish; third, we designed and implemented our solutions; fourth, we demonstrated the solution with respect to the goals set forth earlier; and finally, we evaluated the solution for accuracy, security, and (potential) costs while documenting the risks.

Step 1 of the DSRM: Problem Definition and Importance of Solving

Pervasive devices and apps on such devices that capture individual mHealth data have become popular in everyday use for millions of individuals using wearables, personal health parameter test kits, and medical devices [8]. Such devices and apps have several benefits by positively affecting patient health outcomes through the gamification of health care practices such as increasing the frequency of exercise, monitoring food intake and obesity control, improving communication among patients, and increasing patient motivation by encouraging them to join peer groups of similar individuals [9].

mHealth users generate a significant amount of data through their pervasive devices, which record data such as heart rate, blood cholesterol, and blood pressure. Most often, users own a multitude of devices such as smartwatches, smart apps on phones, smart blood sugar monitors, and smart brainwave readers [2,8,10-12]. Such pervasive devices create large data footprints, and such generated data are usually stored on separate and independent cloud-based servers or network-attached storage. Such databases are centrally administered, and data access is controlled by the firm that manages these data stores after the user’s approval. A key issue with such centrally managed data stores is that users have no control over their data and frequently do not have access to historical data. However, very often, such data can provide valuable insights into user health, and when services such as those demonstrated by Google [1] or by Sleep City [13,14] become more commonplace, it can lead to early diagnosis of medical conditions or provide early warnings about the onset of diseases. Pervasive devices responsible for collecting mHealth data are called edge devices as they have exceedingly small storage capacity and depend on the network to collect and store data [15]. As a result of their resource-lessness and the need to store back-end data elsewhere, blockchains have been shown to provide numerous benefits [16]. However, such benefits are not automatically transferred over pervasive devices and apps that need to be specifically written with security, access, privacy, and performance considerations. Prior health care research on data on health care exchanges, data tamperproofing, and securing health care data have demonstrated the benefits of using blockchains in the context of health care [8].

Several public blockchains are used for building decentralized applications such as those in supply chain management, decentralized finance, and enabling contracts. The blockchain’s advanced features of enabling private-public key cryptography, decentralized consensus algorithms that can be modified, and strong 1-way encryption of data through hashing can address several challenges facing health care data storage [16]. Fang et al [17] discussed the key challenges with current blockchain designs of public, consortium-based, and private blockchains in ensuring that all of the properties required for health care systems (ie, privacy, security, scalability, and immutability of patient health records) cannot be simultaneously available on the same blockchain. This is also known as blockchain trilemma.

The underlying blockchain we developed supports the symmetric encryption of transaction payloads in addition to signing. For this app, we used advanced encryption standards using a secret key associated with the user’s private key. A user may associate multiple secret keys for different apps using the same private key. The mHealth data can only be decrypted using the user’s secret key for onward sharing, downloading, and reading. A user can create multiple secret keys for each app, and each app can run on multiple devices to capture information about the same individual. For example, secret key 1 associated with the user’s ID would be used to capture the user’s heart rate; secret key 2 associated with the user’s exercise log would be used to capture data on the number of steps a user takes while running or doing exercise; secret key 3 could be used capture, for example, sleep patterns; and secret key 4 could be used to log other health care information such as blood pressure, oxygen saturation levels in the blood, and blood sugar. Unique information would be stored in separate wallets or devices and could be deposited or synced up with the blockchain for overall persistent storage.

A feature of HIPAA compliance is providing users with absolute privacy of information and the ability to delete and clean out their data if given a chance. Textbox 2 presents the main requirements of such a software system and why each of these requirements is important to solve.

Step 2 of the DSRM: Objectives of the Solution

A blockchain is a decentralized and distributed data store that can address the potential privacy and security concerns related to data access and data standardization while supporting device interoperability and providing users with total control of their own data [10,11]. Blockchain is a secure and immutable transaction ledger distributed on computing devices. Transactions are stored on the ledger through cryptographic validation and linked upward through the network. Owing to decentralization, peers can transact without a third party. Peers access the blockchain through a combination of private–public key cryptography (usually Elliptic Curve Digital Signature Algorithm) and can create and store as much data as they want within the blockchain transaction record. Such transactions are cryptographically signed by the owner of the data using his or her private key and are accessible on the blockchain only by the owner of the public–private key. All stakeholders of data, for example, device manufacturers, device users, marketplace administrators, and health care solution providers, can be permissioned onto the blockchain network [10], or users can explicitly or implicitly share data with other users.

The key advantage of using a blockchain system to track data is that the blockchain can verify and perennially store all created and validated user data. Some of the common advantages of using a blockchain versus a standard pervasive database system are listed in Table 1.

Step 3 of the DSRM: Design of the System

Overview

Figure 1 describes the main use case scenario that motivated our design of the mHealth app. In Figure 1, we see the same individual user using 4 separate devices for monitoring his or her health parameters: blood pressure monitoring device, physical activity (eg, running, jogging, and walking) monitoring, active blood sugar monitoring (eg, for prediabetic or diabetic conditions), and brain wave monitoring. Each device stores and records the individual’s personal mHealth data, which can either individually or collectively be used to make inferences about a person’s health.

‎View this figure

Use Cases for Storage Retrieval and Messaging

We present different use cases for data storage, data retrieval, and messaging. Apps from different platforms allow users to share data using their private keys to keep the data secure but usable by these apps. These apps can later use whole or part of the user data to provide services, as well as for users themselves to share and control the data provided to the platform.

The use cases are as follows:

1. Use case 1: perform a data collection activity and submit signed data to the blockchain
2. Use case 2: create diverse types of data for the same user from multiple devices using the same private key
3. Use case 3: delink data on the blockchain using private key deactivation (as a blockchain is an immutable structure, data once added to the chain cannot be deleted; however, if the private key is deactivated, that is, delinked from the user, the private components of the data can never be linked back to the user who created it, and any existing encrypted payload data cannot be decrypted in the future or accessed by others)

Other peripheral use cases are as follows:

1. Use case 4: share data across different apps
2. Use case 5: (optionally) sell data in a health care marketplace

Blockchain design could also incentivize users to create, record, and share authentic, high-quality data and possibly auction the information on health care data marketplaces that access personalized health care data for downstream sale for research. A use case diagram demonstrating all the above use cases and their dependencies is shown in Figure 2.

We extend prior research on configurable blockchain patterns and specifically use the CHASM blockchain pattern and the corresponding instantiated PantherChain design to accomplish storage, retrieval, and market functionality for health care data [6]. In the following sections, we describe the design of the PantherChain system and document features of the PantherChain blockchain system used to implement key use cases for pervasive IoT-based mHealth data. The advantage of using the CHASM design pattern is that it is flexible, and each underlying component can be altered to suit the performance, speed, and storage needs of the overall IoT system. Sengupta and Subramanian [6] demonstrated the design and performance functionalities of 4 different blockchains by altering the software components. We present the architecture of such a system and illustrate the benefits of such an implementation in the following sections, which include high performance and tunability of parameters such as difficulty used in mining, especially when IoT devices and high throughput are required.

‎View this figure

The CHASM Design Pattern and PantherChain Implementation

We used the CHASM software design pattern and the implementation of this pattern in Java that we call PantherChain [6]. Sengupta and Subramanian [6] described the CHASM in greater detail. However, they did not configure PantherChain or CHASM to support IoT through web service–based application programming interfaces (APIs) for smart contracts. In this implementation, we adapted CHASM’s configurable architecture and implemented an IoT-based extension to CHASM in the form of a representational state transfer (REST) API layer that accepts requests from devices and supports high performance and throughput.

In Figure 3, we show the CHASM design pattern by illustrating the classes and their interactions. The CHASM pattern is an extension of the popular context object design pattern [18], a core Java 2 Platform Enterprise Edition pattern that allows different classes to share a single controlling context (interface). In our implementation, the BlockchainSystem class references abstract class implementations of the 4 CHASM components: consensus, hasher, storer, and miner. Henceforth, we will refer to these concepts, implemented using abstract classes, as plugs.

In PantherChain, we provided different implementations for each plug. The hasher plug has 3 implementations: MD5 (Message Digest Version 5) [19] implemented as MD5Hasher, SHA256 (Secure Hash Algorithm) [20] implemented as SHA256Hasher, and SHA512 [20] implemented as SHA512Hasher. The storer plug has 2 implementations: a serialized JSON file implementation (FileStorer) and a relational implementation using SQLite (SQLiteStorer). The miner plug was implemented as a proof-of-work (POW) miner with flexible levels of difficulty, similar to Bitcoin [21]. We included 2 implementations of POW: a single-threaded POWMiner and a multi-threaded parallel version (ParallelPOWMiner). Finally, the consensus plug was implemented using a distributed file-sharing mechanism as a proof of concept to demonstrate a distributed Nakamoto [21] consensus, as described by Nakamoto [21] (SimpleConsensus). PantherChain can be extended by replacing the plugs (implemented as abstract Java classes). Each plug provides specific abstract methods that are interfaces to the rest of the blockchain system. Finally, PantherChain can use any implementation of transactions and can be used for different types of transactions (eg, text-based or cryptocurrency-based) within the same instance. In PantherChain, both text-based and JSON-based transactions can be signed and encrypted. Interestingly, as the payloads of encrypted JSON transactions are no longer well-formed JSON, the encrypted JSON transaction class is a subclass of signed text transactions (Figure 3).

‎View this figure

Step 4 of the DSRM: Implementation of the IoT Interface on the Blockchain

Overview

Although smart contract [22] virtual machines are not implemented within the CHASM pattern, we piggybacked on the Java Virtual Machine combined with an easy-to-use web service–based software as a service system that operates on each PantherChain node as the IoT interface. The current implementation of PantherChain includes a Java 2 Platform Enterprise Edition Servlet–based REST API that allows an external app to use all components of PantherChain. Some of the end points in the PantherChain REST API are as follows: APIGetKey (to retrieve an existing wallet or create a new public or private key wallet), APIAddJson (to add a transaction containing JSON data signed with a key), and APISearchUid (to search PantherChain based on a unique identification).

To implement a smart contract, the app can make an API connection to a PantherChain node and provide the client with complete app integration. This method allows app developers to use a blockchain in the back end and develop their app logic in the language or platform of their choice. We developed and tested each of our use cases listed above on PantherChain to demonstrate the capabilities of the system and validate it with user-based tests and HIPAA compliance guidelines. We also set forth future research directions for such a model by illustrating incentivization models based on third-party validation of data accuracy, marketplaces for data, etc. The PantherChain implementation also includes the demonstration of Bitcoin-like cryptocurrency (PantherCoin) atop the existing system.

Invocation of the IoT mHealth Data Interface

Integrating PantherChain into an mHealth system is a 2-step process: (1) initializing or retrieving a user wallet (using APIGetKey) and (2) submitting a transaction to the pool using APIAddJson. In our tests, we developed 2 apps, one for an Android watch and the other for an Apple watch, each of which can capture some health data from the sensors, build a JSON data packet, and send it to the API back end. Multimedia Appendices 1 and 2 show sample Android (Java) and iOS (Swift) codes for performing this action.

Results

Step 5 of the DSRM: Demonstration of the Mobile Data Health Care iOS and Android Apps

Overview

To provide a proof of concept of the process, we developed 2 watch apps: one based on Android and the other based on iOS WatchKit. Both were simple apps that were designed to run on a watch. We programmed the Android app to track steps and heart rate data when a start button is tapped and submit a signed package containing the average heart rate and total steps taken when the stop button is tapped. The iOS WatchKit app worked in the same way, except that, given the iOS watch we used did not have a direct internet connection, the data were uploaded by an iPhone companion app that retrieves the data from the Apple watch and submits a similar signed package to the blockchain. The user can set up both apps with the same wallet (private-public key pair) so that the data from all the devices can be linked to the same user. Alternatively, the user could use a meta-wallet such as metaMask [23] or the Exodus [24] wallet to generate a master public-private key to store independent wallets within the meta-wallet. Overall, irrespective of the approach chosen, all the user’s data and confidential information are captured and stored only by a single user. In the following sections, we provide some illustrations of the apps we designed, thus demonstrating the various use cases above.

Implementation and Validation of Use Case 1

In this use case, the personal health care data of users are stored and accessible on the blockchain using a query interface using the private key by a single user.

The first basic use case involves a user performing a basic workout using an Android watch. Figure 4 demonstrates the Android app running and collecting data while the workout is in progress. The app may enable the encryption of the payload for additional security of the data. We will discuss the encryption process further in the Implementation and Validation of Use Case 3 section. When the workout is stopped, the watch (or the controlling phone if the watch does not have direct internet access) can submit the workout as a new transaction to the blockchain after encrypting it with a secret key (if enabled at the app level).

‎View this figure

Implementation and Validation of Use Case 2

In this use case, personal health care data of diverse types with multiple devices and meta-information are stored on the blockchain.

Although the first use case is the most basic method of tracking mHealth data, similar processes exist in most health monitoring platforms today. The motivation for use case 2 comes from the limitation of the ability to share and aggregate data from different mHealth systems into a single platform. Currently, users do not have the option of using different devices with differing capabilities of collecting health data and reviewing and aggregating all data in a single coherent manner. Our app solves this issue by allowing different apps to collect mHealth data to submit data packages signed with the same wallet to be submitted to the blockchain. Figure 5 shows the 2 apps in iOS WatchKit (left) along with its companion iPhone app (center) and the Android watch app (right), collecting diverse types of data for submission to the same blockchain.

Figure 5 illustrates 2 different devices (an iOS device and an Android device) collecting health care data from the same individual and submitting the data to the blockchain. The user of the app, identified by his private-public key combinations, can access the data within his wallet from a web app (as shown in Figure 1). Such data collected about the user from multiple devices can be used to create a health intelligence dashboard and can also be traded (shared) with data marketplaces.

‎View this figure

Implementation and Validation of Use Case 3

In this use case, personal health care data are deleted based on the private key of the individual after deboarding from the system.

To provide HIPAA compliance, users need to have the ability to delete personal health data from any associated system. As a blockchain is immutable, data cannot be tampered with once it is mined and added to the blockchain (but it can certainly be deleted from the transaction pool before it is mined). However, in our mHealth implementation, HIPAA compliance can be achieved by deactivating the user wallet, which delinks any mined block from the user. If the user chooses to encrypt the data payloads for the transactions, the encrypted components cannot be decrypted without the user’s secret key. However, the blockchain integrity can still be maintained with blocks containing the data, although no association with a specific user can be made without the wallet.

We highlight some other potential approaches for privacy implementations in the following sections.

Implementation and Validation of Multi-key Wallets

A wallet in our app can be associated with multiple secret keys for encryption. Deactivation of any key associated with the wallet renders the transactions encrypted with that key inactive. In our implementation, a wallet included a public and private key pair for signing and verification and several advanced encryption standard secret keys for encrypting payloads. Figure 6 demonstrates (1) enabling the user of the mobile app to encrypt transaction payloads; (2) a wallet with a public key, private key, and a single secret key; and (3) a simple signed transaction and a transaction from the same user with an encrypted payload.

‎View this figure

App Access Restriction

Privacy compliance can be implemented at the app level, where the user requests the deletion of an account, leading to the removal of the user’s wallet from the blockchain. Once the user deboards the system, if the private keys are removed from the personal devices of the users, the data can never be reconnected to the user level.

Implementation and Validation of Use Case 4

In this use case, personal health care data with different types of data are aggregated into a blockchain app.

Once data from different apps are uploaded into the blockchain, a third-party verification method can validate the authenticity of the data (this process may differ from blockchain to blockchain but will involve some form of mining strategy). In this proof-of-concept app, we used a POW mining technique (similar to that of Bitcoin but using a lower difficulty level) to combine validated transactions into mined blocks. These validated blocks can be used by apps to aggregate data from every app that uses the same wallet to be associated with the same user. The mining module in the CHASM pattern in PantherChain is implemented as an interface [6]; hence, it can be replaced with other algorithms such as Proof-of-Stake, which can provide deterministic, time-bound confirmations for transactions logged into blocks [25].

Governance Approaches for PantherChain

One of the largest challenges with IoT-based blockchains is related to who governs the blockchain. Governance functions for the blockchain include the ability to control the functionality of the blockchain [26]. This could include altering algorithms for consensus, hashing, storage, and mining. In addition, the blockchain’s future functionality enhancements, including the ability to support different apps on top, could be subject to governance. Governance protocols that can be considered for the blockchain can be of many types. Table 2 summarizes the key governance mechanisms of the token.

On the basis of our analysis of an mHealth-based app stack, which interfaces IoT with the blockchain, the consortium-based blockchain works best. If a consortium of device manufacturers, app developers, and users cannot be formed, creating a decentralized autonomous organization facilitated by PantherCoin, the inbuilt token of the PantherChain blockchain, will enable such a mechanism. However, the risks of such an approach are greater than having an equitable consortium of stakeholders who invest and control the blockchain and its future enhancements and can ensure decentralization. For a system such as ours that deals with health care, it is recommended that governance not rely on tokenomics; rather, the decentralized functionality of the blockchain should be used overall.

Cost of Setting up a Blockchain

There are many types of costs associated with setting up such a blockchain, such as the costs for programming, the cost of hardware setup, the costs for setting up a network, and the cost of app development and integration with device manufacturers. Although this paper will not be sufficient to cover all these costs because of the detailed cost analysis needed, we have documented the cost of hosting our prototype. We hope that designers and developers will be able to interpret the hosting costs from these figures and find these costs significantly lower than those of the public blockchains or other consortium-based blockchains, which require more specialized knowledge and higher bandwidth equipment such as application-specific integrated circuit (ASIC)–based processors for mining.

Our prototype instance was configured and set up on a cloud virtual machine with 1 TB disk space, 128 GB RAM, and Linux with 2 core Intel processors. The cost of setting up 1 instance of the blockchain was US $300 for 3 years. Similarly, nodes could be set up at US $1200 for 3 years. This is for unlimited incoming and outgoing network traffic. We used a common high-performance computing infrastructure cloud available to us from the university. A similar hosting arrangement could be applied to the cloud environments (such as Amazon Web Services, Google, Microsoft, and Heroku) or even with blockchain-based distributed computing clouds such as FileCoin, Storj, or InterPlanetary File System–based systems, which could cost the same amount. On the basis of the number of consortium members and the number of device manufacturers or devices that store data on the cloud, use could also increase or decrease as time goes by. These systems are flexible enough and can accommodate the need to store only the most recent data (and partial or full replication of data could be supported). As the CHASM architecture is flexible, future versions could include sharding of the data store and other performance enhancements that are typical of large-scale data stores. A full discussion of distributed systems architecture would be out of the scope of this paper as we focus on the privacy and user control of data using an IoT-optimized data store.

Performance Statistics for the PantherChain System

Although the performance of blockchain systems has been subject to much debate in the literature, it must be noted that performance is measured in terms of the number of transactions that the blockchain can handle per minute overall. For example, the VISA network supports 1700 transactions per second, which indicates a submillisecond access time for any web service request on the network. The Bitcoin and Ethereum networks are much less performant, and these systems have not been benchmarked from an app standpoint.

Our approach to testing the performance of the PantherChain is based on the caveat that the performance of any system can be assessed by measuring the overall times taken to access different components of the system. In our case, owing to the architecture of a distributed and decentralized computing system, we could measure the overall performance of our system in terms of the time taken to access the services of the blockchain. For example, the time taken to access the front end of PantherChain and the time taken to access the REST APIs are discussed above. As we use the Apache Tomcat web server, using the software as a service model, several performance benchmarks of the stack exist. Notably, the Center for Internet Security benchmarks for Windows and Linux operating systems and several processor-related benchmarks already exist [27]. Similarly, Apache Tomcat and Java performance benchmarks for a variety of hardware and software, including combinations of Java Development Kit and Java Virtual Machine implementations, have already been performed [28]. For the performance testing of different configurations of blockchains, please refer to the study by Sengupta and Subramanian [6].

We benchmarked the standard typical use cases of the front end of the PantherChain system and the basic API for obtaining the wallet key after generating it. In Figure 7, we plot the means of the API response times on 5 dimensions commonly used to measure the performance of the getKey and uid APIs and the PantherChain user interface.

‎View this figure

Validation of the Artifact

We provide a complete validation of our process, against the requirements, including the HIPAA compliance checklist for mobile devices [29], in Textbox 3.

Discussion

Evaluation of the Prototype

In this study, we developed a complete blockchain-based mHealth data collection system using PantherChain, an implementation of the CHASM-based blockchain framework. We developed mobile apps capable of running on smartwatches to collect personal health data, which are signed with the user’s private keys, and demonstrated that this process could be implemented in high-performance apps. We tested our results with a proof of concept, as explained in detail in previous sections, using both an iOS and Android mobile app and the blockchain. We can clearly show evidence for access to diverse types of health information [6] by the same user.

Further results demonstrating the performance of our app in the context of health parameters and different operating system versions are documented in the following paragraphs.

We collected performance data by running our proof-of-concept apps on different devices and simulators. The proof-of-concept iOS WatchKit app was tested on the following platforms:

1. iPhone 12 Pro simulator running iOS 14.4 paired with Apple Watch Series 6 40 mm simulator running WatchOS 7.2 (Figure 8).
2. iPhone 6 device running iOS 12.5.4 paired with Apple Watch (original) running WatchOS 4.3.2 (Figure 5)
3. iPhone 12 device running iOS 14.6 paired with Apple Watch Series 3 running WatchOS 7.3.2

Our proof-of-concept Android watch app was tested on the following platforms:

1. Android Watch device ZGPAX S99c running Android 5.1 Lollipop (Figure 4)
2. Android Watch simulator (not reported in results because of unavailability of health simulators) running Wear OS 9.0 (Android Pie)

‎View this figure

The host platform for the 2 simulators we used was a MacBook Pro 2018 (Apple Inc, 2.6 GHz Core i7, 32 GB RAM) running macOS Catalina. The work network was a wired 1 Gbps network, and the home network had a maximum upload speed of 5 Mbps. Note that the Android watch device we used had only a 2.4 GHz wireless adapter (which is typical of most low-cost, high-performance IoT platforms, as was available during the writing of this paper). We tested on some old hardware to ensure that our apps could run with adequate performance on low-performance IoT devices. After running our apps, which were configured to send summary as well as detailed workout data, and varying the time of workouts, we noticed that the performance of submitting workout data to PantherChain primarily depended on network latency, network throughput, and HTTP protocol handshake time. The round-trip time from device to PantherChain was observed to be as low as 28 milliseconds (simulator in 1 Gbps network) to a maximum of 724 milliseconds (Android 5.1 device on a 2.4 GHz home wireless network). We collected data for workouts ranging from 1-minute to 30-minute durations, and even with detailed data uploads, the performance was reasonable and as expected for any network-connected device. We plot the graphs of the time taken to submit the data to the blockchain in milliseconds (y-axis) versus the size of the data (in bytes) payload on the corresponding device for the 4 configurations in Figure 9.

The 4 configurations correspond to using the heart rate monitor app running in 4 different modes on different network configurations, as shown in Table 3.

The results demonstrate that our platform and process for collecting and submitting health data to a blockchain does not degrade user experience in terms of performance. Please note that the performance times reported are only based on submission to the blockchain and do not include mining performance, which is not necessary unless the user wants to have the data committed to the blockchain for potential marketplace use. Mining performance comparisons for various difficulty levels (by varying the mining algorithm) of PantherChain are available from the study by Sengupta and Subramanian [6].

‎View this figure

Comparison With Prior Work

Although some prior works have provided a methodology for achieving tamper resistance and privacy in storing mHealth data in blockchain (eg, Ichikawa et al [8]), our implementation takes it further in a full blockchain implementation using actual mHealth data apps. Fang et al [17] suggested using a permissioned private blockchain to accomplish some of the GDPR capabilities to enable users to control their data. Scholars have developed and demonstrated apps for blockchain in the areas of health care exchanges, mobile data exchanges, and centralized health record storage. Such work has mostly been with enterprise health care systems such as electronic health care records and whose primary use case for the blockchain is for decentralizing data storage [30-34]. Although such apps are built and deployed on either Hyperledger or Ethereum frameworks, they are not necessarily tested for IoT compliance, which is at the other end of the performance, data size, and speed spectrum. Griggs et al [35] discussed that with public blockchains, no user data should be stored within smart contracts as HIPAA compliance indicates that such data are not private and are accessible to all. Our configurable blockchain design considers this limitation and solves this problem by encrypting the data and allowing data access only through wallets that are owned by users. Similarly, we can also configure the entire blockchain on a private network and not on public blockchain infrastructure, which prevents public viewing of such data.

Several prior papers have cited and used Ethereum as an underpinning technology for smart contract–based blockchain designs. However, with Ethereum as the blockchain, on-chain storage is expensive, and for IoT apps such as edge devices, which require storage of data on the chain for fast retrieval or health care analytics, Ethereum may not be best suited as a blockchain. A recent estimate for the Ethereum blockchain showed that storing 1 MB of data on chain would cost approximately US $76,000 [36]. As a result, on-chain storage on Ethereum is not recommended for current apps. Storing off chain will also be significantly inefficient because of the gas costs on Ethereum for writing a transaction and operating a smart contract, which today costs approximately US 25$ to US 60$ per transaction, which would be more expensive than some of the low-end smartwatches in the market.

Another limitation of prior work is that with mHealth data and pervasive computing, the need for data platforms to operate in the context of multi-platform data sources has not been tested. Pervasive (edge) devices that need to transmit data frequently to back-end data stores present specific network transmission time (performance), security, and privacy challenges. The web services architecture (CHASM) that we deploy is platform independent, and we demonstrate using Android and iOS apps with different network configurations, all communicating with the same blockchain web service for 1 individual user. Overall, we believe that our approach is a novel method for designing and developing and demonstrating the functionalities of a HIPAA mobile data–compliant system that comprises pervasive mobile data apps on multiple devices and a custom configurable blockchain that is platform independent and performant with respect to IoT characteristics. We conclude our research by stating the benefits of using such a configurable blockchain architecture (CHASM) with a web service stack that receives data from IoT devices.

Limitations

Our proof-of-concept solution has been tested for scalability with 4 nodes and works on a secure public network. We tested fail-safeness and replication of data across nodes for the ascertained (mined) data and blockchain. In the future, the architecture can be extended to include a larger number of nodes, and distributed data replication can be tested. However, we are confident that the CHASM architecture will support such scalability as the underlying network and data distribution interfaces are pluggable. Similarly, we believe that our tests performed with >5 devices, including simulators and health apps that track physical activity, can be scaled to a larger number of devices and several types of apps. The PantherChain implementation is device agnostic, and data stored on the blockchain are agnostic to the source of data.

The heterogeneous usability of the blockchain used by providers and device manufacturers, who would now lose control over the data (or would have to purchase data from their customers), to analyze them will lead to reduced times in designing and developing more efficient data. The need for users to share revenues and profits with other users who produce data will be difficult. The risk of losing the private key to access one’s data will make the data completely unusable forever. Therefore, the storage of the private key (or private key generation algorithms) needs to be adhered to closely.

Conclusions

Overall, we demonstrate the benefits of using blockchain in presenting a unique and novel architecture for mHealth data using multiple devices. Our implementation of a unique blockchain that is configurable with respect to its subcomponents and API layer provides the necessary flexibility and security in addressing privacy, security, and data ownership issues with personal health data. Our findings from implementing the proof of concept with multiple devices and personal data are as follows:

1. With IoT devices and personal mHealth data, blockchains can provide the flexibility of storing, retrieving, and accessing individual user data, despite multiple devices and operating systems generating such data about the individual.
2. Aggregation of data on the individual and providing only individual access to blockchain data using encryption protects the user’s privacy. Using the wallet approach, the user can also transfer or send a copy of his or her data to other wallets through a separate transaction.
3. Our design of mHealth apps on different devices and operating system agnostic apps, which communicate with the blockchain through web services, supports IoT throughput requirements.
4. As stated in the test results above, we demonstrate the performance compliance for IoT devices as well as HIPAA compliance for user data with our design.

Using this implementation, in the future, we could create a data marketplace for personalized health care data, where anonymous users can control the generation, quality, and monetization of their health care data, instead of giving data away for free.