ORIGINAL RESEARCH

Blockchain-Enabled Electronic Health Record Model for Managing Patients’ Vital Data and Medical Reports

Aditi Sharma, PhD¹ ; Rajesh Kumar Kaushal, PhD¹ ; Naveen Kumar Chitkara, PhD¹ and Ekkarat Boonchieng, PhD²

¹Research Scholar, Department of Computer Science and Engineering, Chitkara University Institute of Engineering and Technology, Chitkara University, Punjab, India; ²Professor, Department of Computer Applications, Chitkara University Institute of Engineering and Technology, Chitkara University, Punjab, India; ³Professor, Department of Computer Science and Engineering, Chitkara University Institute of Engineering and Technology, Chitkara University, Punjab, India; ⁴Department of Computer Science, Faculty of Science, Chiang Mai University, Chiang Mai, Thailand

Keywords: blockchain, electronic health record, hyperledger fabric, hyperledger caliper, performance evaluation, remote patient monitoring

Abstract

The Internet of Medical Things is revolutionizing the concept of patient care. It is empowering the implementation of remote patient care protocols through the use of body sensors to monitor vital signs. However, it produces vast amounts of information, which raises security and privacy concerns. High-dimensional medical data are essential for diagnosis and treatment, but they are not currently connected to blockchain-based electronic health record systems. To overcome these limitations, the authors present a Hyperledger Fabric-based secure remote patient monitoring model for storing and retrieving medical imaging. The system records patient vital signs using sensors and stores medical images off-chain in the InterPlanetary File System. This model uses two organizations and a single channel, with Raft consensus, to ensure data consistency and high performance. Additionally, this study evaluates the performance of the proposed system in terms of throughput and latency. A test was conducted at 1,200 transactions with varying transfer rates. The results reveal that the throughput was near the send rate, up to 90 TPS. At a send rate of 150 TPS, the system reaches its peak throughput of 117.04 TPS. Moreover, no transactions were lost, which means that the system was able to make all its transactions, representing system reliability. The latency was noted to be 0.21 to 2.24 s, whereas the read operation was always characterized by the same latency of 0.01 s.

 

 

The electronic health record (EHR) is the core component of modern clinical treatment, which makes patient histories, diagnostic findings, and prescriptions easily accessible, which improves quality and facilitates research. Hospitals have to preserve sensitive patient information and rapidly retrieve and evaluate it for medical decision-making after they adopt digital technologies. However, EHR adoption shows that the challenges include a lack of communication, inadequate data consistency across systems and providers, centralization, a lack of imaging support, and significant privacy and security issues when sharing private medical information.²

Recent reviews and data-quality research highlight that while EHRs enhance accessibility and support clinical decision-making, they must be equipped with robust governance and technical solutions to prevent integrity and patient privacy issues.³ New models are thus increasingly adopting decentralized design patterns and data stores to achieve clinical value and security. These trends highlight the transition from centralized, institution-centric records to patient-centered systems that prioritize regulated sharing and history assessment.

Figure 1 depicts the workflow of a conventional EHR system built around a centralized architecture. The application programming interface (API) allows patients and physicians to register, add medical history, and keep prescriptions and laboratory findings all in a centralized cloud-based database. This repository is where healthcare providers get information about patients to diagnose and treat them. This system has weaknesses, including a single point of failure, lack of data immutability, weak encryption, and failure to support complete medical reports, all of which could compromise data security.

Fig. 1. Process of traditional electronic health records, API: application programming interface, Dx: diagnosis, MR: medical record, Rx: prescription.

In contemporary healthcare, EHRs are important because they centralize a patient’s health information. This integration improves clinical decision-making and the continuity of care provisions by different providers in addition to reducing medical errors.^4,5 Although EHRs enhance the quality of clinical documents, there are significant inadequacies, such as the absence of real-time patient information, slow monitoring, and low continuity in environments other than hospitals.⁶

To address these gaps, remote patient monitoring (RPM) systems have been introduced, enabling the continuous collection of patient vital signs, physiological indicators, and data from home, thereby improving early diagnosis and decreasing hospital readmissions.⁷ However, when combined with EHR, RPM has created new challenges, including data overload, reliability issues, centralization, multi-device interoperability, and gaps in medical image data. These limitations made it necessary to introduce blockchain, which provides tamper-proof storage, decentralized access control, and secure integration of RPM streams into EHR systems.^8,9 As a result, blockchain enhances trust, ensures data integrity, and enables secure, cross-institutional sharing of both EHR and RPM data at scale.

The major contributions of this work are as follows: First, we demonstrate how an enhanced blockchain-based model, integrated with InterPlanetary File System (IPFS) and RPM, can be developed to improve diagnosis. Second, we illustrate the approach that can be employed to integrate Internet of Things (IoT) sensors, a fabric network, and IPFS to build an EHR system capable of handling patient vital data and medical reports. Third, we demonstrate which strategy can be employed to compute the performance of such an enhanced model.

Literature Review

Multiple studies have been conducted to develop a tamper-proof model for RPM and integrate these data with EHR. A systematic search across Google Scholar, IEEE Xplore, PubMed, and other peer-reviewed databases was used to select the studies. We used keywords “Blockchain” AND “EHR,” “Blockchain” AND “RPM,” and “Blockchain” AND “Performance parameters.” What follows is a summary of the relevant published studies regarding blockchain-based systems.

Kayikci and Khoshgoftaar investigated the combination of blockchain technology and machine learning, which shows that blockchain can improve data integrity and ML model transparency, but issues with scalability, throughput, and regulatory compliance still exist.¹⁰ Future directions emphasize the necessity of effective consensus processes, privacy-preserving techniques, and hybrid architectures. Although blockchain has been used in many fields, it is still difficult to manage medical imaging and EHR data effectively.

In another study, Charles and Delgado¹¹ explored the potential of blockchain technology to manage and monetize health data as an intangible asset and enhance the transparency for patients and organizations. The authors concluded that blockchain facilitates trusted data sharing, consent, and secure transactions and enables new health data to empower patients and improve data-driven research. However, there is an absence of consistent valuation processes, complex legal and ethical issues, data-reduction concerns, and uncertainty about applying equitable monetization and privacy-preserving processes.

Cheikhrouhou et al.¹² presented a lightweight, fog-enabled, blockchain-based RPM system to improve resource management, security, and response time in IoT-based healthcare. It enhances data privacy, reduces latency, and facilitates real-time medical decisions by combining fog computing, IoT devices, and a lightweight system. According to the results, compared to cloud-based solutions, responsiveness is increased by 40%, energy consumption is decreased by 36%, and transaction retrieval is 55.1% faster.

Husnain et al.¹³ addressed and enhanced the critical challenges related to data security, scalability, privacy, and interoperability in the healthcare sector. They proposed an Ethereum-based EHR system that uses smart contracts for consent management and secure data transfer through enhanced encryption. According to experimental results, data breaches decreased by 50%, interoperability improved by 40%, and data access increased by 30%. Further work will focus on improving performance and complying with new healthcare information technology requirements.

To enable patients to control their medical information, the research will develop a secure, decentralized system for storing and sharing EHRs using blockchain technology and QR codes. Dobre and Vasilățeanu¹⁴ conclude this will entail the creation of a working prototype that can handle EHR authorizations through blockchain smart contracts and allow patients to transfer their data with physicians, but only the information they wish to provide to them, through temporary QR codes. In the future, this system will be integrated into larger healthcare infrastructures, interoperability will improve, and patient control over data access across platforms will increase.

Carter et al.¹⁵ conducted research on the application of blockchain technology, Bitcoin, Ethereum, and Hyperledger to enhance EHR management and security, minimize fraud, and improve patient-centered care in healthcare systems. The authors reported some major limitations, which include scaling, storing, code vulnerabilities, and the inability to interoperate across different blockchains, as well as the problem of privacy issues and blockchains based on HIPAA (the U.S. Health Insurance Portability and Accountability Act), the risk of vendor lock-in, and the absence of regulatory requirements or vendor collaboration, which make blockchain not yet scalable to a large scale in healthcare.

It has been emphasized that a systematic evaluation should be conducted to select an appropriate blockchain framework for EHR systems based on RPM, capable of handling medical images. The authors compare throughput, latency, and data security in the management of patient records. It emphasizes the importance of applying an appropriate framework to the management of medical imaging in RPM and gives information on how to develop safe and scalable EHR systems in decentralized healthcare systems.¹⁶

To improve data security, privacy, and efficiency, it is recommended that a Hyperledger Fabric-based RPM system be used to manage real-time patient vital information effectively. The data are sent to a blockchain server using Message Queuing Telemetry Transport (MQTT), and microcontrollers receive data. The system’s suitability for real-time applications is demonstrated by a reliable throughput of 104.9 TPS at a 122.8 transmit rate and a low latency of 4.91 s at 175 TPS, as reported by Hyperledger Caliper. The discussion by Garg et al.¹⁷ focuses on the need for a better blockchain-based EHR to achieve RPM, ensure interoperability, securely store key data, and provide real-time access to patient information. Scalability testing, enhanced protection against denial-of-service (DoS) attacks, and improved data collection to accelerate disease detection are all part of future efforts.

To establish an EHR-sharing system, another study by Carter et al.¹⁸ based on Amazon Web Services and Ethereum was conducted to address data exchange, security, and inefficient workflow. It shows that secure data sharing and automation can enhance the use of multilayer encryption, smart contracts, and Fast Healthcare Interoperability Resources standards. The cloud is used to eliminate the storage capacity of blockchain as well as improve its scalability. Results represent improved interoperability, transparency, and less administrative work. However, its negative characteristics are the slowness of Ethereum, the inability of blockchain to store big files, and dependency on the cloud.

Kaushal et al.¹⁹ sought to develop and test an RPM system that is safe for Hyperledger Fabric to store patient vitals on an immutable blockchain. It is based on ESP32 sensors, Node.js API, smart contracts, and a two-organization Fabric network, and its experiments demonstrate 100% successful packet delivery, high fault tolerance, and throughput; write throughput decreases with an increase in transaction rate. The drawback is that the system only supports basic vital signs and limited scalability testing; however, this framework can eventually be expanded to handle more complex healthcare data and medical images by adding appropriate storage methods and increasing network bandwidth.

Tahir et al.²⁰ resolved the issues of the centralized EHR system as a single-point failure, low security, and weak interoperability by replacing it with a decentralized blockchain system, where the patient decides who is allowed to access their information, and it remains resistant. The system is safe and reliable for storing and sharing encrypted records, with enhanced privacy, transparency, and performance, using Ethereum, smart contracts, and IPFS. Only fundamental health data and vital signs are currently stored. Still, it would be beneficial to extend this framework to medical images such as X-ray, computed tomography (CT), and magnetic resonance imaging (MRI), which would offer greater clinical value, more powerful diagnostics, and a more holistic patient-health environment.

Ullah et al.²¹ by addressing security, privacy, and interoperability concerns of centralized EHRs, their article proposes EHRChain, a decentralized blockchain with fine-grained access control. The system enhances data integrity, latency, and throughput through Ethereum smart contracts, IPFS storage, and Attribute-Based Encryption (ABE). Its disadvantages are increased execution time, higher storage costs, and heavy cryptographic overhead. This model could be extended to store not only vital signs, but also medical images on blockchain and would be of great value to doctors and clinical decision-making in the future.

In summary, this literature review shows that while various studies have investigated blockchain-based EHRs and RPM systems, most lack integration of medical imaging and performance evaluation. It is seen in the present state of the art, illustrated in Table 1.

Table 1. The state of the art on blockchain-based EHR systems

Contributors (Year, Ref #)	EHR	Blockchain	RPM	Medical images	Performance evaluation
Kaushal et al. (2025)19	✓	✓	✓	✗	✓
Kayikci et al. (2024)10	✗	✓	✗	✗	✗
Noor Ul Ain et al. (2024)20	✓	✓	✓	✗	✓
Dobre et al. (2024)14	✓	✓	✗	✗	✗
Husnain et al. (2024)13	✓	✓	✗	✗	✓
Garg et al. (2024)17	✓	✓	✓	✗	✓
Ullah et al. (2024)21	✓	✓	✗	✗	✓
Hasnain et al. (2023)22	✓	✓	✗	✗	✗
Cheikhrouhou et al. (2023)12	✗	✓	✓	✗	✓
Upadrista et al. (2023)16	✓	✓	✓	✗	✗
Charles & Delgado (2022)11	✓	✓	✗	✗	✗
Salleh et al. (2021)23	✓	✗	✗	✗	✓
Carter et al. (2020)24	✓	✓	✗	✗	✗
Carter et al. (2019)15	✓	✓	✗	✗	✗
Carter et al. (2019)18	✓	✓	✗	✗	✗
Proposed Work	✓	✓	✓	✓	✓
EHR: electronic health record; RPM: remote patient monitoring.

Furthermore, no literature review shows that no study has proposed a model that addresses all essential elements of EHR, such as blockchain-based capabilities, handling patient medical reports, and integrating patient vitals collected regularly from remote locations via IoT sensors.

Methodology

A multi-phase approach is used under this research methodology to design and assess a blockchain-based EHR system that integrates medical imaging and RPM data. Using decentralized technology, the design prioritizes the safe collection, transmission, and retrieval of real-time health data, as shown in Figure 2.

Fig. 2. Methodology for integrating RPM (remote patient monitoring) with Hyperledger Fabric-based blockchain.

Define Use Case

By utilizing sensors and innovative medical devices, RPM has become an effective alternative in contemporary healthcare, enabling continuous patient health tracking outside of clinical settings. The IoMT sensors are commonly used to record vital parameters such as heart rate, body temperature, and blood oxygen saturation in real time.²² The EHR system cannot be complete without medical reports that include X-rays, ECGs, CT scans, and MRIs. This article presents an advanced EHR capable of storing patient vitals and medical reports.

Set Up a Blockchain Network/Sensor Interface

The Hyperledger Fabric network design process requires several essential components that operate under a dual-organization architecture, in which each organization maintains and controls a single peer node. Moreover, a single channel of communication constitutes the focus of the network structure that allows the two organizations to safely communicate and retrieve patient information, such as vital signs and medical images. For RPM systems, real-time data from sensors and imaging devices are required to be securely recorded, transmitted, and verified across organizations like hospitals, diagnostic centers, or telemedicine providers. With one peer in every node, Reversible Addition-Fragmentation chain Transfer (RAFT) consensus, and single-channel design, the network achieves a balance between decentralization and performance, making it highly suitable for blockchain-based healthcare solutions.^25,26

For the deployment of a distributed network, an HPC server is used; details of both hardware and software are provided in Table 2. To manage the configured services on a single system, Docker and Docker Compose are installed on the Linux server (HPC) along with the Hyperledger Fabric network. Thereafter, the proposed model is set up as a network using a topology that consists of two organizations, a single peer node, and a single channel. A multi-organization topology is set up on the same server due to a lack of multiple HPCs. The blockchain layer, which is implemented using Hyperledger Fabric, ensures transaction validation and access control via smart contracts. In addition to this, smart contracts deployed on the Hyperledger Fabric network ensure read/write operations for both organizations using a distributed environment. This study suggests the following Hyperledger Fabric network architecture to create the RPM system.

Table 2. System requirements for setting up a Hyperledger Fabric network

Component	Requirement
Operating system	Ubuntu Linux 20.04
Processor (CPU)	Intel Xeon @ 2.20 GHz
RAM	32 GB
Disk Space	100 GB
Docker	Container 24.0.6
Docker composer	2.21.0 version
Node.js	version 18.17.0
Curl	7.68.0
Hyperledger Fabric	2.5.3 version
Hyperledger Caliper	0.5.0

• Dual organization
• One peer in every organization
• Ordering services
• Raft-based ordering service
• Single channel

Hyperledger Fabric v2.5.3 is installed on Ubuntu Linux 20.04 with 16 GB of RAM and a 256 GB Hard disk to set up the blockchain network. Table 2 explains the system configuration for setting up a Hyperledger Fabric network.

The RPM is a medical approach that uses wearable sensors and IoT devices to monitor patients’ vital signs, such as body temperature, SpO₂, and heart rate, outside conventional hospital environments. It improves patient outcomes, facilitates early diagnosis, and reduces the load on the healthcare system. To ensure accurate data collection, each sensor’s technical specifications and setups are described.

Table 3 shows the main node for daily data collection. It uses a Wi-Fi module to send the patient’s vitals to the blockchain network, where a smart contract validates and finally stores them on the Hyperledger Fabric, which makes it a reliable setup for patient monitoring.²⁷

Table 3. Sensor configuration

Parameter	Sensor name	Type	Specification
Heart rate	MAX30100	Photoplethysmography (PPG)	Range: 30–240 bpm Voltage: 1.8v–3.3v Dual function with SpO2
SpO2	MAX30100	Optical pulse oximeter	Range: 0–100% Accuracy: ±2%
Body temperature	DS18B20	For analog/digital type	Accuracy: ±0.50C Voltage: 4V–30V/3.0V–5.5V
BPM: beats per minute; C: ; SpO2:peripheral oxygen saturation; V: volts.

To comprehend this, the ESP32 constantly measures the vital signs of the patient after a time interval of 5 s through six consecutive cycles for a total of 30 s, compiles all the recorded values, calculates the average of each vital, and sends the average values to the blockchain ledger, which virtually lowers the constant traffic. The payload size varies due to varying patient information and doctors’ prescriptions, as different patients may be suffering from different diseases. As a result, the payload with context for the prescription is dynamic in nature. As far as the sensor data are concerned, it is in JavaScript Object Notation (JSON) format, and the payload size remains approximately closer to 2 KB. In contrast, the patient’s medical information and physician prescriptions have more detailed clinical data, so the size of the payload varies between 6 and 10 KB.

It is compatible with both digital and analog inputs, supporting various communication protocols like Constrained Application Protocol (CoAP) and MQTT.

Composing Business Logic Using Smart Contracts/Integrating Sensors

The RPM employs the IoT and wearable sensors to remotely monitor the patient’s vitals in a non-conventional environment to facilitate patients with mobility concerns and early diagnoses of critical diseases. Smart contracts, frequently referred to as chaincode in Hyperledger Fabric, are essential for automating business logic and safely handling sensor-generated health data in the proposed blockchain-enabled RPM system. Every sensor node is attached to an ESP32 microcontroller, which uses the Hyperledger Fabric protocol to send real-time patient data to the blockchain network.¹⁹ Smart contracts are immediately activated to validate, process, and store the incoming health records as soon as the data enters the network.²⁸ The integration of blockchain and IoT enhances stakeholder security and confidence by storing health data in an immutable ledger.

Algorithm 1: Secure Transmission of RPM Data to Blockchain

PROCEDURE ReadVitals (ESP32)

1: Initialize the ESP32 microcontroller and sensor modules

2: Set counter ← 0

3: Set N ← 6 // total number of sensor readings

4: Initialize buffer array B[ ] // buffer array to store sensor readings

5: WHILE (counter < N) DO

6:  vitals ← ReadSensorValues() // acquire data from RPM units

7:  Store values in buffer array B[counter]

8:  Wait for 5 seconds // sensing interval

9:  counter ← counter + 1

10: END WHILE

11: Compute mean vitals from buffer array B

12: Create a JSON {patient ID, timestamp, and meanvitals}

13: Send payload to blockchain gateway API

14: IF transaction successful THEN

15:   Storage confirm

16: ELSE

19:   Log transmission error and retry

20:  END IF

END PROCEDURE

The proposed model uses blockchain-based identity authentication to ensure security and privacy. The Certificate Authority (CA), which confirms users’ identities, issues a digital certificate (public and private keys) to each registered entity on the network. The blockchain network verifies the user’s identity when a file is uploaded or a data access request is made by matching the public and private keys. Only verified and authorized users may execute transactions or upload files to IPFS. To ensure that only authorized persons access the stored medical data, the same authentication method is used for data retrieval. In addition, a unique ID is assigned to these entities, called MSPID. This MSPID is utilized to identify who is submitting a transaction. The MSPID interacts with the Membership Service Provider (MSP) to secure the digital identities and certificates of users, peers, and orderers and use them in access control policies.

This proposed model is shown in Figure 3, where patients’ vital data obtained from RPM sensors are directly sent to the blockchain network and stored on-chain using smart contracts running in the Hyperledger Fabric network. Along with the vital parameters, essential patient information, medical history, and transaction timestamps are also stored on the blockchain ledger. On the contrary, medical images are stored off-chain using the IPFS because they are too large to store on-chain. Depending on the diagnostic data source, the patient and the physician can upload medical images to the IPFS server. After uploading an image, IPFS creates a unique cryptographic content identifier (CID), also known as a hash, that serves as the file’s unique identifier. The generated IPFS hash is then stored in the blockchain ledger instead of the entire image.

Fig. 3. Proposed model for electronic health records (EHRs) system.

This hash is a secure key that allows authorized users to access the medical image from IPFS when needed. By doing so, the physician will be able to not only access the on-chain patient vital data, but also the off-chain medical images mentioned by the IPFS hash and analyze the condition that the patient is in and give a suitable prescription. The prescription and the transactions are then safely stored on the blockchain. The proposed blockchain network is set up on a single server, simulated with multiple organizations, where peers of every organization are maintaining an individual copy of the ledger.

The IPFS is a decentralized storage and file-sharing protocol that uses content-based addressing instead of conventional location-based strategies. Rather than directly uploading large medical images onto the blockchain, IPFS maintains them off-chain and provides a distinct cryptographic hash to each file.²⁹ This hash will be stored in the blockchain, and it will be immutable, traceable, and minimize storage overhead.²⁸ The proposed research indicates that IPFS will provide safe, scalable, and functional management of high-dimensional medical data.²⁹ Hyperledger Fabric provides access control, transaction confidentiality, and transaction reliability. When combined, they provide an extensive and patient-centered EHR structure.

The proposed technique uses smart contract logic based on a unique user identity to implement basic access control. Entities such as doctors and patients are given a unique ID when they are registered in the system. These IDs are used by the smart contract to identify who is initiating a transaction and thus help in access control. A doctor is initially linked to a patient at the time of registration. The patient’s medical information and related records are only accessible to the authorized linked physician. The smart contract immediately revokes access from the previously assigned doctor and allows access to the newly allocated doctor if the patient is later assigned to a different physician. Additionally, patients can also grant or remove access permissions and maintain control over their data. This ID-based method offers a simple yet efficient solution to access management.

Reliability Testing and Performance Evaluation

The reliability of the proposed model is also confirmed through the Hyperledger Caliper benchmarking tool, where workloads are as high as 210 TPS. The evaluation indicated that no transaction failed during any of the read and write operations in Tables 4 and 5. The system’s reliability is demonstrated by the 100% success rate for both operations, which provides accurate data handling and integrity in a real-time RPM scenario.

Table 4. Caliper results for write operations

Total transactions infused	Successful committed transactions	Failed transactions	Average latency (s)	Throughput (TPS)	Send rate (TPS)	Total time (s)
1,200	1,200	0	0.21	15	15	80
1,200	1,200	0	0.22	29.02	30	41.35
1,200	1,200	0	0.32	59.04	60	20.32
1,200	1,200	0	0.62	89.02	90	13.48
1,200	1,200	0	0.94	110.02	120	10.90
1,200	1,200	0	1.24	117.04	150	10.25
1,200	1,200	0	2.02	117.02	180	10.25
1,200	1,200	0	2.24	115.02	210	10.43
TPS: throughput per second.

 

Table 5. Caliper results for read operations

Total transactions infused	Successful committed transactions	Failed transactions	Avg. latency (s)	Throughput (TPS)	Sent rate (TPS)	Total time (s)
1,200	1,200	0	0.01	15.1	15	79.47
1,200	1,200	0	0.01	30.2	30	39.73
1,200	1,200	0	0.01	60.1	60	19.96
1,200	1,200	0	0.01	90.1	90	13.31
1,200	1,200	0	0.01	120.2	120	9.98
1,200	1,200	0	0.01	150.2	150	7.98
1,200	1,200	0	0.01	180.2	180	6.65
1,200	1,200	0	0.01	210.1	210	5.71
TPS: throughput per second.

Reliability is tested through two experimental scenarios. In the first scenario, the IoT sensor prototype is set up to send six transactions every 5 s. After that, it calculated the mean and sent the sum of the information to the ledger.³⁰ No transaction failures were seen during this process, which shows that the interaction between the sensors and the ledger was reliable. In the second case, Hyperledger Caliper is used to simulate network traffic where all read and write transactions are successful. These results show that the proposed model is reliable because it has a 100% success rate in both real IoT-based transmission and simulation. Additionally, to evaluate reliability under massive workloads, Hyperledger Caliper was built with five clients, each producing up to 1,200 transactions at varied TPS rates.

When the test environment is created, Caliper initiates the benchmark process by deploying the required number of clients. These clients simulate real-world usage by sending transaction requests to the blockchain network according to workload requirements. By sending a predetermined number of transactions to the blockchain network, executing smart contracts in the form of a chaincode, and then gathering complete information. There are three steps in the performance evaluation, which are depicted in Figure 4, where the various transaction rates are applied.

Fig. 4. Performance evaluation in the three-step process.

Caliper sends a large number of transactions to the blockchain network and also collects performance metrics as the workload is processed. The overall system performance in terms of throughput (TPS) and latency (average delay) is calculated in this study. The performance parameters and the success rate were used to measure system reliability. Write latency refers to the additional endorsement and commit phases in Fabric, whereas write throughput refers to the number of transactions effectively committed to the ledger within a specified time period. These measurements ensure an accurate assessment of the proposed blockchain-based healthcare system across diverse workloads.

Experiment and Results

This study uses the Hyperledger Caliper tool to infuse a heavy load into the network at varying data transfer rates. Each round comprises 1,200 transactions, multiple times across different data transfer rates.

A total of eight rounds is used, each with a different send rate: 15tps, 30tps, 60tps, 90tps, 120tps, 150tps, 180tps, and 210 tps. As a result, 9,600 transactions were posted to the blockchain network to observe the performance of the proposed model and its applicability in real-time scenarios. Hyperledger Caliper was designed to generate 1,200 transactions simulating RPM packets. The RPM unit continues to collect and send data to the blockchain network at 30-s intervals. This controlled transmission rate prevents the system from being overloaded, and all transactions are successful, with no transactions failing. The result obtained from the Hyperledger Caliper is shown in Table 4 for the write operation in terms of transactional throughput and latency.

Performance of the proposed model during the write operations is shown in Figure 5, which shows that none of the transactions failed across the rounds at varying send rates. It is noteworthy that until 90 TPS, the send rate and throughput were very close, but throughput began to decline after that. The peak throughput is 117.04 TPS when the data transfer rate is set to 150 TPS, respectively.

Fig. 5. Throughput and latency analysis for write operation.

In another experiment for the read operation, we observe the behavior of the proposed system with respect to latency and throughput at varying transaction send rates. The system’s reliability during read operations is demonstrated in Table 5, which shows that all 1,200 transactions were successfully committed with no failures. The average latency is continuously low at 0.01 s, indicating a reliable response time. Additionally, the realized throughput improves as the sent rate rises from 15 TPS to 210 TPS. At the same time, the overall execution time decreases, demonstrating the proposed blockchain-based system’s ability and effectiveness.

It is important to note that across all eight rounds, the latency remained constant at 0.01 s, whereas the throughput kept on rising. The peak of throughput is observed as 210.1 TPS. For the read operation of the proposed system, Figure 6 shows the relationship between send rate, throughput, and latency, which indicates reliable and effective read performance even when transaction loads are increased.

Fig. 6. Throughput analysis for read operation.

These findings show that the suggested system is capable of managing massive traffic and applies to real-world applications.The suggested blockchain-based EHR model’s performance shows that it can effectively handle real-time healthcare data even under varying and massive workloads.

Discussion

In order to calculate the performance of a system, we used the standard evaluation model that Hyperledger Caliper used. The mathematical formulas that are used to calculate these metrics are as follows: Transactional throughput indicates the total number of successful transactions recorded in the ledger during a specified time period:

• ▪ T_put : Transaction throughput

• ▪ N_succ : Total number of successfully committed transactions

• ▪ S_total : Total duration of the test in seconds

Round-wise throughput for the round r:

• ▪  : Round-wise transaction throughput

• ▪  : Total number of successfully committed transactions in round r

• ▪  : Total duration of the test in seconds

Average throughput across rounds:

Similarly, the transaction latency calculated in various scenarios is as follows:

• ▪ L_t : Latency of transaction j (represents the difference between submission and commit time)

• ▪ S_comm : Total number of successfully committed transactions

Average latency within round i:

• ▪ i : represents the round number

• ▪  : Total number of successfully committed transactions in round i

Average latency over all rounds:

• ▪ R : Total number of rounds

Equation 1 shows that reducing the test time by the number of successfully committed transactions determines the overall throughput. Equation 2 employs the committed transactions and duration to determine the throughput for each round. Equation 3 takes the mean of all the round-wise throughput numbers to determine the final average throughput. These equations compute latency at three levels: Equation 4 provides the average latency for all committed transactions. Equation 5 calculates the average latency within each round, and Equation 6 provides the average latency values over all rounds to determine the final latency.

The experiment and results reported in section IV make use of Hyperledger blockchain framework configured with a RAFT consensus. The reason for opting RAFT consensus is due to its better performance than other consensus algorithms. Some of the recent studies reporting RAFT as a better consensus are reported in Table 6.

Table 6. Comparison of consensus mechanisms

Ref.	Compared consensus	Parameters evaluated	Key findings
31	Raft in Fabric vs. PoW (Ethereum)	Throughput, latency, and cloud cost	Raft demonstrated significantly higher throughput and reduced latency compared to Proof of Work in enterprise workloads.
32	RAFT and Kafka	Latency, throughput, memory consumption, transaction success rate	RAFT significantly outperforms Kafka by providing low latency, high throughput, and a success rate, which increases stability under heavy workloads.
33	Fabric (Raft) vs. Quorum (IBFT) vs. Sawtooth (PoET)	Throughput, latency	Fabric with Raft proved reliable performance and reduced latency.
34	Raft- based fabric under node scaling	Throughput, Latency, scalability	Raft supports performance for moderate network scales.
35	Fabric (Raft) vs. BFT-based configurations	Ordering delay, system throughput	Raft achieves less ordering latency in Fabric.
IBFT: Istanbul Byzantine Fault Tolerance; PoET: Proof of Elapsed Time; Raft: Reversible Addition-Fragmentation chain Transfer.

It is observed that the outcomes of this study are significantly better than those of the previous research work in multiple areas. The authors of the Study³⁶ calculated the performance of their fabric-based proposed model and achieved a throughput of 65.6 TPS at a rate of 100 TPS, showing a significant performance gap with the solution proposed in this work. The performance of the proposed system is way better due to higher throughput, such as 89.02 and 110.2 TPS when the transaction rate is set at 90 and 120 TPS, respectively. This indicates that under similar experimental conditions, our system delivers significantly higher and more stable throughput.

Another Study³⁷ evaluated throughput under different load conditions of 25, 50, and 100 TPS and achieved the throughput of 25, 50, and 98.78 TPS. Reliability in study³³ is claimed as 96, 98.4, and 96.6% at 20, 50, and 100 TPS, respectively, due to some transaction loss. In contrast, there is no transaction loss in the proposed work. The authors of the paper³⁸ describe a Hyperledger Fabric-based solution with a peak throughput of 95.9 TPS. However, the evaluation does not incorporate IoT-enabled patient vital collection within an RPM context and is restricted to storing textual and numerical data on the ledger. Furthermore, medical reports, a crucial part of actual EHR systems, are neither managed nor stored by the framework. It is also crucial to remember that the performance evaluation was carried out using a distinct experimental configuration, which makes its findings less typical of data-intensive and complex healthcare environments. On the contrary, the Study²⁶ claimed 93.3 TPS as the maximum throughput, which is still lower than the performance results obtained in this work. However, the proposed system achieves its peak throughput of 117.04 TPS at a send rate of 150 TPS, and also maintains the high reliability even at higher rates.

The integration of blockchain and IPFS in the proposed system provides several advantages for the secure storage, ease of access, and management of patient medical data. In addition to network performance, the proposed solution offers a better diagnosis due to the availability of complete medical histories of patients. Another benefit is that even if a new doctor is assigned to a patient, there is no adverse effect on the ongoing treatment. In fact, in the worst conditions, if a patient is referred to another branch of the same hospital, the treatment will still proceed smoothly due to the decentralized blockchain ledger shared among multiple branches. Even if a patient loses the medical reports, they can be securely retrieved using the CID stored on the blockchain. Furthermore, IPFS can greatly decrease the load on the blockchain by storing a large medical image off-chain and storing only the image hash on-chain, which enhances the efficiency and scale of the healthcare system.

Conclusion

To improve accessibility and continuity of care, EHRs digitally combine a patient’s clinical history, diagnoses, and treatment data. On the contrary, RPM expands this care outside of hospital settings by utilizing wearable technology based on the IoT to track vital signs in real time. This study introduces a specially optimized blockchain-based architecture, which combines IPFS and RPM to reinforce the accuracy of diagnosis and clinical decision-making. First, the suggested model is effective in handling the data on large-scale medical imaging, along with diagnostic reporting, by storing them on IPFS and immutably recording the cryptographic hash references on the blockchain ledger, which ensures data integrity, tamper resistance, and verifiable authenticity without drawing excessive work to the blockchain network.

Second, the suggested architecture presents an effective approach to the development of an IoT sensor integration, a Hyperledger Fabric network, and IPFS to build a strong EHR framework that can handle high-frequency vital signs and advanced medical data. It is achieved with the help of smart contracts, which automate access control and ensure that patients have control over data. The system performed well under heavy load and achieved a throughput of over 117.04 TPS and a latency of 0.21 s. The system continues to operate at its greatest effectiveness even when the load increases, confirming its adaptability for practical implementation.

The most important performance indicators, like throughput and transaction latency, are evaluated at different workloads through extensive experimentation, which proves that the RAFT consensus mechanism can achieve a high throughput and low latency with off-chain storage. The topology of a blockchain network applied in this research is also restricted to two organizations, and each organization has one peer. This study has adopted this topology due to resource constraints. A more complex topology demands more complex infrastructure, such as high-end servers.

Contributions

Not applicable.

Data Availability Statement (DAS), Data Sharing, Reproducibility, and Data Repositories

Not applicable.

Application of AI-Generated Text or Related Technology

Not applicable.

Acknowledgments

Not applicable.

References

1. Katoon PM, Turukmane AV. Interoperable blockchain network for healthcare data using Fabric, Ethereum, and IPFS. Discov Artif Intell. 2025;5(1):1–27. https://doi.org/10.1007/s44163-025-00564-7
2. Afzal I, Parah SA, Hurrah NN, Song OY. Secure patient data transmission on resource constrained platform. Multimed Tools Appl. 2024;83(5):15001–26. https://doi.org/10.1007/s11042-020-09139-3
3. Shen Y, Yu J, Zhou J, Hu G. Twenty-five years of evolution and hurdles in electronic health records and interoperability in medical research. J Med Internet Res. 2025;27(1):59024–49. https://doi.org/10.2196/59024
4. Tertulino R, Antunes N, Morais H. Privacy in electronic health records: a systematic mapping study. J Public Health. 2024;32(3):435–54. https://doi.org/10.1007/s10389-022-01795-z
5. Alomar D, Almashmoum M, Eleftheriou I, The impact of patient access to electronic health records on health care engagement: systematic review. J Med Internet Res. 2024;26:473–88. https://doi.org/10.2196/56473
6. Carlos Ferreira J, Elvas LB, Correia R, Mascarenhas M. Enhancing EHR interoperability and security through distributed ledger technology. Healthcare (Basel). 2024;12:1967–87. https://doi.org/10.3390/healthcare12191967
7. Kasa PSP. A distributed and scalable system for remote patient monitoring using cloud-based architecture. IJIRCCE. 2024;12(8):10706–17.
8. Hathaliya J, Sharma P, Tanwar S. Blockchain-based remote patient monitoring in healthcare 4.0. In 9th international conference on advanced computing (IACC). IEEE; 2019. p. 87–91.
9. Wang Y, Zhang A, Zhang P, Wang H. Cloud-assisted EHR sharing with security and privacy preservation via consortium blockchain. IEEE Access. 2019;7:136704–19.
10. Kayikci S, Khoshgoftaar TM. Blockchain meets machine learning: a survey. J Big Data. 2024;11(1):9. https://doi.org/10.1186/s40537-023-00852-y
11. Charles WM, Delgado BM. Health datasets as assets: blockchain-based valuation and transaction methods. Blockchain Healthc Today. 2022;5(10):953–66. https://doi.org/10.30953/bhty.v5.222
12. Cheikhrouhou O, Mershad K, Jamil F, Mahmud R, Koubaa A, Moosavi SR. A lightweight blockchain and fog-enabled secure remote patient monitoring system. Internet of Things. 2023;22:100691. https://doi.org/10.1016/j.iot.2023.100691
13. Husnain G, Ullah Z, Mohmand MI, Qadir M, Alzahrani KJ, Ghadi YY, et al. Healthchain: a blockchain-based framework for secure and interoperable electronic health records (EHRs). IET Commun. 2024;18(19):1451–73.
14. Dobre D, Vasilățeanu A. Electronic health record authentication and authorization using Blockchain and QR codes. Procedia Comput Sci. 2024;239(4):1784–91. https://doi.org/10.1016/j.procs.2024.06.358
15. Carter G, White D, Nalla A, Shahriar H, Sneha S. Toward application of blockchain for improved health records management and patient care. Blockchain Healthc Today. 2019;2(7):240–52. https://doi.org/10.30953/bhty.v2.37
16. Upadrista V, Nazir S, Tianfield H. Secure data sharing with blockchain for remote health monitoring applications: a review. J Reliab Intell Environ. 2023;9(3):349–68. https://doi.org/10.1007/s40860-023-00204-w
17. Garg S, Kaushal RK, Kumar N. A novel design and performance assessment of a blockchain-powered remote patient monitoring system. SN Comput Sci. 2024;5(7):849. https://doi.org/10.1007/s42979-024-03151-2
18. Carter G, Shahriar H, Sneha S. Blockchain-based interoperable electronic health record sharing framework. In IEEE Annual Computer Software and Applications Conference 2019. p. 452–60.
19. Kaushal RK, Kumar N, Kukreja V, Boonchieng E. Hyperledger fabric-based remote patient monitoring solution and performance evaluation. Peer-to-Peer Netw Appl. 2025;18(3):105. https://doi.org/10.1007/s12083-025-01921-0
20. Noor Ul Ain, Parveen F, Rabbani N, Shaheen A. Towards an engaging and integrated climate change pedagogy. 2024 [cited 2026 July 12]; p. 98. Available from: https://ecommons.aku.edu/books/174
21. Ullah A, Ullah Z, Rizvi SS, Gul L, Kwon SJ. Toward blockchain-based electronic health record management with fine-grained attribute-based encryption and decentralized storage mechanisms. Sci Rep. 2025;15(1):542–67. https://doi.org/10.1038/s41598-025-17875-5
22. Hasnain M, Albogamy FR, Alamri SS, Ghani I, Mehboob B. The Hyperledger fabric as a Blockchain framework, preserves the security of electronic health records. Front Public Health. 2023;11(4):787–99. https://doi.org/10.3389/fpubh.2023.1272787
23. Salleh MIM, Abdullah R, Zakaria N. Evaluating the effects of electronic health records system adoption on the performance of Malaysian health care providers. BMC Med Inform Decis Mak. 2021;21:1–13. https://doi.org/10.1186/s12911-021-01447-4
24. Carter G, Chevellereau B, Shahriar H, Sneha S. Openpharma blockchain on FHIR: an interoperable solution for read-only health records exchange through blockchain and biometrics. Blockchain Healthc Today. 2020;3:1–11. https://doi.org/10.30953/bhty.v3.120
25. Çodur S, Erkayman B. Blockchain technology from the supply chain perspective: a systematic literature review. Spectr Decis Mak Appl. 2025;2(1):268–85. https://doi.org/10.31181/sdmap21202520
26. Kaushal RK, Kumar N. Exploring hyperledger caliper benchmarking tool to measure the performance of blockchain based solutions. In: 2024 11th international conference on reliability, infocom technologies and optimization IEEE; 2024. p. 1–6.
27. Bigini G, Lattanzi E. Toward the interplanetary health layer for the internet of medical things with distributed ledgers and storage. IEEE Access. 2022;10:82883–95.
28. Schweitzer M, Flórez K, Steger B, Baumgarten D, Romano V, Augustin M. Integrating a novel eye imaging system into clinical practice: an open-source DICOM simulation platform. Stud Health Technol Inform. 2023;301:198–203. https://doi.org/10.3233/SHTI230039
29. Kumar R, Marchang N, Tripathi R. Distributed off-chain storage of patient diagnostic reports in healthcare system using IPFS and blockchain COMSNETS. IEEE, 2020. p. 1–5.
30. Jayadev V, Moradpoor N, Petrovski A. Assessing the performance of ethereum and hyperledger fabric under DDoS attacks for cyber-physical systems. In: Proceedings of the 19th international conference on availability, reliability and security. 2024. p. 1–6.
31. Battisti JHF, Batista VE, Koslovski GP, Pillon MA, Miers CC, Marques MA, et al. Performance analysis of the Raft consensus algorithm on Hyperledger Fabric and Ethereum on the cloud. In: 2023 IEEE. 2023. p. 155–60.
32. Pradhan NR, Singh AP, Verma S, Kavita, Kaur N, Roy DS, et al. A novel blockchain-based healthcare system design and performance benchmarking on a multi-hosted testbed. Sensors. 2022;22(9):3449–69. https://doi.org/10.3390/s22093449
33. Capocasale V, Gotta D, Perboli G. Comparative analysis of permissioned blockchain frameworks for industrial applications. Blockchain Res Appl. 2023;4(1). https://doi.org/10.1016/j.bcra.2022.100113
34. Khan MM, Khan FS, Nadeem M, Khan TH. Scalability and efficiency analysis of hyperledger fabric and private ethereum in smart contract execution. Computers. 2025;14(4):132–66. https://doi.org/10.3390/computers14040132
35. Yuan F, Huang X, Zheng L, Wang L, Wang Y. The evolution and optimization strategies of a PBFT consensus algorithm for consortium blockchains. Information. 2025;16(4):268–309. https://doi.org/10.3390/info16040268
36. Ucbas Y, Eleyan A, Hammoudeh M, Alohaly M. Performance and scalability analysis of ethereum and Hyperledger Fabric. IEEE Access. 2023;11(3):67156–67. https://doi.org/10.1109/ACCESS.2023.3291618
37. Díaz Á, Kaschel H. Scalable electronic health record management system using a dual-channel blockchain hyperledger fabric. Systems. 2023;11(7):346–69. https://doi.org/10.3390/systems11070346
38. Kumar Kaushal R, Kumar N, Flammini F. Enhancing data integrity in higher education: a blockchain-based student complaint system using Hyperledger fabric. Int J Comput Digit Syst. 2024;16(1):1387–97. https://doi.org/10.12785/ijcds/1601102

Copyright Ownership: This is an open-access article distributed in accordance with the Creative Commons Attribution Non-Commercial (CC BY-NC 4.0) license, which permits others to distribute, adapt, enhance this work non-commercially, and license their derivative works on different terms, provided the original work is properly cited and the use is non-commercial. See http://creativecommons.org/licenses/by-nc/4.0. The authors of this article own the copyright.