Blockchains, healthcare, and platform neutrality

Blockchains have been proposed as a way to enable health data interoperability while empowering patients and preserving privacy. There’s great work underway in this space, and that shouldn’t be lost. However, a core benefit of blockchains in healthcare that has been under discussed has been platform neutrality.

A brief introduction to platforms

Broadly speaking platforms provide underlying core components that are used by their participants either to perform some sort of activity (e.g send a Tweet, post a photo, etc) or by third party businesses and developers to build higher layers of abstraction on top of (e.g applications, analytics, etc). Platforms are dynamic ecosystems often initially driven more by the participants than the creators, and the activity on top of a platform provides complementary value to the platform, as well as the other participants. Android and iOS are platforms for mobile applications, Facebook is a platform for social content as well as applications, Ethereum is a platform for smart contracts, and so forth.

Platforms have varying degrees of openness. Ethereum is arguably the most open platform in history. Anyone around the world, with the right knowledge, can use Ethereum and build on applications or a business on top of it. Platforms like Facebook are more closed. In order to use or build on top of Facebook you have to with their terms of service, and they have ample ability to remove you if you cross their rules. Facebook owns the infrastructure, and as such they can change the rules or choose how they are enforced in an opaque way, and users have little recourse.

The life cycle of platforms

Chrix Dixon in his seminal “Why Decentralization Matters” outlines the lifecycle of platforms. At the beginning of platforms’ lives they have huge incentives to recruit users as well as 3rd parties like businesses and developers for the complementary services they can provide. As the platforms grow their control over those using them also grows, and critically there is eventually a threshold where the marginal benefit of each additional user, business, or developer begins to decline.

It is at this peak that the relationship between platforms and their participants changes from positive-sum to zero-sum. The path to growth changes from attracting users to extracting value from them, and from cooperating with third parties to competing with them. For users this means further monetizing their data, and for businesses and developers it is ruthlessly competing with them for audiences and profits. One way this is done is by changing the rules to suit their interests, and we see this play out time and time again across domains, whether it’s with Facebook kicking off Zynga, Google and Yelp, Twitter and 3rd party clients, or 23andme and its potential competitors.

Platforms in healthcare and their point in the platform life cycle

Healthcare IT has been notoriously closed in the US. A fragmented landscape as well as maligned incentives contributed to and exacerbated this problem, and it is only in the past few years we’ve begun to see the emergence of platforms in healthcare:

These are all somewhere at the beginning of the S curve above, with varying levels of user and third party adoption. There has also been promising adoption of open standards like FHIR . However, let me be unequivocal about this: open standards alone do not translate to open platforms.

Open standards alone do not translate to open platforms.

Even in their nascent state several healthcare platforms are highly restrictive. For example, the Epic app store’s API is mostly limited to reading data, with little ability to change or write data. While this is good for analytics, it stops short of deeper integrations, such as altering work flows. Moreover, Epic vets every application and decides which apps they will allow or disallow to exist on their platform. Not only do they review each app, but Epic also wants to know the details behind each app’s technology, stoking fears that Epic might adopt the best ideas of innovative or popular apps.

More deep integrations have mixed results. In one survey 83% of companies with integrations to an EHR said having a large provider as a client was necessary to engage Epic in a conversation about accessing data. Cerner and Allscripts were 69% and 21% respectively. A loud minority (n = 21, 39%) felt that their contracts with EHRs had troubling terms, such as byzantine IP policies, prohibitive costs, lack of API end points, or being forced to give insight into their technology. That’s not to speak of the difficulty integrating in the first place. Lastly, the terms of service and pricing of these services has been less than desirable, though there are notable exceptions and this has been improving.

Overall growth and maturation of healthcare platforms has been slow compared to other industries, but we have good reason to believe that’s changing. Condensing a lot into one sentence: payment models are shifting from volume to value which necessitates interoperable digital infrastructure, and patient empowerment, particularly over data, is part of the zeitgeist of this moment. Consumers (and venture capitalists) agree, 87% have adopted at least one digital health tool and a staggering $8.1bn was invested in digital health in 2018.

Healthcare platforms will not prove to be an exception to the historical rule. Eventually the relationship between platforms and their participants turns from positive-sum to zero-sum. It is at that point that platforms seek to extract value from their participants. Given their historically closed nature, and the restrictive stance already taken by these platforms, we should pay heightened attention to this rule. How might we be able to escape this bait and switch?

Blockchains provide neutral platforms

Blockchains are complex, but in short, they combine cryptography and game theory such that the network of computers reach consensus on a single state. In the Bitcoin network this state is essentially a ledger of who has what amount of Bitcoin. Other networks, following Ethereum’s lead, have extended this state beyond money to support more general applications. We can think of Ethereum as analogous to a single virtual computer which has its own database (state) and which autonomously runs programs (smart contracts).

What’s unique about blockchains is that they provide strong assurances of trust. You can expect them to execute the rules of the network consistently and objectively, and this is deeply rooted in the verifiable cryptographic and mathematical properties of blockchains. These properties hold true even if individual participants act dishonestly and try to co-opt a blockchain for their own purposes. Furthermore, blockchains are able to achieve this without any trusted parties, which is why we call them decentralized.

Furthermore, a blockchain’s community governance ensures it stays neutral and open over time. Communities of enthusiasts, participants, or businesses maintain an open source code base that allows anyone to participate as well as propose changes. Governance of blockchains varies widely but critically they all provide both exit, by forking the protocol, or voice through on-chain upgrade proposals as well as off-chain formal/informal social structures. I’d argue that the best governance mechanisms share the principles of community participation, rule based systems, and transparency. These factors all seek to keep the platform in check as it grows and powerful parties might seek to influence abuse their positions.

The role of a blockchain EHR platform

Seen in this way, the value of a blockchain EHR platform is not only connecting disparate parties and giving patients control of their data, but also providing open and shared infrastructure that participants can trust they can build on. Going a step further we should think of EHRs in layers. The base layer of an EHR, the storage of data and identity management system, is the most important to decentralize. Critically, this layer must support open APIs leveraging open data standards like FHIR to ensure interoperability as well as the best experience for developers. Data could be managed in a system similar to MedRec’s architecture, where smart contracts encode relationships between participants and are used to locate and authenticate access to data. As an intermediate step data could remain on proprietary databases, but in the long term storage on decentralized file storage systems like Filecoin or IPFS is desired.

Other aspects of EHRs, such as billing, clinical decision support systems, PHR interfaces, work flows, etc do not necessitate the same level of decentralization. Instead they should be built as applications on top, or interfacing with, the underlying blockchain platform. There would be multiple competing implementations of common applications, and individuals would be free to choose whichever one best suits their particular environment. The benefits of having multiple frontend applications interfacing with the same backend is the subject of the next article in this series.

SMART and platforms

In spirit this is similar to SMART, a project run by Boston Children’s Hospital and Harvard Medical School for “Substitutable Medical Applications, Reusable Technologies.” SMART is itself a standard built on top of FHIR and focuses on formalizing how apps would interact with EHRs and standardizing an authentication model. As the name suggests, SMART aims to foster an open ecosystem of substitutable applications that can be plugged into any practice instantly. To that end they offer an “App Gallery” (not a store!) where you can view different applications built using their standard, and which, if your EHR supports it, you can use.

It is no fault of their own, but this is where SMART falls short. The assumption that platforms will support their standard is not at all guaranteed today, and in the long term healthcare platforms are bound to go through the same lifecycle as others have in the past. Although platforms may support adoption today and begrudgingly open up, eventually the relationship always turns from positive-sum to zero-sum. And at that point platforms will become hostile to SMART and its ecosystem. Again, open standards alone do not translate to open platforms. In order for SMART to work we need a neutral platform to build on.

Why this matters

A neutral platform is the perfect landscape for a blossoming of innovation. It provides shared infrastructure to build on top of coupled with hard assurances that the rules of the platform won’t be suddenly changed. We can achieve this goal as well as empowering patients to control their data with blockchains. Such a platform is critical as technologies like artificial intelligence, cheap genomic sequencing, and ubiquitous IoT come to life in very real ways. These are paradigm defining technologies, and with the status quo we risk letting a single, or a small group, of companies shape their development and reap their benefits.

I should also note that a blockchain powered neutral platform for health data represents the end state of blockchain in healthcare development. There are many steps required to get to that end state, several of those steps will pose immense social and technical problems. Nonetheless, I earnestly believe that we should move towards this end state and it is something worth fighting for. I hope you do too.

If you liked what you’ve read, I’d really appreciate a follow and round of applause!

I curate a weekly newsletter called Beyond Blocks that seeks to bridge the gap between blockchain and healthcare. You can sign up below:

Thank you to Vince Kuraitis, Bedie Moran, Robert Miller Sr, Tim Robinson, Mark Waddle, and Philip Xiu for providing their feedback on this article and earlier iterations.