Understanding Blockchains – Part 4: Exploiting blockchain-based solutions
We conclude our four-part series (see the earlier posts here, here, and here) with a survey of how blockchains are (or could be) used in different industries, but especially in the medical and healthcare sectors.
In the previous posts, we provided a step-by-step introduction to blockchains – showing how a fully distributed ledger can be maintained in a consistent state by a large group of unaffiliated peers, mutually distrustful and potentially malicious, and who may not always be responsive. Distributed ledger (or database) technology is not new, but the blockchain as used by Bitcoin offered the first practical solution to solve most of the problems that thwarted researchers in the past. It solved the problem of scale (the number of nodes that have to maintain the ledger), the problem of trust (between pseudonymous peers), the problem of mutability (preventing retrospective changes to the ledger), the problem of centralization (where an attack on a central database can lead to massive data loss or denial of service), and several others. Bitcoin’s successor, Ethereum, as described in our previous post, added a whole new twist to the simple ledger as a repository of immutable records. Records can now contain code which can run business rules incorruptibly and effect changes in the system.
That the success of Bitcoin and Ethereum as a showcase of blockchain technology should have captured the attention of other industries is no surprise. After all, some of the operational issues that such diverse industries as banking, transportation, education and pharmaceuticals face appear to be partly mitigated by a blockchain-based solution. For instance, many of these industries suffer from poor or inaccurate record keeping, which adds to costs, inconvenience and fraud. A blockchain-based solution appears, at least superficially, to address some of these inefficiencies. For example, education records can be maintained permanently on a blockchain (rather than in easily lost or alterable paper records); a drug shipment can be tagged on the blockchain during each stage of its manufacture through transportation between various intermediaries to the ultimate retailer, preventing counterfeiting.
Another source of inefficiency and cost are the number of intermediaries who broker any interaction. (There are, for instance, at least five intermediaries when processing a single credit card transaction.) Musicians and their fans can directly interact (find, listen, buy) on the blockchain, without fees to various hangers-on, while individuals can place various personal identity-related information on a blockchain which they selectively reveal to other parties as circumstances dictate without placing their trust in various “identity services” such as Google or Facebook.
If these examples seem too simplistic, they are! However, such simple use cases form the basis of more complex and formal blockchain-based infrastructure projects. While it is tempting to do away with all intermediaries, deal directly peer-to-peer and avoid all elements of centralization, the fact remains that most industries are governed by rules and regulations that constrain what they can and cannot do. One major constraint, especially for the medical and healthcare industries, is privacy. A fully transparent blockchain – such a Bitcoin’s, even if the identity of the actors is pseudonymous – might run afoul of various laws if used in a manner where personally indefinable information can potentially be inferred from a careful study of transaction patterns. Then there is the problem of throughput. Bitcoin’s consensus mechanism between untrusted and potentially malicious peers takes as long as one hour to firmly confirm a single transaction, which is far too long for e-commerce purposes.
Thus, it is not surprising that the blockchain technology has been co-opted and re-purposed in a manner that fits the needs of regulated enterprises – hence the so-called permissioned blockchain. In our first post, we described the two principal branches along which blockchain technology has bifurcated, which we summarize below.
Bitcoin’s and Ethereum’s blockchains are the exemplars of the permission-less branch, meaning that entry and participation are open to all with the appropriate (open sourced and freely downloadable) software. The data on their blockchain – the records of transactions and, in the case of Ethereum, the contracts – can be openly read, even though the data cannot be directly associated with specific end users or entities. Given the openness of the solution, mechanisms such as proof-of-work mining have to be constructed to ensure that consensus emerges on the state of the blockchain.
This, as the rest of this article will elaborate, is in contrast to the use of blockchains in various industry verticals, who have borrowed the underlying concepts but created their private blockchains for access by and use within a walled garden of known participants. In these permissioned blockchains, many of the key aspects that make up blockchains are greatly simplified as aspects related to maintaining anonymity, circumventing bad behavior amongst participants or rewarding those who maintain the blockchain are not needed or greatly reduced. To many Bitcoin and Ethereum purists such compromises are an anathema, but wiser heads even within that community see value to improving the underlying technology to cover many more use cases and applications beyond anonymous crypto-currency transactions.
Parts 2 and 3 of this series described at great length the workings of a permission-less blockchain. For the remainder of this article, we will concentrate on the permissioned variety.
Permissioned blockchains for various industries
A permissioned blockchain, with known, invited participants subject to internal rules of engagement, typically values the efficiency of updates to records and overall transaction-handling throughput over anonymity and transparency.
This may be a good time to recall the architecture diagram, the first figure with which we motivated the discussion in each of our previous posts. The architecture diagram broke up the different aspects needed for a blockchain, and showed where these differed between Bitcoin and Ethereum.
In this post, we will similarly identify aspects, such as membership or consensus forming, where permissioned blockchains offer other solutions different from proof-of-work and where certain components, for example crypto-tokens, are not needed and therefore absent.
The Hyperledger Fabric
Rather than have each industry create a blockchain solution tailor made for its specific needs, the Hyperledger Fabric is an open source project hosted by The Linux Foundation with participation from many industry leaders to create a common, modular platform from which companies can choose components suitable for their needs to create their private blockchain instance. Thus, each industry can choose components to fit those aspects its considers most critical for its use cases (e.g., privacy, throughput, etc.) to guide the design of its blockchain.
Membership in a blockchain-based system created by this framework is decided by known, white-listed entities (e.g., members of an industry consortium), and each participant is granted a well-defined role for accessing and validating data. Not all participants can do everything, and three roles are defined – orderers, endorsers and committers. The alert reader will have noticed the similarity to standard business roles: orderers invoke transactions, endorsers validate and approve these, while committers agree to record these in the permanent ledger, the blockchain.
There are other differences from permission-less blockchains. A major one is access to information on the blockchain. In public blockchains such as Bitcoin or Ethereum, all transactions (and contract code) are available for inspection and, in fact, are executed by every full node in the network. However, this is a serious concern to commercial applications where contract details (such as price, discounts, etc.) are almost always kept private to the engaging parties to ensure a competitive advantage. Hyperledger Fabric provides a way for several parties to engage in a private contract through a construct called “channels”. Such parties interact over a channel whose transactions are kept confidential by preventing others from joining or “listening in” on the channel. These contracts can be added to the ledger without the specifics of the contract being revealed to or validated by anyone save those on the same channel.
Another major change is the way to achieve consensus on what to add to the blockchain. Recall that mining – solving a cryptographically challenging puzzle that requires serious computational effort – and the longest chain rule is the way for public blockchains to ensure consistency of the ledger despite potentially malicious actors and the latency inherent in a peer-to-peer network. But in a system where the actors are chosen (indeed invited) with some care, and who have a common purpose in using the system, the concerns about malice are much lower.
The aspects that initially concerned most industries were fault tolerance to node failures, power outages, etc. affecting a peer-to-peer network (of albeit a limited number of) nodes. There are well known solutions to achieving fault tolerance under these situations, where the system can continue to function despite the failure of a few nodes. However, for those use cases where it would be foolish to overlook the possibility of malicious behavior, work is underway to define mechanisms by which the system can arrive at a consistent state so long as the number of malicious nodes are below a certain threshold[1]. However, a more robust consensus protocol requires more interactions amongst the nodes which reduces throughput. Thus, Hyperledger allows a range of solutions for consensus, so that each industrial use case can choose the most appropriate mechanism for its purposes, possibly sacrificing one aspect for gains in another.
Hyperledger Fabric has separate working groups for different industry verticals, including one on healthcare.
Blockchains in Healthcare
The use of blockchains in healthcare is at its infancy, and it is difficult to find any real usage that isn’t a small trial or a concept being prototyped. However, the opportunities are wide open if the knotty aspects of HIPAA and other privacy regulations can be met. Details of specific blockchain usage are hard to come by as there are many small companies promoting such solutions that are anxious to protect their intellectual property, coupled with the bashfulness of traditional, conservative healthcare companies not eager to be seen at the cutting edge of new and untested technology. Thus, we simply provide a summary of the many examples that have been proposed or hinted at, pointing out any special characteristics of each.
One example is the use of a blockchain for recording drug supply chain integrity and provenance. Apparently, there is a lot of counterfeiting and replacement of legitimate drugs with counterfeit ones during transportation and distribution. The proposal is for each step of this process from source to ultimate destination to be recorded on a blockchain. Given the immutable record of a particular shipment, the consumer can check and verify the provenance of a purchased medication and be reassured of its origin and quality.
Another example proposed is to ensure that all data from clinical trials are accurately recorded, unaltered and made available to researchers using a blockchain. Here again, the statistics on under-reporting, selective reporting, and outcome switching suggests that a more robust and immutable record can benefit the entire industry.
Perhaps the ultimate test of the value of a blockchain in a healthcare setting is to see if it can effectively handle the issue of fragmented and incomplete medical records for a patient that are scattered in different formats amongst multiple providers that a patient interacts with during the course of her lifetime[2]. Various factors prevent easy sharing of such records, which add to personal inconvenience, increased cost and poor care. There are obvious challenges to placing a patient’s health data on a blockchain, the primary one being access control – who can read and write this data. The next one is the potential size of such data.
There are several attempts at addressing these issues. One research prototype from MIT, MedRec, uses Ethereum smart contracts to maintain a record of patient-provider relationships with stored permissions and hashed pointers to external databases where the actual data is maintained. Providers can add new data via the contract, while patients can approve sharing of these with other parties. Researchers provide the “mining” resources to maintain the blockchain, and are compensated via access to anonymized medical metadata that can be gleaned from such records.
The Center for Disease Control suggests using blockchains for public health applications, as these deal more with overall patterns rather than individual data. Rather than the current arcane forms of data sharing between different agencies, blockchains would increase efficiency and responsiveness during medical emergencies such as pandemics, or follow patterns on drug abuse usage such as opioids.
Rather than tackle the more complex problems related to privacy, there are suggestions to tackle lower hanging fruits that do not directly deal with individual Protected Health Information (PHI). One such proposal is to tackle the claims management and settlement process. Claims data pass through various intermediaries, each of which can add delays and errors. Decentralizing this by allowing appropriate participants to add claims data to a private blockchain may speed up a time-consuming and inefficient process. Another proposal is to put the directory of providers, physicians and their relationships on a blockchain. Currently, such data is only accessible through various provider web sites, which are not always up-to-date. Smart contracts could be written that update various relationships as providers and physicians enter into new agreements or change their arrangements.
Summarizing the series
We hope we have shown that a blockchain-based solution, rising from its crypto-currency beginnings in Bitcoin, has progressed to the point where every industry believes it can have some role in improving aspects of its current infrastructure. Those aspects that seem to be the most amenable to replacement are where business processes and workflows are inefficient owing to multiple intermediaries, lack of trust between partners or too much centralization.
The healthcare industry is at this time in an early exploratory stage with this new technology, but, over time, it would not be surprising if it were to find use for it in mainstream applications taking note of how the common issues of security, privacy, scalability and throughput are handled by other industries which are more advanced along this blockchain-fueled path.
[1] This is called Byzantine Fault Tolerance in the technical literature.
[2] A new factor is the enormous amounts of health data collected by personal wearables and apps, which remain locked in their respective silos and are not made available in a systematic way to the caregiver.
