Key points are not available for this paper at this time.
This research introduces a methodical strategy for integrating a remote patient monitoring (RPM) system based on Hyperledger Fabric blockchain framework. This integration is crucial, as ensuring the secure storage of patient health data aligns with one of the fundamental capabilities of blockchain technology. Furthermore, blockchain technology provides an immutable ledger, ensuring that once patient information is documented, it remains tamper proof. The proposed RPM system makes use of heart rate, body temperature and pulse oximetry sensors. These sensors are connected to an ESP32 microcontroller, which monitors the vital signs of patient health and subsequently transmits the data to the blockchain network. The RPM system, based on the Hyperledger Fabric blockchain framework, is configured with two organizations, a single channel, and a raft-based ordering service for experimental purposes. Two separate trials are undertaken to assess the effectiveness of the proposed system. In the initial experiment, health-related transactions of patients are transmitted in three rounds, each lasting for a duration of 30 min. The outcomes reveal a 100% success rate, with no loss of packets observed during communication. The proposed system has given a provision to keep storing data in JSON format within the ESP32 microcontroller when there is absence of network connectivity. These transactions are later transmitted when connectivity resumes. The system tracks connectivity by periodically transmitting hello transactions to the network. In the second experiment, a substantial volume of remote patient monitoring (RPM) data is transmitted to the RPM blockchain network using the Hyperledger Caliper tool. This aims to examine the overall system performance, considering that, in real-world scenarios, numerous RPM systems might concurrently transmit data. The findings suggest that as the data transfer rate increases, the throughput for write operations decreases, while the throughput for read operations is comparatively less affected. During write operations the blockchain network takes 10.69 s to commit 1000 RPM transactions at the speed of 93.6 TPS (Transaction Per Second) whereas during the read operation similar transactions are read in merely 5.78 s at the speed of 173.3 TPS. During write operations the peak of average latency is reached to 0.6 s whereas during read operations average latency is observed constant at 0.01 s regardless of varying throughput.
Kaushal et al. (Tue,) studied this question.
Synapse has enriched 5 closely related papers on similar clinical questions. Consider them for comparative context: