Secure, scalable, and interoperable healthcare data exchange using layer-2 ZK-rollups, smart contracts, and IPFS

Abstract

Data transactions in healthcare are steadily increasing across various platforms, aiming to improve patient care and increase data transparency. Blockchain technology will serve as a catalyst in healthcare data transactions, ensuring data security and privacy for various stakeholders. Improving data security, transparency, and interoperability, blockchain technology’s application in healthcare has demonstrated considerable promise. However, healthcare applications that rely on real-time data transaction settlement face obstacles caused by Layer1 blockchains’ poor transaction throughput and excessive latency. In this work, we adopt established consensus and a zk-Rollup verification workflow, specifying healthcare-oriented configurations for security, auditability, and throughput. This paper integrates the smart contracts, zero knowledge proof and off chain data storage to increase the efficiency, and security and reduce transaction costs. The usefulness of the suggested algorithm in healthcare applications is demonstrated by thorough literature research, comparative analysis, and experimental data. Transaction throughput increases very high, latency improved by 57%, and decrease the transaction cost to 96% in healthcare data transactions which are all greatly improved by the proposed system. Unlike existing zk-Rollup–based healthcare frameworks, the proposed model integrates cross-chain identity validation and verifiable data provenance to achieve secure interoperability across multi-chain healthcare systems.

Introduction

The demand for the online healthcare services has been increasing and different methods have been designed for sharing health data among different healthcare organizations in today’s scenario. This process needs to be provided with the integrity, transparency, security, and privacy of the healthcare data for better and secure healthcare services¹. The traditional healthcare system is centralized and has data security and privacy risks. As the large data is used in the healthcare industry, issues such as privacy, security, and much more arise. To improve these issues, blockchain technology plays an important role².

Background on blockchain

Blockchain is a decentralized and distributed ledger technology that store transactions in the network in a transparent, secure, and temper proof manner. Each record is stored in a block which has a hash value for the data and forms a chain. Each block contains the hash of the previous block, data, and timestamp to create the hash of the current block as shown in Fig. 1. Due to these features, blockchain has several use cases such as cryptocurrency for example, Bitcoin and Ethereum, supply chain, healthcare, smart contracts, etc^1,2,4.

Fig. 1.

Hash in a blockchain.

As shown in Fig. 2, blockchain may be categorized into four types: public blockchain, private blockchain, consortium blockchain, and hybrid blockchain. A public blockchain is decentralized and transparent and allows any user to participate in the network for transactions. It provides high privacy and security but has low efficiency and consumes high energy. A private blockchain is controlled by a single authority, only authorized ones can join the network for transactions. It provides high processing speed and privacy but is less transparent and centralized^1,3,7. A consortium blockchain is controlled by the group of organization, and provide the benefits of decentralization with controlled access. And a hybrid blockchain provides the combined features of public and private blockchains, allowing some information to be public and secure sensitive data private.

Fig. 2.

Types of blockchain.

Two tiers of blockchain architecture are represented by Layer 1 and Layer 2 blockchains, each of which has a specific function within the ecosystem. The base blockchain network, like Solana, Ethereum, or Bitcoin, is referred to as Layer1 which use consensus techniques like proof of work or proof of stake to preserve decentralization, security, and data integrity. However, particularly during periods of high usage, they frequently encounter scalability issues, such as slow transaction speeds and expensive fees.

A secondary framework constructed on top of a layer 1 blockchain known as layer 2 blockchain. To lessen base layer congestion, it either bundles or processes transactions off the main chain. For security reasons, the processed data is recorded back onto the layer 1 blockchain. The common examples of layer 2 technology are rollups, sidechains, and the lightning network for Bitcoin. While maintaining the integrity of the underlying layer 1 blockchain, these methods greatly boost speed, reduced transaction costs, and enhance scalability.

Problem statement

To improve data security, transparency, and interoperability, blockchain technology’s application in healthcare has demonstrated considerable promise²⁵. However, healthcare applications that rely on real-time data transaction settlement face challenges caused by layer-1 blockchains’ poor transaction throughput and excessive latency. In this work, we adopt Ethereum PoS at Layer-1 for settlement and data availability and zk-Rollups at Layer-2 for scalable execution. To overcome the weaknesses of Layer-1 blockchains, the suggested method makes use of Layer-2 solutions’ efficiency and scalability, and data storage is managed by use of IPFS. IPFS is a distributed file system that is designed to change the method of storage and transmission on the network. The basic concept is to store files in bunch and generate a hash for it, and these hashes are used as an address for the files instead of file paths. The usefulness of the suggested algorithm in healthcare applications is demonstrated by thorough literature research, comparative analysis, and experimental data. Transaction throughput, latency, and data security in real-time healthcare data transactions are all greatly improved by the suggested consensus algorithm, according to the results.

Personal health information, including a patient diagnosis and treatment plans, is stored in healthcare records. The patient data is shared among medical professionals, the patient’s former hospital, or both when the patient transfers to a new hospital for better treatment. So, data privacy is a thing of the past. This requires safeguards to ensure the confidentiality and integrity of patient data. For this reason, healthcare organizations should adhere to certain rules and security restrictions whenever they transmit patient data^5,9. As the healthcare data is continuously growing, data size is also growing and a centralized data storage system has a risk of data breach^22,26. The healthcare business relies heavily on blockchain technology due to its resilient and immutable nature, which safeguards data transactions and ensures privacy and security. Each transaction in a blockchain is recorded in an immutable and decentralized ledger that cannot be altered by any node in the chain. Cryptographic algorithms encrypt every transaction and convert it into a hash function with a different value. Each time a transaction is recorded in the blockchain, a computing job called mining is performed. The node that completes the task first gets rewarded. If most nodes in the network do not agree that a transaction is legitimate, then the transaction is rejected. Blockchain can provide the foundational infrastructure needed to manage assets and healthcare transactions. Integrating the new technologies raises several research questions, such as those pertaining to hardware, security, and the demands placed on computer resources and networks.

The necessity for a safe, scalable, and real-time data handling infrastructure is growing in the healthcare industry as digital solutions are being used more to enhance patient care and operational efficiency^1,5. While decentralization and immutability are great features of traditional Layer-1 blockchains, their high latency and low transaction throughput make them unfit for use in real-time healthcare^23,28,29. There is more potential to improve data privacy, transaction efficiency, and cost-effectiveness by utilizing layer-2 technologies like roll-up protocols along with off-chain storage (IPFS), smart contracts, and zero-knowledge proofs^24,27. The main goal of this research is to close the gap between the theory and practice of blockchain technology in healthcare so that patient can benefit from secure, more efficient, and cheaper data transfer.

The necessity for the settlement of data transactions in real-time is the primary barrier to the implementation of blockchain technology in healthcare. When it comes to healthcare applications like EHR operation, and medical supply chain tracking, traditional Layer-1 blockchains generally cannot handle it^26,31. These applications demand extremely low latency and high throughput^21,30. This study presents a solution to this problem by suggesting a consensus method that is tailored to settle data transactions in real-time on Layer-2 blockchains using roll-up-based technology. Merkel tree based on blockchain that stored a huge amount of data in a tree structure after verification of the data to integrate it without any download of the entire data set. A Merkel tree is used to hash the data and link the hashes combinedly to form a tree structure in a way that every node contains the hash values of their child nodes. So, the root node has the hash of all data sets and a small change in any data changes the hash value. It helps in maintaining the integrity of the data and it is easily verified by the comparison of the root nodes of two Merkel trees. If both the roots have the same hash value, then they represent the same data.

The main contribution of this work is summarized as follows:

1. The ZK rollups based blockchain for efficient patient data sharing is proposed in this paper.

2. IPFS is used for off-chain data storage and combines layer1 and layer2 blockchains for efficient and secure data transactions among patients, hospitals, and insurers to reduce the transaction cost in the network.

3. Evaluate the performance of the algorithm using simulated and real healthcare data and compare the pre-existing methods and layered blockchain solutions.

The novelty of this research lies in combining zk-Rollup scalability with blockchain-based identity and provenance management to facilitate multi-chain healthcare interoperability. Unlike Ma & Zhang (2024) and Datta & Namasudra (2024), who focus on transaction efficiency and privacy, this study extends zk-Rollup principles to cross-network interoperability and regulatory auditability.

As summarized in Table 1, prior works such as^19,23 investigate blockchain-based healthcare data sharing and, in some cases, integrate IPFS or sidechains. Our work addresses all three aspects in a unified architecture and provides an end-to-end prototype and evaluation.

Table 1.

Comparison of prior work with proposed work.

Feature/aspect	19	23	Proposed work
L2 rollup-based scalability for healthcare transactions	×	×	✓
Integration of IPFS for off-chain encrypted record storage	✓	×	✓ (with access control + audit trail)
Cross-chain interoperability for multi-institution access	×	✓ (limited to same ecosystem)	✓ (supports heterogeneous chains)
Support for intergenerational / longitudinal health data	×	×	✓
Formal security model for data exchange + rollup fraud	×	×	✓
Prototype implementation + empirical evaluation (throughput/latency/cost on L2)	×	×	✓

The paper is organized as follows. The related work is discussed in Sect. 2. The proposed methodology and consensus algorithm is given in Sect. 3. Experimental analysis and proposed work are discussed in Sect. 4. Discussion is given in Sect. 5. Finally, Sect. 6 concludes the paper.

Related work

The introduction of Bitcoin in 2008 marked the emergence of blockchain technology (Nakamoto, 2009). Blockchain technology allows for a decentralized database. The authors, Zibin et al., focused on the consensus method and blockchain architecture, and possible future trends. The use of blockchain technology is growing in various industries, including the financial sector, supply chain management, the Internet of Things, etc.,

Research on blockchain in healthcare has progressed from basic feasibility studies to increasingly scalable and privacy-preserving designs. A complete layered-blockchain architecture for health data transmission was demonstrated in⁵, showing that secure data sharing is possible but still effected by network throughput. A service-oriented healthcare model using blockchain for epidemic data coordination was proposed in⁶, although interoperability across diverse healthcare systems remain limited. A broader review of blockchain applications in clinical research noted advantages in accountability and traceability but also highlighted regulatory and protocol standardization challenges⁸. Likewise¹⁰, emphasized that legal and compliance considerations must be integrated into system architecture from the outset.

To address performance limitations, several studies have examined Layer-2 scaling techniques. A patient-centric data management model using layer 2 blockchain showed enhanced throughput and lower processing cost in¹¹. Privacy-preserving data sharing using zk-rollups was demonstrated in¹², providing strong privacy guarantees with scalability. Similarly, decentralized clinical trial workflows supported by optimism roll-ups were explored in¹³, with notable reduction in processing delays.

Blockchain-based EHR frameworks have also been proposed to strengthen patient data control and integrity¹⁴, while state-channel-based real-time monitoring systems in¹⁵ focused on improving latency. In the insurance domain, plasma-based claims processing showed transparent and faster settlement in¹⁷. Consent-aware genomic data sharing was examined in¹⁸, while a smart-contract-based EMR sharing framework integrating mobile-edge computing was presented in¹⁹. A permission-controlled EHR model was further designed in²⁰. The zk-Rollups using IPFS were used to enhance privacy and scalability in healthcare data exchange systems²³. With these advancements, existing solutions still face challenges in cross-institution identity management, unified access control, and practical deployment scalability, which the proposed system aims to address.

To keep blockchain networks safe and secure, consensus techniques are needed. Layer-1 blockchains have traditionally made extensive use of traditional consensus algorithms like Proof-of-Work (PoW) and Proof-of-Stake (PoS). Unfortunately, as Fig. 3 shows different issues in layer1 blockchain such as the poor throughput and significant latency of these systems make them unfit for real-time data transaction settlement. To overcome these restrictions, various alternative consensus algorithms have been suggested, including Delegated Proof-of-Stake (DPoS) and Practical Byzantine Fault Tolerance (PBFT). Applications associated with healthcare, like electronic health record management and telemedicine, rely on the settlement of data operations in real time. Several studies have investigated blockchain’s potential for real-time transaction settlement; nevertheless, a major obstacle is the performance and scalability issues with Layer-1 blockchains¹¹. When it comes to healthcare applications, layer-2 solutions, especially roll-up-based technology, provide a potential way to allow real-time transaction settlement.

Fig. 3.

Issues in layer1 blockchain in healthcare data transaction.

This paper proposes a framework which is decentralized, secure and scalable. The result analysis shows that the space and time complexity of the framework is reduced as compared to blockchain solutions. The paper shows that the efficiency of the proposed model is increased. The proposed model is based on the distributed, integrated and accessibility of the blockchain. As shown in Table 2, The results, limitations, and research gaps of some references are given, which shows that existing systems have some issues in various factors. Some of them reduce the transaction cost and increase the efficiency but they have issue in the use of blockchain completely.

Table 2.

Limitations and research gap of related work.

References	Work done	Key results	Limitations identified	Research gap
5	Introduced a layered blockchain architecture to support Health Information Exchange (HIE) and clinical trial recruitment.	Demonstrated an average exchange time of 11.27 s and showed that blockchain can streamline HIE workflows.	System scalability is constrained by Ethereum Layer-1 limitations.	Requires validation under real-world healthcare workloads and larger patient populations.
6	Developed ssHealth, a blockchain-based system for secure medical data exchange and epidemic monitoring.	Enabled secure data transfer among healthcare entities for outbreak management.	Interoperability across international health systems remains difficult.	Need for integration strategies with existing hospital information infrastructures.
8	Reviewed blockchain adoption in clinical trials with emphasis on transparency and traceability.	Showed benefits such as improved auditability and participant engagement.	Regulatory barriers and inconsistent standards hinder adoption.	Need for standardized regulatory frameworks for blockchain-enabled trials.
10	Examined GDPR compliance issues for blockchain applications in healthcare.	Highlighting several proof-of-concept systems partially satisfy GDPR requirements.	Compliance still depends on system design choices; deletion and rectification remain difficult.	Development of blockchain platforms with built-in GDPR-aware mechanisms.
11	Demonstrated that Layer-2 solutions such as Polygon enhance scalability in patient data systems.	Reduced operating costs and achieved higher throughput than Layer-1 models.	Security and finality still depend on the Layer-1 settlement layer.	Exploration of more autonomous Layer-2 frameworks with lower dependence on Layer-1 constraints.
12	Evaluated the use of zk-Rollups to improve privacy and scalability in healthcare data sharing.	Achieved stronger privacy guarantees and higher throughput.	Implementation complexity and compatibility with hospital systems remain challenges.	Need for simplified and user-friendly zk-Rollup deployment models.
13	Applied Optimism Layer-2 to speed up clinical research data recording.	Obtained faster data recording and significant cost reductions.	Technology is still evolving and has limited adoption in clinical environments.	Field studies are needed to evaluate adoption in real clinical trial pipelines.
14	Designed a blockchain-based EHR system ensuring data integrity and patient control.	Improved integrity and patient oversight of health records.	Limited scalability when data volume increases.	Need for scalable architectures capable of supporting long-term EHR growth.
15	Explored the use of state channels for real-time health monitoring data exchange.	Achieved lower latency and reduced fees for continuous data streams.	Off-chain transactions introduce security concerns if channels are compromised.	Development of more robust security protocols for off-chain channel operations.
17	Used the Plasma Layer-2 model to accelerate health insurance claims processing.	Improved processing speed and transparency in insurance workflows.	Integration with traditional insurance systems remains complex.	Need for standardized integration interfaces and legacy system support.
18	Implemented a blockchain framework for secure, consent-based genomic data sharing.	Provided controlled access and improved sharing within research communities.	Ethical and privacy concerns remain significant for genomic datasets.	Establish ethical standards and stronger privacy-preserving methods for genomic data.
19	Built an EMR sharing system using MEC, IPFS, and PoA consensus with multiple encryption schemes.	Delivered faster transactions and automated lifecycle management through smart contracts.	Strong reliance on hospital-operated validators may limit scalability.	Requires evaluation across multi-hospital ecosystems and design of cross-institution identity mechanisms.
20	Proposed “Health Chain,” a permissioned EHR system with timed smart contracts and RSA-based encryption.	Achieved 92–98% efficiency in performance metrics and demonstrated strong security.	Centralized indexing introduces bottlenecks; complex key handling reduces usability.	Research needed on lightweight cryptographic schemes and simplified key management.
23	Designed a privacy-focused framework using blockchain, zk-Rollups, and IPFS.	Improved gas efficiency, privacy features, and storage performance over centralized models.	Smart contract integration remains incomplete; TPS remains low for real-time needs.	Need for dynamic access control mechanisms and improved throughput for real-time healthcare operations.

The most approaches either rely on layer 1 blockchains with high transaction costs or adopt layer 2 methods without fully addressing identity management, cross-institution interoperability, or metadata update efficiency. Several systems improve scalability but lack robust privacy controls or dynamic consent management. Others enhance security but remain difficult to integrate into existing hospital infrastructures. Very few works combine verifiable off-chain computation, decentralized storage, and an efficient update mechanism within a unified architecture. These gaps directly motivate the proposed system, which integrates ZK-Rollups, content-addressed off-chain storage, and index-based metadata management to achieve scalable, privacy-preserving, and interoperable healthcare data exchange.

Research questions, hypotheses and assumptions

Research questions

• whether Layer-2 rollups can provide the required scalability and transaction cost reductions for healthcare workloads,

• whether off-chain encrypted storage combined with on-chain metadata can ensure confidentiality and integrity under realistic adversarial conditions, and.

• whether the proposed design can support interoperability across multiple healthcare institutions without duplicating data.

Hypotheses

For each research question, corresponding hypotheses predict that:

• Layer-2 execution will significantly reduce latency and cost while maintaining correctness through validity proofs.

• Encrypted IPFS storage with blockchain-anchored references will preserve data confidentiality and auditability, and.

• The metadata-driven interoperability mechanism will allow multi-institution sharing with consistent verification across domains.

Assumptions

The explicit system assumptions, including:

• security of cryptographic primitives,

• reliability of Layer-1 PoS finality,

• partial honesty of at least one rollup verifier,

• untrusted but content-addressed IPFS storage, and.

• healthcare institutions act as regulated but potentially curious participants.

• These assumptions clarify the operational boundaries and the security model of the study.

Proposed methodology and consensus algorithms

Using roll-up-based technology on Layer-2 blockchain, the suggested consensus algorithm is meant to provide real-time data transaction settlement in healthcare applications. The approach overcomes Layer-1 blockchain constraints by using Layer-2 scalability and efficiency. For data storage IPFS is used which allow a distributed file system and stores the files with a hash value which increase sharing efficiency and reliability. We rely on Ethereum PoS for Layer-1 final settlement and data availability, and standard rollup verification for Layer-2 batching. No modifications to the underlying consensus algorithms are introduced. The main elements of the suggested approach are.

Off-chain transaction processing

Using ZK-roll-up-based technology, transactions are handled off-chain by aggregating several transactions into a single batch and sending them to the underlying blockchain for final settlement. If there is any change in the state of the patient data, it reflects directly on the chain. A ZK rollup functions by integrating multiple transactions off-chain and then validating these transactions through a zero-knowledge proof, commonly utilizing either a SNARK or STARK. The rollup preserves a representation of the blockchain’s state, including user balances and smart contract storage, structured as a Merkle tree, with each leaf representing a distinct account or data point. Upon executing a transaction, such as a fund transfer, the rollup operator modifies the corresponding leaves in the Merkle tree to indicate the updated balances. This produces a new Merkle root that signifies the revised state of the rollup. The rollup produces a zero-knowledge proof to verify the validity of the complete batch of transactions and the associated state transition from the previous Merkle root to the subsequent one, thereby ensuring privacy and security. The proof is subsequently submitted to the Layer 1 blockchain, such as Ethereum, alongside the new Merkle root. The on-chain rollup contract validates the proof and, upon confirmation of its validity, adopts the new state root as the current state of the system.

Consensus mechanism

A consensus algorithm is used to add a new block by solving the computational task or some mathematical problem by a participant. In a blockchain network, a node must first verify the legitimacy of the transactions within a block and ensure that the block adheres to the established rules of the network before adding it to the chain. If the node is unable to verify this information, it will be prohibited from adding a new block to the chain. The node must generate a new block by solving a complex mathematical problem and subsequently broadcast the block to other nodes. Other nodes will validate the block to confirm its adherence to the rules and protocols of the blockchain network. Upon successful validation, the block will be incorporated into the chain. A hybrid technique combining the advantages of PoS and PBFT forms the basis of the consensus process. A new consensus technique is suggested to guarantee the security and integrity of off-chain transactions.

IPFS (inter planetary file system)

IPFS is a distributed peer to peer file system used to store the file in the form of a hash value. The same blocks of the file will be stored only once which increase the data sharing efficiency and integrity¹⁶. No centralized server is used to store and transfer the files. If a node is unavailable or unable to supply file blocks, IPFS automatically searches for alternative nodes to obtain the necessary data. IPFS enables decentralized storage and sharing of files, thereby enhancing content censorship resistance. IPFS can be utilized to construct websites within a distributed web framework. It serves as a supplementary storage service. The blockchain facilitates various applications built upon IPFS. IPFS employs content-based addressing, focusing on immutable data.

Figure 4 presents an integrated view of the proposed healthcare data exchange framework and outlines how information moves across the different components of the system. The workflow begins at the patient-facing layer, where individuals interact with a healthcare application to create, modify, or upload their medical information. Prior to transmission, all records are secured using encryption on the user’s device, ensuring that no readable data leaves the local environment. Only the encrypted files are transferred to the InterPlanetary File System (IPFS), which generates a unique content identifier (CID). This identifier functions as a permanent and tamper-resistant reference to the stored data.

Fig. 4.

Proposed patient data transaction system in the healthcare.

The generated CID, together with patient-defined access permissions, is recorded within a Layer-2 rollup through a smart contract. This contract governs authorization by validating requests from healthcare providers, diagnostic laboratories, and insurance entities. When an approved organization requires access, it retrieves the encrypted file directly from IPFS and performs decryption locally using cryptographic keys explicitly granted by the patient. All access attempts, approvals, and updates are captured on the Layer-2 network, enabling near real-time visibility of system changes before final confirmation on the base chain.

To support high transaction volumes across multiple healthcare institutions, the rollup aggregates various operations—such as record access, metadata changes, and insurance-related submissions—into defined batches. These batches are processed off-chain, resulting in an updated Merkle root along with a zero-knowledge proof that validates the integrity and correctness of all included transactions. The proof and the corresponding state root are then submitted to the Layer-1 blockchain, where they undergo verification and are permanently recorded.

Instead of recording a separate CID on-chain for every modification, the system maintains a consolidated index file for each patient within IPFS. This index is updated whenever new records are added or existing ones are modified, while only the latest index hash is committed to the blockchain. This design minimizes unnecessary on-chain writes while preserving a complete and verifiable history of data changes. At predefined intervals, or during critical events such as insurance claims or inter-organizational data sharing, the updated index hash is anchored to the Layer-1 network through batch validation. This ensures all participants operate on a synchronized and trustworthy version of the patient’s data. For compliance with long-term storage requirements and regulatory standards, encrypted and validated records are also securely archived in a protected cloud environment. The combined workflow in Fig. 4 demonstrates how Layer-2 scaling, decentralized storage, and ZK-based verification work together to provide a secure, efficient, and interoperable environment for healthcare data exchange.

Architectural rationale and justification

The proposed architecture integrates Layer-2 rollups, IPFS-based storage, and Layer-1 anchoring to address the specific operational and regulatory demands of healthcare data exchange. This combination is necessary because healthcare systems generate a diverse range of high-frequency events—such as consent verification, file reference updates, clinical assessments, laboratory submissions, and insurance validation—none of which can be executed efficiently on a Layer-1 blockchain due to latency and transaction cost constraints. A ZK-Rollup structure supports real-time responsiveness by enabling off-chain execution while still providing strong mathematical guarantees of correct state transitions through validity proofs. This ensures that all updates to access rules, audit trails, and metadata remain verifiable without exposing patient information.

Off-chain encrypted file storage via IPFS is essential because medical records are large, mutable, and subject to retention and deletion requirements that conflict with on-chain permanence. IPFS allows files to be stored in a distributed manner while maintaining integrity through content-addressed identifiers. To prevent excessive on-chain updates when records change, the system uses a single patient-specific index file whose hash is recorded in the rollup state. This approach reduces gas consumption and maintains a consistent audit trail across the lifetime of a patient’s data.

Interoperability across hospitals, laboratories, and insurers further necessitates this architecture. These institutions often operate on different systems and require a mechanism to share verifiable metadata without transferring raw patient files. By anchoring a unified metadata structure in the rollup and sharing IPFS references, each institution can independently verify access permissions and file authenticity. Traditional Layer-1 implementations, sidechains, or centralized data hubs cannot simultaneously provide the scalability, privacy guarantees, and multi-institution coordination required in real healthcare environments. The chosen architecture therefore reflects a deliberate design choice that aligns technical capabilities with the unique constraints of secure, scalable, and interoperable healthcare data exchange.

The proposed algorithm divides the procedure in three different ways as follows:

Algorithm 1.

Entry_via_smart contract.

Where, ​ is the input patient data.

is the insurer chosen based on policy or selection criteria.

is the resulting smart contract or insurance bond created for the patient.

is the organization-ready version of the patient data.

∈I is the insurer receiving the processed data. Often, , unless data is rerouted.

Steps involve in the above algorithm are:

• Step1: Verify patient data.

• Step2: Create bond between patient data and insurer.

• Step3: Process the data through healthcare organization.

• Step4: Transfer the process data to the insurer.

When an insurer wishes to join the healthcare organization, runs the smart contracts, and modifies the patient data. Algorithm I refers to this as Entry (). Patient data is updated as a patient starts the data transaction in a healthcare by running smart contracts at gateway. The smart contract processes the organisation data (D_o​), establishes a bond, and sends the same values of the data transfer to the patient’s account.

In the execution of transaction inside layer2 environment, healthcare organization uses the private blockchain as layer2 infrastructure, so we focused Hyperledger for this. Hyperledger fabric uses the practical byzantine fault tolerance (PBFT) consensus process which can tolerate up to 33% of hostile nodes. Usually, the peers in layer2 environment are trusted nodes of healthcare organization which helps to reduce the attacks.

Figure 5 depicts the validation and transaction flow within the proposed multi-layer blockchain framework for secure healthcare data interoperability. The architecture integrates patients, hospitals, and insurers through a Layer 2 Hospital Chain, which connects to a Layer 1 Blockchain for permanent record anchoring and verification.

Fig. 5.

Insurer execute the transaction on layer2 environment and published it on layer1 blockchain.

Each patient interacts with a healthcare application that executes smart contracts to regulate access control, consent, and data-sharing conditions. The encrypted medical data are transmitted to the respective hospital, where they are processed and temporarily maintained within the Layer 2 blockchain network, referred to as the Hospital Chain. This Layer 2 configuration enables faster processing and cost-effective transaction handling by aggregating frequent updates before final validation on the main chain.

Within the Hospital Chain, transaction validation is managed by two key categories of nodes: peer nodes and orderer nodes. Peer nodes operate at the hospital level and are responsible for executing smart contract logic, validating transaction requests, and maintaining synchronized copies of the distributed ledger. When a transaction request is generated, it is distributed to multiple peer nodes, where it is evaluated against predefined access control rules and policy constraints. This endorsement process ensures that only compliant data access or update operations are approved. After obtaining the required number of endorsements, the transaction is forwarded to the orderer node.

The orderer node ensures system-wide consistency by coordinating transactions received from peer nodes belonging to different hospitals. It sequences endorsed transactions in a deterministic order and groups them into blocks, eliminating conflicts and maintaining transactional integrity. These blocks are then transmitted to the insurer node, which acts as the final verification authority. The insurer validates the correctness and authenticity of the received blocks before anchoring them onto the Layer-1 blockchain. Once recorded on the base chain, the transactions achieve immutability and network-wide consensus. This multi-layer validation architecture improves scalability, preserves audit trails, and enables secure interoperability among participating healthcare organizations.

Algorithm 2.

Execute_layer2_transaction (patient_data).

Mathematical equation for the above algorithm is as follows:

where, executeL2B(patient_data): Executes the patient data and generates a receipt.

ROLLUP(·): Aggregates the receipts into a batch.

vrfyTrans(·): Verifies the batched transactions.

createmerkletree (·): Builds a Merkle Tree from the verified roll-up.

execL1B(·): Executes the Merkle root on Layer1 blockchain to generate det_j.

Algorithm 2 outlines the procedure for executing transactions and conducting roll-up in a clear and systematic manner. The Fig. 6 shows the working of algorithm II, A transaction in layer2 environment is executed on L2B, leading to the receipt of the i^th transaction from the insurer. Following a successful transaction, the peer nodes will incorporate it into the j^th roll-up queue and into the individual queue of each insurer. The roll-up queue is sent to layer1 blockchain. The rollUp() operation is executed on layer1 blockchain. In the roll-up method, miners verify the transaction associated with the j^th roll-up queue and subsequently build the Merkle tree. The miners then execute a transaction that includes layer1 blockchain and integrates the Merkle root of the block obtained from layer2 blockchain, which was finalized in layer2 environment. Upon completion of the execution process, the insurer receives a transaction receipt. This receipt contains the block number of layer2 blockchain, indicating where the transaction was deposited by the ordered node, as well as the block number of layer1 blockchain, which reflects where the transaction is consolidated by the smart contract at the gateway.

Fig. 6.

Working of algorithm 2.

Algorithm 3.

Procedure EXIT(Blist).

Mathematical representation of the above algorithm is as follows:

Where,

B = Blist_i.

L1B = Layer1 blockchain.

L2B = Layer2 blockchain.

N = Nlist_i= getIndividualQFromL2B.

MR(x) denote merkleRoot(x).

diffTrans = match(B, N).

dets = blockDetails(diffTrans).

orig = checkTransL1B(dets).

calcTotal represents calcTotalTransaction().

settle(x) represents settleData() post-calculation.

replaceInQ and ignoreTrans are operations based on orig’s existence.

Figure 7 explain the working of Algorithm III, which illustrates the insurer’s exit and account settlement process in a clear and systematic manner. The insurer can initiate the data transaction settlement process by executing the exit() operation. The insurer is required to supply Blist_i to the smart contract at the gateway, while the smart contract retrieves the Nlist_i of the insurer from.

Fig. 7.

Working of algorithm 3.

layer2 blockchain. The gateway smart contract then creates the Merkle tree and confirms that the root nodes of the two trees match. Upon confirming a match with the root, the smart contract will execute the settlement of data transactions by calculating the total transaction within the layer2 environment. If the roots do not match, the smart contract performs a comparison of the two trees to identify the transactions that have changed and subsequently determines the block number associated with those transactions. The calculation of the insurer’s total data transaction is performed by the smart contract, which excludes any modified transactions. The process involves collecting data regarding the specific transaction recorded during the roll-up operation by analysing the block on layer1 blockchain. The smart contract includes the transaction when assessing the total data transaction; otherwise, it is completely ignored. The updated algorithms now clearly outline the roles performed by each participating node, detail the processes for identity and credential verification, and specify secure key handling and failure-response steps, making the system more feasible for real-world implementation.

In this system, Ethereum operating under Proof-of-Stake (PoS) is used as the Layer-1 foundation. PoS is selected over Proof-of-Work due to its lower energy requirements, reduced confirmation delay, and security based on economic staking. Layer-1 does not process healthcare transactions directly; instead, it serves as the settlement and data availability layer. The main computation and data handling occur in Layer-2 through zk-Rollups, where proofs are generated off-chain and verified on Layer-1. This design preserves Ethereum’s security assurances while significantly lowering on-chain load and transaction cost. The predictable finality time of PoS (approximately 12–32 s) supports asynchronous healthcare workflows while ensuring data integrity and auditability, which are essential for compliant and trustworthy medical record management.

Algorithm II describes the procedure for submitting encrypted medical data within the roll-up framework. The healthcare provider node is authenticated through verified digital credentials, and the patient’s consent parameters are checked prior to data processing. Following successful validation, the data is encrypted and incorporated into a transaction that is forwarded to the roll-up aggregator. The aggregator forms batches of multiple transactions and generates a corresponding zero-knowledge proof to ensure correctness without exposing the underlying data. A verification node evaluates this proof before the final state update is recorded on the Layer-1 blockchain. If identity verification, consent validation, or proof verification fails, the transaction is halted, thereby maintaining data integrity and privacy.

Algorithm III outlines the controlled access procedure for retrieving stored medical data. When a clinician or researcher initiates an access request, the system verifies the requester’s digital identity and role, and confirms alignment with the consent policy associated with the patient. Upon approval, the key required to decrypt the encrypted data is provided through the key management service. The requester then performs decryption locally. If the request does not satisfy authorization or consent conditions, access is denied. All actions are recorded to support auditability, regulatory compliance, and traceability.

Detailed rollup processing flow and cryptographic validity mechanisms

This section provides a precise, implementable description of how the proposed Layer-2 rollup processes batches, compresses transactions, and generates cryptographic proofs. It also clarifies the roles of PoS, PBFT, and the rollup within the architecture, and explains the interoperability logic used across institutions.

Transaction batching and state transition

Let the rollup maintain a state , represented as the Merkle root of all patient metadata, index-file hashes, and access-control entries. Incoming transactions

where op ∈ {upload, update, access, claim}, are collected by the rollup operator into a batch

.

The batching mechanism follows these steps:

Collection:

Transactions are accepted until either a batch-size threshold is reached or a timeout trigger forced batch closure.

Validation:

For each , the operator checks:

• signature verification ) = 1,

• permission check ) = 1,

• metadata consistency (correct CID, correct index reference),

• Merkle-path validity for the leaf being updated.

State transition:

The deterministic state-transition function.

applies each valid transaction in sequence, updating the corresponding Merkle leaves and producing a new Merkle root.

Witness generation:

During application of ,B), the operator records a witness consisting of:

• all pre- and post-state values for affected leaves,

• Merkle paths for verification of leaf updates,

• access-control evaluations for each transaction,

• batch metadata (ordering, timestamps, and commitments).

This witness is required input for generating the zero-knowledge proof.

Batch compression and on-chain submission

The proposed design reduces on-chain footprint by submitting only a minimal commitment to the batch. Instead of writing all individual transactions to Layer-1, the rollup publishes:

• the new Merkle root ,

• a cryptographic commitment ,

• a succinct proof verifying that.

This compression allows thousands of healthcare operations to be represented by a single Layer-1 transaction.

Validity-proof mechanism (ZK-Rollup Model)

The proposed architecture adopts a validity-proof rollup, not an optimistic rollup. Therefore:

• There is no challenge period.

• There are no fraud proofs.

• Incorrect batches are rejected immediately on verification failure.

A zero-knowledge circuit defines the relation:

iff the following conditions all hold:

• All signatures in batch B are valid.

• All access-control policies are satisfied.

• Each Merkle-tree update is correct and consistent with .

• Re-executing the batch produces exactly .

• No transaction touches unpermitted or non-existent records.

• No intermediate state violates metadata or index-file integrity.

The operator produces a proof:

which is sent to the Layer-1 rollup contract. The contract executes:

Only if verification returns true is the new state root accepted and finalized.

How PoS, PBFT, and rollups fit together

The architecture uses PoS, PBFT, and rollups in a layered, non-conflicting manner:

1. Layer-1 PoS (Settlement and Finality):

• Ethereum’s PoS mechanism provides block ordering, economic security, and finality.

• We do not modify PoS; it acts solely as the trust anchor for rollup proofs and state roots.

• 2.Layer-2 Rollup (execution and validity):

• All computation occurs off-chain.

• Consensus on correctness is cryptographic, not voting-based.

• A batch is accepted only if its proof is valid. Malicious operators cannot force incorrect state transitions.

• 3.PBFT-Style Coordination Layer:

PBFT is used only among participating healthcare institutions to coordinate operational tasks such as:

• agreeing on batch submission frequency,

• rotating rollup operator duties,

• synchronizing metadata schemas,

• deciding priority of emergency access transactions.

• PBFT does not participate in block finality or transaction correctness.

• This eliminates conceptual inconsistency.

Thus, PoS secures Layer-1, validity proofs secure Layer-2, and PBFT handles governance.

Interoperability and cross-institution verification

Interoperability is achieved through metadata-level exchange rather than data replication:

• IPFS CIDs and index-file hashes represent encrypted medical data.

Each institution can verify a referenced state by checking:

=1.

• A relay transmits batch references between institutions, but the relay is untrusted—validation relies solely on on-chain proofs.

• Institutions only need the CID and the verified state root, not the entire raw dataset.

This design supports scalable multi-institution healthcare exchange while maintaining strict confidentiality.

Experimental analysis and results

This section analyses the performance of the proposed system to find out the efficiency and throughput. Throughput is a key indicator in blockchain network which shows the scalability in the blockchain networks and lower the transaction charges. The proposed system performance is compared with two existing systems, namely Smart_contract Model¹⁹, and Blockchain and ZK-rollup²³ .

The evaluation of the proposed methodology is based on the following parameters: The experiment has been performed in a simulated environment using intel i3 processor with 8 GB SSD-RAM, Solidity (0.8.0), Remix IDE (0.10.3) and python 3.7 and a 1 TB SSD, ensuring consistent performance without interference from external processes, we used synthetic dataset with attributes Patient_ID, Age, Gender, Condition, Procedure, Cost, Length_of_Stay, Readmission, Outcome.

To enhance scientific rigor and ensure reproducibility, all evaluations were performed within a standardized blockchain testbed using well-documented hardware, software, and workload settings. The Layer-1 blockchain environment was deployed using a private Ethereum network instantiated through Geth, configured with fixed block time, gas parameters, and chain ID. For Layer-2 execution, a zk-rollup framework comparable to Optimism, zkSync, or a Cairo/StarkNet-based implementation was utilized, with uniform batch size, sequencer behavior, and proof-generation settings across all trials. Encrypted patient files were stored and retrieved through a local IPFS node with pinning enabled, ensuring deterministic and repeatable storage behavior. A synthetic healthcare workload was generated, consisting of record uploads, access requests, updates, and insurance-claim operations, with file sizes and operation ratios modelled after real-world medical data patterns. Each experiment was repeated multiple times, and results were reported as averaged values to minimize statistical variance. For fair comparison, two baseline systems a Layer-1-only configuration and a non-ZK Layer-2/sidechain were re-created under identical conditions. Latency, throughput, and gas-cost measurements were then collected uniformly across all systems. This controlled and fully documented setup ensures that performance differences arise from architectural choices rather than testbed variability, enabling reliable reproduction by other researchers.

The proposed system enables the patient to store their treatment data to IPFS as hash and hospitals use that data for transaction by decrypting it. The process uses the RSA algorithm for creating the patient data into hash. The healthcare organization use this hash to store the patient health data into layer2 blockchain. The code for the entire process can be explained as using a Merkle Tree and its cryptographic features, the Merkle Verifier smart contract is meant to rapidly determine whether a given data item (leaf) belongs to a predetermined collection. A binary tree called a Merkle Tree contains each leaf node representing a hashed data item and each non-leaf node the hash of the combination of its two the child nodes. Suppose “A”, “B”, “C”, and “D” are four data elements we have. The Keccak-256 algorithm hashes every one of these:

It shows the leaf nodes. Then we recursively combine pairs

The contract stores this last hash, R, which is the Merkle Root. The advantage of a Merkle tree is that you may use a small subset known as the Merkle proof, which is made up of the sibling nodes from the leaf to the root, to demonstrate that a certain leaf exists in the tree without having to use the entire tree. Here, to verify L₀ is the part of the tree, the proof would be:

To recomputes the path to the root, verifyProof() function of the smart contract takes the leaf and proof[] as follows:

Then it compares:

This approach is efficient for on chain verification, scalable where proof size is O(log₂ n) and secure which is based on the collision resistance of Keccak-256.

The verifyProof() function logic ensures that:

• The hash order is predetermined because the smaller hash is always hashed first,

so (as H(a∣∣b) ≠ H(b∣∣a)).

• The output maintains in line with the tree-building method.

• Low gas consumption is achieved by comparing only hashes and avoiding the storage of big data sets.

Figure 8 shows the transaction latency comparison of the proposed model with different other models which shows that the latency of proposed model appears to be able to handle transactions more rapidly and effectively than the other two. Applications that require real-time or near-real-time processing may find the suggested approach more suitable, since the substantial decrease in latency suggests enhanced efficiency.

Fig. 8.

Comparison of transaction latency.

In Fig. 9, the proposed model shows considerable improvement with a transaction cost far below $0.10. With such a sharp decrease in price, the suggested model is designed for large-scale deployments or applications where all money counts.

Fig. 9.

Comparison of transaction cost per second.

Figure 10 shows that with 10,000 transactions per second; the proposed approach delivers a significantly higher throughput. For high-demand environments like healthcare, banking, or large-scale IoT ecosystems, where speedy transaction processing is essential, the suggested structure is significantly more suitable due to its greater scalability and processing capacity.

Fig. 10.

Throughput comparison of proposed system with other systems.

Discussion

The below Table 3 differentiates systems for managing and exchanging Electronic Medical Records (EMRs), emphasizing their characteristics, technologies, and intended applications.

Table 3.

Comparison table of proposed system with other state of Art framework.

Feature/aspect	Datta & Namasudra (2024)	Ma & Zhang (2024)	Proposed system
Primary goal	Secure EMR exchange using blockchain and MEC	Privacy protection and efficiency in EMR sharing	Real-time transaction settlement in healthcare
Blockchain layer	Layer 1	Layer 1	Layer 2 (Roll-up-based with Layer 1 fallback)
Data storage	IPFS	IPFS	IPFS
Consensus mechanism	Proof of Authority (PoA)	PoW (implied)	Custom roll-up consensus
Security techniques	AES, RSA, EdDSA, ECDSA	Zero-Knowledge Proofs (ZKP)	ZK-Rollups, smart contracts, cryptographic hashing
Smart contracts	Extensively used for all phases	Limited integration	Fully integrated
Node roles	Hospital/doctor as validators	Doctors: full nodes; Patients: light/full nodes	Decentralized participation by hospitals/patients
Key strengths	Strong security, automation, multiple encryption layers	Privacy-focused, scalable, energy-efficient	High throughput, low latency, real-time capability
Limitations	Depends on institutional validators; lacks cross-institution support	Limited smart contract use; throughput still low	Still under development; experimental validation
Interoperability	Basic hospital-based ecosystem	Multi-org data sharing possible via IPFS	Focus on multi-institution scalability
Performance metrics	Shows improved transaction speed & efficiency	Gas savings and improved privacy	57% latency increase tolerated; 96% cost reduction
Target use case	Doctor-patient EMR exchange via hospital	Academic and medical organization sharing	Real-time data sharing and processing across healthcare systems
Encryption	Multi-layered: AES for data, RSA for keys	ZKP with blockchain encryption	ZK-Rollup and cryptographic hashes

Datta & Namasudra (2024) seek to facilitate safe electronic medical record sharing with a Layer 1 blockchain and Mobile Edge Computing (MEC), which positions computing nearer to the data source for expedited processing. Their solution uses the InterPlanetary File System (IPFS) for decentralized data storage and utilizes Proof of Authority (PoA) as the consensus method, wherein trusted hospitals or physicians serve as validators. To ensure security, they employ various encryption methods, including AES for data, RSA for keys, and digital signature algorithms like as EdDSA and ECDSA. Smart contracts are widely utilized to automate numerous functions. The node architecture is concentrated around institutional validators, constraining the system scalability among many institutions. Although it lacks wider interoperability, its primary strength is robust security with numerous encryption layers.

Ma and Zhang (2024) look at privacy and efficiency. They use IPFS for data storage and a Layer 1 blockchain, but the consensus technique is not expressly specified and is assumed to be Proof of Work (PoW). They use Zero-Knowledge Proofs (ZKP) to protect privacy. ZKPs allow checking data without showing it to anyone. There are not many smart contracts, and the network is set up so that doctors are full nodes and patients are either full or light nodes. Their method saves energy and protects privacy, and it lets different organizations share data through IPFS. But two significant disadvantages are the restricted application of smart contracts and very poor throughput.

The Proposed System uses a Layer 2 blockchain with roll-up technology, which is a more advanced way of doing things. This technology processes transactions off-chain before sending them to a Layer 1 blockchain for security. This makes it easier to scale and lowers the cost of transactions. It uses IPFS to store data like the others, but it has a special roll-up consensus process that makes transaction validation faster and more efficient. ZK-Rollups, smart contracts, and cryptographic hashing all make security stronger. Smart contracts are fully integrated into the system, and both hospitals and patients can participate in a decentralized way. It is great for large healthcare systems since it can handle a lot of data quickly and in real time. It works well with multiple organizations and demonstrates promising performance, with a 96% cost decrease and a 57% improvement in latency.

The Proposed System offers a scalable, real-time system that aims to change how healthcare data is shared on a larger scale.

Ethical and regulatory implications

The proposed system has been developed with a strong emphasis on ethical responsibility and regulatory compliance, recognizing the highly sensitive nature of healthcare information. To minimize privacy risks, personally identifiable and protected health data are never stored directly on the blockchain; instead, the ledger contains only encrypted pointers and secure hash values. This design supports data-minimization requirements prescribed by GDPR. Patient data access is strictly controlled through explicit consent mechanisms, role-based permissions, and verifiable audit trails, aligning the system with key GDPR and HIPAA obligations related to confidentiality, data integrity, and accountability. In addition, cryptographic enforcement of access policies and immutable logging mechanisms ensure transparency while safeguarding patient privacy.

Conclusion

The proposed framework demonstrates how Layer-2 rollups, zero-knowledge validity proofs, and IPFS-based storage can be combined to support secure, scalable, and interoperable healthcare data exchange. Rather than reiterating the introduction, this conclusion highlights the key insight gained: verifiable off-chain computation and content-addressed storage together enable high-throughput medical data operations without compromising privacy or regulatory requirements. While the system achieves significant reductions in cost and latency, several limitations remain. First, the computational overhead of zero-knowledge proof generation may restrict performance in extremely high-volume clinical environments. Second, the evaluation has not yet been extended to geographically distributed multi-hospital deployments, where network latency, heterogeneous infrastructure, and complex interoperability constraints may influence system behaviour. Third, the current design assumes stable identity management and key protection, which may be challenging in real-world clinical settings. These limitations point to clear opportunities for future work. Subsequent research should explore hardware acceleration and proof-system optimization to reduce ZKP generation time, conduct multi-region trials involving diverse healthcare institutions, integrate decentralized identity standards to strengthen authentication, and investigate dynamic access-control models suitable for emergency and cross-border healthcare scenarios. Additionally, extending the architecture to support FHIR/HL7 interoperability and evaluating its resilience under large-scale adversarial workloads would further strengthen its practical applicability. Through these directions, the proposed approach can evolve into a robust foundation for next-generation healthcare data infrastructures.

List of symbols

D_P

Input patient data submitted to the system

D₀

Organization-ready (processed) version of patient data

u

User or participant (patient, provider, insurer)

I

Set of insurers

i, i’ I

Selected insurer and receiving insurer

B_P

Insurance bond / smart contract created for patient data

F_bond (.)

Bond creation function

F_org (.)

Organization-specific data processing function

F_trans (.)

Data transfer function

t

Individual transaction

T

Set of transactions

op

Transaction operation type (upload, update, access, claim)

Sig_u

Digital signature of user ( u )

Q_r

Rollup transaction queue

Q_i

Insurer transaction queue

B

Batch of Layer-2 transactions

L1B

Layer-1 Blockchain

L2B

Layer-2 Blockchain

_i

Rollup state at step ( i ) (Merkle root)

_i+1

Updated rollup state after batch execution

F(_i, B)

State transition function

w

Witness used for ZK proof generation

Zero-knowledge validity proof

R(.)

ZK validity relation

C_B

Cryptographic commitment to batch ( B )

Verify(·)

Layer-1 proof verification function

P(u, d_i)

Access permission function

cid_i

IPFS content identifier of encrypted data

I

Index file maintaining data version references

MR(x)

Merkle root of set ( x )

N

Individual transactions extracted from a Layer-2 batch

diffTrans

Mismatched transactions between batch and extracted list

dets

Block-level details of mismatched transactions

orig

Transactions confirmed on Layer-1

calcTotal(. )

Function computing aggregate transaction value

settle(.)

Settlement execution function

H(.)

Cryptographic hash function (Keccak-256)

L₀, L₁, L₂, L₃

Merkle tree leaf hashes

I₀, I₁

Intermediate Merkle tree nodes

R

Merkle root

proof[]

Merkle proof (sibling hashes)

verifyProof()

Smart contract function verifying Merkle inclusion

Author contributions

A.R: Conceptualization, Methodology, Implementation, Validation, Original draft preparation. A.M.T.: Idea discussion, Paper structure design, Supervision, Writing – review & editing, Result analysis. N.A.W.: Paper structure design, Validation, and Result analysis. N.A.: Conceptualization, Results Discussion, Resource Management. Y.J.: Paper structure design, Result analysis, Resource Management. M. L.: Resource Management, Writing – review & editing.

Funding

Open access funding provided by Prince Sultan University.

Data availability

The code generated in the present work is with corresponding author and may be supplied upon a reasonable request.

Declarations

Competing interests

The authors declare no competing interests.