Sunday, October 23, 2016
HIE of One: Gropper's Healthcare Blockchain Vision
Let's use blockchain technology to shift the balance [of control] back to the physician-patient relationship. This is what Adrian Gropper proposes in ONC Blockchain Challenge paper #7. He compels us to look using the title "Powering the Physician-Patient Relationship with HIE of One Blockchain Health IT*".
Dr. Gropper asserts that physicians and patients are primarily responsible for care decisions and medical expenditures but that EHR and related technology is mostly controlled by large institutions (who can afford such assets). In turn, he reminds us, these institutions need to continue to maximize their own growth and control over the entire process. Dr. Gropper is concerned that these large organizations inhibit cost reductions and innovation due to inertial restraint. Blockchain, for Dr. Gropper is essentially a call to independence and a chance for physicians and patients to take more control over innovation from the large institutions.
I understand his concern about the inertia of large institutions. But, many of his assumptions do not resonate with me. For example, Dr. Gropper states that "hospitals are reluctant to show physicians the cost of a medication or procedure when they're about to order it. They are even less likely to present the physician with a list of alternatives". Dr. Gropper, I would like you to meet my friend, the State of Maryland, where hospital cost is highly regulated and we would love to intervene in your cost choices at the hospital. However, it is true that cost transparency has been a difficult process challenge. Dr. Gropper proposes that blockchain technology can provide for this cost transparency at the mobile device level during decision conversations with the patient. I'm in favor.
Gropper's first work in this blockchain realm is in the creation of identity standards that will address patient matching challenges and allow for identity federation. He would like to take the blockchain concept of the identity "wallet" and incorporate it into existing healthcare technology standards such as OpenID Connect and FHIR. This would support methods for patient and provider access as well as a way to link wallet identities to records. He has demonstrated this system in the context of standards created and discussed by or among participants in HL7 FHIR , OpenID Connect , Kantara UMA Standards and OpenID HEART workgroup. These are all important standards bodies as they help define how individuals (patients, providers, and care teams) can access and exchange components of information in a secure, encrypted, identity authenticated environment over the world wide web.
Unlike other papers reviewed so far, Dr. Gropper makes it clear that PHI will not be stored on the blockchain. The HIE of One will only secure and manage access to PHI. The data stays with the original creators and consumers and each one of these endpoints is accessed by others via the HIE of One when queried. In this way, he initially proposes that nothing will be added to the blockchain beyond the initial creation of identities and relationships. This makes this implementation cheaper than other blockchain proposals since adding data to a blockchain ledger incurs additional "proof-of-work" algorithm and infrastructure costs.
The author loses me when he discusses how the blockchain identity trust can be used to exclude hospital institutions from transactions. He gives an example of a prescription transaction. I agree that the ability to provide a trusted ledger that pharmacies can rely upon to verify that a licensed provider is prescribing to a legitimate patient is preferred. However, I don't agree with his assertion that a "hospital trust" and hospital information system is required for these transactions to occur at a provider practice today. Again, in Maryland, our goal is to keep the patient away from unnecessary hospital encounters in deference to community provider interventions. Most providers process these transactions without any involvement from hospitals.
Aside from that distraction, Dr. Gropper proposes that the physician to patient transactions can be mediated by a blockchain based decentralized identity or DID. The benefit of the DID is that it does not rely upon a Health Information Exchange (HIE) or Enterprise Master Patient Index (EMPI) of centrally stored patient information in order to verify patients when they are involved in a transaction. This is setup, in my version of the truth, like this:
Step 1: Patient downloads trusted DID application to personal device.
Step 2: Patient creates identity wallet secured through various password or question and answer methods.
Step 3: Identity wallet submits encrypted identity onto the HIE of One blockchain.
Step 4: When patient presents at practice, the practice scans device output (let's call it a QR code).
Step 5: Transactions and EHR records are associated with this encrypted identity as verified via the world wide web and the HIE of One.
Gropper says' that the transactions will be recorded in both the provider and the patient's self-sovereign support technology (SSST). This confuses me a bit because he earlier maintained that the PHI would not be stored centrally and that there would not be expensive additions made to the blockchain. Where is this SSST housed? Furthermore, an institutional or vendor-provided SSST is required, thereby re-introducing the potential need for institutional funding. It may be that I don't understand what he is proposing but what I am hearing is:
1.) Let's declare our independence from hospitals, EPIC, Cerner, Meditech, Allscripts and all the other large vendors and systems of the world who provide EHRs and patient portals, and
2.) Let's declare our allegiance to some new brood of vendors who will provide SSST systems for providers and patients.
I'm all in favor of disrupting inertia and decreasing price tags but I'm not sure Dr. Gropper's proposal is inherently a provider's or a patient's ticket to freedom. This new stuff will have a price tag that's paid for with money by someone who has it. Furthermore, if providers are to divorce from all these large entities then who will be providing the expensive services required for evidence-based and precision medicine, disease surveillance, case management, and the myriad of infrastructure required to manage the complexity of our populations?
One of his examples of a federated technology which is not inherently an SSST is called NOSH. It's an opensource charting application that a provider can install and implement without vendor intervention. I think it's great. I love opensource tools. Maybe one day I will have a NOSH jam session with the Linux system I only sort of understand. But, for most independent provider practices, chances are there won't be an abundance of Linux and MySQL techno-geeks and other expertise to install and maintain this system. This returns us to the money premise. Someone needs to spend it.
Make no mistake, Dr. Gropper and his cohort are making an important contribution to the brainstorming for the next generation of healthcare information solutions. I think they should continue this effort albeit without the distraction of using divorce from hospitals and other important team players as a premise for the work. We can do this better together.
And, speaking of federated opensource, Dr. Gropper has posted a user installable version of HIE of One. All you need to do is run some sudo install commands on your Linux system equipped with PHP, MySQL, Apache, and CURL. Are you still with me? Stay awake!
_______________________________________
* Powering the PhysicianPatient Relationship with HIE of One Blockchain Health IT Adrian Gropper, MD August 7, 2016
Sunday, October 16, 2016
Blockchain Ready for Healthcare Now?: A healthcare blockchain solution in testing today
For my 3rd reading from the ONC Blockchain Challenge winners, I found a fairly down-to-earth explanation of applying blockchain to the healthcare EMR and research universe. The authors described a solution called "MedRec" in a paper* originally published by IEEE at the 2nd International Conference on Open & Big Data 2016 (this is known by the cool kids as "OBD2016" which is another great blog topic to save for later). Not only did they inform us about a practical architecture for blockchain on-ramps and off-ramps for healthcare organizations but they helped me envision the role of the Healthcare Information Exchange Leader in this new approach to data sharing. The unwieldy, but descriptive title is, "A Case Study for Blockchain in Healthcare: "MedRec" prototype for electronic health records and medical research data". Best yet, their solution is in trial use today.
The authors set out to address the market need for "patients to engage in the details of their healthcare and restore agency over their medical data". The solution they propose and have begun pilot testing is called "MedRec" and it "manages authentication, confidentiality, accountability and data sharing" among patients, providers, researchers, and other medical stakeholders. They also propose a novel research driven economy that incentivizes these medical stakeholders by providing them with access to aggregate, anonoymized data as a reward for providing the computing power for the distributed blockchain network that serves "MedRec".
Their proposed economic model is intriguing since it addresses the question of who will pay for the computing power required for the data encryption and ledger update transactions. In a bitcoin economy, each entity that provides computational power is rewarded by a small bit of currency. This becomes problematic for the healthcare community since we rarely want patients or community healthcare providers to have to pay to participate in active and complete data sharing activities. So, the author's propose that consumers of aggregate data would actually pay for the computing infrastructure and, in reward, get access to continuous and rich aggregate, anonymized data sets. This in turn, may lead to new solutions for population health, genomic research, precision medicine, social support programs, etc. How such an economy would be effectively governed and kept fair is a question for another time.
The "MedRec" solution addresses "fragmented, slow access to medical data; system interoperability; patient agency; [and] improved data quality and quantity for medical research". It uses data references and encoded hash pointers to build the blockchain ledger based on the work of Zyskind et al. (the wizards of Enigma , a solution I mention in different posts). What all of this means is that when the healthcare data gets into the blockchain that it is virtually unrecognizable to anybody on the internet until blockchain participants are engaged to start decrypting and reassembling data back to a trusted requestor with a digital identity. MedRec's role is played by using Application Programming Interfaces (APIs) to connect existing electronic medical record (EMR) systems to the blockchain network to enable data sharing while adding the distribution and security advantages of blockchain infrastructure.
MedRec developers decided to implement this system utilizing the growing open-source blockchain solution called Ethereum. Ethereum provides ready-made developer tools and programming code for creating "smart contract" transactions. "MedRec" smart contracts include patient-provider relationship associations, viewing permissions, and data retrieval instructions. Additionally, the smart contract includes requirements for sending notifications to participants when data changes. The smart contract participants are verified using their Ethereum registered identification. This is like a domain address and allows for identification of the patient or provider without exposing Social Security Numbers or date of birth.
So, now I will try to perform a walk-through of how I might participate in the MedRec infrastructure as a patient based on my understanding of this paper:
Step 1: I goto Ethereum, or MedRec's on-ramp to Ethereum and establish my account for identity. This becomes my "Registrar Contract" or RC.
Step 2: My healthcare providers must also do the same.
Step 3: Using some sort of portal, setup by a MedRec sponsor, my provider and I establish a "Patient-Provider Relationship Contract" or PPR. This contract contains a bunch of information not limited to: who we each are (identities), what data can be shared, what data can be stored locally, what records are held by the provider, the provider's network location, and so on. The data sharing and viewing contract is mapped to query strings that define allowable inquiries into the data. Through use of a portal, I am able to define at a very granular level which part of my data is viewable and by which participants. This contract is then dispersed among the blockchain nodes like so many pieces of puzzle dust.
Step 4: A "Summary Contract" or SC contains a "list of references to Patient-Provider Relationship contracts (PPRs). This allows me to see all the participants who are involved in sharing my data and allows other authorized participants to see the same. Apparently, I can leave the network at any time and join back in later. The SC will also inform me of changes in relationships and allow me to approve new ones. So, for example, if I go to a new provider or hospital, a new request may pop up and require my approval for allowing the new participant to join in the data sharing fun. This means that if I am diagnosed with a psychosis due to overexposure to technical information, that I can choose not to share that information with all providers. As a side note, I hope this will create an entry that indicates I have blocked some information so that a provider will know to ask me what I might be hiding.
All of the above steps occur through encrypted transactions among many, distributed participant computers that throw my data all over the place in unrecognizable bits (or blocks) so that they are not recognizable until a connected MedRec Node grabs it back to gain understanding of the contract. The same is true for my healthcare data except that it can still reside locally in the healthcare provider's database. This is convenient for both providers and hackers; however, I think the authors are looking to create a transitional solution for interoperability and patient agency that is useful today. Eliminating all large, local caches of patient data is a challenge for another paper. I do speculate though that using the MedRec solution could give us a quicker path to eliminating dates of birth and SSNs from patient databases. (note, most healthcare organizations no longer require SSNs but it sure makes patient matching easier if it is provided)
So, who pays for all these computers that process the blocks in the chain? This part gets interesting. MedRec incentivizes "miners" to "participate in the network and contribute their computational resources to achieve a trustworthy, gradual advancement of the chain". So, essentially, anybody who finds safe, aggregated queries for healthcare data to be a thing of value will provide computing infrastructure to continuously process transactions for the Ethereum blockchain. The authors call this a "bounty query". This bounty query then belongs to the miner and the miner can get updates on an ongoing basis. For example, a query on geographic distribution of toe fungus patients would provide an ever changing dataset for a researcher intent on wiping out toe fungus across the country. This same researcher would decide how many nodes to contribute to the network in exchange for more and more data.
This practical solution is meant to be interoperable with the EMRs in use today. As a result, local databases are still targets for hackers; However, this solution eliminates the problem of centralized data stores that are currently employed to support information exchange and population health. The authors also warn that bad actors can observe activity on the blockchain to infer patterns of interaction. E.g., they may be able to discern frequency of entity interactions in case it might be useful for identifying targets for further hacking activity. The authors propose that one way to avoid this is to limit the participants of the network to only pre-approved nodes so that outside observers are excluded. This, of course, requires some centralized administration.
What I really like about this paper is that it describes something that is approaching immediate utility. MedRec is designed with open APIs that can also support HL7 and FHIR data exchange standards. Integration approaches have been assessed with EPIC and Cerner and a demonstration system is in evaluation at Beth Israel Deaconess Medical Center. MedRec creators are in the process of creating tests to secure compliance with the ONC Roadmap's guidelines for "Ubiquitous, Secure Network Infrastructure." And, some part of their research will be made available on GitHub for geeks like me to download. This could keep me busy for quite some time.
____________________________________________________________
* Ariel Ekblaw, Asaph Azaria, John D. Halamka, MD, Andrew Lippman, MIT Media Lab, Beth Israel Deaconess Medical Center. A Case Study for Blockchain in Healthcare: "MedRec" prototype for electronic health records and medical research data, White Paper. August 2016.
Parts drawn from IEEE, 2nd International Conference on Open and Big Data 2016.
The authors set out to address the market need for "patients to engage in the details of their healthcare and restore agency over their medical data". The solution they propose and have begun pilot testing is called "MedRec" and it "manages authentication, confidentiality, accountability and data sharing" among patients, providers, researchers, and other medical stakeholders. They also propose a novel research driven economy that incentivizes these medical stakeholders by providing them with access to aggregate, anonoymized data as a reward for providing the computing power for the distributed blockchain network that serves "MedRec".
Their proposed economic model is intriguing since it addresses the question of who will pay for the computing power required for the data encryption and ledger update transactions. In a bitcoin economy, each entity that provides computational power is rewarded by a small bit of currency. This becomes problematic for the healthcare community since we rarely want patients or community healthcare providers to have to pay to participate in active and complete data sharing activities. So, the author's propose that consumers of aggregate data would actually pay for the computing infrastructure and, in reward, get access to continuous and rich aggregate, anonymized data sets. This in turn, may lead to new solutions for population health, genomic research, precision medicine, social support programs, etc. How such an economy would be effectively governed and kept fair is a question for another time.
The "MedRec" solution addresses "fragmented, slow access to medical data; system interoperability; patient agency; [and] improved data quality and quantity for medical research". It uses data references and encoded hash pointers to build the blockchain ledger based on the work of Zyskind et al. (the wizards of Enigma , a solution I mention in different posts). What all of this means is that when the healthcare data gets into the blockchain that it is virtually unrecognizable to anybody on the internet until blockchain participants are engaged to start decrypting and reassembling data back to a trusted requestor with a digital identity. MedRec's role is played by using Application Programming Interfaces (APIs) to connect existing electronic medical record (EMR) systems to the blockchain network to enable data sharing while adding the distribution and security advantages of blockchain infrastructure.
MedRec developers decided to implement this system utilizing the growing open-source blockchain solution called Ethereum. Ethereum provides ready-made developer tools and programming code for creating "smart contract" transactions. "MedRec" smart contracts include patient-provider relationship associations, viewing permissions, and data retrieval instructions. Additionally, the smart contract includes requirements for sending notifications to participants when data changes. The smart contract participants are verified using their Ethereum registered identification. This is like a domain address and allows for identification of the patient or provider without exposing Social Security Numbers or date of birth.
So, now I will try to perform a walk-through of how I might participate in the MedRec infrastructure as a patient based on my understanding of this paper:
Step 1: I goto Ethereum, or MedRec's on-ramp to Ethereum and establish my account for identity. This becomes my "Registrar Contract" or RC.
Step 2: My healthcare providers must also do the same.
Step 3: Using some sort of portal, setup by a MedRec sponsor, my provider and I establish a "Patient-Provider Relationship Contract" or PPR. This contract contains a bunch of information not limited to: who we each are (identities), what data can be shared, what data can be stored locally, what records are held by the provider, the provider's network location, and so on. The data sharing and viewing contract is mapped to query strings that define allowable inquiries into the data. Through use of a portal, I am able to define at a very granular level which part of my data is viewable and by which participants. This contract is then dispersed among the blockchain nodes like so many pieces of puzzle dust.
Step 4: A "Summary Contract" or SC contains a "list of references to Patient-Provider Relationship contracts (PPRs). This allows me to see all the participants who are involved in sharing my data and allows other authorized participants to see the same. Apparently, I can leave the network at any time and join back in later. The SC will also inform me of changes in relationships and allow me to approve new ones. So, for example, if I go to a new provider or hospital, a new request may pop up and require my approval for allowing the new participant to join in the data sharing fun. This means that if I am diagnosed with a psychosis due to overexposure to technical information, that I can choose not to share that information with all providers. As a side note, I hope this will create an entry that indicates I have blocked some information so that a provider will know to ask me what I might be hiding.
All of the above steps occur through encrypted transactions among many, distributed participant computers that throw my data all over the place in unrecognizable bits (or blocks) so that they are not recognizable until a connected MedRec Node grabs it back to gain understanding of the contract. The same is true for my healthcare data except that it can still reside locally in the healthcare provider's database. This is convenient for both providers and hackers; however, I think the authors are looking to create a transitional solution for interoperability and patient agency that is useful today. Eliminating all large, local caches of patient data is a challenge for another paper. I do speculate though that using the MedRec solution could give us a quicker path to eliminating dates of birth and SSNs from patient databases. (note, most healthcare organizations no longer require SSNs but it sure makes patient matching easier if it is provided)
So, who pays for all these computers that process the blocks in the chain? This part gets interesting. MedRec incentivizes "miners" to "participate in the network and contribute their computational resources to achieve a trustworthy, gradual advancement of the chain". So, essentially, anybody who finds safe, aggregated queries for healthcare data to be a thing of value will provide computing infrastructure to continuously process transactions for the Ethereum blockchain. The authors call this a "bounty query". This bounty query then belongs to the miner and the miner can get updates on an ongoing basis. For example, a query on geographic distribution of toe fungus patients would provide an ever changing dataset for a researcher intent on wiping out toe fungus across the country. This same researcher would decide how many nodes to contribute to the network in exchange for more and more data.
This practical solution is meant to be interoperable with the EMRs in use today. As a result, local databases are still targets for hackers; However, this solution eliminates the problem of centralized data stores that are currently employed to support information exchange and population health. The authors also warn that bad actors can observe activity on the blockchain to infer patterns of interaction. E.g., they may be able to discern frequency of entity interactions in case it might be useful for identifying targets for further hacking activity. The authors propose that one way to avoid this is to limit the participants of the network to only pre-approved nodes so that outside observers are excluded. This, of course, requires some centralized administration.
What I really like about this paper is that it describes something that is approaching immediate utility. MedRec is designed with open APIs that can also support HL7 and FHIR data exchange standards. Integration approaches have been assessed with EPIC and Cerner and a demonstration system is in evaluation at Beth Israel Deaconess Medical Center. MedRec creators are in the process of creating tests to secure compliance with the ONC Roadmap's guidelines for "Ubiquitous, Secure Network Infrastructure." And, some part of their research will be made available on GitHub for geeks like me to download. This could keep me busy for quite some time.
____________________________________________________________
* Ariel Ekblaw, Asaph Azaria, John D. Halamka, MD, Andrew Lippman, MIT Media Lab, Beth Israel Deaconess Medical Center. A Case Study for Blockchain in Healthcare: "MedRec" prototype for electronic health records and medical research data, White Paper. August 2016.
Parts drawn from IEEE, 2nd International Conference on Open and Big Data 2016.
Tuesday, September 27, 2016
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
Thursday, September 15, 2016
Sunday, September 11, 2016
Coding a Blockchain application for healthcare information exchange
Let’s take some sample code from the BlueMix site which was reposited on Github:
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:
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:
Simple, right?
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?
Subscribe to:
Posts (Atom)