A Blockchain-Based Framework for Privacy-Preserving Medical Report Sharing and Diagnosis-Free Verification

Abstract

The digital sharing of healthcare data necessitates a careful balance between the need for verifiability and the protection of patient privacy. In many real-world scenarios, particularly in employer and third-party verification processes, excessive clinical information is disclosed beyond what is strictly required. This practice introduces significant privacy risks and conflicts with data minimization principles. To address this problem, this study proposes a blockchain-based, privacy-preserving system architecture that enables health report verification without revealing diagnosis information. The proposed system is built upon a dual-layer architecture that structurally separates clinical data from verification processes. In the clinical data layer, health reports are encrypted on the client side and stored in off-chain environments, while only reference data and access control information are recorded on the blockchain. The system further integrates revocation mechanisms, role-based access control, and auditability through a modular smart contract design. In conclusion, this study introduces a modular, privacy-oriented, and practically applicable solution for secure healthcare data verification. By eliminating the need for clinical data disclosure during verification, the proposed architecture offers a novel design perspective and contributes both conceptually and technically to the development of blockchain-based healthcare information systems.

1. Introduction

The digitalization of healthcare services has significantly increased the volume of medical data exchanged among healthcare providers, patients, employers, and other authorized institutions. While digital data sharing improves efficiency and accessibility, it also raises concerns regarding privacy, security, and regulatory compliance. Healthcare information is particularly sensitive, requiring mechanisms that ensure both verifiability and protection against unnecessary disclosure [1].

In many practical situations, individuals must provide evidence that they have received healthcare services without necessarily revealing the underlying medical details. For example, employers often require confirmation of medical leave or attendance at a healthcare institution, yet access to diagnoses or clinical findings is generally unnecessary. Existing verification processes frequently fail to distinguish between proof of validity and access to medical content, leading to excessive disclosure of personal health information [2,3].

Blockchain technology has emerged as a promising approach for secure healthcare data management because of its immutability, transparency, and decentralized trust model [4]. Numerous blockchain-based healthcare systems have been proposed to improve data integrity, access control, and auditability [5,6]. In parallel, privacy-enhancing techniques such as encryption, off-chain storage, and cryptographic proof mechanisms have been adopted to reduce exposure of sensitive information [7].

Despite these advances, most existing solutions primarily focus on secure data sharing rather than privacy-preserving verification. Recent studies have also explored privacy-aware healthcare applications beyond blockchain, including foundation model-based approaches for 3D medical image analysis, highlighting the growing importance of secure and responsible use of sensitive healthcare data [8]. In many cases, some level of access to medical content remains necessary during the verification process. Furthermore, mechanisms for managing the lifecycle of verification outputs, particularly proof revocation, are often treated as secondary design considerations.

To address these limitations, this study proposes a blockchain-based framework that enables diagnosis-free verification of medical reports. The proposed architecture separates clinical data management from verification activities through a dual-layer design. Medical reports are encrypted and stored off-chain, while verification is performed using blockchain-based proofs that do not reveal diagnostic information. The framework also incorporates role-based access control and a dedicated revocation mechanism to support secure and accountable verification processes.

Rather than presenting a production-ready healthcare platform, this work aims to demonstrate the feasibility of a privacy-preserving verification architecture through a functioning prototype. The proposed framework contributes to the literature by introducing a diagnosis-free verification model that combines data minimization, controlled access, and revocable proofs within a unified blockchain-based architecture.

2. Literature Review

The digitalization of medical reports accelerates clinical decision-making processes and improves the efficiency of healthcare services. However, the sharing of health data among multiple stakeholders has made critical requirements—such as privacy, access control, data integrity, and auditability—more visible. In this context, blockchain technology is frequently proposed as a trust layer for healthcare data sharing due to its immutable record structure and decentralized trust model [9,10].

However, the literature clearly shows that blockchain alone does not guarantee privacy. Effective privacy preservation requires the combined use of access control mechanisms, cryptographic methods, and off-chain storage solutions [11].

2.1. Access Control

In blockchain-based healthcare data-sharing systems, access control is generally addressed within a patient-centric authorization framework. In this model, the patient is positioned as the primary authority who determines access rights to health data. Access decisions are implemented through smart contracts, making them transparent and traceable [12,13].

These systems define rules such as who can access which data under what conditions. This improves accountability in data-sharing processes.

On the other hand, multi-chain (or dual-blockchain) architectures have been proposed to enhance scalability in multi-stakeholder healthcare ecosystems. These approaches aim to enable secure data sharing across institutions [14,15]. Similarly, dual-layer access control mechanisms provide policy-based controls that reduce privacy risks while preserving blockchain verifiability [16].

However, most existing studies focus on data sharing among healthcare stakeholders such as patients, doctors, and hospitals. The needs of external verifiers are only partially addressed [17].

2.2. Off-Chain Storage

The large volume and sensitive nature of healthcare data necessitate a reconsideration of storage strategies in blockchain-based systems. The widely adopted principle in the literature is “minimum data on-chain, full content off-chain”.

In this approach, medical reports are stored off-chain in encrypted form. Only hash values or references used for integrity verification are recorded on the blockchain [18,19]. This reduces storage costs and prevents the exposure of sensitive data on-chain.

Recent studies extend off-chain storage approaches to meet interoperability and performance requirements. Solutions enabling data exchange across different healthcare systems integrate off-chain storage with secure data transfer mechanisms [20]. Distributed storage systems such as IPFS further enhance scalability and verifiability when combined with blockchain [21,22].

However, these approaches primarily focus on data storage and access. Minimizing data disclosure during verification remains a secondary concern.

2.3. Privacy-Enhancing Cryptographic Approaches

Due to blockchain’s inherent transparency, additional cryptographic mechanisms are required to ensure privacy preservation. Attribute-Based Encryption (ABE) stands out as a key method in this context [23].

ABE allows only users with specific attributes to decrypt data. It aligns well with policy-based access control models.

In addition, proxy re-encryption enables secure data sharing without requiring the data owner to re-encrypt the content. This approach reduces key management overhead in dynamic access scenarios and improves system usability [24,25].

Searchable encryption techniques further allow operations on encrypted data. This makes healthcare data both secure and functional [26,27,28].

Despite these advantages, most cryptographic approaches focus on securing data sharing. They do not directly address verification scenarios where clinical data must remain completely hidden.

2.4. Diagnosis-Free Employer Verification

Most blockchain-based healthcare systems in the literature focus on the secure sharing of electronic health records among patients, physicians, and healthcare institutions. However, scenarios involving third-party verifiers—such as employers—are only limitedly addressed [22,29].

In such scenarios, the verifier does not need access to clinical data. Only proof of validity is required.

Some studies on medical certificate verification approach the idea of validation without content disclosure [30]. However, these studies do not place the verification mechanism at the center of system design. They also fail to structurally separate clinical data from verification processes.

Therefore, there is a clear lack of holistic architectures that fully preserve diagnosis confidentiality while focusing solely on verifiable proof generation.

2.5. Revocation

In healthcare data-sharing systems, access permissions and verification outputs are inherently dynamic. Therefore, the ability to revoke previously granted permissions or generated proofs is critical for system reliability.

Existing studies emphasize that revocation must be an integral component of verification processes [31].

Similarly, security and privacy analyses highlight that the absence of revocation mechanisms may create a misleading perception of permanent trust within the system [32,33].

However, many existing approaches lack systematic and modular revocation mechanisms that cover the full lifecycle of verification proofs.

2.6. Interoperability and Institutional Applicability

Due to the distributed nature of healthcare systems, data is inherently fragmented across multiple institutions. Therefore, interoperability has emerged as a key research area.

Blockchain-based approaches aim to address this issue through decentralized trust and standardized data access mechanisms [10,20,34].

However, real-world applications are strongly shaped by institutional requirements such as regulatory compliance, governance, and access policies.

For this reason, permissioned blockchains are often considered more suitable for healthcare systems [17].

Recent systematic studies further highlight hybrid architectures and data minimization-oriented approaches as dominant trends in the field [11].

2.7. Research Gap and Contributions

The reviewed literature demonstrates significant progress in blockchain-based healthcare data sharing. However, three major gaps remain. First, most existing approaches focus on secure data sharing but do not address verification mechanisms where clinical data remains completely hidden. Second, although access control and cryptographic protections are well developed, holistic architectures that structurally separate clinical data from the verification layer are limited. Third, studies addressing the full lifecycle of verification outputs—particularly those incorporating revocation as a core design component—are scarce.

This study addresses these gaps through an integrated approach and makes three key contributions. First, it introduces a diagnosis-free verification mechanism that operates independently of clinical data sharing and focuses solely on verifiable proof generation. Second, it proposes a dual-layer architecture that clearly separates the clinical data layer from the verification proof layer. This structure enforces data minimization and privacy-by-design principles at a systemic level.

Third, it presents a modular and mandatory revocation mechanism integrated into the verification process, aligned with the dynamic nature of verification outputs.

Overall, the study extends existing blockchain-based healthcare data-sharing approaches by offering a comprehensive design framework that simultaneously addresses privacy, verifiability, and governance requirements.

The proposed system provides a practical reference architecture for next-generation health information systems. It is especially suitable for scenarios—such as employer verification—where clinical data disclosure is unnecessary and data minimization is essential.

2.8. Comparison with Existing Studies

Table 1. Comparison with Existing Studies.

Study	Diagnosis-Free Verification	Revocation	Fine-Grained Access	Off-Chain Storage	Prototype
MedRec	No	No	Partial	Yes	Yes
HealthChain	No	No	Yes	Yes	Yes
ACHealthChain	No	Partial	Yes	Yes	Yes
ProposedFramework	Yes	Yes	Yes	Yes	Yes

summarizes the comparison between the proposed framework and representative blockchain-based healthcare systems. The comparison highlights that, unlike existing approaches, the proposed framework simultaneously supports diagnosis-free verification, fine-grained access control, off-chain storage, and proof revocation, thereby providing a more comprehensive privacy-preserving verification architecture.

Zero-knowledge approaches represent an alternative method for privacy-preserving verification. Although such techniques provide strong privacy guarantees, they generally require higher computational resources, more complex implementation processes, and specialized cryptographic expertise. In contrast, the proposed framework achieves privacy through architectural separation, client-side encryption, off-chain storage, and diagnosis-free verification proofs. This design prioritizes practicality and implementation simplicity while maintaining the privacy requirements of the targeted healthcare verification scenario.

3. Methodology

3.1. Blockchain

Blockchain is a distributed ledger technology used to verify and record transactions without the need for a central authority. Cryptographic hash functions and the chained block structure ensure data integrity and immutability. Each block contains the hash of the previous block. Therefore, any modification to the chain affects the entire network and can be easily detected. With these features, blockchain provides reliable data sharing not only for financial transactions but also for various sectors such as healthcare, identity management, and supply chains [35,36].

In the context of healthcare data management, blockchain technology offers a more secure, transparent, and patient-centric alternative to centralized electronic health record systems. It strengthens both data integrity and privacy protection [37,38].

3.2. Smart Contracts

Smart contracts are programmable code segments that execute automatically when predefined conditions are met on the blockchain. These contracts enable data access, verification, and recording processes to be performed automatically without requiring intermediaries. For example, smart contracts developed on the Ethereum platform provide advantages such as transparency, automation, and verifiability. They are widely used in domains such as finance, insurance, and digital identity [39]. In healthcare, smart contracts offer an effective mechanism for data access control, patient consent management, and automated verification processes. This enhances both data security and privacy [40]. Their role in patient-centric data management is increasing. However, issues such as code security, authorization design, and the correct implementation of access policies remain critical risk areas [40].

3.3. Consensus Mechanisms

Consensus mechanisms are protocols that ensure all nodes in a blockchain network agree on the current state of the system. They enable transaction validation and addition to the ledger without the need for a central authority. Common consensus protocols include Proof of Work (PoW) and Proof of Stake (PoS). These mechanisms offer different trade-offs in terms of security, energy efficiency, and scalability [41,42]. In systems such as healthcare—where high data volume, strong security, and low latency are required—the selection of consensus mechanisms must consider performance and scalability characteristics [38,43]. Balancing security, speed, and sustainability is therefore a key design consideration in blockchain-based healthcare applications [42,43]. Recent studies have continued to advance blockchain-based healthcare data management by addressing privacy-preserving data sharing, interoperability, and secure healthcare record management in distributed environments [44,45].

3.4. Proposed Architecture and System Model

This study proposes a dual-layer blockchain-based architecture designed to enable verification without exposing clinical data. The model separates clinical information from the verification process at a structural level. This separation is central to preserving privacy.

The architecture consists of two main layers: (i) Clinical Data Layer and (ii) Verification Layer. These layers interact through cryptographic references rather than direct data exchange. This design enforces strict data minimization.

3.4.1. System Overview

The proposed system involves four primary actors: patient, healthcare provider, verifier (e.g., employer), and blockchain network. The healthcare provider generates the medical report. This report includes diagnosis and clinical details. The report is encrypted and stored off-chain. Only a cryptographic hash of the report is recorded on the blockchain. This ensures integrity without exposing sensitive data. The patient acts as the data owner. The patient controls access permissions and initiates verification requests. The verifier does not access the clinical data. Instead, it receives a verification proof generated by the system. This proof confirms that a valid healthcare service was provided within a specific time interval.

3.4.2. Dual-Layer Architecture

The architecture is structured into two distinct but interconnected layers:

Clinical Data Layer: This layer stores sensitive medical data off-chain in encrypted form. It includes diagnosis, treatment details, and clinical observations. Access to this layer is strictly controlled through patient authorization and cryptographic policies.

Verification Layer: This layer operates on the blockchain. It generates and manages verification proofs without revealing clinical content. The layer stores hashes, timestamps, and proof-related metadata.

The two layers are linked through hash references. However, no raw clinical data is exposed during verification. This ensures a clear functional separation.

3.4.3. Diagnosis-Free Verification Mechanism

The core innovation of the system lies in the diagnosis-free verification mechanism. In this approach, verification is performed without disclosing any diagnosis or underlying medical content. Instead, the system generates a verifiable cryptographic proof that confirms the authenticity of the medical report, the identity of the issuing healthcare provider, and the validity period of the healthcare service.

This proof is created using cryptographic techniques and securely recorded on the blockchain through smart contracts. During the verification process, the verifier interacts only with this proof and does not access any clinical data. As a result, the mechanism effectively minimizes unnecessary data exposure while preserving both privacy and verifiability.

3.4.4. Smart Contract Design

Smart contracts coordinate all key processes within the system, including access authorization, proof generation, verification requests, and revocation operations. Each transaction is recorded in an immutable and auditable manner, ensuring transparency and traceability.

These smart contracts enforce predefined rules and guarantee that only authorized actors can initiate specific operations. The overall design follows a modular structure. This approach improves scalability. It also enhances maintainability.

3.4.5. Revocation Mechanism

The system integrates a mandatory and modular revocation mechanism.

Verification proofs are not permanently valid. They can be revoked in cases such as expiration, error, or withdrawal of consent. Revocation status is recorded on the blockchain. This allows verifiers to check the current validity of any proof in real time. The mechanism operates as part of the verification layer. It ensures that outdated or invalid proofs cannot be reused. This dynamic control is essential for real-world applicability.

In the current prototype, revocation becomes effective immediately after the corresponding transaction is confirmed on the blockchain. Therefore, each verification request evaluates the latest revocation status before returning a validation result. Potential confirmation delays and time-window attacks in large-scale public blockchain environments were considered outside the scope of the present prototype and represent an area for future investigation.

3.4.6. Workflow of the System

The system operates through the following steps:

• The healthcare provider generates a medical report;
• The report is encrypted and stored off-chain;
• A hash of the report is recorded on the blockchain;
• The patient initiates a verification request;
• A diagnosis-free proof is generated via smart contracts;
• The verifier checks the proof on the blockchain;
• If necessary, the proof can be revoked dynamically.

Each step is traceable. Yet sensitive data remains protected.

3.4.7. Design Principles

The proposed architecture is built upon the following principles:

• Data Minimization: Only essential verification data is shared;
• Privacy-by-Design: Clinical data is never exposed during verification;
• Decentralized Trust: Blockchain ensures transparency and integrity;
• User Control: Patients retain full control over their data;
• Revocability: All verification outputs can be dynamically invalidated.

These principles collectively ensure a secure, scalable, and privacy-preserving system.

4. Application

The starting point of this study is the problem of excessive data disclosure that arises when medical reports are shared with third parties for verification purposes. To address this issue, a privacy-oriented and verifiable system has been designed, in which clinical data and the verification process are structurally separated.

The research process consists of four main stages: problem identification, architectural design, prototype development, and scenario-based evaluation. This process aims to demonstrate both the theoretical and technical feasibility of the proposed system.

4.1. Research Design

This study focuses on designing a system that balances the tension between the need for medical report verification and the protection of patient privacy.

In particular, the conflict between the requirement to verify healthcare service utilization by third parties (e.g., employers) and the need to preserve the confidentiality of diagnosis and clinical details is addressed within a blockchain-based architectural framework.

Accordingly, the key design requirements (DRs) guiding the system are defined as follows:

DR1—Clinical Privacy: Diagnosis and clinical details must never be shared with employers or other third parties.

DR2—Verifiability: Authorized entities must be able to reliably verify that an individual received healthcare services within a specific time interval.

DR3—Access Control: Access to clinical reports must be restricted to healthcare professionals explicitly authorized by the patient, and such access must be time-bound.

DR4—Revocation: Incorrect, outdated, or withdrawn verification proofs must be revocable and considered invalid in subsequent verification processes.

DR5—Auditability: Data sharing and verification processes must be transparent and traceable, enabling retrospective audits.

DR6—Scalability and Cost: Large healthcare data should not be stored on-chain. On-chain data usage must be minimized to optimize transaction costs.

In addition to these design requirements, the proposed framework is designed to satisfy four core security objectives: confidentiality of clinical data, integrity of stored records and verification proofs, authenticity of issued proofs, and revocability of previously generated verification outputs.

The overall research workflow is illustrated in Figure 1.

The proposed approach goes beyond a purely conceptual model. It also demonstrates technical feasibility and effectiveness through practical usage scenarios.

Thus, the study provides both a theoretical framework and an implementable solution for privacy-preserving healthcare data verification systems.

4.2. System Architecture

The proposed system architecture is developed based on a privacy-oriented design and is built upon two structurally separated workflows: the clinical data layer and the verification proof layer.

This separation ensures that sensitive clinical information and third-party verification requirements are handled independently. It directly enforces data minimization at the system level.

The overall architecture and the separation between these two flows are illustrated in Figure 2.

The system follows a multi-layered architectural approach consisting of a frontend, a backend, smart contracts, and an IPFS-like distributed storage layer. This layered design improves modularity. It also enhances security and scalability. All data flows and verification processes are executed within a role-based system.

4.2.1. Clinical Data Layer

This layer governs the interaction between the patient and the doctor (Figure 3). A medical report created by the doctor is uploaded to the system by the patient. The report is encrypted on the client side using a strong symmetric encryption algorithm (e.g., AES-GCM). The encrypted data (ciphertext) is stored in an off-chain storage system such as IPFS. Only a reference to the data is recorded on the blockchain. The patient can grant time-limited access to authorized doctors when needed. This approach prevents direct storage of clinical data on-chain. It increases security and reduces costs.

4.2.2. Verification Proof Layer

This layer manages diagnosis-free verification between the patient and third-party verifiers. Upon a verification request initiated by the patient, a unique proofId is generated. An authorized entity (issuer) then produces a verification proof that does not disclose clinical data. The verifier checks this proof. The result is presented using minimal information (e.g., valid/invalid). Previously generated proofs can also be revoked when necessary. Revoked proofs are automatically treated as invalid during verification. The detailed workflow of this process is illustrated in Figure 4.

The system is built around four main roles:

• Patient (holder): Manages encryption, data references, and access permissions;
• Doctor: Generates medical reports and accesses encrypted data when authorized;
• Issuer: Produces and revokes verification proofs;
• Verifier: Checks proof validity without accessing clinical data.

This role-based structure ensures strict separation of responsibilities.

4.3. Cryptographic Workflow

Privacy in the proposed system is ensured through a two-layer cryptographic workflow. The overall process is illustrated in Figure 5.

The doctor accesses the report through a two-step process. First, the wrapped symmetric key is decrypted using the doctor’s private key. Second, the ciphertext is decrypted using the obtained symmetric key. At no stage do storage providers or third parties gain access to the plaintext. This two-layer cryptographic design ensures strong data confidentiality. It also provides controlled access to authorized entities only. In addition, it achieves efficient performance through the use of symmetric encryption.

4.3.1. Layer 1—Client-Side Encryption

The medical report is encrypted on the client device using a symmetric key and the AES-GCM algorithm. A unique initialization vector (IV) is generated for each encryption process to ensure semantic security and prevent reproducibility. The output is ciphertext only. Plaintext is never shared with backend services or storage providers. The encrypted data is uploaded to IPFS, while the plaintext remains entirely on the client side. This provides strong end-to-end confidentiality.

4.3.2. Layer 2—Secure Key Sharing

The symmetric key is securely shared using asymmetric cryptography (key wrapping). In the prototype, this is implemented using ECDH (secp256k1) to derive a shared secret, followed by AES-GCM encryption. Thus, the symmetric key generated by the patient can only be decrypted by the authorized doctor.

4.4. Smart Contract Design

The proposed architecture consists of four core smart contracts designed in accordance with the principles of data minimization and modularity. This modular structure enables a clear separation of system components. It also provides significant advantages in terms of security, scalability, and manageability. The overall modular contract architecture and the relationships between components are illustrated schematically in Figure 6.

Figure 1, Figure 2, Figure 3, Figure 4, Figure 5 and Figure 6 were generated from the implemented prototype architecture and represent the actual workflow and component interactions realized during prototype development.

The first contract, ReportAccess, manages on-chain references to encrypted health reports belonging to patients. For each report, a unique reportId is recorded together with a cidHash value based on a content-addressing mechanism, and the identity of the data owner is defined. In addition, access permission is granted to authorized healthcare professionals, such as physicians, for a limited period. The encrypted key required for access is stored securely within the contract. This design strengthens access control. It also prevents the direct sharing of sensitive data.

The second contract, IssuerRegistry, governs the actors authorized to generate verification proofs. This contract operates based on an allowlist mechanism, ensuring that only authorized institutions or addresses can produce valid proofs within the system. As a result, the reliability of generated proofs is increased. Unauthorized interventions are also effectively prevented.

The third contract, RevocationRegistry, is designed to monitor and manage the validity status of issued verification proofs. It maintains whether each proof has been revoked and enforces mandatory verification of this status during the validation process. This mechanism plays a critical role in preserving the timeliness and reliability of verification results, especially in scenarios where health conditions may change over time.

The fourth contract, VisitProof, performs the core verification function of the system. It enables the generation of diagnosis-free proofs that do not reveal clinical information. The contract stores only the minimum required metadata on-chain and interprets verification outputs. It also integrates authorization checks through IssuerRegistry and revocation checks through RevocationRegistry in a unified manner. This ensures that the verification process is both secure and coherent.

Through this modular smart contract architecture, only reference data, access permissions, authorization information, and verification or revocation statuses are stored on the blockchain. In contrast, the actual content of health reports, clinical findings, diagnoses, and other sensitive data remain entirely off-chain. This approach effectively enforces the principle of data minimization. It also reduces on-chain data load and transaction costs. Consequently, the proposed smart contract design provides a balanced and practical solution that simultaneously ensures privacy, security, and system efficiency.

4.5. Implementation Environment

The prototype of the proposed system was implemented in a local development environment using a monorepo architecture to ensure reproducibility and modular development. In this approach, multiple components of the system are maintained within a single repository, allowing consistent version control and integration. The on-chain components were developed using the Solidity programming language and deployed on a Hardhat-based local blockchain network, which enabled rapid smart contract testing, efficient debugging, and controlled scenario evaluation.

The off-chain components were designed following a service-oriented architecture. The backend layer consists of application services built with Node.js and Express, which manage communication between the client interface and the blockchain layer. The frontend was developed using React and Next.js, providing a user-friendly interface for interacting with the system. This overall setup ensures flexibility, modularity, and ease of future system expansion.

The prototype was fully executed within a local blockchain environment using Hardhat. The purpose of this implementation was to validate functional correctness, smart contract interaction, and workflow feasibility. Public testnet deployment was intentionally excluded from the current study because the focus was architectural validation rather than production deployment. Nevertheless, the modular design of the system enables straightforward migration to public or permissioned blockchain environments in future work.

Table 2. Prototype Development Environment.

Component	Configuration
Operating System	Windows 11 Pro 23H2
Node.js	v20.18.0
Hardhat	v2.22.18
Solidity	v0.8.28
React	v18.3.1
MetaMask	v11.16.17
Local Blockchain	Hardhat Network
Storage	Local Off-chain Storage
Smart Contracts	4
Network Type	Local Development Network

summarizes the hardware and software environment used during prototype development. The objective of providing these details is to improve transparency and facilitate future reproduction of the implementation.

Representative screenshots captured directly from the implemented prototype are provided in Appendix A.1, Appendix A.2 and Appendix A.3, illustrating the patient, doctor, issuer, and verifier interfaces used throughout the evaluation.

4.6. Evaluation Procedure

The proposed system was evaluated through a scenario-based functional validation approach designed to assess whether the architecture meets its intended design goals. Within this framework, multiple use-case scenarios were constructed to represent real-world interactions and system workflows. These scenarios enabled a systematic analysis of both the clinical data handling processes and the diagnosis-free verification mechanism.

In the first scenario, the interaction between the patient and the doctor within the clinical data layer was examined. A medical report created by a physician is first transferred to the patient, who then encrypts the report on the client side and uploads it to the off-chain storage layer. Only the reference data is recorded on the blockchain, and the patient defines time-limited access permissions for a specific doctor. This scenario demonstrates that client-side encryption, secure key sharing, and access control mechanisms function cohesively.

In the second scenario, the verification layer is evaluated by focusing on how diagnosis-free proofs are generated and validated. Authorized institutions produce cryptographic proofs that confirm the authenticity of a report without exposing clinical details. Third parties can verify these proofs using limited metadata, thereby ensuring that verification is achieved without compromising patient privacy.

From a security and privacy perspective, the system was analyzed based on key criteria such as confidentiality, data minimization, access control, revocability, and auditability. The results indicate that confidentiality is ensured through end-to-end encryption performed on the client side, where clinical data is never exposed in plaintext to any external component. The use of symmetric encryption combined with asymmetric key wrapping guarantees that only authorized parties can access the data.

Furthermore, the system strictly enforces data minimization by eliminating the need to disclose diagnosis information during verification. Access control mechanisms ensure that permissions are explicitly defined and enforced, while revocation capabilities allow dynamic invalidation of previously issued proofs. Auditability is achieved through immutable blockchain records, which provide transparency and traceability of all system actions.

In addition, a comparative evaluation with existing blockchain-based healthcare systems highlights the distinct contribution of the proposed architecture. Unlike many existing approaches that require partial disclosure of clinical data, this system achieves verification without exposing sensitive information by structurally separating data storage and verification processes. The inclusion of a comprehensive revocation mechanism and fine-grained access control further strengthens its position compared to prior work.

4.6.1. Prototype-Level Quantitative Assessment

Table 3. Prototype-Level Quantitative Implementation Characteristics.

Metric	Prototype Result
Smart Contracts	4
Blockchain Platform	Hardhat Local Network
Encryption Algorithm	AES-GCM
Key Exchange	ECDH (secp256k1)
Report Storage	Off-chain
On-chain Data	Hash + Metadata
Verification Output	Proof ID + Status
Revocation Support	Yes

presents the principal implementation characteristics of the proposed prototype, including the blockchain environment, cryptographic mechanisms, storage strategy, and verification capabilities. While the study does not aim to provide large-scale performance benchmarking, the information reported in Table 3 demonstrates that the architecture is operational and functionally complete at the prototype level. In particular, the off-chain storage of medical reports combined with the on-chain storage of only hashes and metadata contributes to lower blockchain overhead and improved scalability potential.

The primary objective of the present study is architectural validation rather than performance benchmarking. Consequently, detailed measurements such as gas consumption, encryption latency, and transaction throughput were not considered within the scope of the prototype evaluation and are identified as future research directions.

4.6.2. Security Analysis

Table 4. Security Threats and Corresponding Mitigation Mechanisms.

Threat	Mitigation
Unauthorized Data Access	Client-side encryption
Data Tampering	Blockchain hash verification
Unauthorized Verification	IssuerRegistry
Replay of Invalid Proofs	RevocationRegistry
Insider Exposure	Diagnosis-free verification

presents the primary threat scenarios considered within the scope of the proposed framework and the corresponding mitigation mechanisms. The analysis demonstrates that the architecture addresses key security and privacy risks through a combination of cryptographic protection, blockchain-based integrity controls, authorization management, and proof revocation capabilities. In particular, diagnosis-free verification minimizes the exposure of sensitive clinical information, while blockchain-based verification and revocation mechanisms strengthen trustworthiness and auditability throughout the verification lifecycle.

The security assumptions of the proposed framework follow an honest-but-curious threat model. It is assumed that blockchain observers, storage providers, and third-party verifiers may attempt to infer information from accessible data but do not possess the cryptographic keys required to decrypt medical reports. Furthermore, unauthorized entities may observe on-chain transactions; however, only hashes and verification-related metadata are stored on-chain. Under these assumptions, confidentiality is preserved through client-side encryption, integrity is ensured through blockchain-based hash verification, and authenticity is enforced through authorized proof issuance mechanisms.

The current evaluation focuses on architectural security analysis rather than attack simulation. Consequently, formal penetration testing, adversarial simulations, and smart-contract vulnerability assessments were not included within the scope of the prototype implementation. These aspects represent important directions for future validation studies.

4.7. Methodological Scope and Limitations

The methodological framework presented in this study is based on a prototype system developed to demonstrate the technical feasibility of a privacy-preserving healthcare data sharing model with diagnosis-free verification. The proposed architecture is functionally operational and satisfies the core design requirements at the level of a minimum viable product.

However, certain limitations arise from the prototype-based nature of the implementation. Although the storage layer is designed to be compatible with distributed file systems such as IPFS-like infrastructures, the current implementation relies on a simulated storage mechanism rather than a fully deployed distributed environment. Similarly, asymmetric key management and sharing processes are implemented within a controlled local testing setup instead of being integrated into a production-level cryptographic wallet infrastructure. The prototype was evaluated in a local development environment and therefore does not provide performance measurements for multi-node IPFS deployments. Metrics such as upload latency, retrieval latency, and cross-node availability remain subjects for future experimental investigation.

From a regulatory perspective, blockchain immutability may create challenges regarding the “right to be forgotten” defined in certain data protection frameworks. In the proposed architecture, only hashes and verification-related metadata are recorded on-chain, while medical reports remain off-chain and can be deleted or rendered inaccessible when required. This design minimizes the amount of persistent information stored on the blockchain while preserving verification capabilities.

These constraints limit the direct generalizability of the system to large-scale, real-world deployments. Nevertheless, the prototype successfully demonstrates the conceptual validity and technical applicability of the proposed approach, providing a strong foundation for future development and real-world implementation.

Furthermore, the study adopts AES-GCM and ECDH based on their widespread use and established security properties. Comparative evaluations involving alternative encryption algorithms, key lengths, and initialization vector configurations were considered outside the scope of the present prototype and constitute a potential area for future research.

In addition, the prototype was not evaluated under large-scale concurrent workloads. Therefore, response latency, throughput, and service availability under high-demand scenarios remain open research questions requiring future scalability studies.

5. Conclusions and Recommendations

This study addresses the challenge of verifying medical reports while preserving patient privacy. Unlike many existing approaches that require partial disclosure of clinical information during verification, the proposed blockchain-based framework enables diagnosis-free verification through a clear separation between clinical data management and verification processes.

The framework combines client-side encryption, off-chain storage, role-based access control, and modular smart contracts supporting authorization, proof generation, and revocation. By storing only hashes and verification-related metadata on the blockchain, the architecture supports data minimization while maintaining integrity, traceability, and auditability.

A prototype implementation was developed to demonstrate the feasibility of the proposed approach. The scenario-based evaluation confirmed that diagnosis-free verification, controlled access management, and proof revocation can be integrated within a unified architecture. The framework therefore provides a practical architectural foundation for privacy-preserving healthcare verification scenarios involving third-party entities such as employers.

Several limitations should be acknowledged. The prototype was evaluated in a controlled local environment, and some components, including distributed storage integration and advanced key management, were implemented at a proof-of-concept level. Consequently, the present work should be viewed as a prototype-based architectural validation study rather than a production-ready healthcare platform.

Future research should focus on deployment in permissioned or public blockchain environments, large-scale performance evaluation, interoperability with healthcare information systems, and integration with decentralized identity (DID) technologies. Such developments would further strengthen the practical applicability of the proposed framework.

Overall, the study contributes to the growing body of research on privacy-preserving healthcare data sharing by introducing a diagnosis-free verification model that balances verifiability, privacy, and governance requirements within a single architectural framework. Future developments may also incorporate decentralized identity (DID) and verifiable credential (VC) technologies to strengthen the linkage between blockchain accounts and real-world identities while improving interoperability with existing healthcare information systems.