A Lightweight Blockchain and Fog-enabled Secure Remote Patient Monitoring System

1. Introduction

• The paper situates remote monitoring within the growth of healthcare IoT, where biomedical devices send sensed physiological parameters to doctors to inform treatment.It also points to rising security attacks, data breaches, and privacy violations as motivations for blockchain in healthcare.Source: §1 · p. 2
• The introduction describes blockchain uses in healthcare including consent-based record access, treatment traceability, referral integrity, and digitally signed payments.Referral documents are stored on IPFS, with their hashes recorded on the blockchain to protect document integrity.Source: §1 · pp. 2–3
• Blockchain’s processing and communication demands can exceed lightweight IoT devices’ resources, motivating modified roles that still provide blockchain services.The paper describes its lightweight blockchain as modifying architecture and processes to assign IoT devices lighter roles.Source: §1 · p. 3
• Cloud latency can prevent the immediate intervention required for abnormal situations in critical healthcare use cases.The introduction identifies real-time detection and notification in heart-disease monitoring as particularly time-sensitive.Source: §1 · p. 3
• The proposal combines IoT vital-sign collection with blockchain protection for patient-collected data and fog computing for real-time response and data aggregation.The architecture divides blockchain storage between local IoT ecosystems and a global cloud chain, and introduces a lightweight consensus model for fog and IoT nodes.Source: §1 · p. 4
• In the proposed division, IoT ecosystems retain block headers and selected block bodies, while the cloud’s global chain holds whole blocks and smart contracts.The local chain also stores the smart-contract functions needed there.Source: §1 · p. 4

2. Related Work

• The review organizes related studies around their use of IoT, fog computing, and blockchain, summarizing them in Table 1.The table is presented as a summary of the discussed related work.Source: §2 · p. 4, Table 1 · p. 5
• The review cites blockchain systems for EHR access control, remote-monitoring transaction logging, and lightweight identity management, among other healthcare applications.The cited remote-monitoring system stores patient data locally and has a stated limitation concerning transmission time for gateway-aggregated data.Source: §2 · p. 7
• Existing lightweight blockchain designs distribute ledger storage across node types, including edge nodes, IoT cluster heads, and cellular base stations.In the reviewed three-layer model, some IoT peers can endorse or commit transactions, while cluster heads and base stations order transactions and create blocks.Source: §2 · p. 8
• Prior remote-monitoring work often focused on fog-based performance and energy management, while blockchain-based schemes used classical architectures that may not fit resource-constrained IoT devices.The reviewed fog approaches include cloud-based ECG monitoring, fog/cloud task partitioning, edge gateways, migraine prediction, BodyEdge, HealthFog, distributed AI, and fog offloading.Source: §2 · pp. 6–8
• The paper’s stated distinction is a fog layer that both improves remote-monitoring performance and lightens blockchain demands, with consensus designed to avoid PoW or PoS burdens.The authors describe the resulting lightweight blockchain as providing security services adaptable to resource-constrained IoT devices.Source: §2 · p. 8

3.1. RPM System Architecture

• The system has IoT, fog, and cloud layers for vital-sign collection, lightweight processing and alerting, and permanent storage and analytics, respectively.The fog layer aggregates sensed data and decides what to record on the blockchain; the cloud can run complex AI and deep-learning algorithms.Source: §3.1 · pp. 8–9
• The architecture uses smart contracts to trigger alarms when vital signs exceed a specified threshold and lets patients decide who can access their data.The blockchain is private, and patients are assigned anonymous identities.Source: §3.1 · pp. 9–10

3.2. Communication Models

• Fog nodes connect medical devices and users with blockchain-enabled services, while consensus validates transactions and blocks and the network exchanges blocks among nodes.The system describes caregiver-to-fog, sensor-to-fog, fog-to-fog, and sensor-to-sensor communication.Source: §3.2 · pp. 10–11
• Blockchain-enabled fog nodes authenticate and authorize users and sensors, issue access tokens, and restrict device communication to registered, certified devices.Caregivers request access through a fog node; sensors register with an associated node, and fog nodes synchronize service-authorization information.Source: §3.2 · pp. 10–12

4.1. Blockchain Architecture of Proposed RPM System

• Gateways cache incoming data, aggregate it into blocks at short intervals, and send the blocks to cloud servers; each transaction is signed by its creator.The system stores healthcare data as well as registration, access-request, and smart-contract-result transactions.Source: §4.1 · pp. 12–13
• Cloud servers store the full blockchain, gateways store local-chain blocks and full-chain headers, and IoT nodes store full-chain headers.Transactions expire, allowing gateways to delete blocks whose transactions have all expired and make room for new local-chain data.Source: §4.1 · p. 13, Figure 2 · p. 14

4.2. Consensus Protocol

• A cloud server adds a block after receiving at least N/2+1 confirmations, and other servers verify the attached signatures before adding it.Servers validate each transaction’s signature and return CONFIRM or ERROR messages.Source: §4.2 · p. 14
• In the illustrated scenario, gateways G1 and G2 add a block generated in their cluster to their local chains, while G3 adds only its header.The block is broadcast through the cloud-server consensus process before reaching the gateways.Source: §4.2 · pp. 15–16, Figure 3 · p. 15

4.3. Smart Contracts and Data Management

• When requested data is absent locally, the gateway forwards the request to the cloud; smart contracts manage access lists and execute at the gateway or cloud according to chain location.A recipient validates the returned block using blockchain headers before retrieving and decrypting its transactions with an access token.Source: §4.3 · p. 16

5. Specifications of Gateways at the Fog Layer

• Gateways act as hubs between cloud and IoT, and the paper extends them into fog enablers with a distributed network and local data-processing and storage repository.The gateways are described as having ample intelligence and computing resources in the stationary settings considered.Source: §5 · p. 16

5.1. Local data processing and storage

• Gateways store local-cluster data in a local blockchain and temporarily cache other clusters’ blocks, supporting fast access and data flow during weak or unstable cloud links.Patient data may be stored as encrypted or compressed blockchain transactions according to context and security requirements.Source: §5.1 · p. 17

5.2. Data filtering

• Because sensing can introduce noise into bio-signals, the fog layer provides more robust filtering than the lightweight filtering performed by sensors.The passage names electromagnetic interference, electricity-grid current shifts, and poor sensor attachment as noise sources.Source: §5.2 · pp. 17–18

5.3. Data analysis

• A fog-layer deep-learning module analyzes sensed ECG signals to detect irregular cardiac conditions, with results kept locally and later synchronized to the cloud via blockchain.The passage describes continued local system operation when the Internet link is unavailable.Source: §5.3 · p. 18

5.4. Improved latency

• Distributed fog gateways handle time-sensitive analytics and decisions locally, reducing dependence on unpredictable cloud transmission and processing for streaming EEG or ECG data.Processed data can then be sent to the cloud for storage and further processing.Source: §5.4 · p. 18

5.5. Sensor nodes energy efficiency

• Moving heavyweight tasks from resource-restricted medical sensors to intelligent fog gateways is presented as a way to save sensor energy.The passage notes that complex sensor-side tasks can carry significant energy costs.Source: §5.5 · pp. 18–19

6.1. Blockchain Implementation and Performance Evaluation

• Hyperledger Composer's .bna contains a model, queries, transactions, and access-control rules; a REST API exposes medical-platform services to client applications.The implementation also uses a world-state database for blockchain data.Source: §6.1 · pp. 19–20
• Owners can grant doctors specified access levels through access tokens, while private and document keys are not exposed on the blockchain.The implementation models sharing and access requests across user groups.Source: §6.1 · pp. 20–21
• Using Hyperledger Caliper and Postman, the study evaluates round-trip time for adding a healthcare device and querying healthcare data, measures average consensus time, and tests registration timing with groups of 150, 300, and 500 devices.Round-trip time includes sending a client request and receiving the network response.Source: §6.1 · p. 21
• Vital-sign requests are checked at the IoT gateway; if data is absent from its local chain, the request is forwarded to a REST server.The gateway validates the device certificate through a local smart contract before replying with encrypted data when the requested reading is local.Source: §6.1 · p. 22
• 140 ms average consensus time rises 12.5 ms from 150 to 500 devices, versus Ethereum's 10–19 seconds and Bitcoin's 10 minutes to an hour.The proposed consensus method was evaluated across scenarios using five REST servers and five IoT gateways.Source: §6.1 · p. 23, Figure 8 · p. 24

6.2. Efficiency of the Fog computing infrastructure

• The Fog-Cloud simulation uses iFogSim with 24 ECG machines, four local Fog servers, and a Fog regional server.The computing resources are arranged hierarchically.Source: Figure 10 · p. 25, §6.2 · p. 25
• 40% faster emergency-alert responsiveness and around 36% less energy are reported for Fog-based RPM versus Cloud-based RPM.The authors attribute the responsiveness improvement mainly to executing data analytics closer to sources, reducing transfer delay to remote cloud servers.Source: Figure 11 · p. 26, Figure 12 · p. 27, §6.2 · pp. 27–28
• 55.1% lower average transaction-retrieval delay is reported with Fog; at 500 KB, retrieval takes 7.16 ms versus Cloud's 16.54 ms, and at 2000 KB, 8.9 ms versus 19.34 ms.The authors attribute the reduction mainly to transactions fetched from a local chain near sensor nodes.Source: Figure 13 · p. 27, §6.2 · p. 28

7. Security Analysis

• Temporary per-session private keys mean a leaked private key cannot yield the ongoing session key, while bounded key lifetimes make replay attacks improbable.The model uses elliptic-curve encryption for key pairs.Source: §7 · p. 28
• The model uses two-factor authentication, identity-creation cost, and MAC and IP address accumulation to restrict or detect Sybil identities.Source: §7 · p. 29
• Consensus is executed before record validation, and a node can confirm a record after positive consensus.Source: §7 · p. 29
• Public-key encryption and signatures prevent transaction tampering, while records' unique sequence numbers support detection of nodes that withhold requested records.A node that does not provide saved records is detached from the network and barred from interacting with other nodes.Source: §7 · p. 29
• Mutual authentication with session keys is stated to prevent man-in-the-middle attacks, and individual private keys with elliptic-curve encryption are stated to prevent impersonation.Source: §7 · pp. 28–29
• For a compromised cloud server, invalid signatures expose forged blocks, dropped blocks are reported when not added in due time, and wrong replies have no effect if legitimate servers exceed N /2.Source: §7 · p. 29

• 40% improvement in remote patient monitoring responsiveness is reported with Fog augmentation; the blockchain module, implemented and tested in Hyperledger Fabric, achieved low execution and consensus delays.Source: §8 · p. 30
• Future simulations will use real healthcare datasets; planned additions include cloud-layer heart-disease prediction and secure, low-overhead body area network integration.Source: §8 · p. 30
• Fog-layer plans include federated filtering and analysis and blockchain-based IoT-data scheduling intended to give IoT nodes fair, equal opportunities to save data.Source: §8 · p. 30
• Scalability remains future work; proposed geographic- and application-based clustering would distribute cloud, Fog, and IoT nodes and parallelize queries to reduce delay overhead.Source: §8 · p. 30