This is an open-access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in the Journal of Medical Internet Research, is properly cited. The complete bibliographic information, a link to the original publication on http://www.jmir.org/, as well as this copyright and license information must be included.
A blockchain is a list of records that uses cryptography to make stored data immutable; their use has recently been proposed for electronic medical record (EMR) systems. This paper details a systematic review of trade-offs in blockchain technologies that are relevant to EMRs. Trade-offs are defined as “a compromise between two desirable but incompatible features.”
This review’s primary research question was: “What are the trade-offs involved in different blockchain designs that are relevant to the creation of blockchain-based electronic medical records systems?”
Seven databases were systematically searched for relevant articles using the Preferred Reporting Items for Systematic Reviews and Meta-Analyses (PRISMA). Papers published from January 1, 2017 to June 15, 2018 were selected. Quality assessments of papers were performed using the Risk Of Bias In Non-randomized Studies—of Interventions (ROBINS-I) tool and the Critical Assessment Skills Programme (CASP) tool. Database searches identified 2885 articles, of which 15 were ultimately included for analysis.
A total of 17 trade-offs were identified impacting the design, development, and implementation of blockchain systems; these trade-offs are organized into themes, including business, application, data, and technology architecture.
The key findings concluded the following: (1) multiple trade-offs can be managed adaptively to improve EMR utility; (2) multiple trade-offs involve improving the security of blockchain systems at the cost of other features, meaning EMR efficacy highly depends on data protection standards; and (3) multiple trade-offs result in improved blockchain scalability. Consideration of these trade-offs will be important to the specific environment in which electronic medical records are being developed. This review also uses its findings to suggest useful design choices for a hypothetical National Health Service blockchain.
RR2-10.2196/10994
Blockchains contain
Transactions between individuals are recorded. These data are
A: hash functions convert data into fixed-length strings (hashes). B: similar but unidentical data have very different hashes. C: identical data have identical hashes, allowing for verification. D: all lengths of data produce fixed-length hashes.
The hash of the previous block, the Merkle root, and the Nonce are combined into a single hash. This is included in the next block header, linking the two blocks.
To add new blocks, a majority of users must want the same new block (ie, consensus). However, malicious users could create multiple accounts to gain control. To avoid this, Bitcoin uses proof of work (PoW); this requires the users’ processing power for consensus, which will not increase for a user owning multiple accounts. PoW works when the network randomly generates a
Mining is computationally difficult but finding the right number (ie, a nonce) is rewarded with bitcoins. If miners use their combined computational power to mine the same block and share the rewards after finding the nonce, they are more likely to make money than if mining alone. This encourages consensus.
A new block is formed on the chain when a correct nonce is found. The hashes of the previous block are combined into the Merkle root of the new block, cryptographically linking the two blocks (see
Were someone to try to maliciously edit a transaction, they would have to mine a new nonce. This is because a different transaction value needs a different nonce to get the target hash. Furthermore, edits would need to be made to subsequent blocks to ensure chain coherence. For malicious users to find nonces faster than the rate at which nonces are found on the
As described in the 2019 Topol Review [
While the principle of cryptographically linked blocks underpins a blockchain, many design choices can be made [
This review’s research question was derived from Meinert et al’s review protocol [
What are the trade-offs involved in different blockchain designs that are relevant to the creation of blockchain-based electronic medical records systems? This research question is based on the following definitions, which are sorted into Population, Intervention, Comparison, and Outcome (PICO) criteria (see
The selection process of this review is demonstrated using the Preferred Reporting Items for Systematic Reviews and Meta-Analyses (PRISMA) flow diagram (see
PICO (Population, Intervention, Comparison, and Outcome) criteria, terms, and definitions.
PICO criterion | Term | Definition |
Population | Blockchain | A growing list of records, called blocks, which are linked using cryptography |
Intervention | Design | A decision about object function with a specific purpose in mind |
Comparison | Electronic medical record | A systematized digital collection and storage of patient data |
Outcome | Trade-off | A compromise between two desirable but incompatible features |
Preferred Reporting Items for Systematic Reviews and Meta-Analyses (PRISMA) flow diagram of the search strategy.
Screening criteria used to remove papers.
Criterion number | Screening criteria | Justification | Removed in pre-peer-review search | Removed in post-peer-review search |
1 | Papers not containing abstracts | The papers cannot be analyzed at the abstract-screening stage and were therefore excluded. | 75 | 0 |
2 | Papers from 2013-2016 | As an emerging technology, ideas about blockchain’s possibilities and limitations are often changing. Older papers were not included, as they may contain information that does not reflect the current state of blockchain technologies. Papers before 2017 were chosen to be excluded, as 2017 was a year characterized by a significant change in blockchain valuation and regulation [ |
328 | 52 |
3 | Full conference proceedings | The relevant full papers in the conference proceedings should have been identified as individual papers in database searches and included in the 1808 papers. | 63 | 0 |
4 | Duplicate titles | These articles contain repeated information. | 125 | 2 |
5 | Does not contain “block” in abstract | Articles that do not mention “block” in their abstract were deemed unlikely to be focused discussions of blockchain technologies and were therefore not included. | 419 | 89 |
6 | Does not contain “design” in abstract | As a PICOa term, a focus on blockchain design was essential to the papers. No alternative MeSHb terms for “design” were identified, so an absence of “design” in abstracts was used to filter out papers. | 590 | 486 |
7 | Title contains “Bitcoin” and not “block” | Papers that mentioned “Bitcoin” in their title and not “blockchain” were deemed to be too focused on the cryptocurrency to provide useful information concerning principles relevant to blockchain design. | 12 | 6 |
8 | Title contains “IoT” or “Internet of things” | Many papers contained a reference to IoTc devices. The abstracts of these papers contained little-to-no relevant information about blockchains. This exclusion criterion was thus used to remove papers. | 15 | 24 |
9 | Title contains “finance” | It was a concern that papers relating to financial elements of blockchains would be too focused on the economic aspects of cryptocurrency. As the intent of this research is to examine the technical, not economical, aspects of blockchains, these papers were removed. | 15 | 2 |
aPICO: Population, Intervention, Comparison, and Outcome.
bMeSH: Medical Subject Headings.
cIoT: internet of things.
The Risk Of Bias In Non-randomized Studies—of Interventions (ROBINS-I) framework was used to assess bias in the 15 remaining papers [
Only narrative data synthesis was appropriate due to study heterogeneity. To structure this, an enterprise architecture framework (ie, a set of principles used to guide enterprise design, planning, and implementation) was used. The Open Group Architecture Framework (TOGAF) [
A critical technology architecture trade-off was current implementation versus future proofing [
Another trade-off is stale block rate versus network delay [
One data architecture trade-off is block window: computation versus communication [
Another data architecture trade-off is data on-chain versus off-chain [
Block size versus throughput [
An additional data architecture trade-off is read and write performance versus scalability [
One final data architecture trade-off is method of information storage: scalability versus immutability [
One application architecture trade-off is expressibility in blockchain language [
Another application architecture trade-off includes errors on the blockchain: filtering and expiration [
An additional application architecture trade-off includes confirmation blocks: confidence versus speed [
Zero-knowledge proof: security versus scalability [
Another application architecture trade-off is blockchain filtering: safety versus flexibility [
Consensus: Byzantine Fault Tolerance (BFT) versus non-BFT [
An additional application architecture trade-off is consensus: agreement versus termination [
A final application architecture trade-off is transparency versus privacy [
One business architecture trade-off is control versus points of failure [
Another business architecture trade-off is fraction of consortium: time versus trust [
At the time of writing, this was the first manuscript identified in literature searches that systematically reviews trade-offs in blockchain design that are relevant to EMRs. While evidence was chosen based on relevance to EMRs, the trade-offs discovered are relevant to blockchain design in other disciplines and industries. Trade-offs were demonstrated with mathematical proofs, real-world examples, and simulations of blockchain networks. Some trade-offs were not directly evidenced, but these trade-offs were logical and comparable to real-world examples. While the list of trade-offs discussed is likely to be nonexhaustive due to study limitations, the trade-offs discovered can improve understanding of blockchain systems for medical professionals, while also providing useful design information for organizations looking to develop blockchain EMRs.
Limitations have been divided into three types, as discussed below.
Firstly, non-English studies were excluded from the review. Secondly, as very few papers discuss the same trade-offs, there is little interpaper support for findings. Thirdly, while most papers contained logical proofs, not all papers contained simulation data. Thus, not all mathematical relationships in trade-offs are known.
Firstly, a lack of accepted MeSH terms for “design” and “trade-off” meant that alternative keyword terms were chosen nonsystematically. This may have caused exclusion of relevant literature. This is particularly pertinent given that not having “design” in the abstract was used to remove 1076 papers from the literature search. Subsequent reviews should aim to filter through these 1076 papers to see if other pertinent terms can be used to filter papers more effectively. Secondly, While the TOGAF was practical for exploring blockchains, it was not designed for this task and was designed in a preblockchain era. A more suitable framework specifically designed for blockchain analysis may be in existence but was not found for this study. Finally, for most papers, ROBINS-I was an inappropriate tool, as no experimental data was present. Papers instead made claims using logical and mathematical proofs. Furthermore, ROBINS-I was a tool developed for assessing bias in trials involving biological organisms subject to variation. ROBINS-I test questions on topics such as time-varying confounding and participant adherence were not appropriate for assessing bias in computer simulations. Questions relating to deviations from intended interventions were entirely irrelevant, due to the instantaneous nature of simulations. The CASP qualitative tool was used in instances where ROBINS-I was completely unsuited, but the tool is significantly less comprehensive than ROBINS-I.
Firstly, the choice to research trade-offs in blockchain design rather than potential solutions to trade-offs may have resulted in some irrelevant trade-offs being discussed in the study. Secondly, four papers that may have contained relevant information were excluded due to the level of technicality being too complex. This may have led to relevant trade-offs being excluded. Thirdly, only papers written after December 2016 were included in order to remove papers with outdated information. However, this cutoff year was relatively arbitrary and may have eliminated potentially useful pre-2017 studies. Fourthly, in paper filtering, exclusion criteria 7, 8, and 9 (see
There were three key findings. Firstly, multiple trade-offs can be adaptively managed. These trade-offs include block size, the number of confirmation blocks required for a transaction, and the fraction of consortium required to process transactions in consortium blockchains. On a blockchain, multiple rule sets for exchanging data can be used. This will allow for adaptive management and maximization of the utility of blockchain EMRs.
Secondly, multiple trade-offs involve improving blockchain systems at the cost of security. Given this, data protection standards will be an important factor in determining the effectiveness of a blockchain EMR system. Given these trade-offs, research should be conducted on the potential effects of current data protection laws on blockchain EMRs. For instance, it may be necessary for further legislative development to allow for the effective development of NHS blockchain EMRs.
Finally, scalability can be encountered at one end of a trade-off. Blockchain scalability can be improved by moving data off-chain, using hash mirroring instead of digital records, and not using ZKP, among other methods. More infrastructure investment would be required to improve scalability otherwise. Given this, it is important that providers wishing to implement blockchain EMR systems understand the current and future scale of their institution. This will allow for the appropriate scalability trade-offs to be made.
This report would make the following specific recommendations for a hypothetical NHS blockchain:
Blockchains should not interfere with the Local Health and Care Record programs. Instead, blockchains can be used to manage long character (LCHR) metadata and access permissions for off-chain LCHR EMRs.
Given that there are multiple trusted institutions that form part of the NHS structure, a consortium blockchain managed by multiple NHS institutions should be considered. Such a system could potentially make use of PBFT.
The blockchain should have an adaptive block size, potentially implemented by machine learning.
A blockchain should be built with a scripting language that is specific to NHS needs, one that is difficult to exploit and minimizes the risk of insertion of potentially hazardous data like malware onto the blockchain. Expiration dates on scripts should also be mandated to prevent exploits being permanent.
A small number of confirmation blocks should be required for read-only access to patient basic emergency medical data (eg, allergies). More conformation blocks should be required for full access and edit permissions.
Future studies should aim to quantify the mathematical relationships between all identified trade-offs in blockchain design. If this is done comprehensively, this will allow for the exact parameters of a blockchain to be purposely selected when designing a blockchain EMR for a specific provider. Identified trade-offs should also ideally be assessed with data from real-world blockchain EMRs. This will allow the impacts of the trade-offs discussed in this paper to be assessed. In addition, the impact of data protection legislation on blockchain systems should be investigated. The security requirements of health care providers may mean that large trade-offs must be made. The impacts of such trade-offs must be fully understood before a health care provider adopts a blockchain EMR. Given study limitations, further literature searches should be performed to find more examples of blockchain design trade-offs. Discovering more trade-offs that can be adaptively managed and discovering how the scalability of blockchains can be increased through trade-offs will help maximize the utility of blockchain-based EMRs.
Exact search strings used in databases.
Review of paper quality using the Risk Of Bias In Non-randomized Studies—of Interventions (ROBINS-I) checklist.
Critical Assessment Skills Programme (CASP) analysis of papers.
Byzantine Fault Tolerance
Critical Assessment Skills Programme
Decentralized Autonomous Organization
electronic medical record
Institute of Electrical and Electronics Engineers
internet of things
long character
Medical Subject Headings
National Health Service
Practical Byzantine Fault Tolerance
Population, Intervention, Comparison, and Outcome
proof of work
Preferred Reporting Items for Systematic Reviews and Meta-Analyses
random access memory
Risk Of Bias In Non-randomized Studies—of Interventions
Strategies for Engineered Negligible Senescence
The Open Group Architecture Framework
zero-knowledge proof
We acknowledge our colleagues in the Department of Computer Science, Department of Engineering, Department of Paediatrics, and the Oxford Academic Health Science Centre for sharing their insights and expertise that assisted in initiating the idea of the project. We would also like to acknowledge Abrar Alturkistani for her help in formatting the paper. This project was supported by the Sir David Cooksey Research Fellowship, the Strategies for Engineered Negligible Senescence (SENS) Research Foundation, and the Oxford Academic Health Science Centre.
None declared.