REVIEW 4 major objections 4 minor 22 references
Usage of Permissioned Blockchain Architecture for Big Data in Electronic Medical Records
T0 review · 4 major / 4 minor · reviewed 2026-08-14 · deepseek-v4-flash
Pith's one-line read Medi-Chain is a permissioned blockchain for electronic medical records that uses BigchainDB's Byzantine-fault-tolerant consensus and a desktop app to make medical data secure, searchable, and usable by patients, doctors, insurers, and…
desk verdict A concrete but unvalidated design sketch whose central privacy claim is contradicted by its own plaintext, fully-replicated ledger. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The load-bearing mechanism is the permissioned blockchain itself: BigchainDB runs Tendermint-style BFT consensus, which replicates state across nodes and tolerates failure or misbehavior by up to one-third of the network, and stores data as BSON objects that allow nested medical records. Access control is carried by a 'superset' elevation field that assigns each account a level, with higher levels gaining more write permissions, and by a separate login-data structure on the ledger. The phone number is the join key that links patient, prescription, login, insurance, and donor records into a single retrievable chain.
What would settle it
Inspect the login data structure described in Section III-C of the paper: if the deployed code keeps the 'pass' field in plaintext on the ledger, then any node operator can read every user's credential, refuting the stated privacy guarantee.
Extended reading notes
Core claim
The central claim is that BigchainDB, with its Byzantine-fault-tolerant consensus and BSON data objects, is a suitable foundation for a permissioned medical-record blockchain for large populations. Medi-Chain stores patient biodata, prescriptions, login details, and insurance information as linked BSON objects, with an elevation-level access-control list governing who can read or alter each record and the patient's phone number as the common key that ties records together. On top of that ledger, a desktop application adds an open blood-donor index, one-button insurance claims, an anonymized research index, and IPFS-backed storage for scanned prescriptions.
Load-bearing premise
The central privacy promise rests on the assumption that an invitation-only blockchain plus a role-based access list is enough to protect patient data, even though the design stores login credentials on the ledger and links every record by the patient's phone number.
Editorial extensions
If this is right
- A hospital or clinic could run Medi-Chain on four servers and give patients, doctors, insurers, and researchers access through one desktop app, with no per-transaction fees.
- Doctors could search an open blood-donor index by blood type and send anonymous donation requests without exposing personal details.
- Insurance companies could pull a patient's coverage directly from the ledger for one-button claims, while an admin reviews and revokes suspicious requests.
- Researchers could query anonymized age-group cohorts from live records, since the desktop layer strips names and phone numbers before display.
- Handwritten prescriptions could be scanned into PDFs, PNGs, or JPGs and stored on a permissioned IPFS fork tied to the patient's blockchain record.
Reading between the lines
- The paper leaves implicit that using the phone number as the common key makes records re-identifiable: anyone who knows a patient's number and can read the ledger could link prescriptions, insurance, and login data to that person.
- The paper leaves implicit that storing login data on the blockchain gives every node operator the ability to harvest credentials if passwords are not hashed, a risk separate from the access-control list.
- The paper takes BigchainDB's throughput and fault-tolerance figures as given; an independent multi-site deployment test would be needed to confirm the scalability claims for a national healthcare workload.
- The elevation-level access list appears to be an application-layer control rather than a cryptographic one, so a lower-elevation user who bypasses the desktop interface could potentially read records directly from the ledger.
Signed reviews
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper proposes Medi-Chain, a permissioned blockchain architecture for electronic medical records based on BigchainDB, with a desktop application, elevation-based access control, and features such as a blood donor index, insurance claim processing, research data access, and IPFS-based prescription storage. The manuscript describes data structures, a deployment scenario involving four or more servers, and argues for the system's usability and low cost. No prototype, implementation, benchmark, security analysis, or formal proof is provided; all performance and security assertions rest on external white-paper claims or unstated assumptions.
Significance. If the architecture actually delivered what is claimed, it would address a relevant problem: usable, low-cost, permissioned blockchain storage for medical records in resource-constrained settings. The paper also engages with a genuine usability concern by proposing a desktop front-end to abstract the blockchain backend. These strengths, however, are entirely conceptual. The manuscript provides no evidence that the system is secure, private, or performant; every central claim is asserted rather than demonstrated. The referenced prior work (e.g., MedRec, BBDS) is cited but not compared technically. The paper's contribution as written is therefore limited to a high-level design sketch, and the central privacy claim is internally contradicted by the design's own data structures.
major comments (4)
- [§II, §III-A, §III-C] The central privacy claim is invalidated by the described design. Section II states that BigchainDB replicates state over multiple nodes, and Section II-A.3 acknowledges that every node holds a copy of the ledger. Section III-A stores patient objects containing name, gender, date of birth, phone number, photo, blood group, allergies, and insurance details as plaintext BSON. Section III-C stores 'user' and 'pass' directly in the login object. No encryption of the BSON payloads, hashing of credentials, or cryptographic access control is described. The only access-control mechanism is an ACL that 'controls the login page of the application' (Section II), which is an application-level gate. Any operator of a participating node can bypass the desktop application and query the underlying MongoDB/BigchainDB directly, reading all patient records and doctor login credentials. The privacy guarantee therefore fails against the nodes that maintain the network; this is an internal inconsistency in the design, not merely a missing formal analysis.
- [§V] The deployment claims are unsupported and effectively non-falsifiable as stated. The paper asserts that a Raspberry Pi device can be used as a mainframe server and 'can host more than 20 screens to actively run on any mobile device per server' (Section V), but no measurements, configuration details, or workload description are provided. This claim is load-bearing for the paper's feasibility argument, which is the main basis for its adoption narrative. Similarly, the transaction throughput figure of 320 transactions per second is quoted from the BigchainDB white paper (Section II-A.1) without any validation for the proposed ten-node (or four-node) deployment, and without accounting for the replication and access-control overhead of this system.
- [§IV-D] The proposed 'fork of IPFS with hidden permissions and end-points' is an invented entity with no specification, reference implementation, or security analysis. Section IV-D states that such a fork 'can be setup' to save sensitive documents, but nothing in the paper explains how permissions are enforced in a content-addressed peer-to-peer file system, how the fork would interoperate with the rest of Medi-Chain, or what threat model permits a hidden-permissions fork to keep data confidential from the IPFS network. The prescription-history feature therefore cannot be assessed and should not be presented as part of the proposed architecture without at least a cited precedent or a concrete design.
- [§III-D] Using the patient's phone number as the common key to link all records is a direct privacy weakness that contradicts the abstract's claim of 'highly secure and private medical data records.' A phone number is a personal identifier with strong linkage to identity; storing it as an unencrypted key on a replicated ledger means that anyone with access to the raw database can collate prescriptions, insurance claims, and login data for a given patient simply by querying the phone field. This point is not a minor implementation detail; it is the central linking mechanism of the data model and undermines the claimed privacy guarantee.
minor comments (4)
- [§II-A.3] There are typographical errors in key terms, e.g., 'state replecation' in the section heading and 'state replecation' in the body; also 'Medi-Chain contains of two parts' and 'technolgical' in §II-A. These do not block comprehension but should be corrected.
- [Fig. 2] Figure 2 is referenced as a 'Heirarchial Representation of elevation levels,' but the paper does not define the elevation levels in any detail. The caption and surrounding text describe hierarchy without specifying what permissions each level grants, which makes the access-control design impossible to evaluate.
- [§II-A] The comparison of blockchain choices (Ethereum, Corda, Hyperledger, BigchainDB, etc.) is qualitative and does not include any quantitative latency, cost, or scalability data other than the quoted BigchainDB throughput. Since the choice of BigchainDB is load-bearing for the performance claim, a fuller comparison with citations to actual measurements would strengthen the manuscript.
- [§V] The paper states that 'Private hospitals can easily afford the low-cost blockchain solution' but provides no cost breakdown. The cost argument is central to the adoption narrative and should be supported with at least a rough estimate of node hardware, storage, and operational costs.
Circularity Check
No circularity: the paper asserts a security/performance architecture rather than deriving predictions from fitted inputs or self-cited theorems.
full rationale
The paper does not contain a derivation chain that could be circular. It presents a proposed architecture for a permissioned medical-record blockchain, with data structures (patient, prescription, login) and a stated reliance on BigchainDB/Tendermint BFT consensus and an access-control list. There are no equations, no fitted parameters later 'predicted' as results, and no uniqueness theorem imported from the authors' prior work. The only self-citation is reference [10], a prior IEEE paper on a smart work-assisting gear, and it is not invoked anywhere in the argument for Medi-Chain's privacy or performance claims. The central privacy claim is asserted rather than derived, and the design's plaintext storage of patient data and login credentials may undermine that claim, but that is a soundness or correctness objection, not circularity. Because the paper is self-contained as a design proposal and does not reduce any result to its own inputs, the circularity score is 0.
Assumptions & free parameters
assumptions (4)
- domain assumption BigchainDB's advertised performance (320 transactions per second and 1 million transactions in 26 minutes) and Tendermint's 33.3% fault tolerance hold in the proposed medical deployment.
- domain assumption A permissioned blockchain with an elevation-level access-control list provides 'highly secure and private medical data records.'
- ad hoc to paper Linking all patient records by phone number preserves patient privacy.
- ad hoc to paper A Raspberry Pi can act as a mainframe server hosting more than 20 screens per server.
invented entities (2)
-
Medi-Chain
-
Hidden-permissions fork of IPFS
Cite this review
Pith. "Pith review of Usage of Permissioned Blockchain Architecture for Big Data in Electronic Medical Records." pith.science (2026). https://pith.science/paper/O7DE2AYY
@misc{pith2026190901091,
author = {Pith},
title = {Pith review of: Usage of Permissioned Blockchain Architecture for Big Data in Electronic Medical Records},
year = {2026},
howpublished = {\url{https://pith.science/paper/O7DE2AYY}},
note = {Machine review of arXiv:1909.01091}
}
read the original abstract
With the advent of blockchain technology, multiple research avenues and platforms for dialogue have opened up. However technology transfer to the pubic has not been implemented, such that regular public can access and make use of secure and decentralized software. Most blockchain solutions till date deal with financial applications or monetary transactions, which may not be helpful or be accessible to the general public, especially the lower levels of the financial society. Medi-Chain is a people-first medical blockchain with a usable desktop application and interface which makes use of cutting-edge blockchain technology along with BFT consensus protocols to ensure highly secure and private medical data records. This paper aims to bring about a change in how blockchains-as-a-service is perceived and how adoption of new technology is largely based on usability and ease of adoption.
Figures
Reference graph
Works this paper leans on
-
[1]
”BigchainDB: a scalable blockchain database.” white paper, BigChainDB (2016)
McConaghy, Trent, et al. ”BigchainDB: a scalable blockchain database.” white paper, BigChainDB (2016)
work page 2016
-
[2]
”Ipfs-content addressed, versioned, p2p file system.” arXiv preprint arXiv:1407.3561 (2014)
Benet, Juan. ”Ipfs-content addressed, versioned, p2p file system.” arXiv preprint arXiv:1407.3561 (2014)
arXiv 2014
-
[3]
”Electronic medical records system.” U.S
Evans, Jae A. ”Electronic medical records system.” U.S. Patent No. 5,924,074. 13 Jul. 1999
work page 1999
-
[4]
Miller, Robert H., and Ida Sim. ”Physicians use of electronic medical records: barriers and solutions.” Health affairs 23.2 (2004): 116-126
work page 2004
-
[5]
Azaria, Asaph, et al. ”Medrec: Using blockchain for medical data access and permission management.” 2016 2nd International Conference on Open and Big Data (OBD). IEEE, 2016
work page 2016
-
[6]
Xia, Qi, et al. ”BBDS: Blockchain-based data sharing for electronic medical records in cloud environments.” Information 8.2 (2017): 44
work page 2017
-
[7]
Liu, Paul Tak Shing. ”Medical record system using blockchain, big data and tokenization.” International conference on information and communications security. Springer, Cham, 2016
work page 2016
-
[8]
Kim, Tai-hoon, and Seung-youn Lee. ”Security evaluation targets for enhancement of IT systems assurance.” International Conference on Computational Science and Its Applications. Springer, Berlin, Heidelberg, 2005
work page 2005
Show all 22 references
-
[9]
”IoT data privacy via blockchains and IPFS.” Proceedings of the Seventh International Conference on the Internet of Things
Ali, Muhammad Salek, Koustabh Dolui, and Fabio Antonelli. ”IoT data privacy via blockchains and IPFS.” Proceedings of the Seventh International Conference on the Internet of Things. ACM, 2017
2017
-
[10]
”Smart work-assisting gear.” 2018 IEEE 4th World Forum on Internet of Things (WF-IoT)
Gupta, Projjal, et al. ”Smart work-assisting gear.” 2018 IEEE 4th World Forum on Internet of Things (WF-IoT). IEEE, 2018
2018
-
[11]
”Privacy and medicine.” (2009)
Allen, Anita. ”Privacy and medicine.” (2009)
2009
-
[12]
Barrows Jr, Randolph C., and Paul D. Clayton. ”Privacy, confidential- ity, and electronic medical records.” Journal of the American medical informatics association 3.2 (1996): 139-148
1996
-
[13]
”Patient controlled encryption: ensuring privacy of electronic medical records.” Proceedings of the 2009 ACM workshop on Cloud computing security
Benaloh, Josh, et al. ”Patient controlled encryption: ensuring privacy of electronic medical records.” Proceedings of the 2009 ACM workshop on Cloud computing security. ACM, 2009
2009
-
[14]
”Privacy of medical records: IT implications of HIPAA.” ACM SIGCAS Computers and Society 30.4 (2000): 40-47
Baumer, David, Julia Brande Earp, and Fay Cobb Payton. ”Privacy of medical records: IT implications of HIPAA.” ACM SIGCAS Computers and Society 30.4 (2000): 40-47
2000
-
[15]
”Views on health information sharing and privacy from primary care practices using electronic medical records.” Interna- tional journal of medical informatics 80.2 (2011): 94-101
Perera, Gihan, et al. ”Views on health information sharing and privacy from primary care practices using electronic medical records.” Interna- tional journal of medical informatics 80.2 (2011): 94-101
2011
-
[16]
”Patients, privacy and trust: patients willingness to allow researchers to access their medical records.” Social science & medicine 64.1 (2007): 223-235
Damschroder, Laura J., et al. ”Patients, privacy and trust: patients willingness to allow researchers to access their medical records.” Social science & medicine 64.1 (2007): 223-235
2007
-
[17]
Gaur, Danica Balazova, and Samir K
Agrawal, Anurag, Jaijit Bhattacharya, Nishant Baranwal, Sushil Bhatla, Salil Dube, Viren Sardana, Devender R. Gaur, Danica Balazova, and Samir K. Brahmachari. ”Integrating health care delivery and data col- lection in rural India using a rapidly deployable eHealth center.” PLo...
2013
-
[18]
”A case study of an EMR system at a large hospital in India: challenges and strategies for successful adoption.” Journal of biomedical informatics 44.6 (2011): 958-967
Scholl, Jeremiah, Shabbir Syed-Abdul, and Luai Awad Ahmed. ”A case study of an EMR system at a large hospital in India: challenges and strategies for successful adoption.” Journal of biomedical informatics 44.6 (2011): 958-967
2011
-
[19]
”System and method for man- aging patient medical records.” U.S
Lavin, Marianne, and Michael Nathan. ”System and method for man- aging patient medical records.” U.S. Patent No. 5,772,585. 30 Jun. 1998
1998
-
[20]
Krieger, Nancy. ”Overcoming the absence of socioeconomic data in medical records: validation and application of a census-based method- ology.” American journal of public health 82.5 (1992): 703-710
1992
-
[21]
”A proposal for electronic medical records in US primary care.” Journal of the American Medical Informatics Association 10.1 (2003): 1-10
Bates, David W., et al. ”A proposal for electronic medical records in US primary care.” Journal of the American Medical Informatics Association 10.1 (2003): 1-10
2003
-
[22]
Melton III, L. Joseph. ”The threat to medical-records research.” (1997): 1466-1470
1997
Reviewed August 14, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.