A couple of weeks ago I was discussing the opportunities for using block chain technology for medical record interoperability with a group of friends who unsurprisingly see their real experience as evidence that we haven’t made it easy to exchange medical records yet. While chatting, one of my friends asked the question – “Isn’t there some sort of security problem with Health Information Exchanges (HIEs), because block chain technology could solve security issues, especially if that is what is holding things back?” I thought about it and my immediate answer was “not really.” The sharing problem is about trust and finding a model that works for sharing records rather than just some underlying security conundrum.
The HIE architecture we have today has been designed to be secure. The records are encrypted in transit with clear authorization protocols. The systems that store them use The Federal Information Security Management Act (FISMA) standards to have high security controls over data at rest. Therefore, records are shared between groups only by sharing the system rights and permissions established between health care providers or following patient consent. HIEs are running a large portion of identifiable data back and forth between institutions regularly and I don’t know of an HIE hack to date. As I thought a bit longer about this, I began to think about the different challenges associated with HIEs and Personal Health Records (PHRs) where the unresolved patient and physician behavior along with trust issues reside. These issues might be resolved by using block chain or by offering a more flexible and logical way for patients to experience record sharing.
Both HIEs and PHRs are secure systems (encrypted in transit, use role based authorization, and manage security controls at rest). The security and privacy model is based on rules about how patient records are shared between individuals and organizations. Blocks of records are shared and stored in a number of different ways. The system rules that define the authorization to share a record are slightly different in an HIE vs. in a PHR. In an HIE, providers who are trusted by the patient have the ability to establish rules in networks that define the circumstances by which it is okay for a physician at one health system to view a medical record for a patient from another health system. The government has the ability to mandate that all health systems must participate in HIEs and allow for sharing data in the majority of circumstances. By establishing the rules of the HIE for exchanging data and not having the patient serve as an intermediary, a provider can potentially exchange patient information smoothly between two providers of separate healthcare organizations with the patients initial consent. However, this would take the decision-making power away from the patient, and the rules for the HIE would impact the outcome of the sharing agreements. By comparison, in a PHR model, the patient record is delivered to the provider if the patient requests and designates access to their health record to that provider. Both systems use the same underlying protocols integrating the Healthcare Enterprise (IHE) and medical record document formats (CCA) to transmit the documents.
The difference between the PHR and the HIE is in how the contract is structured by the network and the way the patient record flows to the provider from an outside entity. In an HIE patient data flows because a network of health systems have all agreed to trust each other. They have set-up a governance model with policies, established secure system interfaces, and can share patient records in that specific network using that set of policies. In the PHR, the patient’s own specific direct request authorizes use of their record. The patient can thus broker on their own between institutions that have no formal relationship with each other regarding a closed network for patient data sharing.
One challenge in a PHR model is that if we look to the patient to make the decisions about how their health records are shared then every time a physician needs access to the patient’s external medical records, the patient needs to go into an application to give permission. While it is ideal and appealing for privacy and security to have the patient do this, it is complex and a bottleneck that adds labor to the patient who has many other concerns and may not understand what they are doing. The process of filling out additional forms from different providers to share records creates sufficient complexity (such as remembering passwords) that it will fail to get completed in many cases. This transaction burden in a PHR model may be one reason why we have never seen large scale patient controlled health records deployed as a dominant method for interoperability despite the benefits of having the patient as the core of the decision process. The patient, if I look at myself as an example, in most cases just wants sharing within the healthcare community to work in their interests in the background of each system.
Alternatively, on the provider side HIEs enable ‘background sharing’ by having health care providers in an HIE exchange network determine a set of rules for which a provider shares patient data with other providers. The government has the ability to mandate that all health systems must participate in HIEs and allow for sharing data in the majority of circumstances. While this can allow for seamless exchange in each network, any given HIE network is by necessity constructed with a limited set of participating providers. So providers or types of providers who may be important may not be participating in the right HIE network for any given patient thus making data sharing potentially hit or miss. Furthermore, the patient role in controlling their data privacy can be lost by taking a view that the system takes care of it.
So, I got to thinking about block chain and what benefits we might find other than security if health records could be chained together into one large scale network with a common history. The block chain model uses smart contracts attached to assets and subcomponents of assets with rules to handle the exchange of transactions among participants. If we were using block chain for health system interoperability the patient record exchanges could be governed with smart contracts that determine how the patient record should be exchanged. The logic could have more options rather than the current rigid sharing models in place for the HIE and PHR model.
I recently read “Nudge” by Richard H. Thaler & Cass R. Sunstein, on the idea of a choice architecture. The book focuses on the notion that we can benefit from a concept of Libertarian Paternalism, the idea that it is legitimate for private and public institutions to nudge people in directions that will improve their lives while also respecting freedom of choice. Choice architecture is a useful construct for this situation with the general idea that people should have the choice to have either a candy bar or an apple, but because default selections are important, if the goal is to help keep people healthy then apples are the better thing to present as the convenient choice at the check-out aisle in a cafeteria. The ‘smart contract’ within the block chain technology model can establish the right balance of rules between the PHR and HIE models with the patient in the driver’s seat regarding how to tune the contract to meet their level of comfort.
What this boils down to is the idea that the right framework for an HIE/PHR patient data interoperability system might be neither an HIE system controlled by physicians nor a PHR system controlled by patients. It could instead be an integrated system with a built-in choice architecture. We could set the default contract for sharing data to the most beneficial setting for the patient. The patient could be provided with a default smart contract that follows some basic logic (e.g., “If I see two physicians who are both licensed, then regardless of whether they trust each other or not they should be able to access my record on demand based on a shared patient identification mechanism that links the records to me.”).
This idea may not be revolutionary to some, but for me, it was a bit of a surprising new insight because I have often explained that we have a choice of how interoperability should work. I had thought that interoperability should either go down the path of ‘patient-controlled health records’ or the path of ‘a global provider-controlled health information exchange’. I have historically prophesized on the side of the patient controlled health record knowing that patients have a lot of complexity to deal with in order to get there. With a well-designed smart contract system and some future-state data sharing systems this need not become a choice. A single integrated interoperability framework that gives the patient control of overriding a choice architecture which ultimately sets sharing for providers as the default could be transformative. For more optional services like ‘send my genetic data to a particular retailer so they can sell me more relevant items’ the default sharing would by default be more restricted and require the patient to actively share.
Block chain in this system is an infrastructure shift that would include new tools through the distributed ledger as an alternative to the HIE and PHR models. So block chain is a potential game changer in medical records. But it may be more important to construct new ‘nudge’ based tools governing patient data exchange whether we transition to block chain as underlying technology or not for forming trust through smart contracts. Once we can do that we can titrate to a middle ground between the PHR and HIE approaches to find a patient data sharing model that offers a personalized experience with all of the patient’s interests in mind for any patient including good defaults for convenience, comfort, privacy, safety, quality of care, and service.