Blockchain for Patient to sell their data to Clinical Research

August 17, 2018
Smart-Contracts are a very important part of blockchain. The openness of blockchain is another. I have presented a possible way to use these features of blockchain to enable a Patient to be able to sell access to their data. I include some features also enabled by blockchain, such as micro-payments and escrow for breach of terms. I think these are critical to Patient selling access to their Data, and the ability to add this is simple given the Bitcoin example of Blockchain.

This all said, Smart-Contracts are hard to write correctly, and easy to get wrong. So I think there needs to be far more maturity to the space of Smart-Contracts before they are actually controlling access to Patient data.

Patient data for sale for Clinical Research

So a patient might offer access to their data, managed on a FHIR Server, to anyone that can satisfy a smart-contract they put into a public chain. I first described over two year ago as a response to Grahame's original ask Healthcare Blockchain - Big-Data Pseudonyms on FHIR

The smart-contract would include:
  1. Upfront payment for the access (some micro-payment)
  2. Requirement for escrow of coin to be unlocked to the Patient if other terms are violated
  3. Terms of protection of the data
  4. Kind of clinical trial allowed (heart conditions, but not brain)
  5. Agreement to keep all research public
  6. Agreement to contact patient if the patient could benefit from new treatment detected
  7. Agreement to contact patient if some treatable medical condition not previously known is discovered
  8. Agreement to not contact patient if terminal condition is detected
A clinical trail that can meet these, could satisfy the contract and gain access. If they violated any of the terms, the smart-contract would automatically transfer the escrow coin to the patient. Based on some sunset term (like possibly the natural death of the patient), the escrow coin goes back to the research organization. So clearly that legal-will is important to this use-case...

How does this work? 

I have indicated that the data would not exist on the Blockchain, it would exist in some FHIR server somewhere. I use FHIR because it is http RESTful and common to protect it using OAuth using SMART-on-FHIR profile. Thus it is to the general IT world, a RESTful server protected by OAuth.

So, this specific FHIR Server, and the OAuth that is protecting it, is linked to the BlockChain. It is the one taking the results of the Smart-Contract. If the terms of a Smart-Contract are satisfied by an agent, then that agent gets an appropriately scoped OAuth token. That agent can then use that OAuth token to access the data in the FHIR server.

In this way the FHIR Server is just a normal FHIR Server being protected by OAuth using the SMART-on-FHIR profile (aka scopes).   The OAuth service is the bridge between http-RESTful world and the BlockChain Smart-Contract world.

Variants on smart-contract based on de-identification capability

It is possible that the patient publishes multiple flavors of the smart-contract. Each offering different types of pseudonym blinding: Some flavors would expose MORE information, and have higher contract requirements (like shown above). Some would expose very well de-identified data, and have less strict contract requirements.

Highly de-identified data, where ALL direct and in-direct (Quasi identifiers) are removed. Including fuzzing completely dates, patient characteristics, location, etc. If the data is highly de-identified it is less valuable for clinical trials, but it also wold not need to be as strongly protected. So it is possible for this offering the smart-contract does not require an escrow of coin.

These variants would require that the authorized access to the data enforce these variations. Thus one would need some access method to the data where the de-identification can be accomplished. This might be done by different servers hosting the various flavors, confirmed by a human statistical analysis. This might be done by some automated de-identification service as I describe in
#FHIR and Bulk De-Identification

Am I wrong?

I am very willing to hear that I am wrong. I am very willing to hear adjustments. I am very willing to hear that someone has implemented this.

Post a Comment

No comments

Subscribe to: Post Comments ( Atom )