MedRec: Patient Control of Medical Record Distribution

Andrew Lippman, MIT; Nchinda Nchinda, Candidate for MS in Computer Science at MIT; Kallirroi Retzepi, Graduate Student, Viral Communications group at MIT; and Agnes Cameron, Master’s Student, Viral Communications group at MIT

IEEE Blockchain Technical Briefs, July 2018

 

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 Lab1.

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 Azaria2. 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 records3.  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 chain4.  New members with those rights are voted in by a majority of existing members.  This facility is part of the Ethereum Blockchain5.

The interface is a local app run on a PC or phone6.  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.

Figure 1

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 long term or low probability events.  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.  The code is accessible at https://github.com/mitmedialab/medrec

 

[1] https://www.bidmc.org/about-bidmc/news/2018/05/bidmc-launches-htech

[2] Azaria, Asaph, Ariel Ekblaw, Thiago Vieira, and Andrew Lippman. "MedRec: Using Blockchain for Medical Data Access and Permission Management." In Open and Big Data (OBD), International Conference on, pp. 25-30. IEEE, 2016

[3] http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/
smart_contracts_2.html

[4] De Angelis et al.  PBFT vs Proof-of-Authority:  Applying the CAP Theorem to Permissioned Blockchain,
ceur-ws.org/Vol-2058/paper-06.pdf

[5] https://github.com/ethereum/wiki/wiki/White-Paper

[6] This give the app the appearance of a web-app and runs on diverse devices: https://electronjs.org/

 


 

Andy LippmanAndy Lippman is a Senior Scientist at MIT and founding associate director of the MIT Media Lab. He got his BS and MS at MIT, and PhD at EPFL, Lausanne. He has worked for 45 years on personal computing, networking and interactive systems. In the 1980s he directed the “Movie-Map” project that presaged Google's streetview. He helped pioneer visual computing and communications systems such as MPEG and digital HDTV. His current research group addresses Viral Communications, systems that are often peer-to-peer and can grow organically through adoption rather than a priori agreement. He has studied blockchains and digital currency for six years. Some recent work involves developing personal networks for social action and a blockchain-based identity control system for medical records.

 

Nchinda NchindaNchinda Nchinda is a Candidate for MS in Computer Science at the  Massachusetts Institute of Technology. His work has covered on cybersecurity and distributed systems, focusing on blockchain technology. He is a fan of real time multiplayer strategy games and an avid, albeit unskilled Dota2 player. Nchinda is high functioning introvert with a well-developed imagination.

 

 

Kalli RetzepiKallirroi Retzepi is a graduate student at the Viral Communications group at the MIT Media Lab. She has a background in engineering, neuroscience and design. She is interested in the decentralized Web, online interfaces, user behaviors and how to change them.

 

 

Agnes CameronAgnes Cameron is a master’s student in the Viral Communications group. This year she has been part of the MedRec team, and she is more generally interested in decentralised and self-organising network systems. Originally from the UK, she holds an MEng in Information and Computer Engineering from the University of Cambridge, specialising in self-organising systems and holography.

 

 

Editor:

Weisong ShiWeisong Shi is a Charles H. Gershenson Distinguished Faculty Fellow and a Professor of Computer Science at Wayne State University where he directs the Mobile and Internet Systems Laboratory, the Connected and Autonomous Driving Laboratory, and Wayne State Wireless Health Initiative. He is also the Program Director of the Cyber-Physical Systems (CPS) program at Wayne State. He is an IEEE Fellow and an ACM Distinguished Scientist.

Dr. Shi received his B. E. from Xidian University in 1995, and Ph.D. degree from the Chinese Academy of Sciences in 2000, both in Computer Engineering. He authored one book, edited one book, published over 180 publications cited by 5000+ times (H-index: 38), received research support from and consulted for a variety of governmental and industrial organizations, such as National Science Foundation, Department of Veteran Affairs, Air Force Research Laboratory, Gates Foundation, Swedish Research Council, Michigan Life Science Corridor, Facebook, Intel, Chrysler and so on. He is the inaugural Editor-in-Chief of Smart Health Journal, the Associate Editor-in-Chief of IEEE Internet Computing Magazine. He had served as the chair of the IEEE Computer Society Technical Committee on the Internet (TCI) during 2012-2016, and serves on the editorial board of IEEE Transactions on Services Computing, ACM Transactions on Internet of Things, IEEE Internet Computing, Elsevier Sustainable Computing, and so on.

Dr. Shi is a recipient of the National Outstanding Ph.D. dissertation award of China (2002), the NSF CAREER award (2007), Wayne State University Career Development Chair award (2009), Charles H. Gershenson Distinguished Faculty Fellow (2015), College of Engineering Faculty Research Excellence Award (2016), the Best Paper award of ICWE'04, IEEE IPDPS'05, HPCChina'12 and IEEE IISWC'12, the Best Paper Nominee award of ACM UbiComp'14, the Best Student Paper Award of IEEE HealthCom'15, the Best Paper Award from IEEE eHealth in 2017. This month, he received the Most Downloaded Publication Award for his paper “The Promise of Edge Computing” published on IEEE Computer Magazine.