Assessing Blockchain Health Devices: A Multi-Framework Method for Integrating Usability and User Acceptance^†

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

This paper proposes and applies a multi-framework validation method to assess a blockchain-enabled healthcare device, using expert reviews, user toolkits, and real-world testing with the CipherPal prototype to identify key challenges and user experience barriers in practical healthcare blockchain adoption. However, the authors need to address several issues:

• The user studies rely on very small samples—three UX/UI experts, six toolkit participants, and five user testers-all of whom are relatively young and tech-savvy. This sharply limits the generalizability and reliability of the findings for more diverse or less tech-advanced populations.
• The short (three-day) user test is insufficient to capture long-term usage patterns or habit formation.
• The CipherPal device remains a prototype, with documented hardware and software bugs, poor battery management, and usability issues (e.g., bright LEDs, frequent disconnects, complicated setup). Some usability feedback may thus reflect prototype bugs rather than inherent conceptual flaws.
• Across all frameworks, the practical integration of blockchain introduces friction, confusion, and user burden (such as wallet setup, manual gas fees, and complex confirmations). While users accept the idea of blockchain for data control, they do not perceive enough added value to justify the complexity in this implementation.
• The need for “testnet currency” is a major barrier and unrealistic for non-expert adoption.
• There are no technical benchmarks provided on the blockchain solution’s actual security, speed, data throughput, cost, or scalability.
• The paper lacks a head-to-head comparison with non-blockchain or traditional privacy and security approaches in healthcare, making it unclear whether blockchain meaningfully improves security, privacy, or user autonomy enough to outweigh its costs.
• Device design is flagged as potentially stigmatizing in public settings, with social acceptance not addressed in depth.
• Physical factors-such as device size, LED brightness, and charging inconvenience-present barriers to daily use and may overshadow technical innovation.
• For users, the blockchain element is mostly backgrounded and often serves as a hurdle rather than a benefit; its technical contribution is not clearly evidenced.
• The main novelty lies in the methodological approach (multi-framework validation), not in technological advancement. There is no breakthrough in blockchain protocols or device engineering; the case study confirms previous findings about blockchain friction but does not present a strong new solution.
• Some repetitive discussion and over-detailed appendices reduce conciseness and clarity.

 

Author Response

We sincerely thank the reviewer for their thorough and insightful feedback. The comments have been invaluable in helping us to clarify the paper's contributions, contextualize its findings, and improve its overall structure and clarity. We have carefully considered each point and have revised the manuscript accordingly. Below, we detail our responses to each of the issues raised.

Point 1: The user studies rely on very small samples—three UX/UI experts, six toolkit participants, and five user testers-all of whom are relatively young and tech-savvy. This sharply limits the generalizability and reliability of the findings for more diverse or less tech-advanced populations.

Response: We agree with the reviewer that the sample sizes are small and that the participants’ demographics limit the generalizability of the findings. We have revised the manuscript in two key areas to address this:

1. We have strengthened the justification for our sample sizes in the Methodology section (3.3) by explicitly framing the study as formative evaluation. The goal was not statistical generalization, but the identification of critical usability issues to inform iterative design, for which smaller samples are considered effective in established HCI research. For example, Section 3.3.1 now states:

   "The selection of three experts is consistent with practices for formative usability evaluation. The goal of this expert review was not to achieve statistical generalization, but to identify critical usability issues to inform design improvements. Research by Nielsen [44] demonstrates that a small group of 3–5 experts is highly effective for this purpose..."

2. We now proactively frame our findings through the "early adopter" lens in the Discussion (Section 5.2), acknowledging that the results reflect this specific user profile. The section now begins:

   "The synthesis of these frameworks revealed a central narrative in CipherPal's evaluation, which is best understood through the lens of the target user identified during the study: the technologically proficient 'early adopter'."

Point 2: The short (three-day) user test is insufficient to capture long-term usage patterns or habit formation.

Response: We agree completely. To address this, we have clarified the intended scope of the user test in our Discussion (Section 5.1) and reinforced the need for long-term studies in our Future Research section (5.6).

• Section 5.1 now states that the study was "...designed specifically to capture initial usability, first impressions, and immediate barriers to adoption rather than long-term habit formation..."
• Section 5.6 now prominently features longitudinal studies as a critical next step to "...assess sustained engagement, habit formation, and evolving perceptions of blockchain value beyond the novelty effect".

Point 3: The CipherPal device remains a prototype, with documented hardware and software bugs, poor battery management, and usability issues (e.g., bright LEDs, frequent disconnects, complicated setup). Some usability feedback may thus reflect prototype bugs rather than inherent conceptual flaws.

Response: This is a crucial point, and we thank the reviewer for highlighting it. We have added a new introductory section to our Implications for Design and Development (Section 5.4) that explicitly disentangles the findings into two categories, as suggested. This helps to separate addressable engineering tasks from deeper design challenges.

Point 4 & 10: Across all frameworks, the practical integration of blockchain introduces friction, confusion, and user burden (such as wallet setup, manual gas fees, and complex confirmations). While users accept the idea of blockchain for data control, they do not perceive enough added value to justify the complexity in this implementation. For users, the blockchain element is mostly backgrounded and often serves as a hurdle rather than a benefit; its technical contribution is not clearly evidenced.

Response: We thank the reviewer for identifying what we also consider to be the central finding of our paper. We have embraced this insight and worked to ensure it is clearly framed as a key contribution in the Abstract, Discussion (5.2), and Conclusion (6).

Point 5: The need for “testnet currency” is a major barrier and unrealistic for non-expert adoption.

Response: We agree this is a major barrier. We have added a specific discussion of this issue in our Implications for Design and Development (Section 5.4), explaining the context of the proof-of-concept and the need for abstraction in a real-world product. The new text includes:

"As this was a proof-of-concept study, a testnet environment was used where users had to manage testnet currency, a process that proved to be a significant barrier. For any real-world application, which would operate on a mainnet, this requirement is untenable for non-expert users. Future iterations must therefore explore solutions such as meta-transactions or service-sponsored transactions to completely abstract this financial complexity from the user experience.".

Point 6: There are no technical benchmarks provided on the blockchain solution’s actual security, speed, data throughput, cost, or scalability.

Response: We acknowledge this limitation. Our study's focus was on HCI and user-centered validation, not technical performance benchmarking. We have now made this scope explicit in our Limitations section (5.5).

Point 7: The paper lacks a head-to-head comparison with non-blockchain or traditional privacy and security approaches in healthcare, making it unclear whether blockchain meaningfully improves security, privacy, or user autonomy enough to outweigh its costs.

Response: This is a fair point regarding the study's scope. We have added a new paragraph to the Limitations section (5.5) to acknowledge this:

"This study also evaluates the CipherPal prototype as a standalone system and does not include a direct comparative analysis against traditional, centralized healthcare data management solutions. Such a comparison would be a valuable future study to quantify the specific trade-offs between decentralized and centralized models in this context.".

Point 8: Device design is flagged as potentially stigmatizing in public settings, with social acceptance not addressed in depth.

Response: While this finding was present in our results, we agree it deserved more prominence in the discussion. We have revised Section 5.4 (Implications for Design) to elevate this point, framing it as a critical principle that our multi-framework approach successfully identified. The revised paragraph now states:

"Our multi-framework evaluation highlighted a critical principle for health-related wearables: social perception and the need for discretion can be primary drivers of adoption, potentially outweighing novel technological features. This insight emerged clearly from the convergence of two of our frameworks. The User Acceptance Toolkit proactively identified that the device could be stigmatizing in public settings like work or school. This predictive concern was then strongly validated during user testing, where participants explicitly noted that the device’s bright LEDs and form factor made them feel conspicuous and uncomfortable in public. Therefore, a key implication is that the physical form must be refined not only for ergonomics but crucially for discretion. The user suggestions to explore alternative form factors, such as keychains or pebbles, reflect this fundamental need. This demonstrates that for such devices to succeed, designers must holistically integrate physical, digital, and social factors from the outset, treating potential social stigma as a core design challenge.".

Point 9: Physical factors-such as device size, LED brightness, and charging inconvenience-present barriers to daily use and may overshadow technical innovation.

Response: We have revised Section 5.1 (Synthesis of Findings) to frame this as a key strength of our methodology. The new text explains how the combination of frameworks was essential to uncover these issues.

Point 11: The main novelty lies in the methodological approach (multi-framework validation), not in technological advancement. There is no breakthrough in blockchain protocols or device engineering; the case study confirms previous findings about blockchain friction but does not present a strong new solution.

Response: We fully agree with the reviewer's accurate assessment and thank them for this valuable framing of our work. To fully align the paper with this contribution, we have retitled the manuscript to better reflect our focus on methodology. The new title is now: "Assessing Blockchain Health Devices: A Multi-Framework Method for Integrating Usability and User Acceptance". In addition to this change, we have revised the Introduction (Section 1) and Conclusion (Section 6) to explicitly state that the paper's novelty is methodological, ensuring the entire manuscript consistently communicates this as its primary contribution.

Point 12: Some repetitive discussion and over-detailed appendices reduce conciseness and clarity.

Response: We have performed a focused edit of the manuscript to improve conciseness.

• Discussion: We have removed a duplicated paragraph from Section 5.1 and tightened the language throughout Sections 4, 5, and 6 to better distinguish between reporting results and interpreting them.
• Appendices: We have retained the detailed appendices as they are crucial for the methodological transparency and reproducibility of the study, which we believe strengthens the paper. We have ensured they are clearly referenced.

We believe these revisions have significantly improved the manuscript and are grateful for the opportunity to strengthen our work based on the reviewer's constructive guidance.

Reviewer 2 Report

Comments and Suggestions for Authors

Summary

The research paper presents a case study on a multi-framework validation approach for blockchain-based healthcare devices. Its aim is to demonstrate how combining multiple frameworks can ensure reliable integration of blockchain technology in medical devices. The paper addresses an important and timely problem that is leveraging blockchain for secure, patient-centric health monitoring and provides a detailed example in the form of a case study. Key strengths of the paper include the focus on a novel intersection of IoT health devices and blockchain, and the attempt to systematically validate the solution. The authors make a good effort to integrate different frameworks and highlight practical deployment aspects, which are valuable for readers interested in blockchain healthcare applications.

General Comments

• Novelty: The idea of using multiple validation frameworks for blockchain-enabled health devices is impressive and not widely covered in existing literature. If truly new, this approach can offer new insights. However, the authors should clarify more about how this multi-framework approach differs from existing evaluation methods.
• Significance and Interest to Readers: The integration of blockchain in healthcare devices has significant potential for improving data security, privacy, and interoperability between different devices. The topic is of high importance and is the need of the hour in healthcare systems. The case study approach can help practitioners see practical implementation steps. To maximize impact, the authors should ensure that the discussion convincingly demonstrates how their approach advances the field (for instance, by improving data control or regulatory compliance) and not just reiterates known benefits of blockchain.
• Methodology and Technical Soundness: The research design can be appropriate for exploratory validation, but it must be rigorous. It is crucial that the authors provide clear details on their methodology: the specific frameworks used, the system architecture, and the metrics for validation. The paper would benefit from a thorough description of the experimental setup like device specifications, network setup, and software components. For improving technical soundness, the analysis should allow reproducibility like sharing test data or code. At present, it is unclear whether the validation is quantitative, qualitative, or both. A stronger justification of why each chosen framework is suitable for this study is needed, along with any assumptions or limitations.
• Blockchain Integration in Healthcare Context: The paper rightly focuses on blockchain-specific integration. Key aspects to consider would be to include the choice of blockchain platform, how blockchain nodes interact with IoT devices, and how data is stored or referenced on-chain. If the authors use a particular blockchain like Ethereum, Hyperledger, or a custom chain, they should discuss why it fits healthcare constraints which can be latency, energy use, privacy.
• Patient Data Control: A crucial consideration is how patients interact with the system. The paper should address whether patients retain control over their data example through private keys or consent mechanisms and how user interfaces are designed. Patient-centric data ownership is a key theme in literature. The authors should clearly describe how their solution helps the patient’s concerns, for example how consent is managed. Usability is also a concern the cited work on a blockchain-enabled wearable (“smart fidget toy”) found strong user interest in data control but noted that users may struggle to understand blockchain concepts. The paper should consider similar user acceptance barriers, even to acknowledge them as future work.
• Presentation and Ethical Compliance: The research paper should be well-structured and clearly written, following MDPI guidelines. The English level seems generally acceptable but may need refinement for technical clarity. All figures and tables must be clearly labeled and referenced. Ethical aspects include ensuring that any patient or device data used was handled properly anonymized, with consent. If real health data were used, mention any ethics board approval or anonymization measures. Given the topic, citing data protection regulations would strengthen the ethical discussion, especially as blockchain can help with compliance.

Specific Comments

• Abstract: The abstract should clearly state the objective and highlight the multi-framework aspect. Currently it does not fully convey which frameworks are combined or the main findings. For example, if the case study shows improved security or compliance, this should be summarized.
• Introduction: The introduction covers motivation, but it should cite key references on blockchain in healthcare. For instance, work on blockchain for patient-centric data management and medical device surveillance would provide context. Also, clearly define what “multi-framework validation” means early on: are these software frameworks, regulatory frameworks, or evaluation frameworks?
• Related Work: Ensure the literature review includes recent studies on blockchain and IoT in healthcare. Mention any frameworks or standards relevant to medical device validation like ISO standards for medical devices or data governance and how blockchain fits into them. If the paper lacks a detailed literature section, the authors should add one to compare their approach with existing models.
• Methodology: The research paper could also include the frameworks used like technical analysis framework, security framework, usability framework, regulatory framework, etc. Also describe the case study device and software architecture: hardware specs, network connectivity, and how the blockchain network is set up (nodes, consensus). If there are figures (example a system architecture diagram), ensure every element is labeled (patients, providers, servers, sensors). If a table of metrics is used, define each metric (latency, throughput, error rate, etc.).
• Results: Present clear validation results. Are there performance measurements (e.g. transaction time, energy consumption)? Are there surveys or user studies? If numerical results are given, they include appropriate units and statistical information. If a figure shows system performance or security tests, make sure the axes and legend are descriptive. The authors should explicitly tie results back to the objectives: e.g., “Using both Framework A and B, we were able to detect 95% of security violations” or similar. If qualitative insights are reported, explain how they were obtained.
• Discussion: The discussion should interpret the results in the context of blockchain healthcare. For example, discuss how the multi-framework approach helped identify issues (if so), or whether the frameworks overlapped. It should also address potential limitations: are there scalability issues? Does the approach generalize beyond this case study? The authors should also mention known barriers: for instance, the need for user education about blockchain found in prior work.
• Conclusion: The conclusion should restate the contributions and their significance. It should realistically assess what was achieved. Avoid overstating results. For example, if the case study was small-scale, don’t claim the solution is ready for deployment in all hospitals. Instead, note that this is a proof-of-concept and suggests future steps which could be larger trials, integration with clinical systems.

Suggestions for Improvement

• Clarify Frameworks: Clearly list and describe the multi-frameworks used for validation. If these include technical and usability frameworks, name them (with citations if they are established models). Explain how they complement each other.
• Blockchain Details: Specify the blockchain platform and consensus mechanism. If energy or latency is a concern, consider using a permissioned ledger with proof-of-authority for efficiency. Discuss how consensus is achieved among medical stakeholders and how access is controlled.
• Patient-Centric Data Control: Emphasize how the patient controls data. Reference Ferreira et al. (2023) to highlight a patient-as-owner model. If the system allows patients to authorize data sharing with doctors, describe the mechanism.
• User Acceptance: Acknowledge barriers to user acceptance. The authors could cite Bobrova & Perego (2024), which found high patient interest in blockchain features but noted difficulties in understanding blockchain. Suggest including user training or simplified interfaces to address this.
• Performance and Security Analysis: Suggest adding basic performance metrics (e.g., transaction throughput, CPU usage) and security threat analysis. Compare performance with and without blockchain if possible. This will demonstrate feasibility on constrained devices.
• Ethical and Compliance Discussion: Explicitly mention how the approach aligns with health data regulations (GDPR, HIPAA). Cite that blockchain solutions have been shown to facilitate compliance with privacy laws.
• Presentation: Improve figure captions and ensure all acronyms are defined on first use. Verify that English grammar is polished, and the flow between sections is logical.

Author Response

We are very grateful to the reviewer for their detailed, constructive, and encouraging feedback. The comments have helped us to significantly improve the rigor and clarity of the manuscript. We have carefully addressed each point, and we believe the revised paper is much stronger as a result. Below, we detail our responses.

General Comments

• Novelty: The reviewer asked for more clarification on how our multi-framework approach differs from existing methods.
  • Response: We thank the reviewer for this suggestion. To better clarify our contribution and frame the paper around its methodological novelty, we have changed the title to "Assessing Blockchain Health Devices: A Multi-Framework Method for Integrating Usability and User Acceptance". Additionally, we have revised the Introduction (Section 1)and Research Positioning (Section 2.4) to be more explicit about how our multi-framework approach is novel and differs from prior, siloed analyses.
• Significance and Interest to Readers: The reviewer suggested ensuring the discussion demonstrates how our approach advances the field.
  • Response: We agree completely. We have reframed the Discussion (Section 5) and Conclusion (Section 6)to focus on the methodological insights gained. Rather than just reiterating the benefits of blockchain, we now emphasize how our approach revealed the critical tension between conceptual appeal and practical friction.
• Methodology and Technical Soundness: The reviewer requested more rigorous detail on the methodology, setup, and data types, and a stronger justification for the frameworks.
  • Response: We have significantly expanded our Methodology section (Section 3) to address these points.
    • We now explicitly state at the beginning of Section 3 that the study "employs a convergent mixed-methods design" that facilitates the parallel collection of both quantitative and qualitative data.
    • The introduction to Section 3 and Section 3.3 now explicitly explain the choice of the three complementary frameworks.
    • We have expanded our description of the dataset in Section 3.4.
    • We have added a specific mention of the testnet used ("Polygon zkEVM Cardona testnet") and our rationale for choosing it in Section 3.2.2.
    • We have improved reproducibility by adding a paragraph in Section 3.1 that directs readers to the appendices for all survey instruments and to public repositories for the toolkit templates and source code.
• Blockchain Integration in Healthcare Context: The reviewer asked for more detail on the choice of blockchain platform.

  • Response: We have now specified the exact platform and our reasoning in Section 3.2.2:

    "The system utilizes the Polygon zkEVM Cardona testnet [40] to host a custom smart contract. This platform was selected for this proof-of-concept study due to its nature as a zero-knowledge network, offering potential future scalability and privacy benefits, while maintaining compatibility with standard Ethereum development tools. The smart contract is primarily responsible for managing references to user data. Users, identified by their wallet address, can authorize the storage of records on the blockchain. These records contain pointers to the actual session data, which is stored off-chain for efficiency, along with information necessary for authorized retrieval."

• Patient Data Control: The reviewer asked for a clearer description of how patients control their data and consent.
  • Response: We have added a new dedicated subsection, 3.2.3 Data Privacy and Control, to explicitly detail this mechanism.
• Presentation and Ethical Compliance: The reviewer suggested ensuring clear presentation and addressing ethical compliance, including regulations like GDPR/HIPAA and standards like ISO.

  • Response: We have reviewed the manuscript for presentation and clarity, including enhancing the caption for Figure 3.

  • To address the compliance point, we have added a sentence to the Limitations section (5.5):

    "...a future market-ready version would require a formal audit for regulatory compliance, including adherence to medical device software standards and data protection regulations."

Specific Comments & Suggestions for Improvement

• Abstract: The revised abstract now explicitly names the three frameworks (Web3 Design Guidelines, UTAUT2-based User Acceptance Toolkit, and extended user testing) and states the main finding more clearly as a "critical tension" between the device's appeal and its usability friction.
• Introduction: The introduction now contains a dedicated paragraph defining "multi-framework validation" and its novelty.
• Related Work/ISO Standards: We have addressed the comment regarding medical device standards in the Limitations section (5.5) as a direction for future work on a market-ready product.
• Methodology/Frameworks: As detailed above, we have significantly expanded Section 3 to clarify the frameworks, setup, and technical details.
• Results/Performance Metrics: The reviewer correctly noted the absence of performance benchmarks. We have addressed this by adding a paragraph to our Limitations section (5.5) clarifying that the study's focus was on HCI, not technical benchmarking, and that this is a crucial area for future work.
• Discussion: The discussion has been revised to focus on interpreting the results and demonstrating how the multi-framework method itself led to the key insights about convergence, divergence, and the core tensions identified.
• Conclusion: The conclusion has been refined to be more realistic, explicitly framing the work as an evaluation of a "proof-of-concept prototype" and emphasizing the methodological contribution of the paper.
• User Acceptance: The Discussion (Section 5.2) now proactively frames the findings through the "early adopter" lens to acknowledge the nature of our participant sample and the associated barriers to broader acceptance.

We thank the reviewer again for their time and valuable contributions. We are confident that the manuscript is substantially improved thanks to this feedback.

Reviewer 3 Report

Comments and Suggestions for Authors

1. It is better to illustrate the studied system model using a figure.
2. Please show several practical applications of the studied problem.
3. The methodology should be introduced more explicitly.
4. Please describe the data sets in a more detailed manner. 4.
5. Please show the performance metrics in the simulation results.
6. The simulation results are too simple.

Author Response

We thank Reviewer 3 for their time and for providing clear, actionable feedback. We have addressed each of the points raised in the revised manuscript.

Point 1: It is better to illustrate the studied system model using a figure.

Response: We agree completely. The manuscript includes Figure 3, which provides a detailed system architecture diagram illustrating the relationship between the physical device, the companion web application, and the backend storage solution. We have also enhanced the caption for Figure 3 to be more descriptive and have added a clear reference to it at the beginning of Section 3.2.2 to orient the reader.

Point 2: Please show several practical applications of the studied problem.

Response: Thank you for this valuable suggestion. We have added a new paragraph to the Implications for Design and Development section (5.4) that discusses broader practical applications beyond the CipherPal case study, drawing on insights from our expert evaluation. The new text includes:

"Beyond the CipherPal case study, the principles and challenges identified are rel-evant to a wider range of blockchain-based health applications. As suggested by experts during our evaluation, the value of verifiable, user-controlled data extends to numerous potential use cases. These include systems for verifiable prescription adherence, where a pharmacy could confirm a diagnosis before dispensing medication, secure remote patient monitoring systems that provide auditable data to doctors, and other applications where verifying the authenticity and source of health data is critical in an era of artificial intelligence."

Point 3: The methodology should be introduced more explicitly.

Response: We have significantly revised Section 3 (Methodology) to be more explicit.

• The introduction to Section 3 now clearly defines our study as a convergent mixed-methods design and justifies the selection of our three complementary frameworks.
• We have added specific details about the technical implementation, including the exact blockchain testnet used and the rationale for its choice (Section 3.2.2).
• We have added a new subsection (3.2.3 Data Privacy and Control) that explicitly details the system's encryption model and user consent mechanisms.

Point 4: Please describe the data sets in a more detailed manner.

Response: To address this, we have added a new summary paragraph at the beginning of Section 3.4 (Data Analysis). This paragraph provides a comprehensive and consolidated description of all the quantitative and qualitative data gathered from each of the three evaluation studies.

Point 5: Please show the performance metrics in the simulation results.

Response: We acknowledge that the paper does not contain technical performance metrics. This is because the study was designed as a human-computer interaction (HCI) evaluation focused on usability, user experience, and acceptance, rather than a technical benchmark. We have now made this scope clear by adding a dedicated paragraph to our Limitations section (5.5), which states:

"Furthermore, the study's primary focus was on usability, user experience, and ac-ceptance, not technical performance benchmarking. Therefore, we did not measure quantitative performance metrics such as transaction latency, throughput, or device energy consumption. Concurrently, technical logging limitations prevented direct tracking of user interactions within the browser wallet extension, leaving gaps in the detailed analysis of the transaction confirmation process. A full technical evaluation, in-cluding performance analysis, is critical for assessing scalability and remains a key direction for future work.".

Point 6: The simulation results are too simple.

Response: We thank the reviewer for this comment and wish to clarify that our study is not a technical simulation but a user-centered case study involving a functional prototype. The results presented, which include thematic analysis of user interviews, expert reviews, and behavioral observations, are therefore appropriate for the qualitative and usability-focused nature of our research questions. We have reviewed the manuscript (Abstract, Introduction, and Methodology) to ensure we consistently use terms like "case study," "prototype evaluation," and "user study" to avoid any ambiguity about the nature of our work.

We hope these revisions have satisfactorily addressed the reviewer's concerns and have improved the overall quality of our manuscript.

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

Accept in the current form, the comments are satisfied

Author Response

We thank Reviewer 1 for their positive feedback and for recommending acceptance of our manuscript.

Reviewer 2 Report

Comments and Suggestions for Authors

I appreciate for the careful and comprehensive revisions implemented considering the previous review comments. The manuscript has enhanced its clarity, rigor, and transparency. The abstract articulately presents the frameworks and key findings, while the introduction successfully delineates the novelty of multi-framework validation. The elaborated methodology and discussion sections offer increased detail and coherence, and the conclusion appropriately positions the work as a proof-of-concept. By addressing limitations and user acceptance, the manuscript is significantly strengthened overall.

Author Response

We sincerely thank Reviewer 2 for their positive and encouraging feedback on our revisions. We are very pleased that they found the manuscript to be significantly strengthened.

Reviewer 3 Report

Comments and Suggestions for Authors

Although the authors have improved this paper, several improvements still need to be made.

1. It is better to illustrate the studied model using a figure.
2. Please show several pratical applications of the studied model.

Author Response

We thank Reviewer 3 for their continued engagement with our work and for highlighting areas that required greater prominence. We have addressed the remaining points below.

Point 1: It is better to illustrate the studied model using a figure.

Response: We agree completely that a figure is essential for illustrating the system model. The manuscript provides this in Figure 3, titled "System Architecture of CipherPal Prototype."

To ensure this figure is impossible to miss, we have not only improved its caption to be more descriptive but have also added direct references to it in multiple sections of the paper:

• In the Introduction (Section 1), where we first introduce the prototype.
• At the beginning of Section 3.2.2 (System Architecture and Data Flow), where we explicitly introduce the diagram before describing its components.

We hope these additions make the illustration of our system model sufficiently clear.

Point 2: Please show several practical applications of the studied model.

Response: We thank the reviewer for this important suggestion. To address this, we have added a dedicated subsection to the discussion, "5.4.2. Broader Applications and Design Principles," which explores several practical applications beyond our specific case study. This section now contains the following text :

"Beyond the CipherPal case study, the principles and challenges identified are relevant to a wider range of blockchain-based health applications. As suggested by experts during our evaluation, the value of verifiable, user-controlled data extends to numerous potential use cases. These include:

• systems for verifiable prescription adherence, where a pharmacy could confirm a diagnosis
• auditable data collection for clinical trials, where patients retain control over their contributions
• personal health data portfoliosthat can be securely shared with new providers
• and secure remote patient monitoring

The ability to provide immutable, user-authorized data is also critical in an era of artificial intelligence to verify the authenticity and source of health information.”

We believe this new subsection and the detailed examples within it fully address the reviewer's comment. We thank the reviewer again for pushing us to make these valuable additions.

Round 3

Reviewer 3 Report

Comments and Suggestions for Authors

This paper has been improved according to the comments and suggestions.