Skip to main content
Journal of the American Medical Informatics Association : JAMIA logoLink to Journal of the American Medical Informatics Association : JAMIA
. 2019 Mar 25;26(5):462–478. doi: 10.1093/jamia/ocy185

Comparison of blockchain platforms: a systematic review and healthcare examples

Tsung-Ting Kuo 1, Hugo Zavaleta Rojas 2, Lucila Ohno-Machado 1,3,
PMCID: PMC7787359  PMID: 30907419

Abstract

Objectives

To introduce healthcare or biomedical blockchain applications and their underlying blockchain platforms, compare popular blockchain platforms using a systematic review method, and provide a reference for selection of a suitable blockchain platform given requirements and technical features that are common in healthcare and biomedical research applications.

Target audience

Healthcare or clinical informatics researchers and software engineers who would like to learn about the important technical features of different blockchain platforms to design and implement blockchain-based health informatics applications.

Scope

Covered topics include (1) a brief introduction to healthcare or biomedical blockchain applications and the benefits to adopt blockchain; (2) a description of key features of underlying blockchain platforms in healthcare applications; (3) development of a method for systematic review of technology, based on the PRISMA (Preferred Reporting Items for Systematic Reviews and Meta-Analyses) statement, to investigate blockchain platforms for healthcare and medicine applications; (4) a review of 21 healthcare-related technical features of 10 popular blockchain platforms; and (5) a discussion of findings and limitations of the review.

Keywords: blockchain, distributed ledger technology, systematic review, PRISMA, health and Medicine

INTRODUCTION

Healthcare applications using the blockchain technology

Blockchain is a distributed ledger—write once and never erase. Although originally invented for financial transactions,1 its applications are broad.2–4 Medicine, among these applications, is one of the most important and promising areas for adoption of this new technology.2,3,5–13 Four main categories2 of health or clinical blockchain applications are found in the literature: (1) those that improve medical record management (eg, securely storing patient records),14 securely or scalably share clinical data,15 help control privacy risks,16 and promote security or privacy of electronic health records; (2) applications that enhance insurance claim processes, for example, via the utilization of computer code on blockchain (ie, “smart contracts”) (see Supplementary Appendix S1),17 management of pre-authorization payments,18 and “smart health profiles” for insurance applicants or recipients19; (3) applications that accelerate clinical or biomedical research, such as those that assist with the collection and management of patient-generated health data for research purposes3,20 and those that facilitate data sharing among researchers21; and (4) applications that advance biomedical or healthcare through data ledgers, such as those supporting a decentralized health data sharing backbone,22 immutable clinical research protocols,23 and patient consent recording.24

Key benefits of blockchain for healthcare

The main reason for the abovementioned applications to adopt blockchain relies on its “off-the-shelf” features that address many real-world health science’s needs. For example, decentralized management is very useful for organizing digital assets produced by various institutions (eg, biomedical data, software, and “recipes” or workflows frequently used in predictive modeling and analytics). This allows operations without a hub (ie, no single point of “ownership” or “control”). This characteristic is especially attractive for applications in which users prefer not to rely on a single central authority (eg, federated clinical data networks for quality improvement, health insurance operations, cross-institutional consent management without the need for a coordinating center) and in which users want to verify the use of their assets. Another advantage is the recording of data provenance, which can be vital in applications such as clinical decision support and surveillance systems. This is possible because of blockchain creates an immutable audit trail that permanently records transactions, so that critical records (eg, protected patient information access log) are always available for all in the network to inspect. Figure 1 shows simple examples of how a “block” of transactions (eg, clinical or trial data access records) could be mounted to a blockchain for recording healthcare and research transactions. Our published tutorial on blockchain2 summarizes some key blockchain benefits that are important for health sciences and can serve as a first introduction for readers who are completely unfamiliar with the technology.

Figure 1.

Figure 1.

Healthcare and research examples of immutable recording of transactions. Note that in both examples the actual patient data are stored off-chain and only the access records (eg, requests for and receipts of records) are stored on-chain as transactions in blocks. (A) Health informatics exchange example: Patient P1 requests use of data by Clinician C1, institution I1 provides access, and patient P1 and/or primary care clinician C2 are able to see the transaction. (B) Human subject research example: researcher R1 requests use of trial data, institution I2 provides access, and participant P2 and/or principal investigator R2 are able to see the transaction.

Blockchain components to support healthcare applications

The basic blockchain technology components that support healthcare applications have been introduced in several recent studies,1,2,25 including the use of hash-chain timestamping and consensus protocols such as Proof of Work (PoW). To solve the scalability issue (ie, the size of the whole blockchain grows proportionally to the number of transactions), there are 3 techniques:1 Merkle tree26–28 (Figure 2), lightweight nodes (Figure 3), and unspent transaction output (Figure 4). As a distributed network, blockchain faces some challenges,29 such as the famous Byzantine Generals’ Problem, a synchronization problem illustrated in Figure 5. Technical details on how to use the metadata of transactions to store data records and using smart contracts to manage digital assets on a blockchain are explained in Supplementary Appendix S22–4,30–35 and Supplementary Appendix S1,25,36 respectively.

Figure 2.

Figure 2.

To reduce storage, if a block B is “voted” to be correct because the chain is long enough (ie, there are already many blocks created after B), we can discard the transactions contained in B, without changing the hash of B’s header (otherwise all blocks after B would need to be changed). To do this, instead of saving the content of all transactions directly in a block, we first compute the hash values of each transaction, and then construct a tree structure (a Merkle tree),26–28 to “combine” (ie, hash again) all hash values, and store only the Merkle Root hash value at the block header. This way we can prune the transactions in the tree later, without changing the Merkle Root and the block header. In other words, the size of the blockchain is now proportional to the number of blocks instead of being proportional to the number of transactions. (A) An example blockchain without a Merkle tree. The blocks enclose transactions without adopting a Merkle tree. As a result, the size of a block will grow proportionally to the number of transactions (eg, transaction T12) that are enclosed. (B) A blockchain with a Merkle tree. A Merkle tree is constructed by hashing paired data (the leaves) to create a parent node iteratively, until a single hash, the Merkle Root,1 remains. In this example, the transactions (eg, T12) are first encoded into a binary raw-transaction format and then hashed to create the hashes (eg, Hash of T12). Then, hashes such as the Hash of T12 are paired with other hashes such as the Hash of T11 (if a hash does not have a pair, it simply duplicates itself to be paired) to compute the hash as their parent node (ie, Hash of T11–12). The pairing/hashing process repeats until only 1 hash (the Merkle Root) remains, and the Merkle tree construction process is then completed. Finally, by only enclosing the Merkle Root in each block header, the storage space required to verify the integrity/validity of transactions can be reduced.56 That is, if an attacker tries to change the content of any transaction such as T12, all of the related hashes (ie, Hash of T12, Hash of T11–12, and Hash of T11–14), and eventually the Merkle Root (ie, Hash of T11–18) will also change and can be easily verified. To enclose this new Merkle Root to pass the verification process, the attacker then needs to re-create block B1 and all blocks thereafter, which is computationally expensive and is enough to prevent such modification.2,57 A Merkle tree is the basis of lightweight nodes described in Figure 3 (ie, the blockchain nodes that only need to verify transactions can store parts of the Merkle trees to save space, while the full blockchain nodes that need to “mine” new blocks store all of the Merkle trees).

Figure 3.

Figure 3.

Another technique to reduce the need for each user to keep the full history of transactions is to use lightweight nodes together with a Merkle tree. For a user who only wants to use coins but does not want to “mine” new blocks, the full transaction history (more than 150 GB as of January 2018) is too large, especially for smartphones. Therefore, a user can adopt lightweight nodes1 so that only the Merkle Branch1 that links the transactions that the user would like to verify is used. An example of the Merkle Branch for transaction T12 stored on a blockchain lightweight node (eg, on a mobile device), in contrast to the data storage of a full node (eg, on a personal computer), is shown in this figure. With the use of the Merkle tree, a lightweight node only stores data relevant to specific transactions (eg, T12) to save space.1 For example, in addition to T12 itself, this lightweight node only needs to store related hashes (ie, Hash of T11, Hash of T13–14, and Hash of T15–18), instead of storing the full Merkle tree, to make sure T12 is linked to block B1. That is, one can first compute the Hash of T12 using T12, and then compute the Hash of T11–12 using the Hash of T11 and the Hash of T12. Eventually, one can compute the value of the Merkle Root (Hash of T11–18), and compare it with the one stored in B1, to make sure T12 has been verified in B1. This way, a lot of required storage space for those lightweight nodes is saved, making applications such as wallet apps on mobile devices feasible. This verifying process is also known as Simplified Payment Verification.1,59 As a result, users/nodes can be divided into 2 groups: full nodes (the ones storing the whole transaction history and performing mining) and lightweight nodes (ie, the nodes using Simplified Payment Verification just for transactions, without mining), thus reducing the storage space for lightweight nodes and improving the scalability of a blockchain network.

Figure 4.

Figure 4.

The ability of coin splitting and combining can further reduce the number of transactions and thus lower the burden of a blockchain network. To do this, intuitively one can just allow multiple inputs and multiple outputs.1 A special type of output is unspent transaction output (UTXO), ie, the “change” that is returned to the sender of the transaction and can be spent (ie, serve as an input) in the future transactions. In this example, Alice has 10 coins, which constitute the output of previous transactions. Alice sends 7 coins to Bob and receives 3 coins (UTXO) as change. After this transaction, the 3 coins (UTXO) are recorded in each full node. If Alice then tries to spend the original 10 coins instead of the 3 coins, each full node can detect such behavior by checking the UTXO list and reject the transaction accordingly. This way, UTXO helps identify double-spending. That is, each full node maintains a list of UTXO, and compares the input of new transactions against this list. If an input is not in the list, the transaction is considered double-spending and will be invalidated.57

Figure 5.

Figure 5.

The Byzantine Generals' Problem refers to a distributed set of generals who need to reach a consensus/agreement on the timing of a simultaneous attack by multiple divisions of an army. (A) A simplified example64 of the relaxed version of the Byzantine Generals’ Problem, showing the difficulty generals have in agreeing on the proper time for an attack. There are several divisions of a Byzantine army camping outside an enemy city, and each division has its own commanding general who would like to, with other generals, reach consensus on the time to attack the city. That is, each general could make a decision about when to attack the city, but to be successful the majority of generals have to come up with an agreement about the attack time. However, the generals can only communicate with each other via messengers, and such communication form is nonsynchronized (eg, if 2 generals announce 2 different preferred times within a very close time frame, some generals may receive one time and other generals may receive another time). In this scenario, it is very difficult for the majority of generals to find a consensus time and execute a successful attack. (B) A Proof-of-Work (PoW) solution to the relaxed version of the Byzantine Generals’ Problem. To deal with Byzantine Generals’ Problem, many blockchain platforms have created consensus protocols to resolve disagreements within the chain. For example, PoW, the consensus protocol of the Bitcoin Blockchain, can find a solution to the relaxed version of the Byzantine Generals’ Problem, as described by the author Satoshi Nakamoto62 and proved by Miller and LaViola.65 The idea is for each general to first decide an attacking time (eg, at T0 in this example) and start to do PoW (eg, at T1 to find a solution to a difficult-to-compute yet easy-to-verify problem2,66). Once the PoW is completed (eg, general G3 finds the solution at T2), the winning general (G3) asks the messengers (M3) to broadcast the block containing G3’s proposed attack time T (1 pm in this example) to the blockchain. Since the verification of PoW is relatively simple (ie, fast), other generals can verify the PoW easily. They pause their work because they would only be allowed to add their time after the one proposed by G3.After confirming the PoW is valid, every other general agrees with G3 that the attack will be at 1 pm. (C) The process to reach consensus among generals. After the first block (B1) with the time 1 pm is added to the blockchain, all generals restart PoW based on the hash of B1 to find the second block (B2). One important protocol is that all generals will do PoW based on the longest chain, which ensures the consensus. That is, suppose general G4 also completed the PoW to propose another attack time (7 pm) in block B1: since another general (G5) has already created a block B2 to support 1 pm, the next general (G6) will only work on the longest chain to support 1 pm instead of 7 pm, thus the consensus attack time would eventually be 1 pm. Finally, after the blockchain is long enough, every general will be confident that the consensus attack time (1 pm) has been agreed by the majority of generals. This is because many generals have been working on the longest chain, thus the probability of a successful consensus of attack time is now high enough to solve the distributed agreement problem.64

SIGNIFICANCE AND RATIONALE

Blockchain platforms adopted in healthcare applications

To initiate the design and building of a real-world healthcare blockchain project, one of the critical steps is to select the most suitable underlying blockchain platform. The 3 main platforms are the following.

Ethereum. MedRec37,38 and Patientory39,40 propose the use of a blockchain based on the Ethereum platform25 for patient-managed health information exchange applications. Nebula Genomics proposes to share and analyze genomic data on an Ethereum-based blockchain platform.41 Ethereum was also proposed to be adopted in clinical applications such as clinical data sharing15 and automated remote patient monitoring.42

Hyperledger. An oncology clinical data sharing framework10 for patient care proposes to adopt the Hyperledger platform.43 Also, Hyperledger was included in the design of a framework to enforce Institutional Review Board regulations.11 Additionally, Hyperledger is proposed for a mobile healthcare application44 and for medical data storage or access45 applications. A working group was formed by Hyperledger to cultivate technical or business collaborations for healthcare blockchain applications.46

MultiChain. ModelChain29 was used to accelerate research and facilitate quality improvement initiatives by supporting decentralized cross-institutional predictive modeling. The use of blockchain in ModelChain makes it possible for different institutions to improve predictive power by contributing data to a jointly developed model without transmitting data or the model to a central location. The first implementation of ModelChain used a permissioned blockchain MultiChain,31 and was applied for predictive analytics in anesthesia.47

These examples constitute early work in this area and attempt to show the feasibility of adopting popular, open-source blockchain platforms for health or medicine. There are also some health-related blockchain applications that do not explicitly reveal their underlying platforms, such as Luna DNA,48 a proposed genomic and medical research database (with similar goals as those of Nebula Genomics).49 Others may be building an in-house blockchain. However, it is more cost effective, time efficient, and sustainable to adopt an off-the-shelf blockchain platform in the early design and development stages, to ensure feasibility and demonstrate an operational system before large investments are made in recreating existing platforms.

Challenges of selecting a blockchain platform for healthcare

Choosing a proper off-the-shelve blockchain platform for a specific healthcare or clinical application may be challenging, because there is a wide range of technical features that are critical for its adoption in healthcare projects. For example, there are concerns that adopting blockchain would consume too much energy, unnecessarily.50 This concern should not be about blockchain itself, but instead reflects lack of understanding of various block-building consensus protocols that can be selected for a specific blockchain platform. PoW, used in Bitcoin, consumes a lot of energy, but other consensus protocols do not. Other concerns involve the openness of a blockchain network (eg, public or private), ability to modify the code and distribute it (eg, licenses), and need for specific hardware (eg, SGX-enabled processors).

There are many choices of blockchain platform available today, such as Ethereum, Hyperledger, and MultiChain, mentioned previously. A blockchain platforms should be general (ie, not limited to financial applications) and popular (ie, technically mature and with ample community support to ensure future maintenance). Although some platforms may not have been adopted in the healthcare domain so far, they might be considered in the future because of desirable technical features (eg, support for an energy-efficient consensus protocol).

The need for a review of blockchain platforms for healthcare or clinical informatics

To address the difficulties of blockchain platform selection for healthcare or clinical applications, a systematic comparison of these platforms in terms of their technical features is critical. Although there are broad reviews of blockchain platforms,51,52 of blockchain research frameworks,53 and systematic reviews of blockchain technology articles,4 a systematic comparison of blockchain platforms that are relevant for healthcare is still lacking. Such systematic comparison can serve as a practical reference for healthcare blockchain researchers and application designers to choose the appropriate platform for their specific use case (eg, public health, administration, clinical care), especially, as mentioned previously, in the setting of healthcare or research institutions that prefer not to cede control to a central authority but want to work together.

Objective

The objective of this study is to compare the most popular blockchain platforms using a systematic method, considering the technical features that are relevant to healthcare applications, and to provide a reference for selection of suitable blockchain platforms for specific requirements encountered in healthcare and biomedicine.

MATERIALS AND METHODS

We adapted the PRISMA (Preferred Reporting Items for Systematic Reviews and Meta-Analyses) statement54,55 to compare blockchain platforms. PRISMA is a systematic review statement focusing on reviews that evaluate randomized trials.54,55 To review blockchain platforms, we modified the checklist items (Supplementary Table S1) and flow diagram (Figure 6) in PRISMA, and conducted the systematic comparison based on adjusted items.

Figure 6.

Figure 6.

The adjusted PRISMA flow diagram. We only included 3 phases (ie, identification, screening, and included), because the eligibility criteria were integrated into the search strategy (ie, the PRISMA eligibility phase is integrated into the identification phase).

Eligibility criteria and information sources

General purpose blockchain platforms were included. We excluded cryptocurrencies that could not serve as a general-purpose ledger, as they are less important for biomedical informatics applications. This way, the results of the systematic comparison could be utilized in healthcare or clinical application areas such as population health, biomedical and health services research, and healthcare administration. We utilized Google.com58 as our main search engine, and conducted all searches in July 2017. No major blockchain technology has emerged as of November 2018.

Search

We used the phrase blockchain platforms as the initial search term in Google.com. Realizing that the returning results were mostly about either “discussion of multiple blockchain platforms” or “general introduction of blockchain” (instead of the platforms themselves), we manually reviewed the top 30 ranked webpages returned by Google.com, and identified webpages that discussed more than 1 blockchain platform. We then collected all the blockchain platforms names found in these webpages into a candidate list (see the identification phase in Figure 6).

Platform selection

To select the platforms names from the candidate list, we first removed all the duplicated blockchain platforms. Next, we aimed at “popular” blockchain platforms, because blockchain is still an emerging technology and the widely used platforms are in general more mature in terms of the technical development, community support, and long-term maintenance. Intuitively, we could have used the Google Count (ie, the number of webpages returned by searching the platform name, such as “Bitcoin,” using Google.com) to rank the popularity of the platforms. However, we realized that, while certain platform names were specific to the blockchain field (eg, “Ethereum”), other platform names were more general (eg, “Dash”). Thus, using just the Google Count of platform names might unfairly bias the results in favor of more general names.

To mitigate the bias introduced by common names, our strategy was to first determine whether a platform name was a dictionary word or not, using the following 2 online dictionary websites: Dictionary.com60 and Oxforddictionary.com.61 We considered a platform name as a dictionary word only if it could be found in both websites. The only exception was “Bitcoin,” which was included in both dictionaries because it has become famous recently, and in our study context we still consider it as a nondictionary name. For a platform with a name that is not a dictionary word, we simply used the Google Count of the name (eg, searched “Ethereum” directly) as the score of popularity. For a platform with a name that is a dictionary word, we added an additional keyword “blockchain” while searching (eg, “Dash” AND “blockchain”).

Finally, we ranked the blockchain platforms using these “popularity scores” and manually reviewed the platforms to select 10 popular platforms being included in our study (see the screening phase in Figure 6). The reason for the manual review instead of just picking the top 10 ranked platforms was to compensate for the limitations of our dictionary word strategy. For example, although the blockchain platform name NXT is not a dictionary word, it is also a division of World Wrestling Entertainment and thus is very popular (ie, high Google Count). The manual review considered these types of exceptions to choose the most well-known and highly popular blockchain platforms.

Data collection process, data items, and synthesis of results

For the 10 blockchain platforms (see the included phase in Figure 6), we developed a data sheet to extract the data items (ie, technical features, defined in Table 1), and pilot-tested it on 2 most well-known blockchain platforms: Bitcoin and Ethereum. Two authors (T-TK and HZR) extracted the data items from included platforms, mainly from the official published whitepapers and official websites, as well as from the other online resources searched using Google.com. These authors then had discussions to resolve the disagreements. If an agreement was not reachable, the third author (LO-M) was involved in the discussion and made the final decision. After confirming the data items in the pilot test, we extracted those data items for each of the selected 10 blockchain platforms.

Table 1.

Data items extracted from the blockchain platforms

Category # Data Item Description
Basic Information 1 Official Website URL for the official website of the platform.
2 Software Website Online repository system that keeps track of the source code of the platform.
3 Explorer Website Special type of online website, “explorer,” that keeps track of all the transactions for the platform. Note that, multiple explorers may exist for the platform which also serves as a cryptocurrency. In this case, we only list the “official” or the representative ones. Also, the living public websites do not exist for the noncryptocurrency platforms, however, the “explorer” code may be available; in this case, we list the website of their “explorer” code instead.
4 Main Reference Main official white papers or the other types of articles discussing the platform.
5 Real-World Application Examples of the institutions or companies currently using the platform.
Blockchain Technology 6 Main Improvement over Bitcoin Main technical difference from Bitcoin, the first distributed cryptocurrency.
7 Network Permission Permission mechanism of the blockchain network.
8 Consensus Protocol Core protocol used to create a consensus chain of blocks.
9 Special Hardware Requirement Special hardware (ie, besides a normal personal computer) needed to “mine” (ie, create) new blocks.
10 Smart Contracts Support Capability to support smart contracts/properties.
Public Cryptocurrency 11 Symbol Short name for the cryptocurrency (eg, “BTC” for Bitcoin).80
12 Mining for New Public Coins Capability for participants to “mine” new coins to serve as public cryptocurrency.
13 Anonymous Payment Feature that prevents tracing the origin, destination and amount of the transactions.
14 Rapid Payment Support of the high-speed asset transferring.
15 Coin Limit Maximum amount of the coins that can be created for the cryptocurrency.
16 Coin Value Value of the coin in U.S. dollars.81
17 Average Transaction per Second (TPS) Average speed of transactions (data collected in December 2017). TPSs were averaged from values on October 5, November 5, and December 5 in 2017.
Application Programming 18 Scripting Language Supported blockchain scripting language (run instructions such as “freezing funds until a time in the future”82).
19 Open Source Availability of the source code.
20 Main Implementation Languages Programming languages used to implement the source code for the platform.
21 Software License Copyright license for the source code.

Note that we included cryptocurrency-related data items considering their future plausible use in healthcare/medicine applications.

RESULTS

Results of platform search and selection

The search using blockchain platforms on Google.com returned 23 500 webpages. After manually checking the top 30 returned webpages, we identified the following 4 webpages that discussed more than 1 blockchain platform: Medium,62 RadioStud,63 CoinFabrick,51 and Mastek.67 We collected the 54 blockchain platform names mentioned in these 4 webpages into the candidate list. There were 35 platforms after removal of duplicates. We ranked the 35 blockchain platforms using our “popularity” score, and manually selected 10 top ones. The process is shown in Figure 6, while the resulting 10 platforms are described in Table 2.

Table 2.

Platforms included in this study, as of July 2017

Blockchain Platform Dictionary Word Google Count with Blockchain Google Count Without Blockchain Popularity Score
Bitcoin No 6 800 000 31 900  000 31 900  000
Ethereum No 3 890 000 11 300  000 11 300  000
Zcash No 420 000 5 680  000 5 680  000
Litecoin No 1 680 000 4 770  000 4 770  000
Dash Yes 1 440 000 104 000  000 1 440  000
Peercoin No 157 000 1 440  000 1 440  000
Ripple Yes 1 100 000 14 300  000 1 100  000
Monero No 705 000 1 020  000 1 020  000
MultiChain No 10 200 342 000 342 000
Hyperledger No 562 000 324 000 324 000

Selected platform characteristics

In this subsection, we discuss the details of the 10 blockchain platforms selected for our systematic review, following the order of the popularity score shown in Table 2.

Bitcoin

Bitcoin, the first well-known and widely used distributed cryptocurrency, operates a peer-to-peer network without central authority or banks, and introduced the blockchain technology and platform to the world.68 The management of transactions and the issuance of coins are carried out collectively by the blockchain network.68 Bitcoin uses PoW as its consensus protocol to verify transactions, and thus consumes a lot of energy.1 Owing to the success of Bitcoin, many other alternative cryptocurrencies and consensus protocols were proposed and developed, including all other 9 platforms reviewed in this study.

Ethereum

Ethereum is a platform that lets anyone build and use smart-contract-based decentralized applications that run on blockchain technology.69 Ethereum focuses on the capability of automatic digital asset management, and, to do so, it supports smart contracts or properties (Supplementary Appendix S1), making the creation of the asset managing programs easier than when using the scripting language in the Bitcoin Blockchain.25 Ethereum also adapts the PoW consensus protocol.25

Zcash

Zcash is a decentralized and open-source cryptocurrency that offers privacy and anonymity of transactions.70 A challenge of the Bitcoin Blockchain is that, although the senders and recipients are represented with a hashed address, given enough transaction data, the transactions may still be linked or traced through careful analysis and inspection.2,71–74 To improve this, Zcash uses a zero-knowledge proof algorithm known as zk-SNARK, to ensure that the sender, recipient, and amount of a transaction remain private even on a publicly available blockchain network, and thus improves the privacy or anonymity of the transactions, while verifying the transactions privately to avoid the double spending problem. This level of privacy or anonymity is also highly desirable in healthcare applications. Also, Zcash addresses the mining centralization issue (Supplementary Appendix S3).75,76 However, as many health-related applications may be run on permissioned networks, platforms like Zcash that use PoW are less attractive than others that use different protocols.

Litecoin

Litecoin is a decentralized global payment network.77 The major change of Litecoin, compared with Bitcoin, is that Litecoin has a faster transaction speed (4 times quicker) at the expense of 4 times smaller storage space and reduced security.77 Also, Litecoin adopts the “Scrypt” hash algorithm77 for the PoW to mitigate the mining centralization issue (Supplementary Appendix S3). Speed could become important in healthcare applications in which immediate decisions are needed, but, so far, we have not seen examples of blockchain-based applications in health sciences in which this was a critical factor. For example, we have not encountered situations in which a healthcare blockchain needed to accommodate as many transactions per minute as credit cards or major retailers’ websites do.

Dash

Dash (or Digital Cash) is a privacy-centric digital currency with instant transactions.78 It is based on the Bitcoin software, and adds an additional “Masternode” network tier on top of the Bitcoin Blockchain network.79 The Masternode network is composed of nodes that are willing to put “collateral,” such as 1000 DASH coins, to serve as the full nodes to validate the transactions. The Masternode offers additional privacy or anonymity to the users via “Darksend” (based on the “CoinJoin” technology,79 a process of merging multiple transactions together so that the attacker cannot link the transactions using histories).78,79 Also, the relatively few collateral nodes in the Masternode network can speed-up the validation process, providing an instant transaction mechanism known as “InstantX.”79 The additional privacy for the users is attractive to healthcare applications but the centralization introduced by Masternode is a downside.

Peercoin

Peercoin was derived from Bitcoin to reduce the energy required for the coin mining process.83 That is, Bitcoin’s PoW algorithm depends on energy consumption1,2 that, in the long run, will result in lower motivation for miners to keep building blocks unless transactions fees rise to high enough levels to sustain the high energy consumption.83 To avoid this situation, Peercoin proposed to initially adopt PoW and eventually switch to Proof of Stake (PoS) (see Supplementary Appendix S4). While more appropriate for health-related applications than PoW, PoS may also not be necessary, particularly when operating in permissioned networks, as the threat of “fake” blocks is less severe. However, for public networks, Peercoin may offer a good compromise by supporting PoS.

Ripple

Ripple is a low-latency blockchain network that atomically settles and records transactions on a secure distributed database, the Ripple Consensus Ledger.84 Ripple applies the Ripple Consensus Protocol Algorithm, an alternative algorithm to the high-latency Bitcoin Blockchain PoW, for handling the Byzantine Generals’ Problem and the Sybil Attack.85,86 The blocks are only validated by the relatively few “Chosen Validators” to enable low-latency transactions. While reaching consensus, the current distributed ledger is “closed” and considered the most recent one. Also, Ripple coins are “pre-mined” and cannot be created during the consensus process.87 Again, if we consider that most healthcare applications will use permissioned networks, the advantages of using alternative consensus protocols are diminished.

Monero

Monero is a secure, private, and untraceable cryptocurrency.88 Monero offers privacy or anonymity to its users by using the “Ring Confidential Transactions” (a ring signature algorithm based on CryptoNote89 that generates a group signature and in which the actual signer cannot be identified) and the “Stealth Address” (an one-time address for each transaction) technologies, to obfuscate the origins, destinations, and amounts of all transactions.88 Therefore, the ability to “hide the destination and origin of transactions”90 is an important feature of Monero. This platform might be considered in applications in which the privacy or anonymity of patient or participant users is at stake, although it only supports the high energy consumption PoW protocol.

MultiChain

MultiChain is a blockchain platform to create and deploy permissioned or private blockchain networks.31 As a fork of the Bitcoin Blockchain, MultiChain focuses on providing features such as integrating user permission management and improve the data ledger functions.34 Also, MultiChain supports both Bitcoin Blockchain PoW and “Mining Diversity,” a round-robin-based consensus protocol.31 The basic idea of Mining Diversity is that, within a private blockchain network, the participants are already “trusted” to some extent because they are identifiable entities.31 Therefore, Mining Diversity can provide consensus and mining securely on the private blockchain network without the need for the computationally intensive PoW algorithm.31 However, MultiChain does not provide additional privacy for users as do some other platforms.

Hyperledger

Hyperledger is an open-source collaborative effort created to advance permissioned or private, cross-industry blockchain technologies.91 As the use of blockchain must respond to different needs, Hyperledger provides an infrastructure to include a range of modules, such as various smart contract engines.43 Specifically, Hyperledger includes differentiated blockchain frameworks and tools.43 Each framework supports different types of consensus protocols.43 Hyperledger does not support PoW43 and the additional privacy protection is yet to be included. It should also be noted that Hyperledger has global collaborations with various companies.

As we can see from the brief summaries, no platform is perfect, and in the future the best features may be adopted by the platforms that remain in the market. It is unlikely that more than 3 or 4 platforms will become very relevant to healthcare. In terms of platforms likely to continue to be used for healthcare applications, Ethereum, Hyperledger and MultiChain are at the top of the list because they combine the most relevant features at the moment.

Results of platform comparison

The features most relevant for healthcare applications are summarized in Table 3, and the full comparison results of the extraction of the 21 data items (Table 1) from the 10 blockchain platforms (Table 2) are shown in Tables 4–7.

Table 3.

Important items to consider when selecting a blockchain platform

Feature Main Options and Implications
Network Permission
  • Permission-less network: A public blockchain network configuration designed to allow public participation (eg, some applications that rely on patient-managed data).92

  • Permissioned network: A private blockchain network configuration that includes only authorized participants (eg, networks that exchange information among hospitals).31,43

Consensus Protocol
  • Proof of Work: A compute-intensive protocol with proof of security; suitable for permission-less blockchain networks but can also be used in permissioned blockchain networks to increase security. The Bitcoin blockchain uses this protocol: unfortunately, many people mistakenly believe that all blockchain networks need to use this typically high-energy consumption protocol, which is not true.1,66

  • Proof of Stake: A low-energy consumption protocol that is suitable for healthcare applications operating on permission-less or permissioned blockchain networks.93–95

  • Mining Diversity: A round-robin, low-energy consumption protocol specifically designed for permissioned healthcare applications.31 Variations can be designed to suit various needs.

  • Kafka: A voting-based, low-energy consumption protocol that can finalize the consensus decision faster (at least initially), but that requires more time as the number of nodes in the network grows.43

  • Proof of Elapsed Time: A lottery-based, low-energy consumption protocol that can scale well for a network with many nodes while needing more time to reach consensus.43

Special Hardware Requirement
  • Yes: If special hardware (eg, Intel SGX43) is required, the specifications of the computing environment need to be confirmed before the healthcare applications can be deployed properly.

  • No: If no special hardware is required, the healthcare application can be deployed without further hardware checking.

Smart Contracts Support
  • Yes: If the healthcare applications focus on autonomous operations (eg, automatic payment for insurance claims), the immutable smart contract support can be essential.25,43

  • No: If the healthcare applications aim at primarily serving as a ledger (eg, recording access rights or data transaction records), the blockchain platform without smart contract support would be sufficient.91

Scripting Language
  • Bitcoin Script: If smart contracts are not required for the healthcare applications, this basic scripting language would be sufficient.82,96

  • Solidity: The main smart contract language for Ethereum; it is one of the most popular languages for writing smart contracts.97

  • Chaincode: The main smart contract language for Hyperledger Fabric; it is also one of the most popular languages for writing smart contracts.98

Software License
  • MIT: A “permissive” license that allows healthcare applications to reuse the source code of the platform.99,100

  • GPL: A “copyleft” license that also allows using the source code; the derivative works in some situations must be open-source too.99,100

Table 4.

Basic information

Blockchain Platform Official Website Software Website Explorer Website Main Reference Real-World Application
Bitcoin 66 105 115 1 Microsoft (add Bitcoin to Microsoft Account)131
Ethereum 116 106 116 25 MedRec37
Zcash 70 107 117 75 , 125 Adding Zcash technology to J.P. Morgan Quorum enterprise blockchain platform(under development)132
Litecoin 80 108 118 80 Switzerland’s Falcon Private Bank133
Dash 102 109 119 82 Shakepay VISA debit card134
Peercoin 103 110 120 83 CoinURL online advertisement135
Ripple 104 111 121 85 , 86 Sumitomo Mitsui Corp and Japan Post Bank for payments and settlement136
Monero 88 112 122 89 , 90 , 126–130 Direct Voltage137
MultiChain 34 113 123 31 Construtivo as workflow management for infrastructure projects138
Hyperledger 91 114 124 43 IBM Global Financing for Fabric139 and R3 for Sawtooth140
Table 7.

Application programming

Blockchain Platform Scripting Language Open Source? Main Implementation Languages Software License
Bitcoin Bitcoin Script82,96 Yes185 C++185 Bitcoin Core: MIT License194
Ethereum Solidity (similar to C and Java Script), Serpent (similar to Python), and LLL (similar to Lisp)103,182,183 Yes186–190
  • Go-Ethereum: Go186

  • CPP-Ethereum: C++187

  • Py-Ethereum: Python188

  • EthereumJ: Java189

  • Parity: Rust190

  • Go-Ethereum: Lesser General Public License (LGPL) v3.0186

  • CPP-Ethereum: General Public License (GPL) v3.0187

  • Py-Ethereum: MIT License188

  • EthereumJ: General Public License (GPL) v3.0189

  • Parity: General Public License (GPL) v3.0190

Zcash Bitcoin Script125,150,176 Yes107 C++107 Copyright by the Zcash developers and the Bitcoin Core developers107
Litecoin Bitcoin Script177 Yes191 C++191 MIT License191
Dash Bitcoin Script82,178 Yes192 C++192 MIT License192
Peercoin Bitcoin Script179,180 Yes193 C++193 MIT License193
Ripple N/A (Java Script for Codius, abandoned)111,152,181 Yes84 C++84 Various Copyrights84
Monero N/A [GitHub](although the CryptoNote white paper states one89) Yes195 C++195 Copyright by The Monero Project195
MultiChain Bitcoin Script182,183 Yes113 C++113 General Public License (GPL) v3.0 113
Hyperledger
  • Various, for example,

  • Go/node.js for Fabric (Chaincode)98,

  • C++, Go, Java, JavaScript, Python, Rust, or Solidity (through Seth) for Sawtooth154,184

Yes114
  • Various, for example,

  • Go for Fabric,

  • Python for Sawtooth114

  • Various, for example,

  • Apache License v2.0 for Fabric,

  • Copyright by Intel Corporation for Sawtooth114

Table 5.

Blockchain technology

Blockchain Platform Main Improvement over Bitcoin Network Permission Consensus Protocol Special Hardware Requirement Smart Contracts Support
Bitcoin N/A Permission-less141 PoW1 No1,66,141 No25
Ethereum Automatic Digital Asset Management Permission-less or Permissioned92 PoW/Proof-of-Stake (Casper)93 No25,101 Yes25
Zcash Privacy/Anonymity Permission-less142 PoW (Equihash)75,143 No125,143,156 No, under development (Zcash over Ethereum)150
Litecoin ASIC Resistance Permission-less80 PoW (Scrypt hash algorithm)80,132,144 No 80 No80
Dash Privacy/Anonymity Permission-less82 PoW/Proof-of-Service (X11 hash algorithm)82,145 No82,146 No102
Peercoin Long-Term Energy Efficiency Permission-less83 PoW/Proof-of-Stake94,95 No95 No, under development (PeerScript)151
Ripple Low-Latency Transaction Permission-less (Controlled)104 RPCA/Consensus-and-Validation85,86 No111,147 No, abandoned (Codius)152
Monero Privacy/Anonymity Permission-less88 PoW (Ring CT)90 No148 No88
MultiChain Private/Permissioned Blockchain Network Permissioned31 PoW/Mining Diversity31 No91 No91
Hyperledger Business Blockchain Network Permissioned43 Pluggable, for example, Kafka for Fabric by default, Redundant Byzantine Fault Tolerance for Indy, Proof of Elapsed Time for Sawtooth by default, Sumeragi for Iroha43 Various, for example, No for Fabric149, Yes for Sawtooth (Intel SGX)43 Yes43, for example, Chaincode for Fabric153, Burrow-EVM Integration for Sawtooth154

PoW: Proof of Work.

Table 6.

Public cryptocurrency

Blockchain Platform Symbol Mining for New Public Coins Anonymous Payment Rapid Payment Coin Limit Coin Value (in U.S. Dollars, Updated on October 1, 2018) Average Transaction per Second
Bitcoin BTC/XBT Yes141 No157,158 No1 21 Million162 6612.8300 3.50170
Ethereum ETH Yes155 No141,157 No25,160 No163 230.4400 5.40170
Zcash ZEC Yes156 Yes (zk-SNARK)75,125 No75,125 21 Million164 129.4500 0.06170
Litecoin LTC Yes80 No80 Yes (Difficulty Adjustment, 2.5 min per block)80 84 Million80 60.6800 0.35170
Dash DASH Yes146 Yes (Darksend/PrivateSend)82,159 Yes (InstantX/Instant-Send)82,161 19 Million165 187.1000 0.07170
Peercoin PPC Yes95 No83 No83 2 Billion166 1.2200 0.01170
Ripple XRP No (Pre-Mining)87 No157 Yes, RippleNet104 100 Billion167,168 0.5807 10.75171
Monero XMR Yes148 Yes (RingCT/Stealth Address)89,127,129,130 No89,90,128,129 18.4 Million, plus 0.3 XMR per minute afterwards169 115.9900 0.06170
MultiChain N/A No N/A N/A N/A N/A 1000.00172
Hyperledger N/A No N/A N/A N/A N/A Various, for example, 3500.00 for Fabricz173

Because MultiChain and Hyperledger are not public cryptocurrencies, they do not have most of the technical features listed; however, for completeness we still include their transaction speed (ie, the Average Transactions per Second column).

DISCUSSION

Summary of findings

All 10 popular blockchain platforms are open source, which is a key factor to foster their popularity. Also, 8 of 10 platforms support cryptocurrencies, which may become important depending on how systems of incentives are designed for different application. As several blockchain platforms were based on Bitcoin Blockchain (eg, forked from it or work on top of it), these platforms share similar features, such as adopting the PoW consensus protocol, requiring no special hardware to create new blocks, and being implemented in C++. Finally, Zcash, Dash, and Monero focus on privacy or anonymity of transaction information, which is important for users like patients.

Among the healthcare and clinical applications that we are aware of, some are proposed and others are implemented using the blockchain platforms included in this review, especially Ethereum, Hyperledger, and MultiChain. As more applications of blockchain emerge, it will also be important that they adhere to standards that the health informatics community has been supporting for a long time. Thus, it is important that the current somewhat disjoint communities of blockchain technologists and health informaticists converge toward more overlap and collaboration to facilitate standardization of technologies from both sides.

Limitations

A limitation of this study is that the blockchain technology is relatively new and still emerging, so documentation is somewhat very limited (eg, out of date or not available because of the fast and continuing development process), and the applications for healthcare or medicine are mostly in early stages (ie, most are proposed systems that have yet to be implemented). Therefore, our systematic comparison is restricted by the data and information we could gather from publicly available resources for each platform. Additionally, we focused on the most popular platforms, and therefore we only reviewed the first 30 webpages returned from the initial Google.com search (ie, blockchain platforms). After deduplication, we selected 10 of 35 platforms. This selection process may have introduced bias, because we used not only a popularity ranking, but also a manual screening process. Finally, we extracted 21 data items in 4 categories (ie, basic information, blockchain technology, public cryptocurrency, and application programming), which may cover only the most critical aspects in the selection of the blockchain platforms for healthcare applications, while several other minor technical features are yet to be included. Finally, we have not run real controlled cases to verify that the stated speed of transactions is similar to the one stated in the websites.

CONCLUSION

In this study, we identified healthcare applications of blockchain, as well as the platforms that have been proposed or implemented by the state-of-the-art healthcare blockchain studies. To understand which blockchain platform may be more feasible for healthcare or clinical applications, we conducted a systematic comparison of 21 characteristics for 10 popular blockchain platforms, to support health informatics researchers in the selection of the most suitable platform for their specific application. We discussed critical blockchain implementation features, introduced these platforms, and compared the technical features that are most relevant to healthcare. Our results show that most platforms share similar features, but they are also specialized in different technical characteristics, such as improving transaction speed, mitigating block mining centralization, enhancing user privacy or anonymity, and supporting permissioned or private blockchain networks. Based on our findings, which indicate that most healthcare or biomedical research applications are still in early stages of conceptualization, we believe that the use of blockchain technology in the healthcare or medicine domains will require a type of social transformation that constitutes a much bigger challenge than the technological one. The ability to think differently and the willingness to change the way our field operates for decades will require vision, entrepreneurship, and a modest initial investment that is likely to pay off in a few years. The inherent virtues of blockchain (decentralization and immutability of the ledger) presuppose scenarios in which a minimum number of users agree to use and some agree to actively contribute “blocks” and perform other functions (eg, predictive modeling) for healthcare or biomedical applications. The transformation will certainly happen if the proper system of incentives can be put together.

The future directions of this comparative review include monitoring the progress of healthcare applications, comparing the evolution of a larger number of blockchain platforms (through review and empirically), and providing targeted suggestions for application-specific platform selection in an expanded spectrum of biomedical informatics projects.

FUNDING

T-TK and LO-M were partly funded by the National Institutes of Health (OT3OD025462). HZR was supported by the UCSD STARS Program, and the iDASH Summer Internship Program funded by the National Institutes of Health (T15LM11271). Research reported in this publication was supported by the National Human Genome Research Institute of the National Institutes of Health under Award Number K99/R00HG009680. The content is solely the responsibility of the authors and does not necessarily represent the official views of the National Institutes of Health or of the Veterans Health Administration (VHA).

CONTRIBUTors

T-TK and HZR mainly conducted the systematic review and drafted the manuscript. LO-M was principal investigator of this study: she provided the original idea, performed overall supervision of the study, resolved the disagreements in the systematic review process, provided critical editing, and made several additions to the manuscript.

SUPPLEMENTARY MATERIAL

Supplementary material is available at Journal of the American Medical Informatics Association online.

Supplementary Material

Supplementary Data

ACKNOWLEDGMENTS

The authors would like to thank Xiaoqian Jiang, PhD, for organizing the iDASH (integrating Data for Analysis, Anonymization, and SHaring) Summer Internship Program, and Elisa Maldonado, PhD, for organizing the Summer Training Academy for Research Success (STARS) Program at University of California, San Diego, in 2017. The authors would also like to thank Jeremy Blackstone for his support of HZR during his UCSD STARS internship.

Conflict of interest statement. None declared.

REFERENCES

Associated Data

This section collects any data citations, data availability statements, or supplementary materials included in this article.

Supplementary Materials

Supplementary Data

Articles from Journal of the American Medical Informatics Association : JAMIA are provided here courtesy of Oxford University Press

RESOURCES