Distributed /Encrypted Electronic Health Records (EHR)

static_variablestatic_variable Member Posts: 11
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.

Comments

  • aatkinaatkin ✭✭ Member Posts: 75 ✭✭
    Hi! I'm a technical project manager at a county hospital and have worked on Epic and other implementations. The way this might work is to maybe store the CCD encrypted on the chain with private key multisig with patient to access. The main app would still be offchain but would read the chain to access/modify the record. As it currently stands there would be a one-time fee to store the record and some processing fees for look ups and edits. The main thing to keep things HIPAA and ROI compliant is how to manage pki keys/access to the record.
  • chris613chris613 ✭✭ Member Posts: 93 ✭✭
    I've worked in this field as well, on the EHR infrastructure side of things.

    @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.
  • static_variablestatic_variable Member Posts: 11
    Thank you, aatkin and chris613, for your comments! They are very much appreciated!

    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.
  • aatkinaatkin ✭✭ Member Posts: 75 ✭✭
    @chris613 I agree that the CCD itself shouldn't be on chain. We could use @vitalik? 's suggestion of distributed dropbox to store the actual encrypted CCD using bittorrent, TAHOE-LAFS, MaidSafe, BitCloud or some other decentralized storage.

    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).
  • chris613chris613 ✭✭ Member Posts: 93 ✭✭
    @aatkin? your idea seem very sound to me.

    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.
  • aatkinaatkin ✭✭ Member Posts: 75 ✭✭
    On idea for hiding information on the blockchain is to actually store it encrypted with a public key. So you'd access maybe a chart from TAHOE or MaidSafe, get it on the blockchain, but critical info could be public key encrypted and must be opened with a private key on your client.

    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.
  • 123eyes123eyes Member Posts: 3
    edited April 2014
    I am following this - after coming back from a "peer" review conference - Although your immediately talking global changes with the EHR being written to and encrypted storage that's great. What also interests me is all those peripheral devices that write to the EHR. Making existing computer records systems and diagnostic and monitoring devices "etherium" / blockchain compliant would mean truly trustworthy and chronologically correct and globally accessible secure records. physicians notes can be added along with diagnostic and monitoring data from machines and devices . these peripherals are notoriously difficult to integrate . Also doctor / patient communication would be revolutionised - increased trust and compliance . Already standards can be exceptionally high but notes are not easily shared or retrieved quickly enough - we rely on phone calls a lot ? . Global notes are one thing however as most protocols are developed by local practitioners there's a hierarchy of connectivity. primary care needs are different to Hospital needs. connecting primary to secondary care and social input you can see a microcosm of existing systems - the beauty of "etherum compatable" notes would be linking these in real time and as mentioned chronologically and securely so that doctors have clarity of data and patient care can be improved - patient compliance and communication would be able to be verified and rewarded. Clincally proven modifiable risk factors would : could be incentivised as you both mention. My knowledge of code is much less than you guys above however I work with EHR for the last 15 years and have struggled with cloud services now speeds are getting better possibilities are really opening up . Local servers that capture all data and are backed up daily could mean much of the data entry window could be open to editing and manipulation but as speeds increase - real time discussion of notes with telemedicine applications become possible. What I do know for sure is a doctor with accurate data from trusted machines making good clear notes and a patient with copies of his:her notes always result in better prognosis. the possibilities are amazing to say the least as trust is just so essential .. trustworthy data trustworthy care ...proven etherium Blockchain compliant and possibly rewarded and incentivised ..
    Post edited by 123eyes on
  • 123eyes123eyes Member Posts: 3
    research papers documenting integration and clinical outcomes are needed at individual practice level ...the impact of a creating and Storing clinical records.. in practice with these new methods should be evaluated . As a former practice owner I had over 10,000 records and the move from paper to Electronic cards is a epic thing. Infact I would say most people cant afford really good software . I've seen software being implemented in many companies all differently . One possible approach is to start to look at smaller invidivual private practice. Prehaps a open source etherium compliant EHR system could be utilised by individual users.
  • static_variablestatic_variable Member Posts: 11
    Thank you @123eyes for your interest and comments. I am still not sure if ethereum is the ideal platform for this project; it is possible to construct a solution using NXT or Maidsafe, and any of these platforms will require specific client applications to run on the devices that interact with existing EHR systems.

    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.
  • static_variablestatic_variable Member Posts: 11
    @123eyes? @aatkins? @chris613? @vitalik? Any thought on how to create secure private keys that would prevent unauthorized access? I am thinking a mixture of provider-specific keys based on NPI number / DEA number etc, plus patient specific keys based on a mix of name, date of birth, postal code, and maybe fingerprint scan from a smartphone. Thoughts?
  • aatkinaatkin ✭✭ Member Posts: 75 ✭✭
    It's an interesting problem. You would need a provider registry, possibly interfacing with the national registry containing NPI and GPG public key and email. Those provider IDs could be added perhaps for a specific hospital/practice so that a designated credentialing admin would update the registry on behalf of the practice.

    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.
  • 123eyes123eyes Member Posts: 3
    Website to log into. , patient , username and password.
    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

  • AllenHagenAllenHagen Member Posts: 1
    Health care industry is changing rapidly. Everyday there are some new tools, LIS software, medical devices etc. occur in the market which provide better care to patients. Recently we have noticed electronic health record (EHR) systems that provide easier access to the patient’s health information. Health care data encryption provides data security for electronic medical records to avoid unauthorized access. However, there are many questions still occur about the privacy and security concern of EHRs which should be resolve immediately.
  • abrarariesabrararies Member Posts: 1
    We went over the same debate. In the end we decided to drop blockchain storage for health records because sharing health records among different providers was already a huge task for our MVP.
    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.
  • HasLuxHasLux Member Posts: 48
    By using a token based system for the encryption you could ensure the security of the data being transmitted over the blockchain because the key would be generated based on the token which changes every 60 seconds. Therefore you could in theory utilize the blockchain as a VPN between two sites.
Sign In or Register to comment.