A Blockchain-Based End-to-End Data Protection Model for Personal Health Records Sharing: A Fully Homomorphic Encryption Approach

Round 1

Reviewer 1 Report

·      

 LneComment 1 

In lines 52 to 60, this paragraph interrupted the flow of the introduction. Mentioning Section 2 at that phase is not appropriate. This paragraph needs to be relocated to section 2.

Comment 2

English should be revised, for instance bulleted sentences must have the same way of writing. Punctuation in Table 3 must be consistent, ..etc

Author Response

Reviewer 1

Comment 1

In lines 52 to 60, this paragraph interrupted the flow of the introduction. Mentioning Section 2 at that phase is not appropriate. This paragraph needs to be relocated to section 2.

Authors: We appreciate your suggestion, and moved the paragraph to Section 3, "Related Work" (page 6), and updated the text as follows:

Regarding data access, some models assume that whenever a person participates in a model, access to data is automatically granted [ 3,19 ,20 ,25 ]. Some models apply encryption to PHR using specific role keys (doctor, patient, nurse) [3 ,18 ,40 ], while others share data in an unencrypted format [19 , 35, 36, 39 ]. A few models allow individuals to encrypt PHR data [3,20 , 40, 42]. There is an opportunity to elevate the security level and control of the PHR lifecycle from its origination to how it interoperates among health institutions.

Considering this modification, and also thanking you again, we are confident that we have a clearer text where the reading flows better.

Comment 2

English should be revised, for instance bulleted sentences must have the same way of writing. Punctuation in Table 3 must be consistent, ..etc

Authors: Thank you for your suggestions. Before this resubmission, the manuscript was proofread by Elsevier Language Editing Service. The main idea was to solve all eventual English problems, enhancing the grammar and readability of the article. Better English favors the contributions' understanding and improves the chances of the article being cited. With this in mind, we are confident that we have a pertinent contribution to the literature, which can be summarized as follows: (i) mitigation of risk to personal privacy by reducing the use of unencrypted data, and (ii) improvement of semantic interoperability among health institutions by using distributed networks for standardized PHR.

Moreover, we revised all lists’ punctuation throughout the manuscript, adjusted the punctuation in Table 3, and updated the following lists:

● Section 1, page 3:
○ Combination of IPFS and blockchain network to manage PHR data and

metadata;

• ○  Adoption of FHE techniques to reduce the demand for unencrypted data, supporting calculation on encrypted data;

• ○  End-to-end encryption standardization to allow PHR data sharing and interoperability;

• ○  Segregation of responsibilities regarding PHR to improve how individuals control personal data.

• ●  Section 3, page 6:

  • ○  Level of control over data (create, share, revoke, delete);

  • ○  Location of the PHR data (on-chain/off-chain);

  • ○  Data protection in each step (encryption, vulnerabilities).

• ●  Subsection 4.3, page 11

○ The SDV is a temporary data area available via a computational unit managed by

a DS. Each SDV is a file registry in an IPFS cluster, with a unique content identifier CID shared by a process called pinning. After expiration, peer nodes must run a process called unpinning (cease API availability) and garbage collector (remove local unpinned files). It might be accomplished using solutions such as the IPFS cluster;

• ○  The communication between a data requester and DS regarding a specific SDV uses JSON Web Token (JWT). After a JWT token expires, access the a specific SDV is denied;

• ○  The period of data availability is proposed by the requester and accepted by the individual. After data expiration, requesters must submit a signed transaction to the blockchain network regarding the removal of any copy of the corresponding SDV. The signed message must contain useful information, such as the file CID, to allow further auditing;

• ○  Health institutions may keep medical records necessary for further procedures and covered by regulations, such as HIPAA or GDPR. The final transaction is a signal to the participants in the network that the corresponding SDV is no longer necessary and can be removed.

Reviewer 2 Report

In this manuscript authors propose an architectural model that applies a DHT technique called the interplanetary protocol file system and blockchain networks to store and distribute data and metadata separately.

They also claimed that these new modules are responsible for segregating responsibilities from health institutions and promoting end-to-end encryption.

They evaluated performance and storage occupation using a database with 1.3 million COVID-19 registries, which showed 16 that combining FHE with distributed networks could redefine e-health paradigms.

This paper is well written and explains the technical things clearly. I recommend publishing this paper in its current format.

 

Author Response

Authors: We highly appreciate your recommendation and strongly believe our work has contributed to using distributed networks for PHR data protection. The proposed model focused on two significant challenges: protecting personal privacy and obtaining trustworthy information on healthcare management. We proposed new elements called data wards and shared vaults to segregate responsibilities related to personal data and promote trust mechanics to foster network behavior among participants. With an end-to-end encryption model, it is possible to support the exchange and calculation of information regarding healthcare without exposing individuals owing to the homomorphic encryption technique. Finally, we understand that we have pertinent material and inclusion in the healthcare and sensors literature, with real possibilities of being cited by peers.

Reviewer 3 Report

Dear Authors,

Thanks for your efforts to enhance the security of personal health records data sharing.

After reviewing all the sections of your article, I have decided to recommend a major revision since there are some technical shortages and writing errors that must be improved before final publication. Below, you can find my comments.

1) Please proofread all the sections by asking an expert in the field. There are several misused terms or wrong writing structures that confuse readers. For instance, in the abstract, line 3, To bypass this problem? The verb "bypass" is not a proper one for solving or addressing a problem. So, it confuses the reader into thinking about an alternative. There are several other meaning and writing issues in this paper. Please highlight all the revised words in the R1 version with a different font color so that they can be distinguished from the former version.

2) Since there are many abbreviations in the current version, it is very hard to read and find the acronyms and follow the abbreviations. Please include a table of abbreviations and acronyms at the beginning of section 2.

 

3) In the literature, there are similar state-of-the-art models that apply blockchain technology to secure personal health records. Hence, you should include a comparative analysis section after the experiments and compare your results with at least four recent existing works. The current version of your manuscript does not support your claims regarding your contributions since the other works applied similar methods for the same application. The question is, what did you propose, and what are the differences?

Author Response

After reviewing all the sections of your article, I have decided to recommend a major revision since there are some technical shortages and writing errors that must be improved before final publication. Below, you can find my comments.

Authors: Thank you very much for all the contributions. They helped us improve the quality of the manuscript and better explain our model's contributions compared to the related work. We explored different aspects of the model, such as privacy, performance, and node communication in the blockchain. The benchmarks and profiling of homomorphic encryption algorithms demonstrate the applicability of such techniques. The proposed algorithm calculated over one million records in less than 3 min and allowed sharing of a new PHR entry in less than 30 s, which could support calculations and publication of pandemic outbreak data in practical applications. Homomorphic encryption provides a set of techniques to support the statistical calculations of encrypted data as a mechanism to protect personal privacy and provide public-interest information regardless of any individual data representation.

1) Please proofread all the sections by asking an expert in the field. There are several misused terms or wrong writing structures that confuse readers. For instance, in the abstract, line 3, To bypass this problem? The verb "bypass" is not a proper one for solving or addressing a problem. So, it confuses the reader into thinking about an alternative. There are several other meaning and writing issues in this paper. Please highlight all the revised words in the R1 version with a different font color so that they can be distinguished from the former version.

Authors: We appreciate your suggestions. Before resubmission, the manuscript was proofread by Elsevier Language Editing Service. Moreover, all the authors have revised punctuations and sentence styles in all bullet lists and replaced misleading words throughout the manuscript. All replaced words are properly highlighted in the submitted manuscript (Major Review version). Thus, also completely agreeing with you, we are confident that we have a better version of the manuscript, with improved English, and with better chances to be cited by literature peers.

2) Since there are many abbreviations in the current version, it is very hard to read and find the acronyms and follow the abbreviations. Please include a table of abbreviations and acronyms at the beginning of section 2.

Authors: A table of acronyms is a great way to make reading more fluid. Thank you for the suggestion. We updated Section 1 (page 3) with a detailed table of acronyms.

3) In the literature, there are similar state-of-the-art models that apply blockchain technology to secure personal health records. Hence, you should include a comparative analysis section after the experiments and compare your results with at least four recent existing works. The current version of your manuscript does not support your claims regarding your contributions since the other works applied similar methods for the same application. The question is, what did you propose, and what are the differences?

Answer: We heartily thank you for this final comment. We truly believe we have a great contribution to the subject (intersection of healthcare and computing areas) and your comments are of great importance to elevate the level of our work and deliver a high-quality article to the research community. The contributions of our model are (i) mitigation of risk to personal privacy by reducing the use of unencrypted data and (ii) improvement of semantic interoperability among health institutions by using distributed networks for standardized PHR. We evaluated performance and storage occupation using a database with 1.3 million COVID-19 registries (which is significant in the literature). The results showed that combining FHE with distributed networks could redefine e-health paradigms. Finally, we updated the manuscript with a comparison of our work with relevant literature regarding architecture design (Table 2, Section 3, page 6) and regarding experiments on data protection and Homomorphic Encryption (Table 5, Section 6, page 16).

Round 2

Reviewer 3 Report

Dear Authors,

Thanks for your efforts. I would suggest a minor revision since the current comparison is based on some claimed features (Table 5). To have a technical comparative analysis with provable metrics, you should use some equations, plots, and plaintext expressions to validate your model. Unfortunately, I can not see a proven difference between your model and the literature.

Author Response

Thank you for your comment. We agree that quantitative results and additional comparisons could be interesting in improving the quality of the article. In this way, we have added Figure 6 to the article. This figure depicts a benchmark profiling, where we have results that indicate that the proposed model has a faster processing time when compared to related work (in particular, references  [53] and [21]). As we can see in the right column of Figure 6, She et al. used the Paillier algorithm to reach a 128 bits security engine, which demands a prohibitive processing time. 

In addition, we have added a text below Figure 6 to explain the behavior of the observed players: proposed model, Kocabas et al. (reference 21), and She et al. (reference 53). When compared to [ 21], the proposed model can support addition and multiplication operations on encrypted data by the use of the FHE algorithm (BFV) instead of Partially Homomorphic Encryption (Paillier). BFV also has better performance when compared to Paillier. To compare both algorithms, we considered a 128-bit security level parameter, as stated in [54], then we extrapolated it to our database to obtain a metric and compare the models. We show the results in Figure 6.