Skip to main content
SearchLogin or Signup

MedRec IEEE submission

Document to outline the MedRec architecture, for a new white paper.

Published onJun 05, 2018
MedRec IEEE submission

MedRec: Patient Control of Medical Record Distribution


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.  


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.


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.


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.

Nchinda Nchinda: remove light
Kalli Retzepi: we could improve and then add the graphic you used for your slides here
Kalli Retzepi:
Kalli Retzepi: I like the analogy of the Swiss bank but in writing it seems a bit too informal?
Kalli Retzepi: I really don’t think we should be doing that…but thats me
Andrew Lippman: stet
Kalli Retzepi: simple, inviting and easy to navigate.
Andrew Lippman: stet
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?
Nchinda Nchinda: yesyes
+ 1 more...
Kalli Retzepi: “integrate with”? we are using the word “interface” in a different context above…
Kalli Retzepi: patient apps are light nodes
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 everyone is using the same client.
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 roles.
Kalli Retzepi: deployed?
Andrew Lippman: Stet
Kalli Retzepi: distributed network
Andrew Lippman: Stet
+ 1 more...
Kalli Retzepi: instead of university-based, institution-based?
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.
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 proof that must take place every time a new provider is added as a peer, ensuring that each voting member can be sure of the mapping of the provider’s address to their real-world identity“? or something else. This isn’t a mechanism we’ve discussed in any great detail, but would need to form part of the final system if we’re going to use pure PoA. Ultimately it’s an oracle problem: how do you ensure that the eth address maps to the real-world entity of the hospital? There could even be some PGP-style group authentication from existing providers.
Agnes Cameron: “…that acts as the patient’s Ethereum wallet” ? (don’t know if this should go here but might be relevant if so)
Agnes Cameron: “many of these servers to create a presentation“
Kalli Retzepi: “to populate an interface”?
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 maintained by these providers to archive smart contracts, which are used to define access rights to data.”
Agnes Cameron: Asaph I think?
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 avoiding the risks of centralization. The system has been tested with… “
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 control using a network solution, where medical providers make data available on demand, at the behest of their patients.”