Over September 26-27 I was a guest speaker at the US Department of Health & Human Services blockchain for healthcare workshop. It was a fascinating and worthwhile exercise, as I reported in more detail here. However, I have to say most of the presentations confirmed my view that blockchain application development leaves a lot to be desired.
Too often, blockchain-based solutions fall short of good design practice. They typically fail to set out the problem they're really trying to solve, and instead start with the working assumption that blockchain is an inherently valuable part of the end solution. In the current craze, people tend to treat blockchain is the end and not the means.
There were three noticable problems with the blockchain for healthcare proposals, taken as a whole:
- They tended to misunderstand what blockchain does. As I've canvassed elsewhere, the original Bitcoin blockchain only does one thing: it reaches consensus on the order of entries in a ledger. It does not and cannot decide anything else about the entries. And so it does not have a lot to contribute to the health IT problem of interoperability.
- They tended to overestimate blockchain as a database. Several papers submitted to the workshop claimed blockchain could help federate the many disparate and siloed health information repositories, improving on the probematic Health Information Exchange (HIE) model. However, as the workshop progressed, all parties agreed that the blockchain should not be used to hold significant health data, because it's public by nature, and limited in capacity. So if blockchain isnt going to store health data, it cannot help shift health data from its current silos.
- And none of the blockchain papers tackled the challenge of key management. When permissions and confidentiality need to be layered on top of the core blockchain, and the necessary key management arrangements are inplace, the distributed ledger technology actuallt becomes inconsequential.
If distributed ledgers hold some promise in e-health, there needs to be a clear problem statement and a stronger R&D pathway, to take us from the first generation prototype blockchain, to second and third generation DLTs and beyond.
I have published a new research report seeking to improve how blockchain-related R&D is conducted.
The ad hoc way in which permissions and encryption is added to blockchain is just one example of overly hasty "innovation". In the rush to apply blockchain to mainstream applications, few entrepreneurs have been clear about the problems they think they’re solving. If DLT R&D is not properly grounded, then the resulting solutions will be weak and will ultimately fail in the market. The original blockchain was truly only a prototype; greater care is needed to reliably adapt the first generation algorithms to enterprise requirements.
The report examines four strong research organisations in this space: the Hyperledger Foundation, Microsoft's Azure Blockchain as a Service, the banking industry joint vernture R3, and Ping Identity with its investment in the startup Swirlds.
If your organisation needs to conduct its own R&D then the following checklist can help you stay on track:
- Do you have the equivalent of a Double Spend problem? If the order of transactions is not critical or if it’s not really possible for assets such as physical objects to be exercised twice, then the original blockchain is probably not a natural for your use case.
- Are your assets purely digital or do you have physical assets that need mapping onto the ledger? Any mapping or translation of physical assets onto ledger entries logically needs to be done off-ledgewith authority structures that erode the pure blockchain architecture.
- Do you need immutability? The degree of permanence provided by the public blockchains is rarely needed in conventional business, and may not be worth the cost.
- Does your environment have administrators? Blockchain was expressly designed for a special case where central admin is banished. Conventional business lines of command and authority structures can be at odds with the blockchain consensus algorithm.
For more information, a snapshot of the report is available here.
