Figure 1.
Figure 2.
Figure 3.
Figure 4.
Figure 5.
Figure 6.
Figure 7.
Figure 8.
Research Questions and Findings Summary
| Research Question | Key Findings |
|---|---|
| [RQ1]. | Privacy Models: Multiple models exist, including access control with Attribute-Based Encryption (ABE), Homomorphic Encryption (HE), Secure Multi-Party Computation (SMPC), differential privacy, and hybrid approaches. Strong cryptography (HE, SMPC) ensures high privacy but incurs high computation and limited scalability. Lightweight models (DP, hybrid off-chain storage) are usable but weaker in confidentiality. Hybrid models optimized for healthcare remain underdeveloped. |
| [RQ2]. | Scalability Strategies: Layer 2 solutions (channels, sidechains) and sharding improve throughput.Consensus optimizations (PBFT, PoA, PoET) reduce latency but trade decentralization. Hybrid consensus approaches (e.g., PBFT↔PoET switching) show promise but lack validation at production scale. Overall, real-world deployment at national or hospital network scales remains limited. |
| [RQ3]. | Emerging Technologies & Advanced Cryptography: Federated learning aided by blockchain allows collaborative AI without the exchange of raw data but suffers such problems as non-IID data and model poisoning. Cross-chain interoperability models are primarily prototypes which have latency and security issues. The probability of zero-knowledge proofs (ZKPs) and ring signatures offers selective disclosure of transactions and unlinkable transactions, but has seen very little real-world use. The combination of these methods with FL and adaptive consensus is mostly done on a case-by-case basis. |
| [RQ4]. | Research Gaps & Future Directions: Key gaps include: (i) limited deployment of advanced cryptography in real hospital networks; (ii) unresolved privacy-scalability trade-offs; (iii) weak interoperability with standards such as HL7 FHIR and DICOM; and (iv) lack of regulation-aware and sustainability-focused design. Future directions include lightweight ZKPs, poisoning-resistant federated learning, adaptive consensus mechanisms, post-quantum cryptography, and compliant, energy-efficient blockchain infrastructures. |
Comparative Analysis of Blockchain Techniques in Healthcare (2019–2025)
| Technique | Privacy Strength | Scalability | Computation Cost | Adoption Readiness | Representative Studies |
|---|---|---|---|---|---|
| Access Control + ABE | Moderate-High (fine grained control) | Moderate (policies scale poorly across chains) | Low-Moderate | High (easy integration with EHRs) | [19–21] |
| Homomorphic Encryption | Very High (data never decrypted) | Low (latency sensitive) | Very High (orders of magnitude higher than plaintext ops) | Low (few pilots) | [22–24] |
| SMPC | High (multi hospital privacy preserved) | Low-Moderate (communication bottlenecks) | High | Medium (tested in multi hospital studies) | [25–27] |
| Differential Privacy + Blockchain | Moderate-High (depends on noise budget) | High (lightweight) | Low | Medium-High (suitable for IoMT streams) | [28–30] |
| Hybrid On-chain/Off-chain Storage | Moderate (privacy tied to off chain trust) | High (IPFS/cloud scalability) | Low | High (already tested in Hyperledger pilots) | [31–32] |
| ZKPs (Consent/Access Proofs) | Very High (no disclosure of identity/data) | Moderate | Moderate-High (proof generation overhead) | Medium (prototype level) | [33–36] |
| Ring Signatures | High | Moderate (signature size grows) | Moderate | Low-Medium (few healthcare pilots yet) | [37–38] |
Comparative Analysis of Federated Learning and Cross-Chain Interoperability in Healthcare
| Approach | Core Concept | Healthcare Applications | Privacy Preservation | Interoperability Support | Key Limitations | References |
|---|---|---|---|---|---|---|
| Federated Learning (FL) | Distributed model training without data sharing | Disease prediction, medical imaging | High | Low | Trust and auditability gaps | [50–52] |
| FL + Blockchain | Blockchain based coordination and audit of FL | Medical imaging, healthcare IoT | High | Low-Moderate | Ledger overhead, latency | [53–55] |
| Blockchain-Assisted FL | Secure logging of training rounds and updates | Device monitoring, analytics | Very High | Low | Scalability constraints | [56–58] |
| Cross-Chain Healthcare Systems | Interoperable EHR exchange across blockchains | Cross-hospital EHR sharing | Moderate | High | Bridge security risks | [59, 60] |
| Integrated FL + Interoperability | Local FL with cross-chain coordination | Multiinstitution analytics | High | Moderate-High | Cross-chain latency, limited evaluation | [61–63] |
Comparative Overview of Blockchain Frameworks in Healthcare (2019–2025)
| Framework / Use Case | Platform / Architecture | Focus Area | Strengths | Limitations | Adoption Readiness | Reference |
|---|---|---|---|---|---|---|
| Hyperledger Fabric EHR Systems | Permissioned blockchain (Fabric/Sawtooth) with off-chain storage | Secure EHR exchange across hospitals | Fine-grained access, audit trails, HL7/FHIR compliance | Scalability limits, complex deployment | High (pilot deployments exist) | [64–65] |
| Ethereum Telemedicine Platforms | Public/consortium Ethereum smart contracts | Teleconsultations, e-prescriptions, billing | Transparency, patient-doctor trust, micropayments | High gas cost, privacy issues | Medium (prototypes tested) | [66, 67] |
| ZKP-Enhanced Healthcare Chains | Permissioned or hybrid blockchain with ZKPs | Consent verification, anonymized access | Strong privacy, regulatory compliance | Proof size overhead, limited pilots | Low (research stage) | [68–70] |
| FL + Blockchain Prototypes | Hybrid blockchain + federated learning | Collaborative AI without raw data sharing | Privacy-preserving AI, on-chain model logging | Non-IID data, poisoning attacks, latency issues | Medium (academic demos) | [71–73] |
| IoMT Data Integrity Chains | Lightweight blockchain integrated with IoT gateways | Real-time sensor/device data | Real-time auditing, integrity assurance | Edge resource constraints, latency for critical care | Medium | [74–77] |
| Cross-Chain Interoperability | Cosmos/Polkadot-inspired relay frameworks | EHR sharing across heterogeneous blockchains | Interoperability, patient record continuity | Security of bridges, high complexity | Low-Medium (early-stage research) | [78–80] |
Limitations in Blockchain based Healthcare Literature (2019–2025)
| Technique / Framework | Observed Limitations | Analytical Implications for Healthcare Deployment |
|---|---|---|
| Scalability (PBFT, PoA, PoET, Hybrid Consensus) | Evaluations restricted to small networks (<50 nodes); PBFT incurs quadratic communication overhead; PoA/PoET reduce decentralization | Limited evidence of reliability and latency performance in large hospital networks; unsuitable for nationwide or IoMT-intensive healthcare scenarios without adaptive or hierarchical consensus designs |
| Privacy Models (HE, SMPC, DP, ABE) | HE and SMPC impose high computation and communication costs; DP reduces data utility; ABE complicates emergency access | Strong privacy guarantees come at the expense of real-time responsiveness; current designs struggle to balance confidentiality with clinical usability in latency sensitive environments |
| Federated Learning + Blockchain | Validation mostly on synthetic or small-scale datasets; non-IID data and model poisoning insufficiently addressed | Trust and auditability improve, but lack of real EHR validation limits clinical credibility; robustness against adversarial participants remains an open issue |
| Cross-Chain Interoperability | Predominantly conceptual frameworks; absence of healthcare-specific interoperability standards; high coordination latency | Enables institutional autonomy but lacks semantic consistency and performance guarantees required for cross-hospital clinical workflows |
| ZKPs and Ring Signatures | High proof generation and verification cost; ring signatures scale poorly with participant size | Suitable for selective verification and auditing, but impractical for continuous clinical transactions or large healthcare consortia without lightweight adaptations |
| Existing Platforms (Hyperledger, Ethereum, Bespoke Frameworks) | Partial centralization in permissioned systems; high transaction cost in public blockchains; bespoke designs lack standardization | Platform-level constraints limit portability and long term sustainability; healthcare-specific customization remains fragmented |
| Regulatory and Ethical Compliance | Limited embedding of GDPR, HIPAA, or DISHA requirements; emergency “break-glass” access poorly formalized | Legal ambiguity and unclear accountability reduce institutional trust and hinder clinical adoption despite technical feasibility |
Privacy Models in Blockchain-Based Healthcare Systems (2019–2025)
| Technique | Principles | Strengths | Limitations | Representative Studies |
|---|---|---|---|---|
| Access Control (Smart Contracts, ABE) | Access policies enforced via smart contracts;ABE links access to roles/attributes | Fine-grained sharing; strong patient autonomy | Emergency access complexity; crosschain interoperability issues | [19–21] |
| Homomorphic Encryption (HE) | Computation performed directly on encrypted EHR data | Enables secure analytics and ML without decryption | High computational overhead; unsuitable for real-time monitoring | [22–24] |
| Secure Multi-Party Computation (SMPC) | Collaborative computation without sharing raw datasets | Preserves privacy in multi-institution studies | Communication latency; scalability limitations | [25–27] |
| Hybrid (Differential Privacy + Blockchain) | Noise added to data prior to storage or analysis | Lightweight; protects IoMT data streams | Reduced data utility; tuning complexity | [28–30] |
| Hybrid (Encryption + Off-chain Storage) | Blockchain stores hashes/metadata; data stored off-chain | Scalable; efficient storage; auditable | External trust dependency; linkability risks | [31, 32] |
Comparison of ZKPs and Ring Signatures in Healthcare Blockchains(2019–2025)
| Technique | Principles | Strengths | Limitations | Representative Studies |
|---|---|---|---|---|
| Zero-Knowledge Proofs (ZKPs) | Prover convinces verifier of a statement (e.g., consent, correct computation) without revealing underlying data. | Strong selective disclosure (prove consent/qualification without revealing identity or content); enables verifiable off chain computation (e.g., FL update checks); ZK rollups can improve throughput while preserving privacy. | Proof generation can be computationally expensive (hard for IoMT); verifier/transition costs add latency; engineering complexity (tooling, trusted setup for some ZK systems); sparse real EHR integrations. | [33–36] |
| Ring Signatures (including linkable variants) | A signer produces a signature that proves membership in a set but conceals which member signed; linkable versions allow detection of double use without deanonymizing. | Provides unlinkable transaction anonymity (prescriptions, claims); simpler and more compact verification than many HE/SMPC schemes; linkable variants add fraud detection while preserving anonymity. | Larger signature sizes than classical ECDSA; key management in dynamic consortia is non trivial; linkability vs. accountability trade offs need governance rules; not broadly standardised on permissioned platforms. | [37–38] |
Comparison of ZKPs and Ring Signatures in Healthcare Blockchains (2019–2025)
| Technique | Principles | Strengths | Limitations | Representative Studies |
|---|---|---|---|---|
| Layer 2 Solutions (Channels, Sidechains) | Move frequent interactions off chain, anchor summaries on chain. | High throughput; reduced latency; cost efficient for IoMT. | Auditability concerns; relies on trusted off chain operators; regulatory compliance gap. | [39–41] |
| Sharding | Partition blockchain into shards (e.g., hospital/regional clusters) for parallel processing. | Linear scalability; natural fit for healthcare networks. | Cross shard query consistency difficult; vulnerable if a shard is compromised; synchronization overhead. | [42–44] |
| Consensus Optimisation (PBFT, PoA, PoET) | Modify or replace consensus to reduce communication or energy cost. | Lower latency; energy efficient; tailored for permissioned healthcare settings. | PBFT fails at large scale; PoA/PoET reduce decentralization; limited real-world validation. | [45–47] |
| Hybrid Models | Dynamically switch between consensus algorithms (e.g., PBFT ↔ PoA/PoET). | Adaptive to workload; balances security and throughput; suitable for national EHR. | Implementation complexity; security risks during switching; not tested at production scale. | [48, 49] |