This is an open-access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in JMIR mhealth and uhealth, is properly cited. The complete bibliographic information, a link to the original publication on http://mhealth.jmir.org/, as well as this copyright and license information must be included.
Digital health technologies, including telemedicine, mobile health (mHealth), and remote monitoring, are playing a greater role in medical practice. Safe and accurate management of medical information leads to the advancement of digital health, which in turn results in a number of beneficial effects. Furthermore, mHealth can help lower costs by facilitating the delivery of care and connecting people to their health care providers. Mobile apps help empower patients and health care providers to proactively address medical conditions through near real-time monitoring and treatment, regardless of the location of the patient or the health care provider. Additionally, mHealth data are stored in servers, and consequently, data management that prevents all forms of manipulation is crucial for both medical practice and clinical trials.
The aim of this study was to develop and evaluate a tamper-resistant mHealth system using blockchain technology, which enables trusted and auditable computing using a decentralized network.
We developed an mHealth system for cognitive behavioral therapy for insomnia using a smartphone app. The volunteer data collected with the app were stored in JavaScript Object Notation format and sent to the blockchain network. Thereafter, we evaluated the tamper resistance of the data against the inconsistencies caused by artificial faults.
Electronic medical records collected using smartphones were successfully sent to a private Hyperledger Fabric blockchain network. We verified the data update process under conditions where all the validating peers were running normally. The mHealth data were successfully updated under network faults. We further ensured that any electronic health record registered to the blockchain network was resistant to tampering and revision. The mHealth data update was compatible with tamper resistance in the blockchain network.
Blockchain serves as a tamperproof system for mHealth. Combining mHealth with blockchain technology may provide a novel solution that enables both accessibility and data transparency without a third party such as a contract research organization.
Digital health, including the utilization of mobile health (mHealth) apps and devices, has become popular in the everyday practice of medicine [
Blockchain technology has attracted attention because of its efficacy in the prevention of data tampering. It serves as a distributed tamperproof database. To ensure tamper resistance, it maintains a continuously growing list of transactional records organized into blocks, using consensus algorithms that allow untrusted parties to agree on a common state. Valid transactions stored in a blockchain are digitally signed and timestamped by their sender, providing cryptographically irrefutable evidence of both the provenance and the existence of a record at a given time [
To address this issue, we have applied blockchain technology to an mHealth app that enables cognitive behavioral therapy for insomnia (CBTi) using a smartphone. Insomnia is a prevalent public health problem with a huge economic burden. Approximately 20% of the population meets the criteria for chronic insomnia as a disorder [
In this study, we developed an mHealth system for CBTi using a smartphone app together with blockchain storage platform and evaluated the tamper resistance of the data collected using smartphones.
Our mHealth system was composed of the CBTi client and the CBTi servers (
(a) The structure of the mobile health system for cognitive behavioral therapy for insomnia (b) The data update using a blockchain system (c) The structure of the blockchain (d) The virtual computing environment in the study.
The mHealth records collected from patients were divided into two types: subjective and objective data. The subjective data, which include clinical indicators, sleep status, and a review of daytime activities, were collected in the form of a self-administered questionnaire. The objective data, which include the results of a psychomotor vigilance test [
We show the data update process using the blockchain network (
One of the VPs became a leader of the network and accepted requests from the CBTi client. The request that was accepted by the leader was delivered to each VP. The CBTi client sent the first transaction to the leader VP, and then the leader VP let each VP install chaincode and perform the initialization. After that, the CBTi client sent the request for data processing, and the leader VP sent the request from the client to each VP. The VPs executed an installed chaincode and returned hash values generated from the execution result. At that time, each VP followed the consensus algorithm, which was called the Practical Byzantine Fault Tolerance (PBFT) algorithm [
We evaluated the network robustness of the CBTi system with regard to data integrity according to the Recommendation of the Council Concerning Guidelines for the Security of Information Systems and Networks [
To test network robustness during a network fault, we ensured the correctness of mHealth data updates from a smartphone using the procedure described below. First, we verified the process of normal data update. Next, we tested the data updates when one of the VP servers was down.
For the test, we utilized the mHealth data of a volunteer over the course of 5 days. The client data format was JSON and, in the experiments, the data were input manually to the CBTi servers instead of via the smartphone app. Each server was constructed in the virtual environment, which ran in the same local personal computer with Intel Core i5-5200U CPU 2.2GHz and 8GB memory running Windows 10. For the construction of the virtual environment, we utilized Docker version 1.10.2 [
We verified the data update process under conditions where all the VPs were running normally. The test procedure was divided into 2 steps: Deploy and Invoke.
We started the CBTi servers composed of 4 VPs and an MS. We initialized the state with the user data for 2 days and deployed the chaincode on each of the VPs. This is the Deploy step. In detail, the steps were as follows: First, we logged into the CBTi system with a user ID and password. We then initialized the state using the user data of a nonpatient volunteer for 2 days. Next, we deployed a chaincode to each of the 4 VPs. The chaincode describes the procedure for the addition of JSON formed data to the database. When the Deploy step was executed successfully, the block based on the transaction information was produced, and user data were added to the state.
We ensured that the block was generated successfully and that the height (the length of the blockchain) incremented from the one at the start of the normal data update (
The blockchain (excerpt) in the normal mobile health data update.
The user data (excerpt) queried from the state in the normal mobile health data update. (a) The initial user data after the Deploy step. (b) The updated user data after the Invoke step (newly added data were highlighted).
We executed the transaction to update the database with user data for a day using the chaincode on each VP. This is called the Invoke step. We ran the deployed chaincode on each VP, and each chaincode produced a temporary result. When the VPs in the network reached a consensus based on hash information of the temporary results, the transaction was confirmed. When the transaction was confirmed successfully, the user data were updated to the state, after which the block was produced. We ensured the production of the block and the increment of the height from one of the Deploy step (
We further confirmed the success of the data update by querying it. We could see that user data for a day had been added. The excerpt of user data registered to the database is shown in
To investigate the tamper resistance of our system, we produced an artificial fault in the system that caused ledgers in the VPs to contain inconsistencies. We produced a network fault by taking one of the VPs down and then updated data during the network fault. This gave an indication of the robustness of the blockchain network. After rebooting the VP that had stopped, we confirmed that the data in the rebooted VP were one step behind. We also checked that the inconsistency was corrected by ledger synchronization. In detail, the process was as follows: First, there were 4 VPs running in the initial state. We tested sequentially after normal data updates. Thus, the user data for 3 days was recorded (
Next, we rebooted the stopped VP (VP1). We confirmed that the block of VP1 was one step behind because VP1 had been down (
The full user data queried from the state are shown in
We further tested whether the rebooted VP (VP1) could rejoin the PBFT consensus if another VP (VP2) was temporarily down. After VP2 was offline, VP1 completely caught up with VP0 and VP3 because 2×f + 1 nodes must reach consensus before proceeding to the next block of transactions (
The full information for the blockchain from these experiments is shown in
The blockchain in the mobile health data update test when one of validating peers (VPs) was down. The blockchain height of each VP is shown. (a) Robustness of the blockchain network against network failure. (b) Correction of the inconsistency by ledger synchronization. (c) Rejoining the Practical Byzantine Fault Tolerance consensus after another network failure.
The user mobile health data (excerpt) queried from the state in the data update test when one of the validating peers (VPs) was down. (a) The successfully added user data after the Invoke step when VP1 was down (newly added data were highlighted). (b) The user data after the Invoke step when VP1 was rebooted (newly added data were highlighted).
In this study, we have developed and evaluated a tamper-resistant mHealth system using the blockchain technique. The mHealth data collected using a smartphone were sent to a private Hyperledger Fabric blockchain network. The mHealth database in the blockchain network was robust against network faults such as “node down.” The node of the distributed database in the blockchain network that was down could catch up with other normal nodes because of the consensus algorithm, which is not implemented in ordinary distributed database systems. Therefore, the distributed database in the blockchain network was resistant to tampering and revision, and the mHealth data update was compatible with tamper resistance in the blockchain network.
Thus, mHealth technologies such as CBTi using a mobile device enable delivery of treatments that have previously been labor-intensive. The mHealth system needs to be tamper-resistant because the system automatically provides treatment to patients based on the stored data. Recently, attacks to hospital networks using ransomware have been reported where hospitals had to pay ransom to the attackers [
In previous studies, various secure EHR systems have been proposed [
There are two reasons that blockchain technology is favorable to mHealth data. First, as shown in this study, the mHealth data update was not frequent because the patients’ data were transferred to the server only twice a day in our system. So, although blockchain is not ideal for data with high temporal resolution, it could easily deal with mHealth data. Second, mHealth data are valuable, which is why a high level of security is essential. From the point of the view of security, blockchain is expected to accomplish high tamper resistance.
The system guarantees the accuracy of mHealth data without confirmation by a third party, so it has the potential for use in clinical trials in the following two ways: (1) the system would reduce the cost in clinical trials by decreasing the amount currently spent on confirmation by a third party such as a contract research organization [
This study has two limitations. First, there is vulnerability around the blockchain system. Although blockchain technology is tamper-resistant, the implementation around it can be attacked. Poorly maintained and outdated codes allowed vulnerability in an incident involving a decentralized autonomous organization [
In this study, we developed and evaluated a tamper-resistant mobile health care system using blockchain technology.
The user data queried from the state in the normal data update.
The user data queried from the state in the data update test when one of VPs was down.
The blockchain information in the validation test of tamper resistance.
cognitive behavioral therapy for insomnia
electronic health records
JavaScript Object Notation
mobile health
membership service
Practical Byzantine Fault Tolerance
validating peer
This work was supported, in part, by the New Energy and Industrial Technology Development Organization of Japan.
TU designed the research; MK performed the research; DI, MK, and TU analyzed the data; and DI, MK, and TU wrote the paper.
The authors are members of Sustainable Medicine, Inc.