Efficient patient-centric EMR sharing block tree

Colin R. Simpson; Jyoti Sahni; Normalia Samian; Winston K.G. Seah; Xiaohan Hu

REVIEW 5 major objections 4 minor 30 references

Efficient patient-centric EMR sharing block tree

T0 review · 5 major / 4 minor · reviewed 2026-08-16 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A chameleon-hash collision lets a returning patient's new record branch the EMR chain, letting one consensus round finalize n blocks.

desk verdict Novel tree-branch idea with a plausible throughput trend, but the collision-block construction is under-specified and internally contradictory, breaking the central claim as written. read the letter →

arxiv 2504.20544 v1 pith:IUOETENK submitted 2025-04-29 cs.DC cs.CR

Xiaohan Hu , Jyoti Sahni , Colin R. Simpson , Normalia Samian , Winston K.G. Seah This is my paper · ORCID

classification cs.DCcs.CR

keywords EMRsharingblockchainscalabilityblocktreechameleonhashEnhancedProconsensuspatientawarenessthroughput

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper claims that the low throughput of blockchain-based EMR sharing can be fixed by replacing a single chain with a block tree built from chameleon-hash collisions. In MedBlockTree, when a returning patient gets a new record, clinic staff create a collision block that carries the new metadata but the same chameleon hash as the patient's earlier block, and that block becomes the root of a new branch, so a consensus round can append one block per branch instead of one. The accompanying EnhancedPro protocol elects one proposer per branch using VRF-seeded randomness and confirms blocks through Byzantine-fault-tolerant voting. If the construction holds, throughput grows roughly with branch count; the paper reports blocks per second rising from 2.70 in the baseline to 16.18 with ten branches. The paper also presents patient awareness as a benefit, since collision generation is tied to a secret key held by the patient.

What carries the argument

The load-bearing piece is the identity-based chameleon hash function, which behaves like an ordinary hash but lets whoever holds a trapdoor secret key produce a second input with the same hash value. MedBlockTree uses that collision capability to make a new metadata block hash-identical to a patient's earlier block while being treated as a separate branch root; the branch index is written as a tuple $(B(n), m)$. EnhancedPro pairs this with weighted sub-node randomness from a Verifiable Random Function and a two-phase Byzantine-fault-tolerant vote, pre-vote then commit, requiring two-thirds of staked voting power to finalize the block map for a round.

What would settle it

Inspect what is fed into the chameleon hash when a block is created. If the branch index $B(n)$-$m$ is part of the hashed content, the claimed collision is impossible, because changing the index changes the hash; if the index is not hashed, no hash-based check can tell two blocks with the same chameleon hash apart, so branch identity and provenance would have to rely on a side channel. A second test is to try generating a collision block without the patient's secret key; if one succeeds, the patient-awareness guarantee is not enforced by the cryptography.

Watch

Extended reading notes

Core claim

MedBlockTree's central claim is that a chameleon hash lets a returning patient's new EMR metadata be packed into a collision block with the same hash and pre-hash as the patient's former block, so the chain can split into a tree where each branch is an independent append point. Each collision block counts as already validated, because it is made with the patient's secret key, and it starts a new branch at the same level as the old block. EnhancedPro runs one winner election per branch per round, producing $n$ finalized blocks per round and processing speeds the paper states as $\nu\cdot n$ times faster than a conventional chain. The reported simulations against an Enhanced Tendermint blockchain show gains across branch number, collision rate, network latency, and network size, with the paper itself noting a plateau in benefits as branches grow.

Load-bearing premise

The construction stands or falls on one premise: a collision block can share the exact chameleon hash and pre-hash of a patient's earlier block while still being a distinct, verifiable branch root, and clinic staff can create that collision using a secret key the paper says only the patient holds.

Editorial extensions

If this is right

With $n$ branches, one consensus round finalizes $n$ blocks, and the reported blocks per second rise from 2.70 for the baseline chain to 16.18 for ten branches at 100 ms latency.
More frequent returning-patient collisions make the tree grow faster, so follow-up visits reduce rather than lengthen the upload queue; the paper reports overall processing time falling to 217.22 seconds at a 30-second collision rate versus 738.01 seconds for the baseline.
EnhancedPro keeps multiple branches consistent by electing one proposer per branch with VRF-seeded randomness and requiring a two-thirds stake-weighted vote to commit the round's blocks.
Larger networks reduce the gain, with 16 nodes averaging 5.77 blocks per second against 7.77 for 4 nodes, yet they still finish 2.13 times faster than the 4-node baseline chain.
The paper itself reports diminishing returns as branch count grows and names efficient branch management as future work.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The branch-identity question has a binary outcome the paper leaves open: if the branch index $(B(n),m)$ is fed into the chameleon hash, the collision that creates the branch cannot exist, and if it is not fed in, no hash-based verifier can distinguish two blocks with the same hash, so branch provenance must rest on an unhashed, trusted index.
If the patient's secret key is the only way to make a collision, then practitioners must obtain that key to create emergency branches, which conflicts with the stated assumption that only the patient holds it; the practical system therefore seems to require delegated or shared keys, a different security model.
The same collision-branch trick could apply to any permissioned ledger where the same user returns repeatedly, such as supply-chain lot tracking or credential renewal, with the same hash-distinguishability caveat carrying over.
A direct stress test would be to let two branches that share a hash continue growing and then attempt to reorg or merge them; the outcome would show whether record sequence and auditability survive the parallel structure.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

First thing you should know: this is not a paper to reject out of hand, but it is not ready for publication either. The core idea—use chameleon-hash collision blocks as branch roots so that n branches each append a block in one consensus round—is genuinely new relative to the cited chameleon-hash, sharding, and DAG work. If it worked, it would give a simple way to scale permissioned EMR blockchains. The EnhancedPro multi-winner election with VRF is a sensible adaptation, and the simulation shows the expected trend of throughput rising with branch count while consensus round time grows only slightly.

What the paper does well: the problem (EMR upload latency) is real, the related work is fair, and the writing is clear enough that a reviewer can see exactly where the design is tricky. The authors also honestly note diminishing returns in the conclusion.

Now the soft spots, and they are load-bearing. The collision-block construction is under-specified. The chameleon hash collides on the metadata message, but the block index (branch identifier) is not part of the hashed input as far as the paper states. If the index is excluded, then the index is not cryptographically anchored—nothing prevents an attacker from splicing a block from branch B2 onto branch B1, since both carry the same Chamehash. If the index is included, two blocks with different indexes cannot have the same chameleon hash, so the collision equation in §4.2.2 fails. The paper never says which. The same section says practitioners generate collision blocks using the patient's private key, while Assumption 1 states that key is only held by the patient. That is a direct contradiction, and it undermines the patient-awareness guarantee. There's also the standard chameleon-hash trapdoor issue: anyone who holds the secret key can manufacture collisions, so the tamper-evidence claim is weaker than the paper implies.

The evaluation is honest but limited: no code or data, no error bars, and no comparison with the DAG or sharding baselines discussed earlier. More importantly, the n× speedup is almost definitional—if you append n blocks per round, throughput scales with n—so the simulation is largely a demonstration of the construction rather than an independent test.

Bottom line: the paper deserves serious peer review, not because it is close to correct, but because the flaw is specific and instructive, and a good referee can help the authors either fix the construction (by defining what is hashed and who holds which key) or abandon it. As it stands, I would not cite it. For a reading group, it's a useful case study in why hash input domains matter.

Referee Report

5 major / 4 minor

Summary. The paper proposes MedBlockTree, a blockchain data structure for EMR metadata in which a chameleon hash function is used to generate "collision blocks" for returning patients, turning a linear chain into a tree with n branches. It also introduces EnhancedPro, a Proof-of-Stake/BFT consensus protocol that elects one block proposer per branch per round. The authors claim that this achieves roughly n times the block throughput of a conventional single-chain EMR blockchain, while preserving patient awareness, and they support the claim with a simulation study varying branch count, network latency, network size, and collision rate.

Significance. If the described construction were fully specified and correct, the tree structure would be a plausible way to process multiple EMR metadata blocks per consensus round while keeping patients in the loop. The paper does provide a concrete simulation environment, per-component timing measurements, and a fairness comparison, which are useful empirical illustrations. However, the specification is incomplete at the exact point where the design's novelty lies: the authenticated creation of a distinct branch root via a chameleon collision. The patient-key handling is self-contradictory, the hash input to the chameleon hash is never defined, and the claimed n-fold speedup is largely built into the simulation's assumptions. As written, the central contributions are not established.

major comments (5)

[§4.2.2, Contribution 3, Section 4 assumptions] The description of who can generate a collision block is contradictory. The paper states that the patient's private key (SK) is "only held by patients" and that this "strongly ensures" patient awareness, but §4.2.2 says that "clinic practitioners" create collision blocks "in combination with" that same key. If practitioners have access to SK, the exclusivity claim in Contribution 3 is false; if they do not, no protocol is given for obtaining patient authorization. Since collision blocks are the only mechanism that creates new branch roots, the central throughput claim collapses unless this contradiction is resolved and the resulting trust model is analyzed.
[§4.2.1, §4.2.2, Figures 1-2] The message input to the chameleon hash is never defined. The block index (B(n),m) is said to distinguish blocks with identical hash values, but the collision verification in §3.1 and §4.2.2 compares only metadata and chameleon strings. If the index is not part of the hashed message, hash verification cannot authenticate the branch identifier, and a collision block could potentially be relabelled to start a different branch. If the index is part of the message, the collision relation must be stated over the full block message, not just the metadata. The paper must specify the exact message that is hashed and prove that the resulting collision block is both a valid chameleon collision and a distinct, verifiable branch root.
[§4.4.1, Equation (1), §5.6] The winner election is claimed to be "fair and unpredictable," but the randomness source is the chameleon string ζ of an already-committed former block. Both ζ and n are public before the next round begins, so any worker can predict all winners in advance. The VRF is used only to authenticate proposals, not to select winners, so the unpredictability claim is unsupported. Figure 12 measures only the distribution of winners across workers; it does not test whether winners are unpredictable to an adversary who observes the public chain.
[§4.4.1, Algorithm 1, §5.1-5.5] The n-fold throughput result is essentially a consequence of the assumption that there are n branches, each with one matching metadata pack per round. Algorithm 1 creates a block for B(n) only when n=ι, but no rule is given for assigning incoming metadata packs to branch numbers, and the simulation appears to maintain a fixed branch-count/metadata matching. Without an explicit scheduling or assignment mechanism, the reported speedup is not a validated prediction for arbitrary EMR workloads; it is a re-statement of the construction's parallelism.
[§4.4.3] The protocol text says collision blocks are "initially validated" and "uploaded to the data pool to await processing," but also that collisions are "updated at the end of each consensus round." It is unclear whether a collision block is a committed block or a pending transaction, and no consensus step is described that verifies the patient's authorization or the placement of the collision block as a branch root. This ambiguity is load-bearing because the tree grows only when collision blocks become new branch roots.

minor comments (4)

[Figure 7] The labels in Figure 7 are inconsistent with the text: the B1-3 block is labelled "Metadata(Bob<Flu>)" while the text says Claire's Flu, and B2-1 is labelled "Metadata(Ella<cold>)" while the text says Daisy COVID.
[Table IV] The header contains the typo "Syetem" and should be "System."
[§4.4.3] The running example introduces Ella as a new patient but then uses only Claire and Daisy in the actual block construction; the narrative should be aligned with the figure.
[§5] The benchmark and simulation results are reported without error bars, repetition counts, or confidence intervals; given the small differences among configurations, this limits the strength of the quantitative conclusions.

Circularity Check

1 steps flagged · score 6.0 of 10

The claimed n× throughput gain is the architecture's definition; the branch-forming collision mechanism is internally inconsistent.

self definitional [Abstract; Section 4.1 Core idea; Section 4.4.1 Self-processing; Section 5.2 D1]
"Through expanding the one-chain structure into a growing tree, the throughput, blocks per round, is increased from one to n (n is the branch number)... the core mechanism for parallel processing of multiple blocks in one consensus round is that each branch can be seen as a block append point."

The central speedup claim is entailed by the definitions: a branch is defined as a block-append point, and throughput is blocks per round, so n branches by construction yield n blocks per round and ν·n blocks per second. The simulation in D1-D4 re-derives this arithmetic (more branches or collisions mean more blocks per round) rather than testing an independent prediction. The measured overheads (chameleon hash, network, RocksDB) are empirical, but the n-fold scaling itself is exactly the construction's definition, not a derived result.

full rationale

No parameter fitting or self-citation chain is used, so fitted-input and self-citation circularity patterns are absent. The only step that reduces by construction is the headline throughput claim: if n branches each append one block per consensus round, BPS scales as n by definition, so Figures 8-11 demonstrate the design arithmetic rather than an independent prediction. That warrants a moderate score. Two correctness risks (not circularity) are flagged: §4.2.2 requires a collision block to share Chamehash and pre_hash with the prior block while remaining distinct via a branch index; if the index is hashed the chameleon collision cannot exist, and if it is not hashed branch identity is not cryptographically anchored. Also, patient awareness is assumed via SK being only held by patients while collision blocks are generated by practitioners using SK; this is a contradiction in assumptions, not a circular derivation. MedBlockTree is self-contained against external baselines and does not rely on self-citations, so the circularity burden is partial rather than total.

Assumptions & free parameters 1 free parameters · 6 assumptions · 2 invented entities

The performance result rests on the assumption that a tree with n branches can be finalized consistently and that collision blocks do not compromise integrity. None of these assumptions is proven formally, and the simulation does not test the adversarial or equivocation cases, so the ledger is structurally burdened by unverified premises.

free parameters (1)

ν (throughput scaling factor) = undefined in text
The abstract claims 'processing speeds ν·n times faster', but ν never appears in the body. It is introduced ad hoc and never defined or measured.

assumptions (6)

standard math A chameleon hash is collision-resistant without the trapdoor and allows the trapdoor holder to generate a valid collision for any new message.
Assumed in §3.1 and used in §4.2.2; taken from [15] and [17], but no proof or instantiation details for the identity-based variant are given.
domain assumption Each participant, including patients, holds a secret key SKn that is never shared with anyone else.
Stated in §4 assumption 1: 'SKn is securely held by the owner.' This assumption conflicts with practitioners generating collision blocks using the patient's key in §4.2.2.
ad hoc to paper A collision block generated by an authorized practitioner using the patient's key is automatically valid and can become a new branch root.
§4.2.2: 'if a returning patient's newly generated metadata is default validated, it can be prioritized and uploaded in the next consensus round.' This validation rule is a trust assumption.
ad hoc to paper EnhancedPro's BFT voting with at least 2/3 of deposited tokens per branch guarantees network consistency across all branches.
§4.4.2 imposes the 2/3 threshold, but no safety or liveness proof is provided, and message interactions across simultaneous branches are not formally modelled.
ad hoc to paper Winner election via Hash(ζ,n) modulo total deposits is fair and unpredictable.
§4.4.1 Equation (1); the inputs ζ and n are public before the round, so unpredictability is asserted without proof, and the paper's fairness test is only an empirical histogram.
ad hoc to paper In each round, branch n can be matched with metadata pack index n so that n blocks are produced per round.
Algorithm 1, lines 16-19: 'if n = ι then ... createBlock' assumes a one-to-one relation between branch numbers and metadata indices; no queueing or ordering policy is defined.

invented entities (2)

Collision block
purpose: A block that has the same chameleon hash as a patient's existing block but contains new metadata; used as a validated branch root.
No external evidence is provided for its validity; it is asserted by construction and conflicts with hash-based identity in a ledger.
Sub-node
purpose: A virtual index unit representing one deposit token, used to weight winner elections by stake.
An internal mechanism of EnhancedPro with no independent validation or formal analysis.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Efficient patient-centric EMR sharing block tree." pith.science (2026). https://pith.science/paper/IUOETENK

@misc{pith2026250420544,
  author       = {Pith},
  title        = {Pith review of: Efficient patient-centric EMR sharing block tree},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IUOETENK}},
  note         = {Machine review of arXiv:2504.20544}
}

abstract

Flexible sharing of electronic medical records (EMRs) is an urgent need in healthcare, as fragmented storage creates EMR management complexity for both practitioners and patients. Blockchain has emerged as a promising solution to address the limitations of centralized EMR systems regarding interoperability, data ownership, and trust concerns. Whilst its healthcare implementation continues to face scalability challenges, particularly in uploading lag time as EMR volumes increase. In this paper, we describe the design of a novel blockchain-based data structure, MedBlockTree, which aims to solve the scalability issue in blockchain-based EMR systems, particularly low block throughput and patient awareness. MedBlockTree leverages a chameleon hash function to generate collision blocks for existing patients and expand a single chain into a growing block tree with $n$ branches that are capable of processing $n$ new blocks in a single consensus round. We also introduce the EnhancedPro consensus algorithm to manage multiple branches and maintain network consistency. Our comprehensive simulation evaluates performance across four dimensions: branch number, worker number, collision rate, and network latency. Comparative analysis against a traditional blockchain-based EMR system demonstrates outstanding throughput improvements across all dimensions, achieving processing speeds $\nu\cdot n$ times faster than conventional approaches.

Figures

Figures reproduced from arXiv: 2504.20544 by the authors.

**Figure 1.** Block structure Block index B1-1 - Chamehash(Alice) - Metadata(Alice<cold>) - Chameleon strings 1 ... - Pre_hash: Chamehash(Genesis) Block index B2-0 - Chamehash(Alice) - Metadata(Alice<FLU>) - Chameleon strings 2 ... - Pre_hash: Chamehash(Genesis) [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗

**Figure 4.** Example of MedBlockTree with two branches [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗

**Figure 5.** Pre-vote and Commit vote VRFπ, for winners. The other workers can validate the block by the winners’ PKs and the proofs. The overall algorithm of self-processing is shown in Algorithm 1. Algorithm 1 MedBlockTree Self-processing Algorithm Input: former blocks map, sub-node indexes, workers’ list Output: winners map={B1: winner1, B2: winner2, ..., B(n): winnern}, block proposals, VRFys, VRFπs 1: New consensus round st… view at source ↗

Figures from the paper (5 more)

**Figure 6.** Figure 6: Events in networks 4.4.3 Tree update Tree updating contains two parts: new blocks appending and collision blocks claiming. The new blocks will be appended to the MedBlockTree according to the BlockMap. The collision blocks created by the practitioners are based on the …

**Figure 7.** Figure 7: Example of updated MedBlockTree TABLE II: Simulation environments Environment Description Platform Catalyst Cloud Operating System ubuntu (24.04 64), 2 core, 4 RAM Network status 100ms / 200ms latency Data set 2000 generated EMRs Database RocksDB, Redis 5. PERFORMANCE …

**Figure 8.** Figure 8: MedBlockTree performance with increasing branch [PITH_FULL_IMAGE:figures/full_fig_p007_8.png]

**Figure 10.** Figure 10: Performance comparison with various network sizes [PITH_FULL_IMAGE:figures/full_fig_p008_10.png]

**Figure 11.** Figure 11: Performance comparison with various collision [PITH_FULL_IMAGE:figures/full_fig_p008_11.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

30 extracted references · 28 canonical work pages

[1]

Annas, G.J.: Hipaa regulations—a new era of medical- record privacy? New England Journal of Medicine 348(15), 1486–1490 (2003)

work page 2003
[2]

IEEE Communications Surveys & Tutorials 25(1), 386–424 (2023)

Arbabi, M.S., Lal, C., Veeraragavan, N.R., Marijan, D., Nyg ˚ard, J.F., Vitenberg, R.: A survey on blockchain for healthcare: Challenges, benefits, and future directions. IEEE Communications Surveys & Tutorials 25(1), 386–424 (2023). https://doi.org/10.1109/COMST.2022.3224644

arXiv 2023
[3]

The Lancet Psychiatry 10(4), 242–244 (2023)

Astle, D.E., et al.: We need timely access to mental health data: implications of the goldacre review. The Lancet Psychiatry 10(4), 242–244 (2023)

work page 2023
[4]

International Journal of Health- care Management 15(1), 70–83 (2022)

Attaran, M.: Blockchain technology in healthcare: Chal- lenges and opportunities. International Journal of Health- care Management 15(1), 70–83 (2022)

work page 2022
[5]

arXiv preprint arXiv:1407.3561 (2014)

Benet, J.: Ipfs-content addressed, versioned, p2p file system. arXiv preprint arXiv:1407.3561 (2014)

arXiv 2014
[6]

In: Proceedings of the 12th International Symposium on Information and Communication Technology

Bui, N.P., Hoang, M.T., Nguyen, T., Dinh, H.H.Q., Nguyen, B.M.: An enhanced tendermint consensus proto- col powered by elliptic curve vrf for beacon chain model. In: Proceedings of the 12th International Symposium on Information and Communication Technology. pp. 517– 524 (2023)

work page 2023
[7]

nz/, accessed: April 12, 2025

Catalyst Cloud: Catalyst cloud – new zealand’s leading sovereign cloud provider (2024), https://catalystcloud. nz/, accessed: April 12, 2025

work page 2024
[8]

Facebook, Inc.: Rocksdb: A persistent key-value store for fast storage environments (2024), https://rocksdb.org, accessed: April 12, 2025

work page 2024

Show all 30 references

[9]

International Journal of Market Research 59(6), 703–705 (2017)

Goddard, M.: The eu general data protection regulation (gdpr): European regulation that has a global impact. International Journal of Market Research 59(6), 703–705 (2017)

2017
[10]

Peer-to-Peer Network- ing and Applications pp

Guo, G., Zhu, Y ., Chen, E., Zhu, G., Ma, D., Chu, W.C.: Continuous improvement of script-driven verifi- able random functions for reducing computing power in blockchain consensus protocols. Peer-to-Peer Network- ing and Applications pp. 1–20 (2022)

2022
[11]

Journal of Medical Systems 46(12), 86 (2022)

Hermansen, A., Regier, D.A., Pollard, S.: Developing data sharing models for health research with real-world data: a scoping review of patient and public preferences. Journal of Medical Systems 46(12), 86 (2022)

2022
[12]

ICT Express 8(1), 56–60 (2022)

Johari, R., Kumar, V ., Gupta, K., Vidyarthi, D.P.: BLO- SOM: BLOckchain technology for Security of Medical records. ICT Express 8(1), 56–60 (2022)

2022
[13]

In: 2024 IEEE International Con- ference on Blockchain and Distributed Systems Security (ICBDS)

Kale, D.R., Jadhav, A.N., Salunkhe, S.J., Hirve, S., Goswami, C., et al.: Sharding: A scalability solutions for blockchain networks. In: 2024 IEEE International Con- ference on Blockchain and Distributed Systems Security (ICBDS). pp. 1–8. IEEE (2024)

2024
[14]

Annals of internal medicine 164(7), 500–502 (2016)

Kesselheim, A.S., Hwang, T.J.: Breakthrough medical devices and the 21st century cures act. Annals of internal medicine 164(7), 500–502 (2016)

2016
[15]

Cryptology ePrint Archive (1998)

Krawczyk, H., Rabin, T.: Chameleon hashing and signa- tures. Cryptology ePrint Archive (1998)

1998
[16]

In: 2020 {USENIX} Annual Technical Conference ({USENIX}{ATC} 20)

Li, C., Li, P., Zhou, D., Yang, Z., Wu, M., Yang, G., Xu, W., Long, F., Yao, A.C.C.: A decentralized blockchain with high throughput and fast confirma- tion. In: 2020 {USENIX} Annual Technical Conference ({USENIX}{ATC} 20). pp. 515–528 (2020)

2020
[17]

In: Proceedings of the IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP)

Li, C., Shen, Q., Xie, Z., Dong, J., Fang, Y ., Wu, Z.: Effi- cient identity-based chameleon hash for mobile devices. In: Proceedings of the IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP). pp. 3039–3043. IEEE (2022)

2022
[18]

In: Proceedings of the IEEE Symposium on Computers and Communications (ISCC)

Li, J., Pandey, V ., et al.: A blockchain-based personal health knowledge graph for secure integrated health data management. In: Proceedings of the IEEE Symposium on Computers and Communications (ISCC). pp. 1–7. IEEE (2023)

2023
[19]

Scientific Reports 14(1), 11746 (2024)

Ma, S., Zhang, X.: Integrating blockchain and zk-rollup for efficient healthcare data privacy protection system via ipfs. Scientific Reports 14(1), 11746 (2024)

2024
[20]

In: Proceedings of the 40th annual sym- posium on foundations of computer science (cat

Micali, S., Rabin, M., Vadhan, S.: Verifiable random functions. In: Proceedings of the 40th annual sym- posium on foundations of computer science (cat. No. 99CB37039). pp. 120–130. IEEE (1999)

1999
[21]

In: 2024 IEEE International Con- ference on Blockchain and Cryptocurrency (ICBC)

Raikwar, M., Polyanskii, N., M ¨uller, S.: Sok: Dag-based consensus protocols. In: 2024 IEEE International Con- ference on Blockchain and Cryptocurrency (ICBC). pp. 1–18. IEEE (2024)

2024
[22]

Cluster Computing 27(5), 5547–5570 (2024)

Rao, I.S., Kiah, M.M., Hameed, M.M., Memon, Z.A.: Scalability of blockchain: a comprehensive review and future research direction. Cluster Computing 27(5), 5547–5570 (2024)

2024
[23]

In: Proceedings of the IEEE International Conference on Consumer Electronics (ICCE)

Sakurai, A., Shudo, K.: Impact of the hash rate on the theoretical fork rate of blockchain. In: Proceedings of the IEEE International Conference on Consumer Electronics (ICCE). pp. 1–4. IEEE (2023)

2023
[24]

In: Proceedings of the Interna- tional Conference on Information and Communication Technology Convergence

Santiago, C., Lee, C.: Accelerating message propagation in blockchain networks. In: Proceedings of the Interna- tional Conference on Information and Communication Technology Convergence. pp. 157–160. IEEE (2020)

2020
[25]

Journal of Medical Systems 45, 1–10 (2021)

Santos, J.A., Inacio, P.R., Silva, B.M.: Towards the use of blockchain in mobile health services and applications. Journal of Medical Systems 45, 1–10 (2021)

2021
[26]

The Lancet Digital Health 3(6), e383–e396 (2021)

Sheikh, A., Anderson, M., Albala, S., Casadei, B., Franklin, B.D., Richards, M., Taylor, D., Tibble, H., Mossialos, E.: Health information technology and digital innovation for national learning health and care systems. The Lancet Digital Health 3(6), e383–e396 (2021)

2021
[27]

Cryptology ePrint Archive (2016)

Sompolinsky, Y ., Lewenberg, Y ., Zohar, A.: Spectre: A fast and scalable cryptocurrency protocol. Cryptology ePrint Archive (2016)

2016
[28]

Graphs: theory and algorithms 118 (1992)

Thulasiraman, K., Swamy, M.: 5.7 acyclic directed graphs. Graphs: theory and algorithms 118 (1992)

1992
[29]

ACM Computing Surveys 55(13s), 1–35 (2023)

Xu, J., Wang, C., Jia, X.: A survey of blockchain consensus protocols. ACM Computing Surveys 55(13s), 1–35 (2023)

2023
[30]

Information Processing & Management 58(4), 102604 (2021)

Zou, R., Lv, X., Zhao, J.: Spchain: Blockchain-based medical data sharing and privacy-preserving ehealth system. Information Processing & Management 58(4), 102604 (2021)

2021

Pith tools

Reviewed August 16, 2026 · model on record in the stance chip above.

[1] [1]

Annas, G.J.: Hipaa regulations—a new era of medical- record privacy? New England Journal of Medicine 348(15), 1486–1490 (2003)

work page 2003

[2] [2]

IEEE Communications Surveys & Tutorials 25(1), 386–424 (2023)

Arbabi, M.S., Lal, C., Veeraragavan, N.R., Marijan, D., Nyg ˚ard, J.F., Vitenberg, R.: A survey on blockchain for healthcare: Challenges, benefits, and future directions. IEEE Communications Surveys & Tutorials 25(1), 386–424 (2023). https://doi.org/10.1109/COMST.2022.3224644

arXiv 2023

[3] [3]

The Lancet Psychiatry 10(4), 242–244 (2023)

Astle, D.E., et al.: We need timely access to mental health data: implications of the goldacre review. The Lancet Psychiatry 10(4), 242–244 (2023)

work page 2023

[4] [4]

International Journal of Health- care Management 15(1), 70–83 (2022)

Attaran, M.: Blockchain technology in healthcare: Chal- lenges and opportunities. International Journal of Health- care Management 15(1), 70–83 (2022)

work page 2022

[5] [5]

arXiv preprint arXiv:1407.3561 (2014)

Benet, J.: Ipfs-content addressed, versioned, p2p file system. arXiv preprint arXiv:1407.3561 (2014)

arXiv 2014

[6] [6]

In: Proceedings of the 12th International Symposium on Information and Communication Technology

Bui, N.P., Hoang, M.T., Nguyen, T., Dinh, H.H.Q., Nguyen, B.M.: An enhanced tendermint consensus proto- col powered by elliptic curve vrf for beacon chain model. In: Proceedings of the 12th International Symposium on Information and Communication Technology. pp. 517– 524 (2023)

work page 2023

[7] [7]

nz/, accessed: April 12, 2025

Catalyst Cloud: Catalyst cloud – new zealand’s leading sovereign cloud provider (2024), https://catalystcloud. nz/, accessed: April 12, 2025

work page 2024

[8] [8]

Facebook, Inc.: Rocksdb: A persistent key-value store for fast storage environments (2024), https://rocksdb.org, accessed: April 12, 2025

work page 2024