MedRec IEEE submission

Document to outline the MedRec architecture, for a new white paper.
Updated Jun 18, 2018 (1 Older Version)chevron-down
36 Discussions (#public)
4 Contributors
MedRec IEEE submission
··

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.


Discussions


Labels
Sort
New Discussion on Jun 3
NN
Nchinda Nchinda: remove light
New Discussion on Jun 1
Kalli Retzepi: we could improve and then add the graphic you used for your slides here
New Discussion on Jun 1
Kalli Retzepi:
New Discussion on Jun 1
Kalli Retzepi: I like the analogy of the Swiss bank but in writing it seems a bit too informal?
New Discussion on Jun 1
Kalli Retzepi: I really don’t think we should be doing that…but thats me
Andrew Lippman: stet
New Discussion on Jun 1
Kalli Retzepi: it does more than that “It allows for contract creation and deployment, visualization of the user’s network and the ability to request and view data from the remote database.”
Andrew Lippman: FIne, make the edit!
New Discussion on Jun 1
Kalli Retzepi: simple, inviting and easy to navigate.
Andrew Lippman: stet
New Discussion on Jun 1
Kalli Retzepi: I think this is a bit convoluted. by “large providers” you mean hospitals? if so, are you referring to the cost of making sure medRec talks to their database?
NN
Nchinda Nchinda: yesyes
Andrew Lippman: MIT is a large provider but not a hospital. It doesn’t equate to hospitals.
New Discussion on Jun 1
Kalli Retzepi: “integrate with”? we are using the word “interface” in a different context above…
New Discussion on Jun 1
Kalli Retzepi: patient apps are light nodes
NN
Nchinda Nchinda: we should leave out the mention of light nodes, both because then we don’t have to explain the difference between light/full and because in the MedRec of today every node is a full node because eve...
New Discussion on Jun 1
Kalli Retzepi: Different UI designs afford logging in as a provider or as a user.
Andrew Lippman: That is not a good idea. I always thought that one was in there to facilitate our demos. There should be a different interface for each. They do different things and one does not commonly change...
New Discussion on Jun 1
Kalli Retzepi: deployed?
Andrew Lippman: Stet
New Discussion on Jun 1
Kalli Retzepi: distributed network
Andrew Lippman: Stet
Andrew Lippman: stet
New Discussion on Jun 1
Kalli Retzepi: instead of university-based, institution-based?
New Discussion on Jun 1
AC
Agnes Cameron: “serve“ appears twice:maybe:“simultaneously serve the needs of the medical community, and contribute to improved societal health“
Kalli Retzepi: hm this sound too medicine-focused, maybe we can remind the reader that the power of the system is that it should be data-agnostic?
Andrew Lippman: OK
New Discussion on Jun 1
AC
Agnes Cameron: maybe mention this a bit further up too? If it appears for the first time in the conclusion it seems a bit incongruous. Could go well in the discussion about open source maybe.
New Discussion on Jun 1
AC
Agnes Cameron: This doesn’t really support the robustness argument: indeed, being easy to run a node somewhat contradicts it. Maybe a sentence in-between like:“We propose an off-chain system of authentication and...
New Discussion on Jun 1
AC
Agnes Cameron: “…that acts as the patient’s Ethereum wallet” ? (don’t know if this should go here but might be relevant if so)
New Discussion on Jun 1
AC
Agnes Cameron: “many of these servers to create a presentation“
Kalli Retzepi: “to populate an interface”?
New Discussion on Jun 1
AC
Agnes Cameron: This is a bit unclear: the providers don’t use the records to define access rights. Maybe:“We define a medical provider as an entity that generates medical records. We use a blockchain that is main...
New Discussion on Jun 1
AC
Agnes Cameron: Asaph I think?
New Discussion on Jun 1
AC
Agnes Cameron: how about:“We use an Ethereum blockchain maintained by trusted providers to create a distributed solution that avoids the problem of Swiss banks, bringing records together on the patient end whilst...
New Discussion on Jun 1
AC
Agnes Cameron: This is a bit long + unclear, maybe something like:“As an alternative, we propose a non-commercial distributed system that allows patients control over who may access their records. We enable this ...