Blockchain in Healthcare

What is Blockchain?

The National Institute of Standards and Technology (NIST) defines it as “tamper evident and tamper resistant digital ledgers implemented in a distributed fashion (i.e., without a central repository) and usually without a central authority ([e.g.,] a bank, company, or government). At [its] basic level, it enable[s] a community of users to record transactions in a shared ledger within that community, such that under normal operation of the blockchain network no transaction can be changed once published.”

While there are differences, oftentimes the terms blockchain and DLT are used interchangeably, especially when discussing the business value of the solutions.

Blockchain describes a chain of data or transactions as blocks linked or chained together by cryptographic signatures, each of which is called a hash, stored in shared ledgers and supported by a network of connected processes called nodes. Nodes maintain a copy of the entire chain and are continually updated and kept in-sync.

While depending on well-known and tested underlying technology, such as networking, hashes and encryption, this technology is very different from traditional programming, networks, databases and web interfaces. A new understanding of design, patterns, data sharing and implementation is required.

The application of blockchain in healthcare is nascent; nevertheless, early solutions shown the potential to reduce healthcare costs, streamline business processes, and improve access to information across disparate and diverse stakeholders working toward a common goal.

Adding or Updating Data

Adding or updating data requires consensus of the network making it nearly immutable. This means that once a block is written to the chain, it cannot be altered or deleted. Transaction records are immutable, because each block of data is linked to the previous block by including the previous block’s unique hash, which is mathematically derived from the block’s content.

If a bad actor were to change the content of a block, the block’s hash would change, which would then break its connection to the subsequent block. This would require the bad actor to then re-hash the next block, and all subsequent blocks in order to cover their tracks. However, since there are multiple copies of the ledger, the bad actor would have to simultaneously change every version of the ledger at each location, which is practically impossible especially as networks grow large and risk of collusion becomes negligible.

To correct or remove data from the chain, one may append a new record with corrected data that supersedes the original, or one may append a record that marks a previous record as deleted. However, the original records added earlier remain as is. This is an intentional characteristic that enables verification by all parties in the consortium and helps to build trust.

As this technology is not a panacea for data quality and accuracy, we recommend reviewing data storage considerations for an overview of what to store on-chain.

A Decentralized Solution

The technology is characterized by being a decentralized, or a distributed solution, rather than a centrally controlled solution. It is typically a peer-to-peer network—where participants interact directly and transactions are shared across all—hence there is no single point of failure. The technology is available on a variety of platforms and protocols, and brings with it concepts that may introduce nuances or changes to existing healthcare business models.

While it achieves a certain level of democratization of data—or accessibility of data to the average end user—the technology does not necessarily open access to the fullest extent, but it may address existing needs and uncover new business, administrative, and clinical opportunities that were not previously considered.

A Focus on Transactions

This technology depends on consensus for the validity of transactions, and while transactions can be interpreted widely, not all healthcare activity is transaction-based, and not all healthcare transactions may be appropriate for the technology. Blockchain brings with it the potential for smart contracts, digital computer code that automates the execution of programs, functions or transactions. The technology also provides the ability to create value for transactions through tokens. This tokenization has been implemented in cryptocurrency settings as well.

Strengths and Weaknesses

The technology holds significant promise as a solution for a number of use cases in various industries, but as with any emerging technology, it still has its drawbacks. It’s important to weigh both strengths and vulnerabilities to determine suitability for each use case.

A Single Source of Truth

The primary benefit of the technology is its ability to provide a single source of truth for those who participate in the network. Since all nodes must reach consensus, this ensures that all participants are in agreement about the nature of the data contained in the network. Its ability to settle disputes and provide a ledger of all activity on the network gives it a unique transparency that eliminates the need for middlemen. Its transparency and immutability also makes it ideal for industries that have regular audits of their data.

Lack of Privacy

Blockchains, especially those available publicly, are not ideal for storing private information due to the transparency that they provide. For the use of blockchain in healthcare, privacy considerations for protected health information (PHI) are critical when considering the technology for certain transactions.

Security Vulnerabilities

The technology provides resilience to certain types of attacks but are by no means entirely secure. Since they are essentially just code, they are still susceptible to zero day attacks and technical bugs. Also, the technology is almost always accessed by people, making it susceptible to one of the greatest risks in information technology, social engineering. Due to this, the technology needs just as much scrutiny towards information security as any other network or piece of software, especially for blockchain in healthcare.

Back to top

Blockchain Components

Blockchain is a type of DLT. DLT is a decentralized data structure where the data are distributed across all computers or nodes within a network and every node in the network stores a copy of the ledger. There is no central administration of the data and the data are agreed upon by consensus by all nodes in the network.

DLT components include data models to describe what data are captured in the ledger and agreement for protocols, such as a consensus protocol to determine how transactions are accepted into the ledger.

Ledger

Similar to the common use of the word ledger, a ledger in the context of DLT is simply an electronic record or collection of transactions.

An important distinction is that the ledger is not a collection of assets. While assets are a part of transactions, the ledger records the transactions of those assets. For example, bitcoin is a well-known asset and transactions involving bitcoin are recorded using a distributed ledger.

Blockchain technology constructs the ledger by building a chronological and consecutive chain of blocks. It can also record a collection of code called smart contracts that enable functions to be run on the blockchain.

Transactions, Blocks and Chains

Transactions in this context are:

• A record, for example of an event
• Verified and secured cryptographically
• Ordered chronologically
• Bundled to form a block

A block is a set of transactions that are bundled together and then appended to a chain of other blocks. Hence, the name blockchain. When the blocks are chained together, each new block contains a reference to a unique identifier from the previous block called a hash code or a cryptographic hash. Blocks can include one or more transactions. In other words, it is possible to batch transactions into blocks, and this is often done to improve the transaction throughput rate for a blockchain platform with a given block throughput rate.

The block contains the following information:

• Previous Cryptographic Hash: Unique identifier, called a hash, referenced from the previous block
• Timestamp: Timestamp of each block added to the chain
• Merkle Root Hash: Merkle tree root hash for all of the transactions included in the block
• Nonce: Stands for “number only used once.” The nonce is the cryptographic challenge number that nodes are solving for in order to propose a new block. It is a number added to a hashed block, and, when rehashed, meets the difficulty level restrictions. This number is related to consensus algorithms.

Cryptography

Without a central authority within a network, trust is established through consensus and cryptography. Cryptography is used to shift the burden of trust from intermediaries to cryptographic algorithms.

Components of cryptography include:

• Message or Payload (also called plaintext): The actual data or payload within the message that the sender and/or receiver wish to keep secret.
• Secret Key: Data used for encrypting and decrypting the message. In DLT, reference is often made to public and private keys.
• Cipher (also called ciphertext): The output of the encryption function, which is the encrypted version of the message that is sent between the sender and receiver.
• Encryption/Decryption Algorithm: Algorithm pair used to convert between the plaintext message and ciphertext message.

In general, cryptography is often used to encode or encrypt data so that intermediaries or outside actors cannot decipher a message. It enables a confidential two-way exchange, where each party can encrypt or decrypt the cipher to access the message payload. With blockchain, cryptography is also used to validate data integrity.

The cryptographic algorithm uses the message and the key to create an encrypted version of the message called the cipher. The cipher can be exchanged by the sender and receiver. A key is then used to decrypt the cipher back into the original message.

Public Key Cryptography

Public key cryptography is often used in DLT for data validation and user authentication through digital signatures. User authentication is achieved through a combination of a user’s public and private key through a Public Key Infrastructure (PKI) framework. A public key represents the public identity of a user that can be shared with others. The user also holds a private key stored in a wallet that stores the user’s private credentials.

Mathematical algorithms generate the pairing of the private and public keys, and these make it possible to encrypt and decrypt a message. In PKI, it is mathematically improbable to calculate or derive a private key from a public key. The pairing of the public and private key enables the authentication of a particular user or node. Public and private keys can also be used in a way that preserves the anonymity of users.

Hash Functions

DLT uses a specific type of cryptography called cryptographic hashing. A hash code is created by a mathematical function that takes a digital object and generates a fixed 32-character size string of letters and numbers to represent it (e.g. a transaction represented as d7w0993waty9n33234qw949g02b9o34238878501032ff2si04d3d99sq93jzwa9).

Cryptographic hashing uses cryptography for a one-way conversion, where the encoded data, or hash, is created. The hash result is intended to be shared with other parties, but not decoded. The encoded hash is mathematically impossible to decrypt or reverse engineer. This makes it impractical to derive the input message used to create a hash code, from the hash code itself.

Cryptographic hashing is used by DLT so that the data can be proved without actually sharing the contents of the data. Each party can prove the data by matching and validating that the calculated hash matches each other.

Hashes are used to maintain the immutable characteristic of blockchains. Since any change to the original object will generate a new hash, changes are easily detectable. For each block, a hash code is computed as a combination of the data in the block plus the hash code of the previous block. In this way, hash codes are chained. Hash codes are easy to compute and can be verified by all participants that the data have not been altered. Any attempt to delete or alter the data on a block renders the chain of hash codes invalid and easily detected by the participants.

Merkle Tree

Merkle trees are used to reduce the volume of data and enable efficient validation of data on the blockchain. A Merkle root hash is stored in each block and created by hashing transactional data that are included as part of the block.

In the diagram below, there are four transactions (Tx). Each of these transactions are represented by a hash 1-4. Each pair of hashes are further hashed (Hash 12 and Hash 34), which are finally represented in the parent block as the Merkle root hash.

The Merkle root hash is used so the validation of transactions is more efficient. Rather than having to validate all of the data in a block, data for a single transaction can be sent along with the relevant hash values. The validating node can calculate the hash values for the given data and confirm that the transaction is valid without needing all of the data in the block.

Zero-Knowledge Proof

Zero-knowledge proof enables a system to prove a condition of the message without revealing the actual contents of the message. For example, if currency is being sent from one user to another, the blockchain can verify that the sender has enough money without needing to know who the user is or the total amount that the user has.

Blockchain Networks

A blockchain network is made up of network participants, which are computers or nodes where the ledger is stored, updated and maintained. Every node in the network stores a copy of the shared ledger and continuously synchronizes with other nodes across the network. The network’s goal as a whole is to provide consensus and ensure the consistency and validity of each copy of the shared ledger across nodes, and validate each new block appended to the ledger.

Networks include consensus algorithms or protocols that define how nodes communicate and interact with each other. Each node synchronizes its copy of the shared ledger as consensus is achieved, according to the specific consensus protocol of that network, which is determined by the particular platform used to implement the network. This consensus ensures the validity and consistency of each copy of the distributed ledger running on each node of the network.

Networks can be permissionless or permissioned. A permissionless network is open to the public and anyone can join. Permissioned networks are private and require pre-verification and authorization of participating parties. Groups of organizations that participate in permissioned networks are often referred to as consortiums.

Peer-to-Peer Network

The “distributed” in DLT refers to the idea that it uses a peer-to-peer (P2P) network structure. Compared to a central server network, nodes on a P2P network are connected directly to each other rather than to a central server. There are no intermediaries, such as a bank or clearinghouse, to process the transaction.

This data distribution model is a defining characteristic of the technology: centralized authorities do not communicate updates to records. Instead, each node executes P2P communication to achieve consensus among the nodes and trigger updates in the form of blocks appended to the shared ledger.

Permissionless or Public Networks

Permissionless or public networks allow anyone to participate, and members are pseudonymous to each other. The Ethereum network is a well-known, open-source example of a permissionless network. Due to its public nature, trust is established in the data, which nodes agree upon through consensus algorithms.

Trustless systems simply trust the authenticity of the data, but do not need to share data beyond the transactions on the blockchain.

Permissioned or Private Networks

With P2P networks, since there is no central control, trust between nodes becomes an issue. One solution that is widely used in applications to increase trust is the use of a permissioned, private or consortium network, where only well-known and trusted organizations are allowed to participate, and only their nodes are allowed to join the network. In permissioned networks, participation is controlled by an authority who provides a membership service for user authentication and identity management.

A consortium may be established to govern these networks of disparate participants. Participants in the consortium have a business need to know regarding data on-chain, and use cases and associated business values are known and make sense to all participants. These networks allow for easier paths to demonstrate trust by validating all participants on the network. Private networks typically concentrate control to consortium members and sometimes to only a few stakeholders depending on the deployment of validating nodes.

Beyond clear-cut private and public networks, some semi-private networks are emerging with use cases leveraging elements of both public and private aspects.

Distributed Storage

A blockchain is essentially a type of data storage, but very different from a traditional database that many of us are used to. The characteristics are quite different from the well-known traditional, relational and noSQL databases. It is important to understand these differences when considering blockchain in healthcare and if this technology is appropriate for your use case.

The technology is designed to store transactions grouped into blocks that may then be queried concerning the characteristics of those blocks and can be public or private. For public, the database is read/append by anyone on the network, and therefore uncontrolled. In contrast, if private, read and append capabilities are controlled.

Maintenance and Storage

A blockchain is also a distributed and decentralized type of data storage in that it propagates multiple copies of the shared ledger across nodes. Each node on the network stores and maintains its own copy of the shared ledger. Through a network consensus protocol unique to the particular platform, network nodes agree to which transaction blocks are valid and will be appended to the shared ledger and then synchronize each of their copies of the shared ledger accordingly. This architecture is what contributes to the technology’s resilience. Multiple nodes can fail and, as long as a critical mass of nodes remain, this will not impact the data integrity of the shared ledger.

Data Sizes

The amount and types of data that can be practically stored on the blockchain are determined by the particular solution. Data storage restrictions imposed by public networks typically are enforced by technological or practical limitations or for economic or ethical reasons. In private networks, these restrictions may not necessarily exist. For example, it may not be economically feasible to store a large data set on a public network. However, it is potentially feasible or desired using one of the private, permissioned technologies. Performance, as well as privacy, security, and compliance should be taken in to consideration in determining what data should be stored. General guidance is to store only minimal but sufficient (for the use case) data.

Off-Chain Data Storage

Off-chain storage refers to the storing of data off the blockchain, for example, in a relational database. The on-chain data can store metadata about this off-chain data, together with pointers to where the actual data resides, and hash codes that may be used to verify the integrity of the off-chain data. The technology can also be used for identify and access control, in other words as a mechanism to control access privileges to this data stored off-chain.

Smart Contracts

A smart contract is a term commonly used to describe computer code protocol intended to digitally facilitate, verify, or enforce the negotiation or performance of an agreed transaction. A smart contract in its simplest form is really an if-then statement that runs on a blockchain. While it’s possible to automate some actions under an actual legal contract, like payment obligations occurring on a certain date, a typical legal contract is a much more multifaceted instrument. For instance, it may include a standard of behavior, like reasonable or in good faith, that cannot be encoded in software.

While the technology was originally used to exclusively record transactions, it has evolved to where it can now also enable the running of programs or functions, similar to how users may run software on a computer. Smart contracts constitute self-executable code on the network, triggered upon predefined conditions or actions. Within the network, each node must execute the code in order to remain in sync with the rest of the network. The role of a blockchain node is to maintain the consistency and validity of the shared ledger.

All of this is done in a transparent, streamlined manner allowing the parties to transact directly with each other without conflict or the need for intermediaries. Since a smart contract is stored on a blockchain, they are automatically trackable, immutable and distributed by nature, and hold each party responsible for their role.

The primary benefits of utilizing smart contracts are:

• Speed and Savings: Smart contracts can be executed faster and at lower cost without the need to rely on brokers or intermediaries. They are automated, accurate and save time and money.
• Security and Trust: Smart contracts inherit the properties of residing on a blockchain. Hence, they can be trusted given their immutable nature, which eliminates the possibility of any alteration to the contract. The smart contract is transparent and accessible within the blockchain, while also offering a reliable backup due to its distributed storage.

Some U.S. states have legally recognized the use of smart contracts under specified conditions; however, there is much work to be done to ensure both clarity of enforcement and uniformity of definition. Since a smart contract is stored on chain, it is automatically trackable, nearly immutable and distributed by nature, and holds each party responsible for their role.

Back to top

Frequently Asked Questions

Watch Abdullah Albeyatti, MBBS, BSc, MRCS, CEO and co-founder at Medicalchain, talk with HIMSS TV about applying the technology to healthcare.

Like any emerging technology, there is a lot of hype and questions around what it may mean for various industries. Along with this comes the spread of misinformation. Due to how controversial cryptocurrencies have been in the media, blockchain has garnered much attention, which in turn has created many myths about the technology. These questions address some of the common questions around the technology in general and in relation to the application of blockchain in healthcare.

Is it the same as cryptocurrency?

One big myth is that it is inherently tied to cryptocurrencies; this could not be further from the truth. Part of the confusion around the differences originated from terminology that was used during the early evolution of the technology, where it’s most attention-grabbing application, cryptocurrency, was at the forefront of the press. Often, the terms were used synonymously, leading to some confusion for those trying to understand this new technology and the benefits it could provide.

Blockchain itself is the backbone of all cryptocurrencies and enables their creation and exchange through secure, decentralized and anonymous transactions. Cryptocurrency is essentially a digital form of money or medium of exchange; an alternative to traditional fiat money—or government-issued currency —such as the U.S. dollar or Euro.

Cryptocurrency functions as P2P money without the input of banks (the issuer of fiat money) as an official issuing intermediary. Similar to cash and banking transactions, cryptocurrency needs to maintain a digitized, decentralized, public ledger of all transactions, which is stored in the blockchain.

Simply put, cryptocurrency cannot exist or function without blockchain, but it is far from the only use case that can be applied to this technology. Blockchain is a foundation or platform, which supports running different applications. Cryptocurrencies are one type of application that can run on it, but there are many more potential applications, and several promising healthcare specific applications or use cases.

Is it unhackable?

Another common misconception is that it cannot be hacked. While the technology is resilient by nature to many typical vulnerabilities, it is still susceptible to a wide range of attacks. The most notorious vulnerability to date is the 51% attack, wherein a single entity gains control over 51% of the blockchain and can then control the ledger. Like any piece of software or network, this technology is also susceptible to code exploits and social engineering.

How do you achieve consensus?

Consensus refers to the process, or protocol, that network participants use to agree upon the correct state of data on-chain and to synchronize the data across all nodes in the distributed network. Consensus algorithms are the main way in which nodes secure the technology.

In current business scenarios, systems must often reconcile transactions that occur throughout the day (e.g., banks, supply chains, etc.) through batch processing, sending, receiving, exporting and importing data. With blockchain, reconciliation of data occurs in near real-time across all participants within the network.

In order to achieve consensus, the technology uses consensus algorithms to ensure that data that reside in the shared ledgers are the same across all nodes in the network, and to prevent malicious actors from attempting to alter the data.

Different platform implementations use different consensus algorithms. Examples include:

• Proof of Work
• Proof of Stake
• Simplified Byzantine Fault Tolerance
• Practical Byzantine Fault Tolerance
• Proof of Elapsed Time (PoET)
• Proof of Burn
• Proof of Capacity
• Proof of Authority (PoA)
• Directed Acyclic Graphs (DAGs)

The two main consensus algorithms currently used today are Proof of Work and Proof of Stake.

Proof of Work

The Proof of Work (PoW) consensus algorithm involves solving a computational challenging problem in order to create new blocks, referred to as mining. It is the most commonly used consensus algorithm to date.

The problem is solved by randomly guessing a value for a nonce, which is added to a hashed block, and when rehashed, meets the difficulty level restrictions. When a miner finds a solution, the miner creates a block and broadcasts the nonce to the network, finalizing that block. The winner receives a reward in the form of payment (such as tokens).

PoW algorithms can be susceptible to the 51% attack, which refers to a scenario where a group of miners controlling more than 50% of the network's computing power can collude to conduct an attack. Since its first use in 2009, such an attack has rarely been successful but are becoming more regular. This attack becomes less feasible as the size of the network grows, and there are more and more miners that would have to collude to reach higher than the 50% threshold.

Proof of Stake

With the Proof of Stake (PoS) algorithm, nodes are considered validators rather than miners, where nodes validate each transaction in order to earn a transaction fee. Nodes place a stake of their own assets, and the block forger is randomly selected from all of the nodes with staked assets. The selection process is weighted based on the size of the stake, so a user that stakes twice as much as another user is twice as likely to be called to validate the block. The PoS algorithm saves the need to obtain a large amount of computational resources used in mining under the PoW consensus algorithm.

What is immutability?

The technology is designed so any changes to data on a block are easily detectable to the network, giving blockchain a capability called immutability. Since all of the blocks are chained together, each block including the previous hash, a malicious actor that wishes to change data in a block would need to gain control of the majority of nodes in the network. They would then need to also recalculate all of the subsequent chained hashes, which would require control and collusion on an impractical scale, especially as networks grow large, and may also require an enormous amount of computing power, depending on the consensus algorithm.

This also means that the past history of the data on the blockchain also persists and cannot be changed or deleted. Updates are added as new blocks as an append-only mechanism rather than as an overwrite. This has significant performance ramifications when dealing with information that frequently changes, with each change requiring a new transaction. This also has significant ramifications from a privacy, security, and compliance standpoint where a blockchain may contain sensitive information such as personally identifiable information (PII).

How is transparency and trust achieved?

The entire history is visible and stored in an immutable and verifiable way, and new blocks and the transactions within those blocks are visible near real-time across the network, giving blockchain a characteristic of transparency. There are permissioned and private networks versus permissionless and public networks that control the network access, the visibility of data in shared ledgers within, and therefore the level of transparency.

Since data are immutable, the blockchain supports a network where nodes can operate in a trustless system. This means that nodes do not have to trust each other or establish a way to ensure trust, as long as they trust the blockchain, the associated consensus algorithm, and the data on-chain. Without a central authority within a network, trust is established through consensus and cryptography. Cryptography is used to remove the burden of trust from intermediaries to cryptographic algorithms for data validation. Certain permissioned implementations may also use a central authority to provide access and identity management.

How is a high level of fault tolerance achieved?

The P2P network and redundancy of data lend itself to a high level of fault tolerance. This means that nodes can be added or deleted from the network, and still the overall network remains in operation, and the consistency, validity, integrity and immutability of the data is ensured.

The technology is designed to have Byzantine Fault Tolerance, which refers to the idea that even if nodes are untrusted, the network must come to a consensus on the official state of the blockchain.

How mature is blockchain in healthcare and what are the barriers for adoption?

Currently, private networks are more mature than public networks for healthcare. Certain use cases are seeing traction with adoption. Most barriers are not related to the technology, but rather relate to:

• Business
• Governance
• Healthcare organization buy-in and trust
• Laws and regulations
• Social and cultural change

For example, the technology may provide traditionally adversarial organizations the opportunity to work together to create new business opportunities within a consortium. This may create challenges in aligning culture and establishing governance across these organizations. From a regulatory standpoint, antitrust considerations and cross-border collaborations face compliance challenges because of differing regulatory environments.

There are some technology considerations around blockchain in healthcare. With a wide variety of legacy systems in the healthcare environment, integrating all of these diverse systems can be challenging.

Overall, lack of education is a considerable barrier to adoption. There are opportunities to educate on the appropriateness of blockchain in healthcare, the use cases and associated business values it can provide, its relationship to existing legacy systems, and its privacy and security implications. Workforce training will also be required.

How will it affect costs in healthcare?

The cost-effectiveness depends on a number of factors, including the use case applied, the size and demographics of the implementing organizations, and the requirements of the consortium or governance model. Adoption may potentially bring both potential costs and savings.

Some current solutions simplify the supply chain and administrative processes in healthcare, such as streamlining prior authorization, which may decrease costs. Ultimately, organizations can expect some added technology costs that are prevalent in the adoption of any new technology or solution, including implementing workforce training and change management requirements.

What healthcare data should be put on the blockchain?

The type of data stored on-chain is dependent on the needs of the specific use case. However, for blockchain in healthcare, we generally suggest implementers adopt a minimal but sufficient approach to determine what is included on-chain. Organizations should strongly consider the ramifications of storing any PII or PHI when considering the data for each use case. Examples of identifiable information to keep off-chain also include data outlined in the Payment Card Industry and school health data regulated by the Family Education Rights and Privacy Act.

Keep in mind its immutable nature when considering data stored on-chain. Storage may also be a consideration when determining data included on-chain, especially if the data files are large or change often. Some states also include regulatory requirements for medical record storage that can influence decisions regarding on-chain data.

In many scenarios, the blockchain includes data that serve as identification for access permissions and pointers to data off-chain. This means that the majority of data that is stored on-chain consist of metadata, information about the data records together with pointers and a hash to verify integrity. To be useful, solutions must use identifiers for people, but these may be generated IDs used only on-chain and useless off-chain, instead of sensitive PII elements such as name, Social Security number, date of birth, and so forth.

While your use case will determine what information is needed to be stored on and off-chain, these guidelines can help inform a minimal but sufficient approach for your needs.

On-Chain:

• High Level Data: The ideal transaction typically takes the form of higher level data, metadata, transactional information, audit records, pointers and hash codes.

Off-Chain:

• Large Data Files: The architecture of the distributed ledger should keep large volumes of clinical information off-chain and in secure access-controlled enterprise systems where they exist today, and reference these data records as required from the blockchain with pointers and hash codes that can be used to verify their integrity.
• PHI and PII: This information should be stored in secure access-controlled enterprise systems. Referencing these data records as required from the blockchain would be an acceptable way to get the benefit of the technology while maintaining HIPAA and other privacy standards.

Utilization of existing data stores allows organizations to leverage their existing data storage investment while capitalizing on the advantages of blockchain for decentralized data exchange.

Can it handle the current needs of data exchange?

This depends on the specific needs of data exchange. Blockchain is a technology for record locating and other lightweight transactions that can facilitate access to shared data through metadata, pointers and hashes. The technology co-exists with other health IT infrastructure.

For example, metadata and pointers are used to search and discover data records of interest, locate off-chain records, and verify the integrity of these records using hashes stored on-chain. Systems using the technology can leverage existing standards to facilitate interoperable exchange between systems. Smart contracts also provide solutions to facilitate data exchange since they provide the executable logic for validation and processing of data records as required to support data exchange. Zero-knowledge proofs can also be leveraged together with blockchains to exchange information in a manner that preserves privacy.

What are some common considerations when integrating this technology into existing systems?

Initially, interface engines and connectors are likely needed to provide input, output, verification and validation of data between blockchain systems and the existing systems of record; this is until future versions of applications are able to use application programming interfaces (APIs) to interface directly. A robust patient matching system and/or decentralized identification system for integration is important to ensure validity of data. Furthermore, a relationship should be defined between the data on the blockchain and the data that live within legacy systems that may be linked.

How is patients’ access to and interaction with their data affected?

As a middleware technology, patients do not interact with the technology directly. Instead, they could interact with applications or websites as they do today, and the server infrastructure behind these applications in turn may interact with blockchains. However, they may have the potential to empower patients with greater control of their data and privacy.

For example, when used as a decentralized record location service, the technology could enable patients’ access to their longitudinal record across providers and grant access to appropriate parties. If patients want to have others verify and validate their data to ensure provenance and accuracy, hashes should be able to provide this capability.

Back to top

Adopting Blockchain in Healthcare

Now that you have a basic understanding of the technology, it is essential to identify real-world scenarios in healthcare where this technology may be relevant and valuable. Organizations must consider existing problems or needs that the technology may help address instead of looking to implement a solution without a problem to solve.

When implementing this technology, organizations must be aware of and open to the new organizational paradigms that accompany these solutions. Fundamental to assessing this technology is understanding the paradigm shift to decentralized, distributed solutions. Referred to as the new economy, this may not align with existing business models, regulation at multiple levels of authority and multiple locales, and technology infrastructure. Since the transition to any new paradigm will be gradual as many stakeholders engage at different times and velocities, blockchain will find application to existing business use cases and new opportunities in parallel over time.

Consortium Governance

Blockchains are designed for consortia. In contrast, they are not intended for use only within a single organization. Consortia must have robust governance to enable the success and evolution of the technology. Its capacity or throughput depends largely on the consensus protocol, and can also depend on the network latency and bandwidth. Use cases and expected throughput requirements should be analyzed up front to ensure the platform and its consensus protocol have sufficiently high throughput and capacity to support the target use cases. Private networks typically have throughputs in the range of 100s to 1,000s of blocks appended per second. Note that transactions can be batched onto blocks to improve the transaction throughput for a given block throughput.

To date, the majority of solutions for blockchain in healthcare are private consortia. The governance adopted depends on consortium structure. This structure can include one or more than one member and should be detailed in legal agreements. A consortium may have a master consortium agreement, agreed to by each of the consortium members, and should specify responsibilities to assure security and define the rules of the road for engagement. Often, a specific organization takes responsibility for technical support and system integration, facilitating consensus among the consortium.

Privacy Considerations

A key consideration when implementing a blockchain in a healthcare setting is patient privacy. A strategy is needed to address concerns related to how patient PHI will be collected, used, accessed, disclosed, stored and ultimately disposed of.

With new regulations on the rise, such as the General Data Protection Regulation (GDPR), in conjunction with regulations that have been around for more than a decade, such as HIPAA, patient privacy is now a standard when considering processing any form of PHI.

Individual Access Rights to Data

Users will want to consider how to best include the individual as an end-user of the system or application. A major consideration must be the right of an individual to access their data. HIPAA provides statutory guidance on making patient data available to the individual through a copy of their record upon request. To date, no data set has been identified that would be required to be made available, but policy through the federal government is driving an individual to own their health data as a motivation for participation in their personal health and care.

HIPAA does not require an individual consumer’s permission or consent to share data for permitted purposes, which include the sharing of data for treatment, payment or operations. However, HIPAA is silent on rules related to third-party health care applications (apps). HIPAA does require that a covered entity (provider or facility) keep an audit log of disclosures. DLT would assist with these requirements.

A key component for the GDPR also refers to right of access. Article 15 Right of Access by the Data Subject entitles subjects to be able to transfer their data from one electronic storage entity to another without restriction from the data controller. This entails ownership of the data by the subject.

Individual Right to Erasure

Since blockchains encompass immutable properties, it is important that the data cannot be attributed to any one subject. This is addressed in Article 17 Right to Erasure (“right to be forgotten”) of GDPR. Given these boundaries, it is important to address where data is being stored in regards to implementation. Implementers will also need to consider other federal and state laws and regulations outside of HIPAA that may impact data use from a privacy perspective, especially when the entities involved are not covered entities under HIPAA.

Security Considerations

Security should include protecting the confidentiality, integrity and availability of sensitive data and systems. For effective overall security of the network, it is important to secure the blockchain, each of the nodes, and the healthcare organizations and enterprise systems that are connecting to the technology.

Confidentiality

Protecting the confidentiality of data requires ensuring only authorized access to data in shared ledgers, the validity and consistency of which are maintained by nodes using several mechanisms, including consensus mechanisms. For blockchain in healthcare, organizations are using a multi-layered approach to achieve this through the use of private blockchains, where all of the connected healthcare organizations are well known and trusted. Permissioning may also be used to restrict the privileges of each healthcare organization on the network to only what is required to fulfill their role in the network. Data may be encrypted to further protect its confidentiality and ensure only authorized access.

Different DLT platforms employ various additional strategies to achieve confidentiality. For example, Hyperledger Fabric deploys a channel architecture, Quorum leverages a constellation network, and Corda uses notary services. An organization’s strategy to maintain confidentiality is critical in the implementation process.

Integrity

Immutability of the shared ledger depends on sufficient decentralization where nodes are deployed and under the control of different organizations in order to mitigate risk of collusion. Because of the technology’s immutable nature, end users are able to trust that the data on-chain have not been altered. Updates can be appended to the chain, however without the ability to alter data already added, each data point has integrity. In a private or consortium scenario, an additional layer of predetermined trust exists between the nodes that adds to the integrity of the data.

Availability

Availability of the overall blockchain is enhanced through the decentralization of the network such that if one or more nodes fail, the overall network lives on, and when the nodes recover, they catch up to ensure the consistency and validity of their shared ledgers.

However, the technology does not protect the availability of each individual node. As a healthcare organization grows to depend on blockchain for mission critical services, it is important that the access of that organization to the network is protected. This is the responsibility of the healthcare organization in deploying their node(s). As similarly deployed in non-blockchain systems, nodes can be protected with redundancy across availability zones, load balancing and automated failover, backup and restore, business continuity and disaster recovery, and several other safeguards.

Additional Security Strategies

On its own, this technology is not inherently secure and does not replace security management protocols; rather, it can augment an existing security solution. It should not be the only component in an organization’s strategy. Its data integrity protection characteristics depend on sufficient decentralization of nodes across different organizations across a consortium to minimize risk of collusion.

Some security strategies that may be considered include the following:

• End to End Security (from endpoints to the cloud): Proactive security measures, such as conducting regular risk assessments, compliance audits, upgrading and patching software, operating systems, and firmware at the endpoint are important measures to implement.
• Encryption: Data are generally encrypted before being sent across the network to the receiver. The ciphers used must be strong to prevent attacks. Additionally, strong key management is vital to safeguard the private/secret keys.
• Protecting Node Availability: There is no single point of failure. However, individual nodes are not protected. To protect node availability, redundant nodes, load balancing and automatic failover are proven strategies.

Interoperability

This technology has the potential to advance interoperability efforts. At its core, it is a shared ledger, which enables participating organizations to have a common view of the status of digital assets and transactions. On its own, it can help provide foundational levels of interoperable exchange between network participants. Some current solutions leverage existing interoperability standards to support the standardized exchange of PHI. The technology itself does not deliver interoperability, but rather offers an opportunity and driver for interoperability.

Existing healthcare interoperability standards such as IHE (Integrating the Healthcare Enterprise) and HL7 FHIR (Fast Health Interoperability Resources) should be used to the maximum extent possible to ensure healthcare organizations can communicate and collaborate efficiently via the blockchain. Pilots underway are leveraging existing IHE frameworks within the blockchain infrastructure to support standardized exchange PHI. Peng Zhang et al. discuss some of these challenges in the proposed FHIRChain architecture. However, adding standards like FHIR to the blockchain will allow the participating systems and organizations to reach semantic interoperability within a given network.

The specific types of healthcare organizations in the network, the use cases, and types of data shared are key factors in identifying existing applicable interoperability standards. Interoperability should be enforced in the writing or appending of new transactions and blocks. This can be done through APIs and smart contracts. Blockchain can also enable the discovery, record location, and subsequent direct P2P exchange of healthcare data.

In addition to the interoperability of healthcare-related data on and off a chain, one also needs to look at the interoperability of the networks. Many healthcare-related solutions are forming based on different platforms. These platforms may be public or private, and organizations may be participating in multiple networks. Interoperability within a blockchain does not guarantee interoperability across it. As an example, payers participating in blockchains of clinical and claims metadata may have interoperability within each chain but not between both the clinical and claims, a consideration as many organizations seek to integrate clinical and administrative data. Several projects have started to create bridges between platforms to allow for the flow of assets between them.

Performance, Throughput and Scalability

When considering the type of protocol to employ for a blockchain in healthcare solution, the concepts of network performance, transaction throughput, and scalability must be considered.

Performance

In software, performance is generally measured by the volume of data moving from one endpoint to another. Performance depends on the latency and bandwidth of the network and, in blockchain specifically, the distribution size of the consensus nodes.

Typical performance for a private consortium platform ranges from hundreds of blocks per second to thousands of blocks per second. Real-world examples of using blockchain in healthcare data are limited and the metrics likely will be different based on the types of data in healthcare.

Best practice states that smaller data sets are better. Unfortunately for performance, most EHR and clinical data sets consist of large amounts of data, including historical information and data from multiple institutions. Data may not be accumulated in chronological order (one facility reports slower than another). Since a full copy of the ledger is presented each time a new transaction is added, as this information accumulates performance may degrade. Including only data sets with demographics, encounters, diagnosis, medications and excluding larger data (images, notes, etc.) could help keep performance stable. This would still depend on the participating networks’ bandwidth, and there may be other limiting factors affecting network performance within nodes, which are beyond the architectural design of the blockchain.

Patients’ ability to own their data and provision access to who they choose is one of the potential uses for blockchain in healthcare. This type of solution would be less impacted by the performance characteristics based on a less critical need for speed. Conversely, the need for critical information about a patient in an emergent scenario would be dependent on a high-performance solution; for example, the sharing of medication allergies during an encounter.

Throughput

In general, all protocols express throughput in terms of blocks appended to the blockchain per second. This transaction metric depends on the applicable consensus algorithm, which specifies how nodes communicate to ensure the validity of the appended transaction and the consistency of each of their copies of the shared ledger.

The predominant factors affecting throughput will be the design, size of data and scope. Design based on the smallest footprint (critical vs. non-critical information) is a limiting factor. Current data trends focus on sharing everything and using what you need. However, this technology depends on a different mindset to facilitate throughput, focusing on moving a limited set of data. If throughput is a major consideration of the technology’s design, examples of easily encapsulated data are demographics, diagnosis, date of service and other self-contained pieces of information.

Scalability

Blockchains scale best with lightweight metadata, provenance, transaction information, and audit information. In contrast, they do not scale as well with the addition of larger information types, such as images or full genomic datasets. This is because the data for every block committed must be replicated around every node, and each node stores a complete copy of the shared ledger, representing the sum of all data across all blocks from the start of the chain.

Scalability is always a consideration in software implementations. It is the largest problem faced by entrepreneurial companies built around a small set of clients who then need to assimilate a larger set of clients. The same will be true for blockchains storing healthcare data; it is at an entrepreneurial point and will need to expand rapidly. Design considerations could be as simple as multiple blockchains with different data sets (demographics change very little, encounters change on a regular basis), but options for scaling should be considered as part of initial buildouts.

With this technology, the ability to refactor all of the information gathered (after the fact) as it grows will be challenging. Starting with the right set of data from the beginning (which is difficult) will improve the ability to scale.

The upfront design is critical to the performance, throughput and scalability of the technology. Having a clear idea of the problem that you are working to solve, what information and which stakeholders are needed to address the problem, and the expected result will shape these elements.

Limiting the result set initially and expanding as you discover what is needed and used, is a way to control all three of these factors. When speaking of a distributed ledger, getting what is needed versus getting it all will help with performance, throughput and scalability.

Deployment Architecture

Blockchains may be considered a type of middleware, enabling collaboration across a network of participants, from individuals to multiple healthcare organizations.

A given network may consist of on-premises or cloud-based node deployments, or a hybrid. However, each of the nodes in a network must implement the same consensus algorithm and transact using the same consensus protocol in order to communicate with other nodes in the same network. Typically one platform, for example Ethereum Enterprise, will be used consistently across a given network, although the deployment of each node may vary, some on-premises and others in the cloud.

Deployment models for blockchain networks can leverage the existing, traditional models of system deployments, using on-premises environments or cloud-based environments, using either Platform-as-a-Service (PaaS) or Infrastructure-as-a-Service (IaaS) hosting models.

On-Premises Deployments

In a traditional on-premises deployment, a healthcare organization must procure hardware, install and configure software, maintain all updates and patching, and update network configurations to enable communications between the node in the DMZ, or demilitarized zone, and other nodes over the internet.

Cloud-based PaaS Deployments

In a cloud-based, PaaS deployment model, the organization also must provide acquisition, configuration and maintenance, but does not have to support the blockchain network within their data center, which presents some cost advantages in terms of computing use and lifecycle costs, as well as agility and scalability. As blockchains are used in production for mission critical use cases, availability becomes critical. The technology naturally helps improve availability with decentralization and no single point of failure. However, healthcare organizations must protect the availability of their nodes, which can be thought of as their on-ramps or off-ramps to the blockchain. Redundant nodes across availability zones with load balancing and automated failover can help with this. For healthcare organizations without data centers, or without multiple availability zones, cloud-based deployment of nodes across availability zones can be a decision factor.

Cloud-based IaaS Deployments

For a cloud-based IaaS model, a healthcare organization may avoid the capital costs, delays, and maintenance of an on-premises deployment and transfer lifecycle costs to a cloud service provider, which enables them to create and host nodes as needed, and leverage the cloud’s security and availability. Cloud environments typically provide availability zones, load balancers, DDoS mitigations, and so forth that can be easily deployed, further simplifying and accelerating cloud deployment of nodes and enabling accelerated deployment of blockchain in healthcare organizations, thus improving their focus on the business or application layer, and evolving and improving their use of the technology.

It is important to note that this technology is part of an ecosystem, and is not a standalone solution. Within this ecosystem a blockchain is integrated with enterprise systems. These enterprise systems also have various deployment models, and some may be deployed on-premises while others are cloud-based. However, for any enterprise systems that hold records referenced by the blockchain, it is important that such systems provide an externally accessible interface for retrieval of such information. If such systems are based in the cloud, this can be straightforward. However, if such enterprise systems are within the intranet of a healthcare organization, it will be necessary to provide an externally accessible interface, either in the DMZ of the healthcare organization, or in the cloud, and have this external interface integrated with the internal on-premises enterprise system.

The following architecture framework may be useful for constructing and evaluating solutions in healthcare.

Source: Healthcare Blockchain in the Cloud

Back to top

Public Policy and Governmental Efforts

Regulatory and Compliance Considerations

Implementation of blockchain in healthcare must consider regulatory and compliance impacts on the use of the technology depending on its use case. If your solution will store PHI or any sensitive healthcare information, and be used by covered entities and business associates under HIPAA or data controllers and data processors under GDPR, then it is recommended to engage your compliance team early in your initiative to ensure compliance with all applicable regulatory or data protection law requirements. Considerations on what information will be stored on-chain and off-chain will also be important to comply with regulations related to PHI storage.

While regulations and compliance considerations differ by federal, state or local jurisdictions, this section aims to provide some examples of regulatory requirements that may impact healthcare solutions that intend to leverage the technology.

HIPAA

For U.S.-based organizations, considerations should be made when the blockchain use case either relates to or is parallel to transactions adopted under HIPAA. In instances where the data exchange is determined to meet the definition of specific data exchange (i.e., a transaction as defined in 45 CFR §160.103) under HIPAA, implementers will need to pursue the exception process identified (45 CFR §162.940) to mitigate any risk of non-compliance to the implementers.

Another consideration from a compliance perspective is that of third-party management with blockchain initiatives (e.g., covered entity and business associate agreements). Having a solid understanding of what each party has agreed to do and the impact of data sharing/storage responsibilities is essential.

As of January 2020, the Office of Civil Rights (OCR) is reexamining HIPAA’s language to eliminate barriers to access and exchange of health information for value-based care. Considerations for your organization’s compliance with these regulations may shift pending the updates to these regulations.

42 CFR Part 2

Information sharing under 42 CFR Part 2 is much stricter than under HIPAA, which may create additional instances where data cannot be pointed to or shared, regardless of the technology.

GDPR

If your solution will include any data that belong to a citizen of the European Union (EU), GDPR regulations must be considered when implementing a blockchain solution. Specifically, considerations must be made on the inclusion of data as it relates to Article 17 Right to Erasure of GDPR. Given these boundaries, it is important to address where data is being stored in regard to implementation.

Additional International Regulations

• Chinese Privacy Laws: New Chinese Privacy law covers any citizen’s PII, meaning that any company, regardless of location, with Chinese citizens as customers is bound by these new regulations. This law goes even further than GDPR’s citizenship coverage and covers any “natural persons.”
• EU Medical Device Regulations: A global investigation by the International Consortium of Investigative Journalists into the medical device sector has brought an increased focus on the safety of medical devices. As a result, the European Council, the European Parliament and the European Commission approved a new EU Regulation, 2017/745 on Medical Devices Regulation (MDR). For entities either manufacturing or contracting with medical devices in or out of a blockchain ecosystem, MDR has a transition timeline into 2025 that should be considered. One of several potential impacts is that devices already being marketed in Europe may be subject to re-classification under MDR. Devices that are ‘up-classified’ are likely to need additional scrutiny regarding available clinical data to ensure compliance. This means that devices that are subject to re-classification may require additional resources in order to continue to be marketed post-MDR. Bottom line, the adoption of MDR may result in the removal of a number of legacy devices from the EU market if commercial considerations around the cost of MDR compliance becomes prohibitive. Vendors should consider readiness plans for compliance with this regulation.

U.S. Federal Efforts Exploring the Technology

Given that this is a relatively nascent technology, there are only several operational initiatives at the U.S. national level and only a few focused on blockchain in healthcare. These initiatives span several national agencies and are largely in the proof of concept and pilot stages. National health agencies with an ongoing operational pilot or proof of concept include the Food and Drug Administration (FDA), Department of Health and Human Services (HHS), and the Centers for Disease Control and Prevention (CDC).

The FDA’s Drug Supply Chain Security Act (DSCSA) (2013) includes a 10-year rollout to address secure track and trace needs for drug companies. Many blockchain-enabled solutions are growing to address the needs outlined in this legislation. DSCSA supports a pilot program to explore innovative solutions to ensure compliance with the forthcoming DSCSA requirements; solutions include blockchain, artificial intelligence, and APIs.

The CDC is exploring how this technology can alleviate the privacy and security concerns of the copious amount of data needed to track public health concerns. The CDC partnered with a major technology company and provided a successful proof of concept to enable the CDC to control access to sensitive information and monitor how datasets move through the organization. CDC says this could be used to inform the opioid epidemic, controlling the spread of infectious disease and deploying experts to crisis zones.

There are some successful use cases in public health, most notably for food safety. This may offer one solution to track and link the outbreak to a specific food or grower. The FDA Commissioner recommended food suppliers conduct testing. One use case with a major retailer has shown success; with the retailer now able to trace food back to its seller in only 2.2 seconds using the technology. This speed and efficiency has the potential to identify the root cause of issues as they arise, reduce illness, reduce cost and save lives.

In addition to agency activity, bipartisan-bicameral legislation that seeks to define and promote the use of this technology within the U.S. national government has been introduced to Congress. The Blockchain Promotion Act of 2019 (S.553) (H.R.1361) directs the Department of Commerce to create a working group of diverse stakeholders. The working group would be responsible for submitting a report to Congress with a definition of the technology and recommendations of non-financial applications and opportunities for national agencies to use this technology.

U.S. State Efforts

U.S. states have been more active than the federal government in this case. The majority of state legislation does not focus on blockchain in healthcare, but may mention healthcare in a minor way, so tracking and understanding these legislative measures remains vital. The National Conference of State Legislatures (NCSL) outlines relevant state legislation.

Examples of enacted state legislation include:

• South Dakota, Utah and Washington enacted legislation to amend existing law to validate and define the technology (SD HB 1196, UT SB 213, WA SB 5638).
• Florida, Kentucky, North Dakota, and Utah enacted legislation to research and identify pilot programs (FL SB 1024, KY HR 171, ND HB 1048, UT HJR 19).
  • Florida SB 1024 creates a task force in the Florida Department of Financial Services to study opportunities for the technology’s impact on economic growth, workforce, efficiency, cost savings and cybersecurity; identify a pilot program; and, to submit recommendations for use in the public and private sectors to the governor and legislature.
  • Kentucky HR 171 urges the Kentucky Cabinet for Economic Development to work with state and federal officials and study how the technology can support innovation and economic growth and ensure consumer privacy.
• Illinois and Ohio enacted legislation on use permissions and limitation of the technology (IL HB 3575, OH SB 220)
  • Ohio SB 220 permits transactions recorded by blockchain technology under the Uniform Electronic Transactions Act.
• Alabama signed a resolution to recognize the expanded workforce and economic development through emerging technologies (AL SJR 45).

Some states are looking outside of the U.S. for model practices. For example, Rhode Island’s Department of Business Regulation turned to the country of Estonia, a hot spot for digital innovation. The state issued a request for proposal (RFP) on solutions in order to understand how the state can leverage the technology for state government business operations and evaluate the suitability of the technology in other areas of state government. Potential applications included in the RFP were antifraud, official records, licensing and crowdsourcing, all of which are applicable to healthcare. The state will fund entrepreneurs to test their products. Although this is a general request to the industry, it may include application of blockchain in healthcare.

Illinois government officials presented an Illinois Blockchain and Distributed Ledger Task Force Final Report to the General Assembly in accordance with House Joint Resolution 25. The task force was comprised of state legislators, representatives from Illinois state agencies, and representatives of the private sector; the task force did not include a health sector representative. The report described the opportunities and limitations of the technology for state government. One opportunity identified for government is its use to supplement and simplify the Medicaid enrollment and eligibility process since it could remove the siloed databases and connect them to a shared eligibility ledger. Another opportunity applies to food stamp administration; the digital identity verification would help verify applicants and reduce fraud.

Global Government Efforts

We see greater traction in some countries outside of the U.S. From Europe to the Middle East to Asia, the following are a few examples of government initiatives.

The EU has positioned themselves as global leaders across sectors. The European Blockchain Partnership joins EU member states and members of the European Economic Area to produce international standardized solutions. This partnership and the European Commission formed the European Blockchain Services Infrastructure to deliver cross-border public services. Their use cases do not include blockchain in healthcare at this point, but there may be potential for growth in the future.

One model practice in the EU is in public-private partnerships. In 2019, the International Association for Trusted Blockchain Applications was formed to realize these partnerships and to “transform digital services.” The association includes several workgroups, one of which is focusing on healthcare data.

In Estonia, one of the first global leaders in the technology, it is used to ensure data integrity in the nationwide electronic health record system. e-Estonia is globally recognized for connecting government services; it integrates and stores data from healthcare and other sectors using blockchain. In these cases, the technology assures data integrity and system access logs, which improves security. Estonia also developed a KSI, a blockchain technology that is used in multiple countries.

The United Arab Emirates (UAE), and specifically the Emirate of Dubai, is also positioned to be a leader in this space. Their successful initiatives leverage the power of public-private partnerships and blockchain for healthcare professionals licensing data, verification of medicinal safety and organ donation. The UAE aims to be 50% supported by this technology by 2021 and leverages some of Estonia’s model practices for their strategies. The UAE Ministry of Health and Prevention announced their first blockchain in healthcare system to track health professional licenses, as part of this nationwide strategy. The ministry was especially attracted to the technology’s ability to improve trust and transparency in the sector due to the nature of immutable data.

The National Health Service (NHS) leads the public healthcare system in the United Kingdom (U.K.). A London-based organization, Reform, published a report detailing the benefits and challenges the technology can bring to the U.K. through the NHS. It states that access control as a security and privacy measure is one of the most significant benefits. One challenge is complying with the EU GDPR, however these challenges can be mitigated by using a private network and limiting PII on-chain.

At a national level, China has taken an assertive and proactive stance. Local governments in China have also explored and implemented use cases. For example, the City of Changzhou partnered with Alibaba to reduce the silos in the health systems and to improve data security. One identified model practice is leveraging public-private partnerships for these types of initiatives. Results of this initiative have not been shared at this point.

Back to top