Blockchain and InterPlanetary Framework for Decentralized and Secure Electronic Health Record Management

Abstract

Blockchain is an emerging technology that is being used to create innovative solutions in many areas, including healthcare. Nowadays healthcare systems face challenges, especially with security, trust, and remote data access. As patient records are digitized and medical systems become more interconnected, the risk of sensitive data being exposed to cyber threats has grown. In this evolving time for healthcare, it is important to find a balance between the advantages of new technology and the protection of patient information. The combination of blockchain–InterPlanetary File System technology and conventional electronic health record (EHR) management has the potential to transform the healthcare industry by enhancing data security, interoperability, and transparency. However, a major issue that still exists in traditional healthcare systems is the continuous problem of remote data unavailability. This research examines practical methods for safely accessing patient data from any location at any time, with a special focus on IPFS servers and blockchain technology in addition to group signature encryption. Essential processes like maintaining the confidentiality of medical records and safe data transmission could be made easier by these technologies. Our proposed framework enables secure, remote access to patient data while preserving accessibility, integrity, and confidentiality using Ethereum blockchain, IPFS, and group signature encryption, demonstrating hospital-scale scalability and efficiency. Experiments show predictable throughput reduction with file size (200 → 90 tps), controlled latency growth (90 → 200 ms), and moderate gas increase (85k → 98k), confirming scalability and efficiency under varying healthcare workloads. Unlike prior blockchain–IPFS–encryption frameworks, our system demonstrates hospital-scale feasibility through the practical integration of group signatures, hierarchical key management, and off-chain erasure compliance. This design enables scalable anonymous authentication, immediate blocking of compromised credentials, and efficient key rotation without costly re-encryption.

1. Introduction

In today’s healthcare environment, securely managing and sharing patient data is critical for effective and personalized care. Patient records and diagnostic histories must be readily accessible to providers, but centralized systems often face inefficiencies, duplication, and security risks [1]. With increasing digitization, more sensitive data is exchanged across networks, raising concerns about privacy and cyberattacks [2]. New approaches are needed to ensure availability, integrity, and compliance while safeguarding patient trust [3]. Blockchain has emerged as a promising solution, offering decentralization, immutability, and transparency [4], reducing reliance on vulnerable centralized servers [5].

While blockchain ensures security, it cannot handle massive medical files directly. The InterPlanetary File System (IPFS) addresses this limitation by enabling distributed and tamper-resistant storage [6], with cryptographic hashes stored on the blockchain for verification [7]. Group signatures further enhance privacy by allowing anonymous data usage while maintaining accountability [8]. Together, blockchain and IPFS provide healthcare organizations with integrity, security, and efficient data sharing. Figure 1 highlights blockchain’s applications in areas such as electronic health records (EHRs), supply chain management, and patient data security.

This paper introduces a framework integrating IPFS, lightweight blockchain, traditional EHR systems, Proof of Stake consensus, and group signature encryption. The proposed model focuses on the following:

• A blockchain-based framework for secure EHR management, emphasizing remote accessibility and privacy.
• Solutions enabling patients to access records securely anytime, in compliance with privacy regulations.
• Advanced validation to ensure confidentiality, integrity, and protection against unauthorized access.

The paper is structured as follows: Section 2 reviews related works, Section 3 presents the proposed framework, Section 4 analyzes results, and Section 5 concludes.

2. Related Work

The healthcare industry faces unforeseen challenges in managing, securing, and sharing sensitive patient data in an increasingly digital and interconnected world. Due to the regular centralized system, traditional healthcare systems are susceptible to interoperability problems, inefficiencies, and data breaches. Concerns over data confidentiality, integrity, and availability have grown as a result of increasing data quantities and reliance on electronic health records (EHRs) [9,10,11]. Healthcare providers need to handle the challenges of integrating new technology into current medical workflows while maintaining secure access to patient data in addition  to privacy requirements [12,13]. In spite of these challenges, the healthcare industry is calling for more interoperable, scalable, and secure solutions to facilitate effective, patient-centered treatment [14].

Blockchain technology, which provides decentralized, tamper-resistant data management, has become a revolutionary technology to address these issues. The decentralized architecture and immutability of blockchain technology have the potential to improve traceability, transparency, and trust in the sharing of medical data. The blockchain is made up of numerous pieces that are chronologically connected. Figure 2 shows a block that is made up of four parts: data, the hash of the current block, and the hash of the block before it, nonce and timestamp. The genesis block will be the first block made, and every subsequent block will include its own contents and hash while keeping the hash of the previous block. The role of blockchain in protecting healthcare data has been investigated by researchers; however, there are significant obstacles to its implementation, such as scalability bottlenecks [15], integration issues with real-time medical devices [16], and worries about centralized control [17,18]. Data integrity may be compromised by security flaws in blockchain systems [19], and adhering to privacy regulations in the healthcare industry makes adoption of blockchain much more difficult [20,21]. However, blockchain is still a key technology for creating distributed, safe healthcare systems, particularly when combined with other complementing technologies.

Although blockchain offers transparency and data integrity, researchers are exploring the InterPlanetary File System (IPFS) as a potential option because of the demand for scalable, decentralized storage [22]. By sharing data among nodes, IPFS makes decentralized file storage possible, decreasing the need for centralized servers while enhancing data availability and resistance against loss or manipulation. IPFS has been applied in healthcare settings to improve scalability and privacy. Ghassan et al. [23] investigated embedding metadata in distributed storage for decentralized record-keeping, whereas Haya et al. [24] used IPFS combined with proxy re-encryption to protect patient data. Joao et al. [25] created an IoT-based healthcare data platform by integrating IPFS with blockchain and MQTT protocols. Similarly, Yufei et al. [26] and Pearl et al. [27] illustrated how IPFS may improve access control and confidentiality of medical data. Blockchain, IPFS, and CP-ABE (Ciphertext-Policy Attribute-Based Encryption) were coupled by Kaur et al. [28] to provide scalable medical record management with fine-grained access control. For instance, to solve security and privacy issues, Rahul et al. [29] created a decentralized EHR solution utilizing blockchain, RSA encryption, and IPFS storage. IPFS’s increasing importance in decentralized healthcare data management is further supported by other works that suggested blockchain–IPFS solutions for attribute-based encrypted medical records, secure EHR sharing, and self-sovereign identity systems [30].

Healthcare information transfer requires privacy-preserving authentication and access control in addition to storage and integrity. Group signature methods enable users to sign messages on behalf of a group while maintaining the anonymity of individual identities unless a trace is necessary [31]. Group signatures provide a means of participant authentication without disclosing their identities, striking a balance between accountability and privacy protection. Group signatures were used by Shijie et al. [32] to secure blockchain-integrated mobile-edge computing. The SLTGS system was introduced by Zijian et al. [33] in the healthcare industry to provide effective, privacy-preserving data sharing. Group signature-based protocols were introduced for IoT settings by Zhiwei et al. [34], Mukesh et al. [35], and Weihan et al. [36] to guarantee safe, verified IoT data transfers.

Studies have explored threshold-based group signatures for IoT [37], elliptic curve cryptography schemes [38], and decentralized group signature models [39] to enhance performance and scalability while maintaining privacy. To build secure and privacy-preserving healthcare data systems, recent works recommend integrating blockchain, IPFS, and group signatures. For instance, Samraiz et al. [40] combined blockchain and IPFS to improve medical data sharing, while others applied attribute-based encryption [41], polymorphic encryption [42], smart contracts, and proxy re-encryption [43] to strengthen decentralized governance. Despite progress, adoption faces challenges related to privacy, regulatory compliance, and scalability [44]. Advanced mechanisms such as group signatures and multi-manager systems often require complex coordination, and their verification processes show weaknesses [45]. Similarly, blockchain combined with group key distribution and smart contracts remains largely theoretical [46], where many group signature models lack practical deployment analysis [47] and research shows efficiency gains, but fails against device impersonation [48].

Overall, integrated frameworks highlight a trend toward multi-layered healthcare infrastructures. Group signatures ensure privacy-preserving authentication, blockchain secures data immutability, and IPFS supports decentralized storage. Together, these technologies aim to meet regulatory demands while addressing data security, privacy, and interoperability challenges in healthcare. The main contributions of this body of work are summarized in

Table 1. Adoption of recent technologies such as blockchain, IoT, EHR systems, and cryptography in modern healthcare management.

Reference	Based On	Limitations
[49]	Blockchain, IPFS	TCCM has limitations in platform reliance, complexity, ethical risks, access control, and scalability.
[50]	Blockchain, IPFS	The framework faces limitations in scalability, model accuracy, explainability, and standard compliance, requiring further validation across diverse healthcare settings.
[51]	Blockchain, IPFS	The system faces limitations in scalability, user dependence, and institutional adoption.
[52]	IoT, EHR	The scheme is limited by its simulation-based evaluation, single authority support, and lack of quantum resistance.
[53]	IoT, EHR	The main limitation of the study is its validation using data from a single hospital’s EHR system and one type of wearable device (Garmin), limiting generalizability.
[54]	Blockchain, EHR	B-HIES is limited by assumptions on ethical data use, lack of scalability testing, partial semantic interoperability, absence of data quality control, and no integrated threat modeling.
[55]	Blockchain, EHR	The system lacks real-world evaluation, scalability testing, and integration with AI and IoT for advanced healthcare functionality.
[56]	Blockchain, Group Signature	The proposed TASS scheme lacks real-world deployment and has not yet addressed resistance to malicious aborts in distributed settings.
[57]	Blockchain, Key Distribution	The study lacks practical implementation or evaluation of ECC within real-world healthcare systems.

, showing how blockchain, smart contracts, IPFS, group signatures, and IoT are converging toward secure, patient-centered data ecosystems. Existing blockchain–EHR frameworks often rely on ZKP, PRE, or ABE mechanisms to enforce privacy and access control. These approaches introduce significant overheads: ZKP schemes scale poorly under frequent authentication, PRE incurs high re-delegation cost, and ABE suffers from large key sizes and complex revocation policies. In our work, we implemented and evaluated a group signature–based framework with hierarchical key management and on-chain revocation. As summarized in

Table 2. A detailed comparison of the proposed framework with existing blockchain–IPFS–encryption approaches, highlighting differences in privacy mechanisms, revocation handling, and scalability.

Reference	Privacy Mechanism	Revocation Handling	Scalability/Rotation
[58]	zk-SNARKs	Not supported	High computation cost; limited TPS
[59]	Proxy Re-Encryption	Limited, delegation only	Overhead grows with number of delegates
[60]	Attribute-Based Encryption	Policy-based revocation (complex)	Large key sizes; poor scalability to thousands of users
Proposed Method	Group Signatures + Hierarchical key Management	On-chain, immediate via smart contract	Constant-size signatures, efficient verification, low-cost key rotation

, this design provides constant-size signatures, immediate credential revocation, and efficient key rotation, addressing the scalability and credential-compromise challenges identified in prior approaches.

3. Proposed Methodology

Traditional centralized systems have inbuilt constraints such as single points of failure, scalability challenges, and privacy concerns in modern data management and governance frameworks. Our proposed approach uses blockchain for decentralized architecture and IPFS for decentralized storage to solve these problems. Furthermore, we enhance the system’s security, scalability, anonymity, and resilience while maintaining robustness by implementing a multi-manager approach within the group signature scheme. Our ultimate objective is to create a system that achieves the perfect balance between privacy and openness, giving users control over their data while maintaining the fundamental advantages of blockchain technology.

3.1. Framework Description

The proposed framework establishes a decentralized system for secure patient data management. By integrating IPFS and blockchain with hospital-specific EHR storage, it ensures both data accessibility and integrity. Users register through decentralized applications (DApps) and authenticate using group signatures, enabling secure access to the blockchain network. While specific patient data is stored on IPFS servers, the blockchain handles authentication and data retrieval processes. This integrated approach enhances the security, reliability, and interoperability of healthcare data management.

Furthermore, the framework guarantees secure patient data storage within hospitals by equipping them with dedicated EHR storage systems and leveraging decentralized IPFS infrastructure to strengthen data protection.

Figure 3 illustrates the decentralized workflow for securely requesting and verifying patient data within the proposed healthcare system. In this framework, users (doctors/patients) first register through a decentralized application, where multi-group managers oversee the registration process and provide each user with unique identification credentials for authentication. Patient data is encrypted and uploaded to a hospital-managed electronic health record (EHR) server, ensuring sensitive information remains protected at the source.

Access to the stored data is facilitated through the InterPlanetary File System (IPFS), where encrypted data hashes and associated access keys are maintained. Users can retrieve data selectively by referencing these hashes, enabling efficient and secure access without directly exposing the raw data. Group managers play a critical role in overseeing the registration process and securely distributing cryptographic keys to authorized users, maintaining strict access control and identity management.

In parallel, smart contracts operate across the blockchain to enforce consensus protocols, validate transactions, and guarantee data integrity throughout the distributed storage nodes implemented across hospital networks. This decentralized architecture not only strengthens data security and trustworthiness, but also ensures interoperability and accountability among various healthcare stakeholders.

3.1.1. Hospital EHR Storage and DApp Registration:

The proposed approach ensures secure patient data storage within hospitals by providing them with their own EHR storage system.

DApp facilitates user registration with group signature technology for enhanced security and privacy. According to Agorithm 1, each user receives a unique identifier, GPK, and GSK[i] for authentication and data access within the blockchain network. The REG(U) procedure defines the process of registering a user U, who can be either a doctor or a patient, in the proposed blockchain-based healthcare system. During registration, the system generates a unique identifier $I{D}_U$, a group public key $GPK$, and a group secret key $GSK{\left[i\right]}_U$ for the user by invoking the function $Reg\left(U\right)$. These credentials allow the user to participate in the system securely through group signature mechanisms, enabling anonymous yet verifiable authentication while maintaining accountability through group managers. The registration ensures that each user is linked to their role: if the user is a patient, their credentials are denoted as $I{D}_p$ and $GSK{\left[i\right]}_p$; if the user is a doctor, they are represented by $I{D}_d$ and $GSK{\left[i\right]}_d$. This role-based distinction supports customized access control and authorization policies in subsequent operations, ensuring privacy, security, and scalability within the healthcare data management framework.

Algorithm 1 Registration Algorithm

1: procedure Reg(U) 2:      Let $Reg\left(U\right)$ denote the registration function for user U, where U can be a doctor or a patient. 3:      The registration process involves generating a group signature $GSK{\left[i\right]}_U$ for user U using the group public key $GPK$. 4:      After registration, the user is assigned a unique identifier $I{D}_U$, a group public key $GPK$, and a group secret key $GSK{\left[i\right]}_U$. 5:      Mathematically: $$I{D}_U,GPK,GSK{\left[i\right]}_U=Reg\left(U\right)$$ 6:      Note: 7:      If the registered user U is a patient, then $I{D}_U$ is referred to as $I{D}_p$ and $GSK{\left[i\right]}_U$ is referred to as $GSK{\left[i\right]}_p$. 8:      If the registered user U is a doctor, then $I{D}_U$ is referred to as $I{D}_d$ and $GSK{\left[i\right]}_U$ is referred to as $GSK{\left[i\right]}_d$. 9:      This naming convention is used in later algorithms for role-specific operations and clarity. 10: end procedure

3.1.2. Data Addition and Encryption IPFS Storage Integration

According to Algorithm 2, after successful registration, doctors apply their unique group secret key $GSK{\left[i\right]}_d$ and assigned identifier to securely upload full patient data $D_p$ into the system via the decentralized application (DApp).

Algorithm 2 Secure Data Storage Algorithm

1: procedure SecureStore($Dp,GSK{\left[i\right]}_d$) 2:       Input: $Dp$ (Full patient data), $GSK{\left[i\right]}_d$ (Group secret key of the doctor) 3:       Output: $has{h}_{IPFS}$ (IPFS content hash) 4:       Encrypt the full patient data: $ED\leftarrow Encrypt(Dp,GSK{\left[i\right]}_d)$ 5:       Store the encrypted data into the EHR system: $StoreToEHR\left(ED\right)$ 6:       Select sensitive data (e.g., allergies) from the EHR: $D_{sel}\leftarrow SelectFromEHR\left(ED\right)$ 7:       Store selected data on IPFS and obtain a content hash: $h_{IPFS}\leftarrow IPFS\_Store\left(D_{sel}\right)$ 8:       Link the IPFS content hash to the blockchain for verification: $Blockchain\_Link\left(h\right)$ 9:       return $has{h}_{IPFS}$ 10: end procedure

The data is first encrypted using $GSK{\left[i\right]}_d$ to ensure confidentiality and data protection before being transmitted to the electronic health record (EHR) server. A selected extraction procedure in the EHR system finds important medical data, like allergies, chronic illnesses, or emergency information. This selected sensitive subset is then stored on the InterPlanetary File System (IPFS). Upon uploading to IPFS, a unique content hash ${\mathrm{hash}}_{IPFS}$ is generated, representing the exact location of the data on IPFS without exposing the raw medical data.

This content hash is subsequently registered and linked onto a blockchain network, thereby ensuring data integrity, traceability, and immutability.

3.1.3. Blockchain Network Connectivity

Every hospital serves as a node in a decentralized blockchain network, creating a dispersed and robust infrastructure for patient data management. Furthermore, the blockchain network is seamlessly integrated with the Inter-Planetary File System (IPFS) storage, allowing for the safe and decentralized archiving of patient data.

3.1.4. Data Retrieval Process

After registration and secure data storage, patients can retrieve their medical information through a verified process to ensure secure access and maintain confidentiality, according to Algorithm 3. When a patient p initiates a request to access their data, the system first verifies the patient’s identity and authenticity by validating their unique identifier $I{D}_p$ and group secret key $GSK{\left[i\right]}_p$ through the blockchain network. This ensures that only authorized users can retrieve sensitive information. Upon successful verification, the system retrieves the corresponding IPFS content hash ${\mathrm{hash}}_{IPFS}$ associated with the patient’s stored selective medical data. Using this content hash, the encrypted selected data $EncDat{a}_p$ is fetched directly from the IPFS server. The retrieved encrypted data is then decrypted using the patient’s group secret key $GSK{\left[i\right]}_p$ to reconstruct the original sensitive medical information $Dat{a}_p$. This two-step process—first verifying through blockchain and then decrypting with a secret key—ensures both the authenticity and confidentiality of patient data. If the verification process fails, access is immediately denied, preventing unauthorized data retrieval attempts. This secure retrieval flow maintains data integrity, privacy, and strict access control across the decentralized healthcare system.

Algorithm 3 Data Retrieval Process

1: procedure DataRetrieval(p) 2:       Input: p (Patient requesting data) 3:       Output: $Dat{a}_p$ (Patient’s selected data) 4:       Verify the patient’s identity and group signature: $$\mathrm{status}\leftarrow Verify(I{D}_p,GSK{\left[i\right]}_p)$$ 5:       if status == success then 6:             Retrieve the IPFS content hash linked to the patient’s data: $$has{h}_{IPFS}\leftarrow Blockchain\_Fetch\left(I{D}_p\right)$$ 7:             Fetch the selected encrypted data from IPFS: $$EncDat{a}_p\leftarrow IPFS\_Retrieve\left(has{h}_{IPFS}\right)$$ 8:             Decrypt the retrieved data using patient’s secret key: $$Dat{a}_p\leftarrow Decrypt(EncDat{a}_p,GSK{\left[i\right]}_p)$$ 9:             return $Dat{a}_p$ 10:      else 11:            Verification failed: Access Denied 12:      end if 13: end procedure

3.1.5. Further Data Retrieval and Requests

Patients can directly request detailed information from their registered hospital’s EHR via the IPFS server, bypassing middleman verification through the blockchain network. This streamlined process ensures secure data retrieval, enhancing accessibility without compromising patient data security.

Here, Figure 4 shows the sequential workflow of the proposed framework. In the registration phase, users enroll through the DApp using Algorithm 1 with group signature authentication. In the data upload phase, doctors or patients encrypt and store records in the EHR, link selected data to IPFS, and record its hash on the blockchain using Algorithm 2. In the data request phase, patients or authorized entities retrieve data through blockchain verification and decryption as outlined in Algorithm 3. This ensures secure, private, and verifiable access to EHRs.

3.1.6. Key Management, Rotation, and Revocation

The framework integrates a hierarchical envelope encryption model to ensure robust key management and fast recovery from credential compromise. At the top level, organizational root keys are maintained within an HSM/KMS. Departmental Key Encryption Keys (KEKs) are derived from this root and used to wrap Data Encryption Keys (DEKs), which in turn encrypt individual electronic health records (EHRs). This structure localizes the effect of compromise—the exposure of a single DEK affects only one record—while KEK rotation can be performed without re-encrypting the underlying data. As shown in Algorithm 2, this process is applied when encrypting and storing medical records in IPFS.

Anonymous user authentication is achieved through group signatures, where each user receives a credential issued by a group manager at registration (Algorithm 1). Every transaction is validated in two steps: (i) group signature verification, and (ii) checking the user index against an on-chain revocation list. Compromised credentials are revoked via a revoke (i) transaction, which updates a compact bitset or Merkle accumulator and emits an auditable event. Revocation takes effect within a single block, and active sessions are further limited by short-lived tokens (less than 5 minutes). This verification step is integrated into Algorithm 3 (Data Retrieval).

Key compromise scenarios are handled efficiently: departmental KEK exposure triggers re-wrapping of encrypted DEKs (EDEKs), while record-specific compromise leads to DEK regeneration and re-encryption of only the affected EHR. Manager key compromise, though rare, is mitigated by key rotation and re-issuance of member credentials. Key lifetimes are enforced periodically (root annually, KEKs quarterly, DEKs per update), and all rotation/revocation actions are logged both on-chain and within the KMS audit trail.

This layered design, illustrated in Figure 5, builds directly upon Algorithms 1–3, enabling scalable and auditable key management while ensuring confidentiality and resilience against compromised credentials in healthcare blockchain networks. A common conflict arises between blockchain immutability and GDPR’s “right to erasure.” As shown in Figure 6, the hospital EHR remains the primary storage for Protected Health Information (PHI), while only pseudonymous metadata and selectively encrypted subsets are linked via IPFS and the blockchain. PHI is encrypted using per-record Data Encryption Keys (DEKs), which are wrapped under departmental Key Encryption Keys (KEKs) and secured by an organizational root key in an HSM/KMS (envelope encryption). Group signature keys (GPK/GSK) are used only for anonymous authentication and credential revocation, not for encrypting PHI. When an erasure request is made, the patient is authenticated, the corresponding DEK is destroyed in the KMS (crypto-erasure), related IPFS entries are unpinned and dereferenced, and RevokeCID and ErasureReceipt events are logged on-chain. As depicted in the figure, this process ensures PHI becomes permanently unreadable while the blockchain ledger remains immutable, thereby reconciling GDPR’s “right to erasure” with Health Insurance Portability and Accountability Act (HIPAA) confidentiality requirements.

3.1.7. Operational Context for Evaluation

In a typical hospital workflow, we considered a patient receiving regular care for diabetes. For example, the patient’s blood test results are uploaded through the DApp, encrypted, and stored in the hospital’s EHR system. A selected portion of sensitive data is then stored in IPFS, and its content hash is linked to the blockchain. The doctor, after authenticating, retrieves the data by verifying the patient’s identity through the blockchain and accessing the corresponding encrypted file from IPFS. This process is repeated for larger records such as imaging scans, and each access is immutably logged, ensuring accountability across the hospital network.

Building on this workflow, we assume a hospital-scale deployment consisting of 5–20 nodes. Each node runs an Ethereum client connected to IPFS. The system is evaluated on the Proof-of-Stake (PoS) Ethereum test network (Sepolia). Patients and doctors interact with the system through a decentralized application (DApp) integrated with MetaMask. Medical records are represented as encrypted files, ranging from small reports to large imaging data.

In this research, the framework is planned to be evaluated using several metrics. Gas consumption is expected to be measured for each contract function, latency is intended to be recorded from request to blockchain confirmation, throughput is planned to be assessed by transactions per second, and scalability is proposed to be analyzed by varying file sizes, block sizes, and node counts. These metrics are intended to provide a baseline for future performance assessment.

4. Result and Discussion

This section explores the efficiency of blockchain integration and encryption techniques in enhancing healthcare data management and compares with the existing methodologies.

4.1. Environment Configuration

The Remix IDE offers a complete virtual environment for creating and executing smart contracts on the Ethereum network. It seamlessly handles smart contract integration within its platform, streamlining the process. MetaMask authentication is required to deploy the contract successfully. The entire smart contract implementation process occurs within the Remix IDE environment. Figure 7 demonstrates the transaction transfer to the blockchain network via the MetaMask extension tool where the Sepolia testnet network is used for the integration with a test ethereum blockchain network.

After confirming the transaction in MetaMask, a healthcare contract will be generated, as depicted in Figure 8. After confirmation of the transaction, its data will be added to the Ethereum platform, including details such as the transaction hash, transaction fee, and other relevant information shown in Figure 9.

4.2. Deployed Contract

With the help of the given Solidity smart contract, "Healthcare," patient and physician data can be managed on an Ethereum blockchain healthcare system. As seen in Figure 10, it constructs two primary structs, "Patient" and "Doctor," to hold data such the patient’s name, age, health status, and the doctor’s name and ID. Functions to set and retrieve these details for physicians and patients are included in the contract. As seen in Figure 11, these features enable the safe archiving and retrieval of healthcare-related data on the blockchain, promoting openness and accessibility in healthcare administration.

4.3. Performance Analysis

The research has found significant advancements in security, efficiency, and traceability with the following advancements:

• The proposed framework establishes a decentralized and secure system for managing patient data by integrating blockchain, IPFS, and hospital-specific EHR storage, ensuring high data integrity and accessibility.
• Our system maintains low and predictable latency even as block size increases, supporting timely access to patient data without significant delays.
• The system maintains reliable throughput across varying file sizes, demonstrating scalability and efficient resource management even when handling larger health records or medical images.

To assess the performance of the proposed system, key factors such as latency and throughput were evaluated under varying conditions. Figure 12 demonstrates the scalability and robustness of the proposed approach with respect to changes in block size. The X-axis represents the block size (in MB), while the Y-axis denotes the latency (in milliseconds). While an increase in latency is observed as the block size grows, the rate of increase remains controlled and linear, with latency values ranging from approximately 90 ms to 200 ms as the block size expands from 0.5 MB to 16 MB. This trend reflects the system’s optimized architecture, which effectively mitigates latency overhead despite larger data transmissions. These results support the proposed system’s ability to maintain a favorable throughput-latency balance under diverse workload conditions, making it well-suited for healthcare applications that demand timely access to large patient records, medical imaging data, and secure health information exchanges.

The effect of different file sizes on the suggested system’s throughput is shown in Figure 13. The file size is displayed on the X-axis in kilobytes (KB), while the throughput is displayed on the Y-axis in transactions per second. The throughput gradually decreases from about 200 transactions/sec to about 90 transactions/sec as the file size grows from 10 KB to 800 KB. Even though the system becomes less efficient, its performance declines in a steady and predictable way, which shows that load allocation and resource management are working well. This behavior highlights the system’s scalability and resilience, which makes it ideal for healthcare applications where data sizes might vary greatly but reliable performance is essential to guaranteeing safe and prompt data transfers.

Since group signatures are central to our authentication mechanism, we include representative performance data from recent benchmarking studies. Using the BBS04 pairing-based construction, prior evaluations report signature generation and verification times of approximately 1–3 ms on commodity hardware, with constant-size signatures of around 200 bytes [61,62]. Revocation checks, implemented via bitset/Merkle accumulators, add negligible cost (sub-millisecond).

Table 3. Representative performance of group signature operations (pairing-based, BLS/BBS schemes), including the time required for signature generation, signature verification, and revocation checks, along with the corresponding signature sizes in bytes. This table provides an overview of the efficiency and storage overhead of typical group signature schemes.

Operation	Time (ms)	Signature Size (bytes)
Signature Generation	2.1	200
Signature Verification	3.0	200
Revocation Check	0.5	Negligible

summarizes these metrics, showing that group signature operations add only a few milliseconds—this is insignificant compared to the ∼12 s confirmation delay of Ethereum transactions on Sepolia.

Along with the throughput and latency results, the gas cost graph shows that the system stays efficient and scalable even as file sizes increase. Figure 14 illustrates the relationship between file size (X-axis, in kilobytes) and gas cost (Y-axis, in gas units) within the proposed healthcare system. As the file size increases from 10 KB to 800 KB, the gas cost also rises gradually. This is because larger files require more metadata, such as encrypted hashes and access keys, to be securely processed and recorded on the blockchain. Although the actual patient data is stored off-chain on IPFS and in hospital EHR systems, the blockchain still handles critical operations like access control, authentication, and data verification. These processes become slightly more complex with increasing file size, leading to a controlled and linear increase in gas usage. However, in healthcare applications, this trade-off is acceptable, as ensuring the privacy, security, and integrity of sensitive patient information is far more important than minimizing gas costs. The graph thus demonstrates the system’s ability to scale efficiently while upholding strict healthcare data protection standards.

4.4. Comparative Analysis of Privacy Mechanisms

To assess the suitability of different privacy-preserving cryptographic mechanisms for electronic health record (EHR) sharing, we compared group signatures with zero-knowledge proofs (ZKPs), proxy re-encryption (PRE), and attribute-based encryption (ABE).

Table 4. Comparison of alternative cryptographic mechanisms with respect to suitability in healthcare EHR sharing. Group signatures provide the most balanced trade-off between privacy, efficiency, and scalability, making them preferable for hospital-scale deployments.

Mechanism	Advantages	Limitations in Healthcare EHR Context	Scalability Concern
Zero-Knowledge Proofs (ZKP)	Strong privacy, non-interactive proofs possible	High computation cost, inefficient for frequent authentication	Scales poorly with frequent transactions
Proxy Re-Encryption (PRE)	Enables delegation without sharing private keys	Complex key management, added decryption latency	Overhead grows with number of delegates
Attribute-Based Encryption (ABE)	Fine-grained access control policies	Large key sizes, high ciphertext overhead	Scalability issues for thousands of users
Group Signatures	Anonymous authentication, constant-size signatures, efficient verification	Requires trusted group manager, credential issuance overhead	Scales efficiently with large networks using multi-manager models

summarizes the trade-offs. ZKPs provide strong privacy but incur significant computational overhead, which makes them unsuitable for frequent authentication events in clinical workflows. PRE schemes support flexible delegation but introduce complex key management requirements and decryption delays when sharing records across multiple users. ABE enables fine-grained policy enforcement, but its large key sizes and ciphertext overhead limit efficiency and scalability in networks with thousands of participants.

By contrast, group signatures enable anonymous authentication with constant-size signatures and efficient verification. Table 4 presents the comparative analysis. While the scheme requires a group manager to issue and revoke credentials, this model aligns well with hospital governance structures. Moreover, multi-manager extensions support horizontal scalability across institutions. Therefore, group signatures strike the best balance of privacy, efficiency, and scalability for large healthcare networks.

4.5. Comparison with the Existing Systems

With the growing need for secure and efficient healthcare data management, many researchers have explored blockchain and IPFS-based solutions. However, existing systems face several challenges that limit their practical use in real-world healthcare environments.

The comparison of previous studies [28,63,64,65,66] shows that many blockchain and IPFS-based healthcare systems face problems like slow performance, high costs, and weak privacy protection. Most of these systems rely on external encryption, which can be complicated and less secure. They also have complex smart contracts that can cause bugs and are not always tested in real hospitals. Regulations like HIPAA and GDPR are hard to follow because data on the blockchain cannot be changed or deleted. Additionally, many earlier systems do not work well with existing hospital software and have trouble managing users and their access rights at a large scale.

Table 5. Comparison of proposed system with previous systems.

Feature	Kaur et al. [28]	Khan et al. [63]	Tiwari et al. [64]	Mallick et al. [65]	Ma et al. [66]	Proposed System
Scalability	High gas and encryption overhead	High gas fees and latency	Improved but limited scalability	Limited throughput	Dependent on Ethereum congestion	Controlled latency, scalable throughput for large files
Data Privacy and Encryption	Depends on external CP-ABE encryption	Privacy risks due to blockchain transparency	Requires external encryption	Limited privacy focus	Metadata privacy limited	Uses group signatures and source encryption; secure IPFS storage
Smart Contract Security	Complex smart contract management	Risk of bugs from insufficient auditing	Complex system due to combined tech	Complex integration	Requires specialized expertise	Optimized smart contracts for validation and consensus
Regulatory Compliance (HIPAA/GDPR)	Not specifically addressed	Challenges due to immutability	GDPR “right to erasure” conflict	Not deeply addressed	Not addressed	Group signature and encryption support confidentiality and privacy needs
Real-World Integration	Simulated only	Prototype, no live integration	Limited integration	Limited hospital interoperability	Not deployed in real environments	Integrated with hospital EHR systems and tested for real-world use
Interoperability	Not addressed	Not addressed	Difficult integration with legacy systems	Limited interoperability	Not addressed	Designed for hospital EHR compatibility via blockchain and IPFS
User Management	Complex and unscalable attribute management	Not addressed	Not addressed	Not addressed	Not addressed	Uses group signatures for scalable decentralized authentication

summarizes a detailed comparison of key features across the reviewed systems and highlights how the proposed system outperforms them. Regarding scalability, earlier works suffer from high gas fees, latency, or throughput limitations, while our system supports smooth handling of large files with controlled latency. In terms of data privacy and encryption, previous solutions mostly depend on external methods or offer limited protections. In contrast, our system uses group signatures and source-side encryption, ensuring secure and decentralized storage using IPFS.

Smart contract security is another concern, as many existing systems have overly complex implementations, increasing the risk of bugs. Our proposed system simplifies this by using optimized smart contracts that are streamlined for validation and consensus, reducing vulnerabilities. Regarding regulatory compliance, only a few systems address HIPAA or GDPR. Our system, however, is designed with confidentiality and access control in mind, aligning with regulatory requirements using group-based access and encryption.

Real-world integration and interoperability are often lacking in prior works, which are either simulated or partially implemented. Our system stands out by being tested with actual hospital EHR systems, ensuring real-world applicability. Additionally, our use of group signatures allows scalable and decentralized user management which is not supported in earlier models.

Overall, these comparisons clearly show that the proposed system offers significant improvements in performance, security, privacy, compliance, and practical deployment, making it a more viable and effective solution for real-world healthcare environments.

4.6. Scalability Evaluation with Simulated EHR Data

To approximate realistic hospital conditions, we generated simulated EHR workloads based on record distributions reported in benchmark datasets such as MIMIC-III [67]. File sizes ranged from 128 KB laboratory reports and 256 KB prescriptions to 512 KB doctor notes and 2 MB imaging scans, with access frequencies reflecting typical hospital use patterns (20 lab reports, 15 prescriptions, 10 notes, and 5 imaging scans per patient). The tests were conducted on a multi-node setup with standard server hardware and typical LAN network conditions.

As shown in Figure 15, throughput scales nearly linearly up to 3000 requests/s, achieving 2350 tps with an average latency of 400 ms. Beyond this point, the curve begins to flatten, with throughput stabilizing at 2700 tps under 5000 requests/s. Latency rises more sharply (up to 650 ms), while success rate remains above 92 percent. This flattening effect is primarily due to consensus delays in the PoS network and IPFS retrieval overhead, which become more pronounced under high concurrency.

5. Conclusions

This research presents a novel decentralized framework for managing healthcare data using blockchain, IPFS, and group signatures. It ensures data security, privacy, and integrity while enabling easy and secure data exchange between healthcare providers. The optimized architecture of the system maintains efficient performance even with large data sizes, as shown in the experimental results. Our approach provides a robust, scalable solution that improves patient care and builds trust in healthcare data management by combining advanced technologies for secure, transparent, and efficient data handling. In contrast to existing works that combine blockchain with IPFS and conventional encryption, our framework advances the state of the art by integrating group signatures, hierarchical KEK/DEK management, and smart contract–based revocation. This combination not only strengthens privacy but also addresses scalability and credential-compromise challenges, which remain limitations in many prior approaches.

However, the system is not without limitations. Challenges such as energy consumption, transaction latency, and potential deployment barriers in large-scale healthcare infrastructures need to be carefully addressed before real-world adoption. Moreover, ensuring compliance with strict regulatory frameworks like GDPR poses additional hurdles, especially when dealing with highly sensitive electronic health records (EHR). In the future, we aim to test this system in real healthcare settings. We are actively communicating with hospitals to explore opportunities for deployment and real-world validation. Currently, due to General Data Protection Regulation (GDPR) restrictions, we cannot access or test real EHR datasets, which continues to pose a significant challenge. Nonetheless, practical testing will provide valuable insights into usability and integration with medical workflows, allowing us to refine the system for everyday clinical practice.

Synthetic EHR evaluation demonstrates that the system sustains thousands of concurrent requests while maintaining high success rates, confirming its feasibility for hospital-scale deployment. Furthermore, future research directions can focus on integrating blockchain and IPFS with emerging technologies such as IoT-enabled medical devices and AI-driven analytics, which can enhance automation and predictive healthcare. Additionally, addressing regulatory challenges and establishing globally accepted standards will be essential for broader adoption. By advancing in these directions, secure, efficient, and patient-centered digital healthcare ecosystems can become a reality.