Speaking as a practicing U.S. physician, one of the biggest barriers to quality care is lack of timely communication between various providers of health services. Remarkably, the advent of electronic health records (EHR) has made this problem even worse, as pertinent information about patient care is buried in reams of redundant filler information, each EHR vendor uses proprietary data formats incompatible with other vendors, and regulations regarding privacy restrict the flow of information, all to the detriment of quality, timely patient care. Also, the complexity of EHR and the ever-changing regulatory and insurance environment make it impossible for individual practicioners to customize their UI to maximize their effectiveness. There is no centralization or standardization of even the most fundamental medical data structures.
I think that a Distributed /Encrypted EHR system could solve this problem, if it were widely adopted. The advantages I see are firstly that electronic information would be highly encrypted in a distributed blockchain-like structure, thus it could be accessed easily from anywhere but only by providers with the keys. This would solve the communication piece while maintaining privacy. The open source project development would allow for both standardization of medical data structure and customizability of UI. The exorbitant cost and waste of multiple incompatible proprietary systems could be eliminated, and quality metrics would become more accessible to patients and payors.
It would be great to hear from others about how to implement such a project.
4 ·
Comments
@static_variable? have you ever heard of HL7? It's what most every EHR and other health systems (including Epic) uses to communicate and it is very well standardized. That said, it's a HUGE spec, most systems only implement parts, and there is always interfacing to be done to map how one establishment chooses to use the available fields versus how others want to. It's not perfect, but to say "each EHR vendor uses proprietary data formats incompatible with other vendors" is not quite true in my experience. Imaging and other test outputs aren't handled nearly as well as text, but it's generally all there in a reasonable format.
I don't think storing documents on the blockchain is a good idea or what has been intended while designing ethereum so far. It can be used to coordinate an incentive system for others to store and make it available in other ways, but by and large the data itself should not be stored in the blockchain as far as I understand.
Here is what I am thinking for D/E EHR. The blockchain is a ledger of transactions. But instead of financial transactions, transactions here are individual clinical events. So, if someone does a potassium blood test, the date of the test, the provider ID (NPI), and the numerical result enter the distributed blockchain. If a new medication is ordered, the date, NPI, NDC, and instructions enter the blockchain. The blockchain would not store documents, it would store a ledger of encrypted data, and the data can only be decrypted and read by authorized providers with keys in compliance with HIPAA regulations, and by using offchain client applications that would be analogous to a "wallet".
My point is, right now if provider A uses NextGen and provider B uses Allscripts, yes they can both generate HL7/CCD files, but there is no easy way to share these and comply with HIPAA regulations. Implementing D/E EHR before and after each encounter would make the use of HL7/CCD automatic, routine, secure, and more robust. In other words, the blockchain of this implementation would be the glue that binds together all the disparate health information systems and make them seamless.
How to incentivize this project, how to implement the keys, how to integrate offchain clients with current software that supports HL7/CCD, and whether Ethereum is even the proper vehicle, are all open questions at this point. I invite any and all readers to comment, question, critique, or supplement this general outline.
I believe that if this could be implemented and fairly incentivized, it would be a huge step forward both in providing quality care and lowering the cost of care. It would be akin to removing blinders from the eyes of healthcare providers, whenever there are multiple specialists or facilities involved. It would open the door to vastly improved quality metrics, which is a major focus for U.S. payors and gov't agencies.
Putting all the CPOE (orders) on the chain might be excessive as well. The blockchain could contain merkle roots to specific patient records stored off chain. A registry (including provider UPN registry) could record a patient national/world health identifier and a check-in/check-out status. Retrieve a CCD from decentralized storage using world patient ID (IPv6?) with a payment in ether to the filehost(web front end) and a checkout flag set. A utility like GPG decrypts the CCD for use by the EHR. When the episode of care is over, the CCD is recreated (with updated info) and placed back into storage. The registry knows the latest version stored.
We could do a world wide EHR agnostic health information exchange if we can decide on a world patient ID (IPv6), a registry format in Ethereum (patientnamecoin), an encryption standard(GPG), key managment(WoT), the back end(s) for distributed storage(BitTorrent,Tahoe-LAFS,MaidSafe), and a patient record format (like CCD).
How would you obscure check-in/out and document registrations so that they do not reveal that a particular UPN was at a particular facility except to authorized parties? Some people might be uncomfortable with the idea that the association of a real world identity to a UPN would grant a widely accessible future and historic tracking system for their whereabouts (assuming the interact with medical facilities)
I find that bittorrent is too much overhead for the size of data we're talking about and maidsafe is a bit opaque and immature at the moment IMO, but I haven't tried Tahoe-LAFS and it seems very interesting. Do you know where I can find details of any public grids that exist? Clearly the trustless distributed storage and retrieval element is the lynch-pin to this concept.
You bring up a great point about privacy, security and key management. Key management and distributed storage are keys to getting this working.
There is a Tahoe-LAFS testgrid at (https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid). There was a pubgrid but it's no longer in service. A commerical firm (leastauthority.com) sells 350GB for $50/month, I think if one needs to really test this reliably. It's built off the same technology I believe. I met Zooko once, he's a great guy doing important work. Funnily enough he was wearing a "I am Satoshi" T-Shirt.
I do think that there is a clear stepwise progression in the evolution of connectivity of EHRs. The first step, at least in the U.S. is nationally mandated "meaningful use stage 2" in 2014 requiring HL7/CCD compatibility. So the first distributed application should build on that. When use of the distributed system becomes widespread, then there is the possibility of building further on that to create a chain of medical transactions that more resembles a standalone EHR.
This way the practice is responsible for registering providers, the practice and the provider would need to sign out a chart for EHR import and processing. A chart would need a "checked out" flag so that 2 different EHRs don't try to update the chart.
Basically it's a central registry but it could be an ethereum contract.
This would give user access to basic details not everything.... Prehaps a combination of Physician and patient interaction with the cryptography being generated at each client visit using a new password generator would work to create increasing levels of access.Then physical ID can be exchanged with the trusted 'doctor' a new key created that lasts say 72 hours. ID is in person - with the physician and the password generation occurs at that point allowing higher level access. Ive just has the same issue. data is stored at various stations ...people want their data often years later.
I would like to quote this 'Speaking as a practicing U.S. physician, one of the biggest barriers to quality care is lack of timely communication between various providers of health services. Remarkably, the advent of electronic health records (EHR) has made this problem even worse, as pertinent information about patient care is buried in reams of redundant filler information, each EHR vendor uses proprietary data formats incompatible with other vendors, and regulations regarding privacy restrict the flow of information, all to the detriment of quality, timely patient care. Also, the complexity of EHR and the ever-changing regulatory and insurance environment make it impossible for individual practicioners to customize their UI to maximize their effectiveness. There is no centralization or standardization of even the most fundamental medical data structures.
I think that a Distributed /Encrypted EHR system could solve this problem, if it were widely adopted. The advantages I see are firstly that electronic information would be highly encrypted in a distributed blockchain-like structure, thus it could be accessed easily from anywhere but only by providers with the keys. This would solve the communication piece while maintaining privacy. The open source project development would allow for both standardization of medical data structure and customizability of UI. The exorbitant cost and waste of multiple incompatible proprietary systems could be eliminated, and quality metrics would become more accessible to patients and payers.'
As companies consolidate and say the backward looking doctors are the issue and they have the NEXT best thing...they don't I've seen it Ive paid for it...distributed records have to tie in with postal issues , payments and other factors ...thats how they add value they are often NOT about EMR but about reminders SMS , letters etc...
The idea first would be to focus simply on the actual medical data ...not reminders SMS and payment history.
Thats always the issue. Some systems use the experian databases to target clients!
My dentist sends several reminders ....I think those things are a distraction to what the physician needs and the patient wants. Ihave seen some very good open source systems before but anyway I think this is all beyond me....i will check back with you experts sometime...good luck
I think it is still a couple years until such a system can be made truly useful. Some of the issues are where and how to store data and private key management. You can't really store any large amounts of data on a block chain, but apparently Ethereum is looking into DHT storage, so that might be an option.
Private key management is another interesting issue. I think users, doctors and smart devices like a smart watch with a pulse reader, could all have their own private keys stored in hardware devices. Users and doctors should have something like a hardware wallet, and perhaps hospitals or doctors offices or similar should keep backups of the keys in case they are lost.
To make a hardware wallet easy to use, perhaps it could connect to the computer by bluetooth and use this to receive and requests. This might also be useful for a smart toilet, whenever a user goes to the toilet, the toilet would connect to the watch via bluetooth to know which person is currently using the toilet and then measure as much as possible and upload it, as time goes by, more and more sensors should be possible to integrate in a toilet.
A smart watch could also track how much a person moves every day. It would be great to have diet information also, but that might be difficult to track automatically, perhaps it could be combined with an easy to use smartphone app where a person just has to click a couple buttons like drink, then it would show tea and coffee buttons if that is what the person likes drinking, or eat and then it would show buttons for the most common things that person eats. At least people who likes tracking their health might want to use something like that.
It would be really great if many people shared their generic health data read by smart watches and toilets. Of course people should be able to choose what, if any, data they want to share. While it might be dangerous to share data in certain countries with health insurance, as it could mean that you would not be able to get health insurance if you are at risk of getting cancer for example, it could be really useful for the rest of the world. Not only would it open up a great amount of data to researchers, which could be used without complicated procedures or asking anyone for permission, it might even save the lives of individuals using it. Researchers and doctors all over the world who is analyzing the data might find people who are in the process of developing and illness for example, and could give them notice before it gets serious.
We are working to solve the inter-operability problem among disparate healthcare systems.
Checkout our website (AzaadHealth)
Right now we are only focusing on transferring medical records among hospitals and patients. In future we will expand to sharing all health information among almost all healthcare providers.