Usability of MedRec: Blockchain in Healthcare System Design (IMAT5209)

This report examines MedRec, a novel, decentralized Electronic Health Record (EHR) management system utilizing blockchain technology. The system aims to provide patients with a comprehensive and immutable log of their medical information, ensuring easy access across various providers and treatment sites. The report details the system's architecture, including its modular design that integrates with existing local data storage solutions, and its use of smart contracts on an Ethereum blockchain to manage authentication, confidentiality, and data sharing. It also discusses the incentive model for medical stakeholders to participate in the network as blockchain "miners," providing them access to aggregate, anonymized data in exchange for securing the network. The report further explores the system's usability requirements, and provides an evaluation of the software, concluding with findings and references to support the research and development of MedRec. The report highlights the potential of blockchain in health IT and research, with the goal of exposing a working prototype in preparation for field tests.

Running head: HUMAN FACTORS IN SYSTEM DESIGN
HUMAN FACTORS IN SYSTEM DESIGN
Name of the Student:
Name of the University:
Author Note:

1HUMAN FACTORS IN SYSTEM DESIGN
Executive Summary
A long-standing focus on compliance has traditionally constrained development of fundamental
design changes for Electronic Health Records (EHRs). We now face a critical need for such
innovation, as personalization and data science prompt patients to engage in the details of their
healthcare and restore agency over their medical data. In this paper, we propose MedRec: a
novel, decentralized record management system to handle EHRs, using blockchain technology.
Our system gives patients a comprehensive, immutable log and easy access to their medical
information across providers and treatment sites. Leveraging unique blockchain properties,
MedRec manages authentication, confidentiality, accountability and data sharing—crucial
considerations when handling sensitive information. A modular design integrates with providers'
existing, local data storage solutions, facilitating interoperability and making our system
convenient and adaptable. We incentivize medical stakeholders (researchers, public health
authorities, etc.) to participate in the network as blockchain “miners”. This provides them with
access to aggregate, anonymized data as mining rewards, in return for sustaining and securing
the network via Proof of Work. MedRec thus enables the emergence of data economics,
supplying big data to empower researchers while engaging patients and providers in the choice to
release metadata. The purpose of this paper is to expose, in preparation for field tests, a working
prototype through which we analyze and discuss our approach and the potential for blockchain in
health IT and research.

2HUMAN FACTORS IN SYSTEM DESIGN
Table of Contents
Introduction......................................................................................................................................3
Discussion:.......................................................................................................................................4
What is Blockchain? How it works?...........................................................................................5
Use cases or components of the system.......................................................................................6
1. Registrar contract (RC).................................................................................................6
2. Patient Provider Relationship contract (PPR)...............................................................7
3. Summary contract (SC).................................................................................................8
4. System node description................................................................................................9
5. Backend API library......................................................................................................9
6. Ethereum client............................................................................................................10
7. Database keeper...........................................................................................................10
8. EHR Manager..............................................................................................................11
9. MedRec blockchain mining.........................................................................................11
Usability requirements...............................................................................................................11
Evaluation of the software (Methods and Procedure)...............................................................13
Conclusion and Findings...............................................................................................................15
References:....................................................................................................................................17

3HUMAN FACTORS IN SYSTEM DESIGN

4HUMAN FACTORS IN SYSTEM DESIGN
Introduction
Today’s e-hospital management environment requires that interactive systems exhibit abilities
such as autonomy, adaptive and collaborative behavior, and inferential capability. Such abilities
are based on the knowledge about users and their tasks to be performed. To adapt users’ input
and tasks an interactive system must be able to establish a set of assumptions about users’
profiles and task characteristics, which is often referred as user models. However, to develop a
user model an interactive system needs to analyze users’ input and recognize the tasks and the
ultimate goals users trying to achieve, which may involve a great deal of uncertainties.
The interactive system chosen in this report is the use of blockchain in healthcare used for
accessing data in electronic health records (EHR) and medical research. The data is easily
available to patients and is high protected and securely kept via the blockchain security
measures. EHRs were never designed to manage multi-institutional, life time medical records.
Patients leave data scattered across various organizations as life events take them away from one
provider's data silo and into another. In doing so they lose easy access to past data, as the
provider, not the patient, generally retains primary stewardship (either through explicit legal
means in over 21 states, or through default arrangements in the process of providing care).
Through the HIPAA Privacy Rule, providers can take up to 60 days to respond (not necessarily
to comply) to a request for updating or removing a record that was erroneously added. Beyond
the time delay, record maintenance can prove quite challenging to initiate as patients are rarely
encouraged and seldom enabled to review their full record. Patients thus interact with records in
a fractured manner that reflects the nature of how these records are managed.

5HUMAN FACTORS IN SYSTEM DESIGN
Our blockchain implementation addresses the four major issues highlighted above: fragmented,
slow access to medical data; system interoperability; patient agency; improved data quality and
quantity for medical research. We build on the work of Zyskind et al. to assemble references to
data and encode these as hashed pointers onto a blockchain ledger. We then organize these
references to explicitly create an accessible bread crumb trail for medical history, without storing
raw medical data on the blockchain. Our system supplements these pointers with on-chain
permissioning and data integrity logic, empowering individuals with record authenticity,
auditability and data sharing. We build robust, modular APIs to integrate with existing provider
databases for interoperability. A novel data-mining scheme is proposed to sustain the MedRec
network and bring open, big data to medical researchers. We present MedRec not as the panacea
for medical record management, but as a foray into this space to demonstrate innovative EHR
solutions with blockchain technology.
Discussion:
For MedRec, the block content represents data ownership and viewership permissions shared by
members of a private, peer-to-peer network. Blockchain technology supports the use of “smart
contracts,” which allow us to automate and track certain state transitions (such as a change in
viewership rights, or the birth of a new record in the system). Via smart contracts on an
Ethereum blockchain, we log patient-provider relationships that associate a medical record with
viewing permissions and data retrieval instructions (essentially data pointers) for execution on
external databases. We include on the blockchain a cryptographic hash of the record to ensure
against tampering, thus guaranteeing data integrity. Providers can add a new record associated
with a particular patient, and patients can authorize sharing of records between providers. In both
cases, the party receiving new information receives an automated notification and can verify the

6HUMAN FACTORS IN SYSTEM DESIGN
proposed record before accepting or rejecting the data. This keeps participants informed and
engaged in the evolution of their records.
MedRec prioritizes usability by also offering a designated contract which aggregates references
to all of a user's patient-provider relationships, thus providing a single point of reference to check
for any updates to medical history. We handle identity confirmation via public key cryptography
and employ a DNS-like implementation that maps an already existing and widely accepted form
of ID (e.g. name, or social security number) to the person's Ethereum address. A syncing
algorithm handles data exchange “off-chain” between a patient database and a provider database,
after referencing the blockchain to confirm permissions via our database authentication server.
What is Blockchain? How it works?
Originally designed for keeping a financial ledger, the blockchain paradigm can be extended to
provide a generalized framework for implementing decentralized compute resources. Each
compute resource can be thought of as a singleton state-machine that can transition between
states via cryptographically-secured transactions. When generating a new state-machine, the
nodes encode logic which defines valid state transitions and upload it onto the blockchain. From
there on, the blocks journal a series of valid transactions that, when incrementally executed with
the state from the previous block, morph the state-machine into its current state. The Proof of
Work consensus algorithm and its underlying peer-to-peer protocol secure the state-machines'
state and transitioning logic from tampering, and also share this information with all nodes
participating in the system. Nodes can therefore query the state- machines at any time and obtain
a result which is accepted by the entire network with high certainty.
This transaction-based state-machine generalization of the blockchain is informally referred to as
smart contracts. Ethereum is the first to attempt a full implementation of this idea. It builds into

7HUMAN FACTORS IN SYSTEM DESIGN
the blockchain a Turing-complete instruction set to allow smart-contract programming and a
storage capability to accommodate on-chain state. We regard the flexibility of its programming
language as an important property in the context of EHR management. This property can enable
advanced functionality (multi-party arbitration, bidding, reputation, etc.) to be coded into our
proposed system, adapting to comply with differences in regulation and changes in stakeholders
needs.
We utilize Ethereum's smart contracts to create intelligent representations of existing medical
records that are stored within individual nodes on the network. We construct the contracts to
contain metadata about the record ownership, permissions and data integrity. The blockchain
transactions in our system carry cryptographically signed instructions to manage these properties.
The contract's state- transition functions carry out policies, enforcing data alternation only by
legitimate transactions. Such policies can be designed to implement any set of rules which
govern a particular medical record, as long as it can be represented computationally. For
example, a policy may enforce that separate transactions representing consent are sent from both
patients and care providers, before granting viewing permissions to a third party.
Use cases or components of the system
1. Registrar contract (RC)
This global contract maps participant identification strings to their Ethereum address identity
(equivalent to a public key). We intentionally use strings rather than the cryptographic public key
identities directly, allowing the use of already existing form of ID. Policies coded into the
contract can regulate registering new identities or changing the mapping of existing ones.
Identity registration can thus be restricted only to certified institutions. The RC also maps

8HUMAN FACTORS IN SYSTEM DESIGN
identity strings to an address on the blockchain, where a special contract described below, called
the Summary Contract, can be found.
2. Patient Provider Relationship contract (PPR)
A Patient-Provider Relationship Contract is issued between two nodes in the system when one
node stores and manages medical records for the other. While we use the case of care provider
and patient, this notion extends to any pairwise data stewardship interaction. The PPR defines an
assortment of data pointers and associated access permissions that identify the records held by
the care provider. Each pointer consists of a query string that, when executed on the provider's
database, returns a subset of patient data. The query string is affixed with the hash of this data
subset, to guarantee that data have not been altered at the source. Additional information
indicates where the provider's database can be accessed in the network, i.e. hostname and port in
a standard network topology. The data queries and their associated information are crafted by the
care provider and modified when new records are added. To enable patients to share records with
others, a dictionary implementation (hash table) maps viewers’ addresses to a list of additional
query strings. Each string can specify a portion of the patient's data to which the third party
viewer is allowed access.
Our prototype demonstrates this design with SQL data queries. In a simple case, the provider
references the patient's data with a simple SELECT query conditioned on the patient's address.
For patients, we designed a tool which allows them to check off fields they wish to share through
our graphical interface. Under the hood, our system formulates the appropriate SQL queries and
uploads them to the PPR on the blockchain. Note that by using generic strings our design can
robustly interface with any string queried database implementation. Hence, it can conveniently
integrate with existing provider data storage infrastructure. At the same time, patients are

9HUMAN FACTORS IN SYSTEM DESIGN
enabled with fine-grained access control of their medical records, selecting essentially any
portion of it they wish to share.
3. Summary contract (SC)
This contract functions as a bread crumb trail for participants in the system to locate their
medical record history. It holds a list of references to Patient-Provider Relationship contracts
(PPRs), representing all the participant's previous and current engagements with other nodes in
the system. Patients, for instance, would have their SC populated with references to all care
providers they have been engaged with. Providers, on the other hand, are likely to have
references to patients they serve and third-parties with whom their patients have authorized data
sharing. The SC persists in the distributed network, adding crucial backup and restore
functionality. Patients can leave and rejoin the system multiple times, for arbitrary periods, and
always regain access to their history by downloading the latest blockchain from the network. As
long as there are nodes participating in the network, the blockchain log is maintained.
The SC also implements functionality to enable user notifications. Each relationship stores a
status variable. This indicates whether the relationship is newly established, awaiting pending
updates and has or has not acknowledged patient approval. Providers in our system set the
relationship status in their patients' SC whenever they update records or as part of creating a new
relationship. Accordingly, the patients can poll their SC and be notified whenever a new
relationship is suggested or an update is available. Patients can accept, reject or delete
relationships, deciding which records in their history they acknowledge.

10HUMAN FACTORS IN SYSTEM DESIGN
4. System node description
We design the components of our system nodes to integrate with existing EHR infrastructure.
We assume that many nodes, and in particular care providers, already trustfully manage
databases with patient data stored on servers with network connectivity. Our design introduces
four software components: Backend Library, Ethereum Client, Database Gatekeeper and EHR
Manager. These can be executed on servers, combining to create a coherent, distributed system.
We provide a prototype implementation of these components that integrates with a SQLite
database and is managed through our web user interface.
5. Backend API library
We construct multiple utilities, bundled in a backend library, to facilitate the system's operation.
Our library abstracts the communications with the blockchain and exports a function-call API.
Record management applications and their user interfaces can thus avoid the hurdles of working
directly with the blockchain. One such hurdle is verifying that each sent transaction is accepted
with high confidence by the network. Our library automatically handles the uncertainty of when
transactions are mined and deals with cases when they are discarded. The backend library
interacts with an Ethereum client to exercise the low-level formatting and parsing of the
Ethereum protocol.
Steps 1 and 2 in Figure 2 illustrate our backend implementation of a scenario where a provider
adds a record for a new patient. Using the Registrar Contract on the blockchain, the patient's
identifying information is first resolved to their matching Ethereum address and the
corresponding Summary Contract is located. Next, the provider uploads a new PPR to the
blockchain, indicating their stewardship of the data owned by the patient's Ethereum address.
The provider node then crafts a query to reference this data and updates the PPR accordingly.

11HUMAN FACTORS IN SYSTEM DESIGN
Finally, the node sends a transaction which links the new PPR to the patient's Summary Contract,
allowing the patient node to later locate it on the blockchain.
6. Ethereum client
This component implements the full functionality required to join and participate in the
Ethereum blockchain network. This handles a broad set of tasks, such as connecting to the peer-
to-peer network, encoding and sending transactions and keeping a verified local copy of the
blockchain. For our prototype implementation we use PyEthereum and the PyEthApp client.
We modify the client to be aware of our mapping of identity and addresses. We then implement a
service to locate the node's Summary Contract (SC), via Registrar Contract address lookup. This
service runs continuously within the client to monitor real-time changes to the SC. In the event
of an update, the service signals the EHR Manager to issue a user notification and, if necessary,
sync the local database..
7. Database keeper
The Database Gatekeeper implements an off-chain, access interface to the node's local database,
governed by permissions stored on the blockchain. The Gatekeeper runs a server listening to
query requests from clients on the network. A request contains a query string, as well as a
reference to the blockchain PPR that warrants permissions to run it. The request is
cryptographically signed by the issuer, allowing the gatekeeper to confirm identities. Once the
issuer's signature is certified, the gatekeeper checks the blockchain contracts to verify if the
address issuing the request is allowed access to the query. If the address checks out, it runs the
query on the node's local database and returns the result over to the client.