Notes on "Blockchain and Health IT: Algorithms, Privacy, and Data" whitepaper (1 of 15 in the ONC blockchain series)

I read through Blockchain and Health IT:Algorithms, Privacy, and Data , a whitepaper prepared for the ONC* and re-invigorated my enthusiasm for blockchain in Healthcare.  The authors start with the growing awareness that current centralized databases "cannot assure security and data integrity, regardless [of] de-identification and controlled access requirements." And, they suggest that "Safe, vetted queries that are distributed to private, encrypted databases assure that organizations and participants can share health care data with cryptographic guarantees of privacy with various stakeholders, assuring momentum for a new era of medical research and practice." Sounds good.

They propose that an MIT platform project called "OPAL/Enigma" provides a blockchain-driven, secure environment suitable for healthcare data.  Furthermore, they suggest that the platform will improve interoperability and reduce time and cost of utilizing infrastructure to analyze and process data that supports clinical trials and development of drugs and treatments.  In short, the OPAL/Enigma platform (and other blockchain solutions) end the legacy of centralized healthcare databases that are essentially (my thoughts inserted here) large safes of gold awaiting a hacker's demonstration of safe-cracking (and/or people-cracking, termed "social engineering") skills.

One of the core concepts to the security and privacy mechanism in this solution is that "significant security compromises would require consensus" among the ledger holders. In layman's terms, I assume that this plays out like this:
Bad Actor: "I want to get to this record on Ben Franklin's Syphilis treatments and sell it"
Ledger Owner (a computer somewhere in the world): "Are you entitled to this record?"
Bad Actor: "Yes"
Ledger Owner: "I'm going to ask 1,000 other ledger co-owners if this is true."
Bad Actor: "You're a bit of a nuisance."
Ledger Owner: "I asked around. You're not entitled to this record. And, I've logged your request"
Bad Actor: "I bet you're not much fun at parties."

My summation of this is that, in this case, the hacker's-gold is distributed all around the world and requires multiple key-holders to turn their keys in order to release the data.

So, how do the "good actors" get to the data they need?  This occurs through "smart contracts". These are electronic contracts that govern access, use, payment, and other terms for use and operation of the shared infrastructure and data. I imagine some possible smart contracts, such as:
1.) Provider: contract to view, and update patient record (IF the patient has consented)
2.) Health system business office: contract to view patient record (again, with the patient consent)
3.) Patient: contract to view, update certain portions, and request changes from provider for other portions.
4.) Patient's sister: contract to view data and message with provider team
And, so on.  These smart contracts would also be spread across the blockchain ledger ecosystem for integrity enforcement.

Should the health system need greater access to a repository-like bucket of data, then smart contracts would govern allowable queries of the encrypted data, and in many cases these queries would return only de-identified data as governed by a usage agreement.

The authors reveal a bit of Enigma's security framework that includes concepts that quickly suck us into an ooze of vocabulary that becomes more and more difficult to learn. The ooze includes terms like "secret sharing", "multiparty computation", and "Proof-of-Multiparty Computation" that lead to even more complex topics such as, "reverse cryptographic computation", "ciphertext pieces, called 'shares'" and "reconstitution of data".  At this point, I have to just believe what they say until I can prove it through further understanding; it's more secure than what we have today in healthcare. I guess this is the equivalent of saying, "I've heard a few people on the internet say..."

Note, that I (and the authors) used the word "ecosystem" above. This is because the people who provide computing resources for the distributed blockchain ledgers of data are remunerated for their participation. The data is of value and so are the networking and computing assets used to manage it. Here is my un-educated guess about how this works:
1.) My healthcare system sends a share of my data into the network which ten computers pick up and store.  Let's say it's my allergy list and it's completely garbled based on an encryption key not held by those ten computers.
2.) Ten computers log to the distributed ledger that they have the data. (I'm guessing here. Maybe it's not this simple)
3.) The ten computers collect a microfee for storing the shares (some fraction of cents, maybe)
4.) If the share is accessed later by someone holding the appropriate smart-contract, some or all of those ten computers will collect another micro fee.

Now, here's where it gets even more exciting. What if we want to learn from aggregated data without exposing it? The MIT Engima platform provides a "multiparty computation" (MPC) construct that provides for this.  So, if my health system wants to know how many diabetics are behind on getting blood glucose tests, it can submit the query and get an answer without ever calling back or storing the large data set that exists on the patients.  These queries would be pre-vetted as allowable and "safe" in preserving privacy. Then, given the right smart-contract, the health system could also get more specific as to who the patients are and their routine primary care provider once they've processed the first query. And, again, multiple computing nodes, called peer-to-peer (P2P) nodes, across the world (or across the established network) would need to confirm the identity of the query requester and the terms of the smart-contract. Sounds bullet-proof, right? I couldn't say, really.

Imagine this additional scenario in the population health realm. A patient signs an electronic smart-contract which includes a clause allowing his/her de-identified and aggregated data to be accessible for public use. A pre-vetted query is submitted by a panel of experts and submitted into the ledger system for any contract holder to use. Maybe this particular safe query is to see all body-mass indexes (BMIs) and zip code of any patient who signed the contract.  This would allow just about any researcher, health system, insurer, or BMI obsessed blogger (who has an appropriate smart-contract) to run reports on BMI trends across the planet and cross-match it with other data sets on zip codes of fast-food chains and hot-yoga sweat lodges.

Here's an excitement killer though. The authors warn that the limitations of the OPAL/Enigma solution include "a lack of standardized APIs (application programming interfaces) in the healthcare IT relative to other industries." Oh yeah, there's that.  Personally, I think our healthcare application vendors better get on it. And, many of them are doing this with new projects using the FHIR (Fast Healthcare Interoperability Resources) interoperability standard, but also required is storing and manipulating the back-end data from their products such that the data can easily be retrieved through APIs.  This is a lot of work so bring on the multi-million (billion?) dollar investments.

To recover from that excitement-killer, I'll regale you with a new possibility for healthcare infrastructure. The blockchain ecosystem could expand, on-the-fly, to provide more computing resource as you need it. Too many providers accessing the data? No worries, additional nodes could automatically start participating in your network, given the proper smart-contracts are in place. Then, they scale down as demand slows. All at a cost, of course, but with the right contract could cost less than over or under-specifying a large data center full of processing and storage power. If it doesn't then we'll have a problem.

I use a fixed-cost (relatively speaking) population health analytic system today, and I can tell you from staring at a spinning hour-glass (actually, it's a circling bracelet thingy) for ten minutes at a time that an automatic scale-up of computing resource might be worth an extra, on-demand cyber-fee.  What if our Health Information Exchange (HIE) could automatically add lab interface messaging nodes when the network became congested in the morning?

The MIT folks (the authors) also add some more icing to this cyber-cake.  They are working on a clinical trials platform that is driven by this smart-contract, blockchain infrastructure.  Organizations that enter into a contract could query a clinical trials blockchain ecosystem for patient eligibility and submit tolerance, response, and outcomes data for those patients that participate. Other contract holders could issue the statistical analysis needed to make sense of all the aggregated and encrypted data in the form of safety and outcomes reporting. And, it's worth mentioning, that this ecosystem would keep a ledger of every query and querier (MIT uses this as a word , so there it is) for future audit. I imagine, and this is purely my rumination, that there could also be rules in place to detect if query patterns are worrisome. At any rate, MIT is proposing that this clinical trials implementation could be a solution in support of the White House initiated Precision Medicine Initiative.

The good news for me is that MIT proposes Enigma and OPAL as open source projects. Which means, at some point and in my not copious spare time, I can play with Enigma. If I'm smart enough.
_______________________________________________________
* Article cited above and throughout was Prepared for: Office of the National Coordinator for Health Information Technology U.S. Department of Health and Human Services Prepared by: Allison Ackerman Shrier, Anne Chang, Nadia Diakun-thibault, Luca Forni, Fernando Landa, Jerry Mayo, Raul van Riezen Project PharmOrchardTM of MIT's Experimental Learning "MIT Fintech: Future Commerce" & Thomas Hardjono MIT Connection Science . August 18, 2016.  Prepared for Office of the National Coordinator for Health Information Technology U.S. Department of Health and Human Services

15 NIST sponsored whitepapers on blockchain for healthcare

See HIMSS article for 15 whitepapers submitted to describe uses for blockchain in healthcare. And, see here for ONC posting of the articles: http://www.hhs.gov/about/news/2016/08/29/onc-announces-blockchain-challenge-winners.html

Coding a Blockchain application for healthcare information exchange

Let’s take some sample code from the BlueMix site which was reposited on Github:

(https://github.com/hyperledger/fabric/blob/master/examples/chaincode/go/chaincode_example02/chaincode_example02.go)

And see if we can hack it into a healthcare information update chain. Daunting.

I believe this is js.Node . I've never done js.Node before.

/* TODO: BUT, HOW DOES THE LEDGER KNOW WHAT INFORMATION I AM TRADING?

In this example, I am simply coding the information into a variable that I trade into the blockchain.

So, I supposed that if we all agree on code standards (say HL7, C-CDA standards) then all we have to do is get the data in and out using C-CDA standards.

*/

We can just look at the beginning of this code and see that it will not help me with my goal.  It is informative though. This code trades quantities of only one asset.  It subtracts a qty from entity A and gives it to entity B , verifies the transaction, and closes the ledger state for these entitites. What I want to do is trade information. I want to add information to entity B (the patient) and credit entity A (the practice) for providing the information. (or maybe in "debiting" Practice A, I'm noting for the practice that it submitted the information) The code referenced above is strictly for an integer subtraction from one entity and addition to another entity. I'll search for another code example so that maybe I'll have a better starting place for modeling healthcare information exchange in the Blockchain universe.

Coding a Blockchain application for healthcare information exchange

Let’s take some sample code from the BlueMix site which was reposited on Github:

(https://github.com/hyperledger/fabric/blob/master/examples/chaincode/go/chaincode_example02/chaincode_example02.go)

And see if we can hack it into a healthcare information update chain. Daunting.

I believe this is js.Node . I've never done js.Node before.

/* TODO: BUT, HOW DOES THE LEDGER KNOW WHAT INFORMATION I AM TRADING?

In this example, I am simply coding the information into a variable that I trade into the blockchain.

So, I supposed that if we all agree on code standards (say HL7, C-CDA standards) then all we have to do is get the data in and out using C-CDA standards.

*/

We can just look at the beginning of this code and see that it will not help me with my goal.  It is informative though. This code trades quantities of only one asset.  It subtracts a qty from entity A and gives it to entity B , verifies the transaction, and closes the ledger state for these entitites. What I want to do is trade information. I want to add information to entity B (the patient) and credit entity A (the practice) for providing the information. (or maybe in "debiting" Practice A, I'm noting for the practice that it submitted the information) The code referenced above is strictly for an integer subtraction from one entity and addition to another entity. I'll search for another code example so that maybe I'll have a better starting place for modeling healthcare information exchange in the Blockchain universe.

Coding a healthcare application for Blockchain

I usually have to dive right in if I'm going to understand something.  So I found some sample code via IBM BlueMix to read through.

Here is the first application I will try to create:

1.) Identify a patient using a cryptographic entity identifier.  Imagine that I have an application on my phone. I used it to connect to the Blockchain Healthcare Network (BHN).  The first time I did this, it issued me my cryptographic identifier that I stored on an application on my phone.  We won't bother talking about how this is kept secure. That's for a later discussion.

2.) In the case of this example, the identifier I discussed above will simply be a hard-coded key that is provided by BlueMix.

3.) I pretend I am a healthcare primary care provider that has co-identified me when I came to the practice (e.g., I log into my phone, open my BHN key application, and show them my QR code and they scan it in.)

4.) They prescribe/order me to take 1 Ibuprofen

5.) I leave and the practice submits this new medical information to the BHN

And, it's a transaction for the ledger.

So, here are the steps I believe will happen:

1.) Practice entity identifier is submitted to the blockchain.
2.) My patient entity identifier is submitted to the blockchain
3.) The transaction is this:

• Credit Patient's ledger with an Active Medication called Ibuprofen, quantity 1
• Debit Provider's ledger which indicates the practice has issued the unfilled prescription
• Verify the transaction is legitimate (not sure how this part works but it uses hundreds of "volunteer" computers around the world who get a micro-fee for providing their infrastructure)
• Close the transaction for these entities

Simple, right?

Hypothesizing on applying Blockchain to healthcare

Okay, so it’s a ledger that's "secure" and "transparent". hmm. http://blogs.wsj.com/cio/2016/02/02/cio-explainer-what-is-blockchain/

I must come up with a transaction that adds from one side of the ledger to the other and/or subtracts from one side to the other.

Once the transaction is complete, I must make sure the ledger is reconciled and auditable.

How would we put this to use in healthcare?

I assume, possibly wrongly, that the transaction for healthcare would add to a person’s healthcare record or subtract from it.

In other words, I am adding healthcare information to Person A’s record and taking it from the provider that Person A saw?

I’m not sure that is correct but let’s try a use case.

Person A goes to Practice Z and is administered drug Ibuprofen.  My blockchain transaction would look like this: Add drug Ibuprofen to drug list ledger of Person A and subtract drug Ibuprofen from drug order list of Practice Z.

This doesn’t make sense to me unless the ledger already has a record of Practice Z’s drug orders. I think I may be hung up on my far distant knowledge of double-ledger bookkeeping. In double-ledger bookkeeping, every addition to one account must correspond to a subtraction from another account. This doesn’t seem like a starter.  Time to go back and do more reading.

Blockchain Tools

I went searching for blockchain tools. I really wanted to find something on Google Cloud Services but came up empty. Then I did a cursory search for Amazon Web Services Tools. Maybe I'm a bad searcher.
I like Ethereum because I'm a big open source fan but I was wooed away because IBM provides all the infrastructure in the magical thing called "the cloud".
So, I went to IBM's BlueMix and started some wild and somewhat uninformed attempts at setting up my blockchain service.

Blockchain for healthcare data hypothesis

After reading a pitiful small amount about blockchain, I am proposing this hypothesis about how to use it for managing a nationally available,  secure healthcare record. Then I will do more reading and experimentation to disprove or not disprove my thesis.
Hypothesis: I can setup a demonstration blockchain economy that allows healthcare and patient entities to add to, decrement from, and audit (or read from) patient health records stored in a blockchain ledger.
Secondarily: it's all secure and robust
Thirdly: there's an easy way for a patient to provide his/her entity identity, securely with a token. Wow. Now we are stretching.

I am not the first to propose this use case, just the most ignorant.  Soon that will all change.