I've had someone pitch the same blockchains-as-EMR to me, and they made the same mistake of construing data integrity with data security.
Blockchains are public record, which you do not want your health data stored in. Even this article acknowledges that and recommends using private blockchains, which offers no competitive benefit over other decentralized databases.
This just seems like another hammer looking for a nail.
You are describing the Merkle Tree which is not unique to the blockchain and existed some time before bitcoin. This isn't an argument for bitcoin it's an argument for the Merkle Tree.
Tierion anchors the root of a Merkle Tree made up of all inbound records every 10 minutes into a Bitcoin transaction. With that root in a Bitcoin transaction, you can use a portable cryptographic proof (Tierion calls them blockchain receipts) to validate the integrity of each record at a later point in time.
The Bitcoin blockchain is a global immutable data ledger that makes for a great place to anchor hashes to.
Okay, that is not blockchains for healthcare, that is third party validation for hashing. You're just storing the validation in Bitcoin's public network instead of your own secure servers. There are problems with this:
- You can't guarantee which block the transaction is on [1], which means all your customer encryption is asynchronous (slow).
- Your customers are assuming that you're keeping your private keys safe, which is not any different than trusting a non-bitcoin verification provider.
- The first quantum computer is going to destroy ECDSA, meaning your private keys will be reversed and every health product depending on your service will be trustless. Merkle trees can theoretically be used in a post-quantum world [2], but the method by which you're generating the root for the tree is not safe because you're relying on a network you don't control (Bitcoin).
Just because the bitcoin wiki says it, doesn't make it a good prediction. Experts also used to say that a computer couldn't beat a Go Grandmaster until 2030.
The other points are still problems of using bitcoin right now.
A more interesting application would be storing health "meta data" - for example, permissions around viewing health data, or focused data like advanced directives ("code status"). For advanced directives, this could be really valuable to guarantee that disparate health care systems that don't share data are aware of your wishes.
That's just an exercise in signalling at this point, and as far as I'm aware, there aren't many issues with the current implementation of advanced directives. In fact, the few U.S. healthcare systems that implement advanced directive programs are working surprisingly well [1]. Hammer -> nail.
The point is that advanced directives should not be tied to a specific healthcare system. Decentralization (blockchain or otherwise) is an interesting way to make this more accessible.
Practically, advanced directive knowledge requires verbal confirmation with the patient or healthcare proxy; or something like a MOLST (paper).
Frankly, you get most of the claimed benefits of blockchains by just putting the transactions in git, which is very fast and efficient, and there's a ton of tooling relating to copying git repos around and using the hashes in them and so forth. And doesn't use as much power as Ireland.
As a clinician, I'd love a way to see all the past health records of any patient that walked in the door. They usually would love for me to as well.
I'm not sure how blockchain as a technology necessarily moves us forward to get there. The vendors have a stranglehold on medical record software and have no incentive to work together, share data, or agree to any standards -- I mean, it wasn't until last year that the two hospitals I work at (owned by the same umbrella hospital, using software from the same vendor, and 3 miles apart from each other) could electronically access records from each other. We had to fill out paper forms, make phone calls, and send faxes to get access.
It's not for want of a technological breakthrough that we've been struggling so much...
Having worked previously in the healthcare sector (both USA and AUS), I must agree. There is zero incentive for vendors to work together to share patient data.
There is a standard for medical data already called HL7, but not everyone adheres to it.
What would work better is if the medical record is a service provided by the government or some public service which takes care of security for you.
Every medical record would then be added to the patient's blockchain record and vendors can read/write to it.
Of course a vendor would have to vetted for security purposes.
Agreed. I carry all of my health records on a very small USB flash drive in my pocket. Every time I show it to a doctor, they are scared to plug it into their desktop for fear of malware.
Amusingly, I work with a rather large organization which still buys machines with PS/2 keyboards and fills the USB ports with epoxy. This is the state of security.
Something I wrote a while back about this [0]. To summarize, it's not the lack of technology, rather it's the financial disincentivization of vendors and lack of leadership by providers.
My proposed solution is government regulation in order to level the playing field by way of EMR certification and/or tax-centivization. The goal should not be to pick a standard but rather set the rules:
- if you create data you offer public docs and/or SDKs to grok that data
- if you store data you offer public docs and/or SDKs to access that data
I hear this from all over the world, and I honestly don't understand it.
Or rather, the only way I can see this happening is that everyone, everywhere on the buying side is either actively doing harm or so incompetent those are indistinguishable.
The arguments that "butbutbut, all vendors require us to do X and never let us do anything" got to be bullshit. If you have sexy multimillion medical project that needs vendors, and some of them won't take it if they can't force you into submission, I have no doubt that the million other companies in the world would take the project more than gladly.
As a general problem, when you want to give your vendor the boot, you go to their competitors and say you want a system that does all the things the old system does plus these additional requirements that the old vendor couldn't give you. Since you probably paid for additional features year over year for the system you do have, the price tag to replace it all at once is rather steep and the timelines will be incredibly long.
As such, the project will have a rather long list of problems. The functional specification of the system to be built will have a large number of gaps because the people writing the functional specification aren't the people using all of the parts of the system (no one person will be using all the functionalities). There will be a number of unforeseen problems causing delays, if the vendor does not have proper risk management in place the delays will compound and the entire project will become delayed. Due to frustrations, the customer will relax the priority of some of the nice-to-haves from the functional specifications and focus on the critical requirements.
Even if the new feature makes it into the end product, since it wasn't a key requirement of the system in the first place (otherwise the first vendor would have provided it from the beginning) it will most likely not be used often and may not even be piloted. Future upgrades to the system will degrade the functionality in unpredictable ways and no one will notice. When someone does notice, it is easier to revert to the old manual way of solving the problem than getting the functionality fixed or learning how to use it.
This is why some people are scared of replacing multi-million dollar software. That is why banks still have a lot of systems written in COBOL, risk averse people aren't willing to hope that everything might go right.
I implemented a few exchanges. We had the legal requirement to record all changes. For liability. What did you know and when did you know it kinda stuff.
Tamper evident transaction logs (rolling hash) were sufficient.
I don't quite see what blockchains (proof of work, consensus protocol) would add.
Is there a use case for tracking prescriptions? Not a provider, so I'm just guessing.
EMR systems are mainly constructed to solve financial needs not medical ones. (Mainly because they are the ones paying for the system)
Sharing medical information from providers out of network is not of much value for this purpose, so it does not goes up on the priority list.
Part of the challenge is that the word blockchain is misused. Here's a quote from the first page:
“…the term ‘blockchain’ has been so misappropriated that no one knows what it means anymore.”
– Elaine Ou, Bloomberg
People are using blockchain to describe Bitcoin, private ledgers, the public Ethereum network, private Ethereum forks, and other tech that shares design characteristics with Bitcoin.
I read through this and I still have no idea what they actually applied the idea of the blockchain to within healthcare. To an HIE? Does each patient receive their own "wallet" that is their patient record? This just seems to be a generic overview of EHRs/Blockchains within the same page.
Thanks for reading the report. This last weekend there was the first Blockchain Healthcare conference where blockchain was pitched as a panacea for a wide spectrum of healthcare problems.
Our report was targeted at a non-technical audience. Printed copies were distributed to about 500 attendees. We wanted to make them aware that while there may some opportunities for using blockchain technology also comes with substantial risks. We want to help them cut through the hype and maintain a healthy dose of skepticism.
Gartner recently placed blockchain technology at the beginning of their hype cycle.
You could, but a relational database isn't distributed upon 5,000+ worldwide nodes in an immutable data ledger. That's the value the Bitcoin blockchain provides, it allows you to stick data into a transaction that will be there forever. The Bitcoin blockchain provides an economic incentive to keep the data accurate and accessible, as it would be (near) impossible to pull off a 51% attack in todays day and age.
Many databases can be modified by the ones who centrally operate it. The Bitcoin blockchain is the worlds first distributed global database that takes the burden of trust off your internal systems and records.
No; using the Bitcoin blockchain to store medical records is a terrible idea.
Yes, they are robustly distributed on each of 5,000 worldwide nodes.
But, think about that!
How's that going to work for 10 million patients' MRI records? Each MRI being a series of high res images?
That's not possible with Bitcoin - its not designed to store near that quantity of data - its not even desirable.
I don't know what the advantage of Blockchain is with healthcare, but its certainly not storing your medical records on the Bitcoin blockchain. [Standard disclaimers about predicting the future apply.]
Maybe a hash of them, so you know they aren't tampered with, or that sort of thing - but that seems like a second order problem.
No one is advocating putting medical records on the blockchain. That's crazy.
He's talking about using a technology like Tierion or Chainpoint to anchor a hash of the data in the blockchain. This can be used to verify the integrity and approximate timestamp of the data.
Should have been more clear. No records should be stored on the Bitcoin blockchain, only a hash of the data. Using a service like Tierion, a hash of your data is anchored into the Bitcoin blockchain, and Tierion gives you back a blockchain receipt. That blockchain receipt is a cryptographic proof that can be used to verify the integrity of that data at a later point in time.
I still don't see the point in a 'permissioned blockchain' without proof of work. If you just put Paxos / Raft / any other consensus protocol on top of a 'blockchain', all you're basically doing is reinventing distributed databases.
Is this a trustless system? If so, what is the game theoretic aspect of it, what nodes do the mining and what are their incentives? If it is not, what prevents you from implementing a traditional distributed system with traditional consensus protocols? I'd wager that traditional methods are much more performant than the BitCoin blockchain in that scenario.
I am pretty sure that Gmail database is 1000x times larger than all non-imaging healthcare data for entire population of the world.
There are instances where blockchain type technology is useful such as transactions between multiple parties with lack of trust. This isn't true in healthcare and surely not for EMR/EHR data.
Blockchains are like scrolls: you can write information on them that a society can use to coordinate current actions based on the past. You don't want a scroll for your medical records. You want a journal that can't lose data and can safely give access to any app you want to install without losing privacy. That sounds more like Urbit than a blockchain.
Blockchains are public record, which you do not want your health data stored in. Even this article acknowledges that and recommends using private blockchains, which offers no competitive benefit over other decentralized databases.
This just seems like another hammer looking for a nail.