Comparison of blockchain platforms: a systematic review and healthcare examples.

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.

INTRODUCTION

Healthcare applications using the blockchain technology

Blockchain is a distributed ledger—write once and never erase. Although originally invented for financial transactions, its applications are broad. Medicine, among these applications, is one of the most important and promising areas for adoption of this new technology.,, Four main categories of health or clinical blockchain applications are found in the literature: (1) those that improve medical record management (eg, securely storing patient records), securely or scalably share clinical data, help control privacy risks, 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), management of pre-authorization payments, and “smart health profiles” for insurance applicants or recipients; (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 purposes, and those that facilitate data sharing among researchers; and (4) applications that advance biomedical or healthcare through data ledgers, such as those supporting a decentralized health data sharing backbone, immutable clinical research protocols, and patient consent recording.

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 blockchain 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.

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 P requests use of data by Clinician C, institution I provides access, and patient P and/or primary care clinician C are able to see the transaction. (B) Human subject research example: researcher R requests use of trial data, institution I provides access, and participant P and/or principal investigator R 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,,, 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: Merkle tree (Figure 2), lightweight nodes (Figure 3), and unspent transaction output (Figure 4). As a distributed network, blockchain faces some challenges, 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 S2, and Supplementary Appendix S1,, respectively.

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), 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 T) 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, remains. In this example, the transactions (eg, T) are first encoded into a binary raw-transaction format and then hashed to create the hashes (eg, Hash of T). Then, hashes such as the Hash of T are paired with other hashes such as the Hash of T (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 T). 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. That is, if an attacker tries to change the content of any transaction such as T, all of the related hashes (ie, Hash of T, Hash of T, and Hash of T), and eventually the Merkle Root (ie, Hash of T) 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 B and all blocks thereafter, which is computationally expensive and is enough to prevent such modification., 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.

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 nodes so that only the Merkle Branch that links the transactions that the user would like to verify is used. An example of the Merkle Branch for transaction T 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, T) to save space. For example, in addition to T itself, this lightweight node only needs to store related hashes (ie, Hash of T, Hash of T, and Hash of T), instead of storing the full Merkle tree, to make sure T is linked to block B. That is, one can first compute the Hash of T using T, and then compute the Hash of T using the Hash of T and the Hash of T. Eventually, one can compute the value of the Merkle Root (Hash of T), and compare it with the one stored in B, to make sure T has been verified in B. 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., 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.

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. 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.

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 example 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 Nakamoto and proved by Miller and LaViola. The idea is for each general to first decide an attacking time (eg, at T in this example) and start to do PoW (eg, at T to find a solution to a difficult-to-compute yet easy-to-verify problem,). Once the PoW is completed (eg, general G finds the solution at T), the winning general (G) asks the messengers (M) to broadcast the block containing G’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 GAfter confirming the PoW is valid, every other general agrees with G that the attack will be at 1 pm. (C) The process to reach consensus among generals. After the first block (B) with the time 1 pm is added to the blockchain, all generals restart PoW based on the hash of B to find the second block (B). One important protocol is that all generals will do PoW based on the longest chain, which ensures the consensus. That is, suppose general G also completed the PoW to propose another attack time (7 pm) in block B: since another general (G) has already created a block B to support 1 pm, the next general (G) 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.

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. MedRec, and Patientory, propose the use of a blockchain based on the Ethereum platform for patient-managed health information exchange applications. Nebula Genomics proposes to share and analyze genomic data on an Ethereum-based blockchain platform. Ethereum was also proposed to be adopted in clinical applications such as clinical data sharing and automated remote patient monitoring.

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

MultiChain. ModelChain 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, and was applied for predictive analytics in anesthesia.

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, a proposed genomic and medical research database (with similar goals as those of Nebula Genomics). 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. 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,, of blockchain research frameworks, and systematic reviews of blockchain technology articles, 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) statement, to compare blockchain platforms. PRISMA is a systematic review statement focusing on reviews that evaluate randomized trials., 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.

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.com 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.com and Oxforddictionary.com. 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, RadioStud, CoinFabrick, and Mastek. 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. The management of transactions and the issuance of coins are carried out collectively by the blockchain network. Bitcoin uses PoW as its consensus protocol to verify transactions, and thus consumes a lot of energy. 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. 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. Ethereum also adapts the PoW consensus protocol.

Zcash

Zcash is a decentralized and open-source cryptocurrency that offers privacy and anonymity of transactions. 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., 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)., 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. 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. Also, Litecoin adopts the “Scrypt” hash algorithm 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. It is based on the Bitcoin software, and adds an additional “Masternode” network tier on top of the Bitcoin Blockchain network. 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, a process of merging multiple transactions together so that the attacker cannot link the transactions using histories)., Also, the relatively few collateral nodes in the Masternode network can speed-up the validation process, providing an instant transaction mechanism known as “InstantX.” 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. That is, Bitcoin’s PoW algorithm depends on energy consumption, 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. 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. 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., 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. 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. Monero offers privacy or anonymity to its users by using the “Ring Confidential Transactions” (a ring signature algorithm based on CryptoNote 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. Therefore, the ability to “hide the destination and origin of transactions” 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. As a fork of the Bitcoin Blockchain, MultiChain focuses on providing features such as integrating user permission management and improve the data ledger functions. Also, MultiChain supports both Bitcoin Blockchain PoW and “Mining Diversity,” a round-robin-based consensus protocol. 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. Therefore, Mining Diversity can provide consensus and mining securely on the private blockchain network without the need for the computationally intensive PoW algorithm. 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. 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. Specifically, Hyperledger includes differentiated blockchain frameworks and tools. Each framework supports different types of consensus protocols. Hyperledger does not support PoW 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

Permission-less network: A public blockchain network configuration designed to allow public participation (eg, some applications that rely on patient-managed data).

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

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.,

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

Mining Diversity: A round-robin, low-energy consumption protocol specifically designed for permissioned healthcare applications. 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.

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.

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

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

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.

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

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

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

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

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

Go-Ethereum: Go

CPP-Ethereum: C++

Py-Ethereum: Python

EthereumJ: Java

Parity: Rust

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

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

Py-Ethereum: MIT License

EthereumJ: General Public License (GPL) v3.0

Parity: General Public License (GPL) v3.0

Go/node.js for Fabric (Chaincode),

C++, Go, Java, JavaScript, Python, Rust, or Solidity (through Seth) for Sawtooth,

Python for Sawtooth

Copyright by Intel Corporation for Sawtooth

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.

Click here for additional data file.

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).