MedRec: Patient Control of Medical Record Distribution

Introduction

Increasingly, people in the United States are required to manage their own healthcare and associated information.  The days of the lifetime family doctor are over.  At the same time, healthcare providers have to make that data available.  This circumstance opens the door for innovative approaches to patient management.  One obvious solution is a “Swiss bank” for healthcare records.  This offloads engaged patient management to a cross-provider intermediary.  In return for that convenience, we risk the addition of new data silos and commercial control points.

As an alternative, we can use a non-commercial, distributed system that allows patients to control who can access their records and thereby create a network solution where providers join that network and make data available on-demand at the behest of patients.  MedRec is a network rather than a service.  The advantage of this is that we can provide a cross-provider, patient-oriented interface and interaction mechanism. We constructed it using an Ethereum blockchain and we have tested it with diverse data bases provided by our research partner, the Massachusetts-based Beth Israel Deaconess Medical Center.  Further development will be done by a new, non-profit research endeavor called the Health Technology Innovation Center operated at BIDMC with continued participation by a team at the MIT Media Lab.

We note three features of the system that are potentially significant.  First, the system is designed to accommodate access to data for clinical researchers and serve as a point of entry for socially valuable epidemiological research for example to understand the propagation of disease and epidemics.  MedRec is about more than patients or doctors, it is a component of a general healthcare environment.  

Second, the architecture of MedRec is general.  There is little that is health specific.  We envision that it can be a model for the management of individual identity and permissions in many circumstances where end-user control of identity and personal information across applications is important.  This can be a basis for social networks and as a convenience for individuals who want to simplify who knows what about them. There is no coinage or transaction inherent in MedRec; it is designed to be free and open.

Third, in keeping with the design ethos of the Viral Communications Research Group at the MIT Media Lab, the system can be adopted incrementally, organization-by-organization.  It is useful for internal management of records by hospital networks that consist of many independent providers and it scales to multiple, large-scale healthcare organizations.

MedRec was inspired by original work by Ariel Ekblaw and Asaf Azaria. The current version, which is a new architecture, is supported by a grant from the Robert Wood Johnson Foundation.  We use a blockchain that is maintained by medical providers who originate records to archive “smart contracts” that define access rights.  Other information is also stored on chain.  The goal of the program is to create a disinterested, non-profit, university-based system for patient control.  

Design

The architecture of MedRec is easily understood by analogy to the World Wide Web.  The web  consists of three elements:  An HTTP server that provides access to local data, the HTML protocol by which access is obtained and web elements are defined, and a browser that forms the interface.  Ideally, anyone and everyone could be a server and web browsers can draw from multiple ones to create a presentation.  The World Wide Web is by design a network rather than a client-server architecture even though in practice there are dominant servers.

In MedRec, the language is a set of contracts initiated by patients that define what entities or parties can access which records.  There are currently three types of contracts and more can be created.  The simplest is one that asserts that entity can access the records of patient A.  More complicated ones allow for intermediary healthcare proxies, or allow a pharmacy to access all prescription records for patient A from any healthcare provider.

We call the server equivalent a “full node.”  Full nodes are administrative members of the network.  They can append blocks to the chain, admit new administrative members, and distribute notifications submitted to or originated by them. Examples include requests for participation in a clinical or epidemiological study or record changes.  We use proof of authority to append blocks and the addresses of holders of that authority are also stored on chain.  New members with those rights are voted in by a majority of existing members.  This facility is part of the Ethereum Blockchain.

The interface is a local app run on a PC or phone.  It allows generation of contracts and polls providers for notifications.  There is an interface for a provider and one for a patient.  Patient interfaces are light nodes and may or may not contain a copy of the blockchain.  Third parties can also run an equivalent light node.  That may include research organizations, pharmacists, patients relatives, etc.

Operation

In this section, we show the work flow for three potential network constituents:  healthcare providers, patients, and third parties such as pharmacies and research organizations.

Every user in the MedRec network installs the software and creates a login account. New providers make proposals to a special smart contract that orchestrates the addition and removal of providers to the network. Existing providers vote on whether to accept these proposals. Patients form relationships by sharing their account ID (an Ethereum address) with medical providers. Once a relationship with a provider is formed, patients can enable other accounts with the power to view portions of the medical data stored by that provider.

Caveats, Assessment, and Future Work

There are several elements to adoption of a MedRec network that are subjects of further work and development.

Most important is the means by which providers adopt and interface to the system.  A provider, as operator of a full node, commits to run a program that grants access to their databases under the rules of MedRec contracts.  This entails an interfacing investment that can be significant.  For large providers who already use an existing patient management application, this need be done once for that system and others can then use it.  For smaller providers such as group practices, one must build an interface for each system that is in use.  

As with any blockchain implementation, important questions include who maintains the blockchain, what the trust model is, what threats are to be defended, and what consensus scheme is to be used.  In this case, the network is semi-public.  Anyone can join as a light node and be the predicate in a contract.  But only providers can authorize contracts and append to the blockchain.  Providers are trusted entities but we immunize the system against intrusions of their internal systems by requiring majority voting.

We argue that Ethereum-supported proof of authority mechanism is a robust solution.  The overhead of running a full node is small both in terms of management and allocation of resources.  Conversely, the advantages are large.  The open-source model allows us to evolve with needs and community desires.  These issues are assertions that will be tested at scale in real use.

A second issue is the nature of the patient interface.  We suspect that individual management of personal data is a chore akin to management of a retirement plan.  They are similar in that when we are young and healthy, we likely dedicate little energy to either retirement or healthcare.  It has been amply demonstrated that people devalue longterm or low probability events [Reference needed.]  A good interface may ameliorate this.  To date, the interface we have implemented is optimized to be simple, and encouraging. It allows for contract creation and deployment, visualization of the user’s network and the ability to fetch and view data from the remote database. As we add features that are common in commercial healthcare interfaces, we have to ensure that the system does not become a chore to use.  This will evolve in time.

Conclusion

We have created a blockchain-based system that serves a societal need without the intrusion of visible transactions or an application-specific coinage.  We substitute a network for a service and use the blockchain to manage that service.  There is no implicit economic associated with the work, nor any view of how society is organized.  The general nature of the solution is amenable to other cases where an open-source, distributed model is useful.  We hope that the system will evolve to serve the needs of medical community and societal health.