See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/349213820

Decentralized Data Access with IPFS and Smart Contract Permission

Management for Electronic Health Records

Conference Paper · February 2021

DOI: 10.1007/978-3-030-66498-5_1

CITATIONS READS

5 973

2 authors:

Michaël Verdonck Geert Poels

Ghent University Ghent University
31 PUBLICATIONS 219 CITATIONS 324 PUBLICATIONS 3,747 CITATIONS

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Value Network Software Ontology View project

Development of a modeling language for flexible and knowledge-intensive processes View project

All content following this page was uploaded by Michaël Verdonck on 11 February 2021.

The user has requested enhancement of the downloaded file.

Decentralized Data Access with IPFS and Smart Contract
Permission Management for Electronic Health Records
Michaël Verdonck, Geert Poels
Faculty of Economics and Business Administration, Ghent University;
[email protected];
[email protected]

Abstract. Through the adoption of smart contracts as a permission management

database for electronic health records (EHRs), blockchain technology has intro-
duced several advantages such as traceability, transparency and enhanced secu-
rity. Despite that the permissions to a patient’s record are being managed in a
more secure and decentralized manner, these records remain stored within the
servers of local hospitals and health providers. As such, it remains perfectly pos-
sible to query an EHR from within the hospital infrastructure, without the query
being stored or even be detected by the smart contract. Moreover, the introduc-
tion of smart contracts to facilitate the management of permissions results in a
new challenge: how to verify an actor’s identity with public key cryptography
and the handling of stolen or lost private keys. In this article, we propose a dif-
ferent design where we integrate the research performed by previous efforts to
adopt blockchain technology for the management of permissions of EHRs to-
gether with the InterPlanetary File system (IPFS) as a peer-to-peer distributed
network to provide decentralized storage for EHRs, and a governing body that
performs the task of public key governance and identity verification.

Keywords: Blockchain technology, smart contracts, electronic health records,

IPFS, public key governance.

1 Introduction

Blockchain technology has given rise to transform current health care systems and pro-
cesses by placing the patient at the center of the health system and increasing the secu-
rity, privacy, and interoperability of health data. This technology has the potential to
provide a new model for health information exchange by making electronic health rec-
ords (EHRs) more efficient and secure [1]. Adopting healthcare information systems
and EHRs result in various benefits for the healthcare sector such as real-time decision
support for clinicians or making critically clinical information available to health pro-
viders [2]. Besides healthcare advantages, health information exchange in the form of
EHRs are estimated to have substantial financial benefits [3]. Despite the many benefits
that are associated with adopting EHRs, the transition to digitally stored and shared
records holds various challenges regarding the privacy and security of medical data [4,
5]. An EHR is typically stored by and spread among multiple hospitals, clinics, and
health providers [6]. As such, these providers maintain primary access to the records,
preventing easy access to past data by patients or other healthcare providers. This
2

results in situations where patients and healthcare providers alike interact with a frag-
mented and incomplete health record. Moreover, data that is stored electronically is
prone to be copied, distributed, and mined for confidential information. Securing sen-
sitive data is a tedious and costly endeavour and is not considered as the core activity
of a typical healthcare provider, whom often lack the proper resources to do so. Data
breaches and the consequent loss or misappropriation of data has already exposed pa-
tients’ confidential information and have led to hefty fines for hospitals1.
In order to tackle these problems, recent research efforts have been investigating the
application of distributed ledger technology, more in particular blockchain technology.
While originally introduced as a technology to support new forms of digital currency
[7], blockchain has evolved as a promising foundation to support any type of transac-
tions in society. In its essence, a blockchain is a data structure that is composed of an
ordered, back-linked list of blocks of transactions [8]. Through the years, several new
blockchain technologies have emerged, that act both as a database that records data
transactions between parties, while also providing a computational platform for execut-
able programs, i.e., smart contracts. Smart contracts can carry and conditionally trans-
fer digital assets or tokens between parties [9]. Since they are stored and executed on
the blockchain platform, they can be publicly viewed (assuming a public blockchain)
by parties having access to this platform. This feature also guarantees that the execution
of a smart contract runs in a deterministic and decentralized manner. Consequently,
these unique features give blockchains and smart contracts certain advantages such as
traceability, transparency and enhanced security. While certain research efforts [10–12]
have already managed to leverage blockchain technology to enhance the security of an
EHR system – mainly through the adoption of a smart contract as a permission man-
agement database – the fundamental problems associated with EHR systems persist.
Despite that these permissions to a patient’s record are being managed in a more secure
and decentralized manner, these records remain stored within the servers of local hos-
pitals and health providers. As such, it remains perfectly possible to query an EHR from
within the hospital infrastructure, without the query being stored or even be detected
by the smart contract.
Moreover, introducing additional decentralization and adopting the public key cryp-
tography mechanism for authentication implies however several important design de-
cisions concerning the governance of public and private keys. Since any entity in a
decentralized system is identified by their corresponding public key (both requestor and
patient), the consequential loss or theft of the private key results in a complete loss of
control of a patient’s EHR. As there is no central authority, there is no way for a patient
to regain access to the electronic health record. Moreover, the loss or theft of the private
key corresponding to a healthcare provider can result in a malicious requestor obtaining
access to numerous EHRs due to patients unknowingly accepting access to their
healthcare records. Furthermore, an additional issue that arises through public key cryp-
tography is the verification associated to one’s identity that belongs to a particular pub-
lic key. Notwithstanding the theft of keys by malicious actors, how can we verify and

1
https://eurocloud.org/news/article/fine-of-eur-460000-imposed-on-dutch-haga-hospital-by-
dutch-data-protection-officer-the-first-dutch/
 3

safely presume that a licensed healthcare provider is associated with a certain public
key? Therefore, it seems that moving to a fully decentralized system imposes the prob-
lematic issue of verifying a requestor’s or patient’s identity associated with a particular
public key, and the governance of private keys including their theft or loss. Hence, the
existing fundamental issues of EHR systems are maintained in such a way that: (1) in
essence, a patient has no absolute privacy-control over his or her own EHR and (2)
EHR data remains stored with different providers, each remaining responsible for the
security and privacy of a patient’s sensitive data. Moreover, the introduction of smart
contracts to facilitate the management of permissions results in a new challenge: (3)
how to verify an actor’s identity with public key cryptography and the handling of sto-
len or lost private keys.
Based upon these issues, we formulate the following research question as a basis for
this article: how can we design a blockchain-based system that provides a decentralized
and secure way of managing permissions while enabling patients to have full privacy-
control and storage of their own electronic health record? Therefore, as the main con-
tribution of this article, we seek to answer this research question by proposing a novel
and more decentralized design to enhance the privacy-control of a patient over his or
her own record, while also maintaining the additional security that arrives through im-
plementing smart contracts as a permission management database. Adopting a more
decentralized design gives rise to challenges as how to deal with the immutability of
data on public blockchains, and regulatory frameworks such as the General Data Pro-
tection Regulation (GDPR, EU), which asserts the right of the user to have control over,
and access to their data upon request, as well as the ‘right to be forgotten’. Similar
legislation is also formulated by the HIPAA Privacy Rule (USA). Hence, if personal
data is stored directly on the chain, this means that the EHR system would be unable to
fully comply with the required legislation. In this article, we propose a design based
upon the InterPlanetary File System (IPFS) as a decentralized storage solution that also
complies with the existing legislation.
An additional contribution of this article is that we will provide a process-aware
perspective of how EHR request are handled through smart contracts and blockchain
technology. While most research efforts demonstrate their architecture and design
through a more data-driven representation, this article seeks to highlight the process
that takes place while handling EHR requests with blockchain technology.
In section 2, we will discuss several research efforts that each propose a rather dif-
ferent design to manage EHRs through blockchain technology. Next, in section 3, we
will provide a more detailed description in the form of a process description of the
issues that can still be identified with adopting smart contracts for decentralized per-
mission management of EHRs. In section 4 we describe how a distributed peer-to-peer
network, i.e. IPFS, can be adopted to provide decentralized storage for EHRs. Moreo-
ver, due to the additional layer of decentralization, we propose the role of a governing
body to aid with public key governance and identity verification. Section 5 then com-
pares this new design with the existing research efforts that we have discussed in section
2, while also providing a process model to illustrate their differences. Finally, in section
6 we conclude the research of this article and discuss in more detail the implications of
the proposed design decision and the associated limitations.
4

2 Related Research

In this section we aim to discuss several relevant research efforts that have been pub-
lished to provide a solution to the security issues that occur with EHR management
systems through the adoption of blockchain technology. We haven choses these spe-
cific research efforts since they each propose a rather different architecture and design
to implement blockchain technology for the management of EHRs.
One solution that implements a public blockchain to EHR management is MedRec
[10]. MedRec is designed as a decentralized record management system to handle
EHRs, using the Ethereum blockchain. More specifically, the system assembles refer-
ences to disparate medical data and encodes these onto the Ethereum ledger. These
references are organized to create an accessible ‘bread crumb trail’ for medical history.
Moreover, the MedRec system supplements these pointers with on-chain permissioning
and data integrity logic, as such empowering individuals with record authenticity, au-
ditability and data sharing. Additionally, the modular design of MedRec enables APIs
to integrate with existing provider databases for interoperability. An important empha-
sis of MedRec is to create a data-mining scheme in order to bring open, big data to
medical researchers.
Another solution proposed by Fan et al. [11] and given the name Medblock applies
blockchain technology as a type of index database, that stores encrypted summary data
of a patient’s data from a specific healthcare provider. Patients can then query the block-
chain for finding certain data at the server of a specific healthcare provider, where their
data is encrypted with an encryption key. Key in their design is a central, governing
role called the Certificate Authority that can be seen as both a system administrator and
an authority management agency. It safeguards the blockchain network from malicious
nodes and holds the private keys of patients.
Xia et al. [12] propose a different architecture, more specifically a data sharing
model that relies on cloud service providers that adopt the blockchain. Their design
employs the use of smart contracts and an access control mechanism to effectively trace
the behavior of a patient’s data as well as revoke access to violated rules and permis-
sions on data. Their proposed system – i.e. MeDShare – relies on big data entities and
their adoption of blockchain to provide data provenance, auditing, and control for
shared medical data in cloud repositories.
The above-mentioned research efforts have successfully managed to improve secu-
rity of EHRs through the implementation of smart contracts to manage the permissions
of a patient’s EHR and the immutable ledger to store these granted/revoked permis-
sions. Nonetheless, several fundamental issues remain unsolved. While permissions are
managed through smart contracts, the actual EHR is still stored in a centralized manner,
either with the care provider or with a data custodian such as a big data entity. For
instance, MedRec assumes that many care providers already trustfully manage their
databases. Their design therefore allows caretakers to store patient’s EHRs within their
own databases and servers. Every healthcare provider is expected to implement an off-
chain (i.e. outside the blockchain) gatekeeper to manage access to patient data of that
particular provider. Hence, access to patient files are managed and guarded offside the
blockchain, which defeats the purpose of utilizing blockchain technology. As such, it
 5

remains perfectly possible to query an EHR from within the hospital data infrastructure,
without that this query would be recorded or even detected by the smart contract or
blockchain. A similar design can be found within the MedBlock and MedShare sys-
tems. Within the architecture of MedBlock, national hospitals fulfill the major tasks in
their system. National hospitals are expected to arrange the encrypted summaries of
EHRs uploaded by the sub-area community hospitals and the various departments. Af-
ter sorting the data, a national hospital is then required to pack this sorted data into
blocks and send a request to consensus nodes to add blocks on the according block-
chain. MedShare relies on big data entities and cloud providers to store the medical data
on their existing database infrastructure layer. They require these data providers to
truthfully register any modifications of views of a patient’s data to the smart contract.
The authors further explicitly assume that these database systems are only accessible
by authorized personnel of the respective companies. If patient data remains stored in
a centralized manner, this clearly defeats the purpose of adopting a decentralized per-
mission management database. We cannot exclude that off-chain search queries are
being performed within these centralized databases.
Moreover, another issues that arises with the adoption of smart contracts and block-
chain technology to manage the permissions of EHRs, is the reliance of the system on
the private/public key cryptography for authentication. Patients and requestors alike are
represented in the system with a public key. While for instance MedShare specifies that
requestors and patients are responsible for generating and managing their own keys, it
does not describe how the system will handle the loss or theft of a private key by for
example a patient. Not only would this lead to a full loss of control of a patient’s EHR,
in the case of a healthcare provider that loses its private keys to a malicious actor, this
would result in the malicious actor obtaining access to numerous EHRs. To deal with
certain situations, MedShare proposes that the Certificate Authority generates and man-
ages the private keys of requestors and patients. This solution however results in one
central authority managing all private keys of every participant, which strongly reduces
the decentralized character of the design and places a strong vulnerability on the central
authority. In the section below, we will describe in more detail the process that takes
place when implementing a smart contract for permission management and identify the
pitfall in this design. Next, we will propose a different design, one that aims to alleviate
the issues associated with the current process of applying smart contracts for EHR per-
mission management.

3 Process of Smart Contracts for Decentralized Permission

Management

As to give an overall process perspective on how smart contracts are currently being
applied to manage the permissions to a patient’s EHR, we have created an abstract
business process model with the Business Process Model and Notation (BPMN) of how
requests are being handled. As demonstrated in Figure 1, we can identify three parties:
the patient, the requestor of a patient’s EHR (e.g. the healthcare provider) and a smart
contract (which is executed on a public blockchain). Note that for the sake of abstraction
6

we represent only one smart contract in the process model, although it is more likely
that multiple smart contracts will be created that each fulfill a distinct task (such as
patient registration). In this process model, the healthcare provider is assumed to store
the EHRs of its patients. In a similar process, the storage of EHRs could be fulfilled by
a data custodian, as described in the MedShare design [12]. Since public blockchains
operate through public/private-key cryptography (also known as asymmetric cryptog-
raphy) to identify owners of an account and enable secure transaction between these
accounts, each patient and healthcare provider needs to be associated with a public key.
The execution of this process is similar to the design of MedRec, where a smart contract
maintains a mapping of the public keys that belong to a particular patient or healthcare
provider. Here patients and requestors generate their own private key, and then register
their pubic key with the smart contract. Hence, in the process below, when a healthcare
provider sends a request to obtain a certain patient’s EHR, the smart contract will have
to query this mapping in order to identify that patient’s public key. Only when a public
key is found, can this request be forwarded to the corresponding patient. In the case a
public key has not been found, this would mean that a patient has not been registered
by the smart contract and therefore is not included in the EHR system. However, as
addressed in section 2, the proposed designs do not suggest a mechanism to cope with
stolen or lost private keys. Additionally, no identity verification process takes place in
order to establish that for instance a healthcare provider is a licensed and legitimate
party and not a malicious actor. How can we verify that a patient or requestor registering
their public key with the smart contract are actual patients and requestors?
When the request is forwarded successfully, the patient can then respond by either
accepting or rejecting the request. An accepted request will result in the smart contract
adding a permission for the respective healthcare provider to access the patient’s health
record. These permissions are again stored within the smart contract (technically, this
is stored within the corresponding blockchain) as one or multiple mappings between
the public key of the healthcare provider to the public key of the patient. In either situ-
ation, the healthcare provider will be informed by the smart contract if the request was
accepted or rejected by the patient. The process in Figure 1 – and similar to the designs
proposed by MedRec, Medblock and MedShare – make the crucial assumption that the
centralized server of the healthcare provider (or data custodian) will always consult the
permissions as stored within the smart contract. This design cannot guarantee nor pre-
vent however that off-chain queries are being performed within the local hospital pro-
vider, even though access was denied by a particular patient. While it is clear that the
implementation of blockchain technology and smart contracts result in a simple yet
powerful and secure process to manage the permissions of EHRs, the pitfall of this
design lies within the centralized or off-chain storage of the health records and a lack
of public key governance that verifies the identities behind these public keys, and copes
with any losses or thefts of the corresponding private keys.
As -IS model EHR Medical blockchain 7

Patient
Patient

Smart Contract

Patient Patient
Rejects Request Accepts Request

not registered
Public key is Send request
Obtain public to patient
address of
patient
Smart Contract

Receive request Update

for EHR Inform Requestor of Permissions of
Patient's record
Request is sent
failed request

provider that request

to Public Address

Inform Healthcare
of Patient

is rejected
Inform Healthcare
provider that request
is accepted

Mapping of public keys

to identity patient Permission
Management Database

Requestor
Requestor

EHR Database

Figure 1: BPMN process model of smart contracts as permission management database.

4 Decentralized EHR storage and Public Key Governance

IPFS - Decentralized Storage of Electronic Health Records

While implementing central storage servers for EHRs seems to contradict the applica-
tion of decentralized blockchain technology, this design decision almost seems una-
voidable. Despite that a blockchain is essentially a distributed database of records [13],
it is rather inefficient at storing large files. Moreover, sending and storing large files
using smart contracts is expensive, while all files that are appended to the blockchain
need to be executed and stored at every mining or verifying node.
There are several off-chain data storage solutions designed to overcome this trade-
off between decentralization and storage capacity, such as Storj (https://storj.io/),
Swarm (https://ethersphere.github.io/swarm-home/), and IPFS (http://ipfs.io/). We
have decided to adopt IPFS for our design because of it general purpose applications,
wide adoption and for not having any limitations on storage. More specifically, IPFS is
a is a peer-to-peer distributed file system that seeks to connect all computing devices
(or nodes) with the same system of files. An important characteristic of IPFS is that
files are identified by their content and not their location. Therefore, every file that is
managed by the IPFS protocol has a content identifier, which is a cryptographic hash
that is computationally derived from the specific content of that file. IPFS then opti-
mizes the management of files and directories between different nodes through directed
acyclic graphs (DAG). Specifically, IPFS uses Merkle-DAGs, which are DAGs where
each node has an identifier that is a hash of the node’s contents. To build a Merkle-
DAG representation of a file’s content, IPFS first splits this file into blocks. This means
that different parts of a file can come from different sources or nodes and can be au-
thenticated quickly. To illustrate this with an example, when a healthcare record would
be submitted to the IPFS network, it is split into different blocks, each containing at
8

most 256 kilobytes of data and/or links to other chunks. Every one of these blocks are
then identified through the cryptographic hash – i.e. the content identifier – that is de-
rived from the content of that block and enables the content-addressing feature of IPFS.
The combined content identifiers from the separate blocks that compose the EHR form
the Merkle-DAG, which can be thus be used to reconstruct the EHR from its distinct
blocks. Once an IPFS node has divided the EHR into blocks, and the Merkle DAG has
been formed, this node registers itself on the IPFS network as a provider of the EHR.
In order to enforce privacy on IPFS for sensitive data such as EHRs, smart contracts
can serve as access-control lists [14] with attribute-based encryption [15], allowing for
the dynamic modification of sensitive data through adding, removing and updating file
ownership and accesses. The role of smart contracts in this case would be very similar
to the management of permissions as proposed for MedRec, Medblock and MedShare.
However, by introducing this additional level of decentralization in the form of de-
centralized storage, we rely entirely on the public key cryptographic system to authen-
ticate users within our EHR design. As such, this leads us to the challenging aspect of
how to deal with lost or stolen private keys, and how we can truthfully verify an actor’s
identity behind the public key.

Governing Body – Public Key Governance

To deal with the issue of verification of identity and possible loss/theft of private keys,
an off-chain and objective actor (e.g. an oracle in blockchain community terms) would
have to perform public key governance by maintaining a mapping between actual
healthcare providers and patients, and their corresponding public key.
In our design, we believe an institute such as the national government of a country
is the most evident choice to assign as governing body since a national government
actually already performs these tasks by storing and verifying the actual and digital
identities of its citizens. However, any type of institution that is capable of performing
these tasks can of course be assigned as governing body. By introducing a governing
body as a means to verify identities, we can overcome the issues of a decentralized
storage system for EHRs. In the case of a loss or theft of the private key of a patient,
the patient can then notify the governing body, whom no longer recognizes the public
key as a valid digital identity of that patient. The patient can then create a new private
key and share the new public key with the governing body. The governing body can
then verify if the newly generated public key actually does belong to that specific pa-
tient - similar to the case where a person would lose his or her identification documents.
A patient can thus, through the governing body, easily be associated with a new public
key without losing forever access to their EHR in case of a loss or theft of the private
key.

5 Comparison with Related Research

In our discussion of the related research efforts of MedRec, Medblock and MedShare,
we argued that certain fundamental issues of EHR systems concerning privacy control,
 9

centralized storage and identity verification were still maintained. Through the intro-
duction of IPFS and a governing body, we believe such issues can be alleviated.
Adopting IPFS would allow patients to take full control in terms of privacy and data
access of their HER, while avoiding the tedious task of providing reliable and secure
storage. Through the identification of a patient’s private key, ownership of an EHR can
be confirmed on IPFS, while files are managed by their unique cryptographic hash.
Smart contracts fulfill their tasks as a highly secure permission management database,
controlling the ownership and accesses to EHRs on IPFS. As such, a patient owns their
EHR, which is not stored centrally within one or multiple healthcare providers or data-
base custodians but is instead safeguarded by a decentralized network. A patient de-
cides who can have access to their record and can revoke this access also at any given
time. Since data is controlled by the patient, and not stored on a public blockchain, the
implementation with IPFS does not defy regulatory requirement such as for instance
GDPR. While the designs of MedRec, Medblock and MedShare cannot prevent off-
chain queries being performed on a patient’s EHR – due to the assumption that the
centralized servers of a healthcare provider (or data custodian) will always consult the
permissions as stored within the smart contract – off-chain queries are not possible
without the explicit patient’s consent on IPFS.
Additionally, we have included a governing body for public key governance and
identity verification to cope with the loss or theft of keys, or to identify any malicious
actors that may act as a healthcare provider. While the discussed research efforts have
focused on creating a network without a governing body, we believe that this role is
still crucial. We do not argue that a blockchain implementation without governing body
cannot be accomplished, we argue however that the technology is still too immature
and lacks an overall adoption in current society. We would like to emphasize however
that the purpose of the governing body is to serve merely as an objective and reliable
source of information concerning the identities of the different actors interacting with
the blockchain-based EHR system. Unlike, for instance the Medblock design, where
private keys are being stored by a central certificate authority, the governing body in
our design does not store the private keys of say patients or healthcare providers. The
governing body instead is responsible for maintaining a mapping between the digital
identities of patients and authorized healthcare providers represented by their unique
public key with their national identities (e.g. social security number). Hence, our design
incorporates that a patient (and requestor) will always choose – and consequently con-
trol – their own private key and only share their public key to other parties, such as the
governing body. Additionally, a second advantage of the public governance of public
keys by the governing body relates to the detection of illegitimate requests to a patient
record by an unauthorized healthcare provider. Since every healthcare provider has to
register with the governing body in order to practice healthcare, the smart contract can
easily verify that a public key corresponds to a recognized healthcare provider by con-
sulting the governing body.
To illustrate the process of implementing IPFS for decentralized EHR storage and
the incorporation of a governing body for public key governance, we have created a
BPMN process model as depicted in Figure 2. Similar to the process in Figure 1, a
requestor (e.g. a healthcare provider) initiates the process by sending a request for a
 10

particular patient’s EHR to the smart contract. Unlike the initial process, where the
smart contract was responsible for maintaining a mapping of the public keys of patients,
the smart contract now forwards the verification of identity of both requestor and pa-
tient towards the governing body. It is the governing body that then verifies if the re-
quest was actually sent by an authorized and legitimate healthcare provider, and that
the patient is also an existing citizen with a corresponding healthcare record. In the case
of for instance a theft of the private key of a patient, the informed governing body no
longer recognizes that particular public key as a valid digital identity of the respective
patient and notifies the smart contract. When the smart contract receives a positive val-
idation of both identities, the request is forwarded to the patient’s public key. The pa-
tient can then decide to accept or reject this request. Similar to the process described in
section 3, and the corresponding EHR designs of MedRec, Medblock and MedShare,
the smart contract serves as a permission management database that maintains a list of
accepted requests. However, the main difference now lies with the decentralized stor-
age of the EHR provided by IPFS. Healthcare providers (or data custodians) no longer
maintain a patient’s health record. It is the patient itself that controls the storage of the
EHR with IPFS. Consequently, off-chain queries by unauthorized parties are no longer
possible. Due to the content-addressing characteristics of IPFS, a requestor will always
need to obtain the content identifier of the EHR (i.e. the cryptographic hash of the file).
Since their access is managed by the smart contract, a requestor therefore always needs
To-BE to
- EHR Medical
be given blockchain
permission from (BPM Conference)
the patient.

Requestor
Request
or

Patient
Patient

Electronic Health Record

stored on IPFS

Blockchain/Smart Contract
Rejects Request

Send PK of Patient to Inform Requestor of

Governing body for Rejection request
Patient

Identity verification
Receive
verification and Verified
Verify Patient PK
Public Key of
Patient

Send request
Blockchain/Smart Contract

to patient
Patient
Accepts Request
Receive request Update
Permissions
of Patient's
record
Receive Inform Requestor of
Verified Request is send Accepted request
Request is a Verify Requestor verification and to Public address
transaction, send Public Address Public Key of of Patient
to the smart Patient
contract. Request
is signed by the
private key from
the requestor Permission
Management Database

Send PK of Requestor
to Governing body for
Identity verification

Governing
Body
Governing
Body

Mapping of Public keys to

corresponding requestors/patients

Figure 2: Process model of Decentralized EHR storage with IPFS and public key governance
through a governing body
 11

6 Conclusion

By introducing IPFS for decentralized storage of patient’s EHRs and a governing body
to acts as reliable source for public key governance, we aimed to provide an answer to
the research question posed at the beginning of this article on how we can design a
blockchain-based system that provides a decentralized and secure way of managing
permissions while enabling patients to have full privacy-control and storage of their
own electronic health record. Through the adoption of IPFS for decentralized storage
for EHRs, we offer a solution to provide patients with full privacy control over their
own healthcare record without reducing the security of these records. Since permissions
and access to EHRs on IPFS are managed through the smart contract on the blockchain,
the patient itself only has to accept or reject incoming requests from a healthcare pro-
vider, without having to care with the security or data storage of his or her health record.
Additionally, we have included a governing body for public key governance and
identity verification to cope with the loss or theft of keys, or to identify any malicious
actors that may act as a healthcare provider. While other research efforts have focused
on creating a network without a governing body [10, 12] – we think that this role is still
crucial. Therefore, our design of a blockchain-based EHR management system remains
dependent on a governing body in order to be operational and to be adopted by
healthcare providers and patients. Our proposed design is a decentralized system that
integrates the existing tasks and responsibilities of a governing body with a more effi-
cient, secure and automized way of sharing and managing EHRs, that benefits patients
by giving them full privacy control.
Design Limitations. Several limitations can be addressed of the proposed EHR
management design of this paper. First, this article has not implemented the proposed
design into a functioning system or prototype. Future research efforts aim to translate
the system design into a first proof-of-concept, while also evaluating its performance
against similar EHR management designs. Second, we have not specified who would
compose and own (in as far that his is possible) the smart contract. In a way, it can be
argued that the most obvious choice would be the governing body, since the smart con-
tract relies on the governing body to verify the identities of the public keys every time
a new request is submitted. This would reduce the overall decentralized character of the
EHR system however, since the governing body gains even more control of the system
itself. Another concern that we have not addressed within the article is that given the
full control a patient has over the EHR, how can a healthcare provider obtain the re-
quired access to an EHR if that particular patient is unable to provide access, for in-
stance because the patient is unconscious due to an injury. One possible solution to deal
with this kind of situation is to enable ‘emergency rights’ to healthcare providers, which
can be invoked when a patient cannot accept a request. In this case, the identity of the
healthcare provider can still be verified by the governing body to prevent any malicious
actor gaining access to a healthcare record. The smart contract can be programmed in
such a way that emergency request immediately gain permission to a certain EHR, after
identity verification has been performed. Finally, the argument can be raised that the
inclusion of a governing body for identity verification reduces or defeats the purpose
of adopting a decentralized blockchain. While the authors concur that the degree of
 12

decentralization is reduced through a governing body, we are unaware of an existing

and suitable decentralized alternative that can overcome the loss or theft of private keys
or identify malicious actors.

References

1. Rabah, K.: Challenges & opportunities for blockchain powered healthcare systems: A re-
view. Mara Res J Med Health Sci. 1, 45–52 (2017).
2. Wang, J., Middleton, B., Prosser, A., Bardon, G., Spurr, D., Carchidi, J., Kittler, A.F., Gold-
szer, R.C., Fairchild, D.G., Sussman, A.J., Kuperman, G.J., Bates, D.W.: A cost-benefit
analysis of electronic medical records in primary care. Am. J. Med. 114, 397–403 (2003).
3. Walker, J., Pan, E., Johnston, D., Adler-Milstein, J., Bates, D.W., Middleton, B.: The Value
Of Health Care Information Exchange And Interoperability: There is a business case to be
made for spending money on a fully standardized nationwide system. Health Aff. (Mill-
wood). 24, W5-10-W5-18 (2005).
4. Matthias, W., Christian, J., Rainer, R.: Secondary Use of Clinical Data in Healthcare Pro-
viders; an Overview on Research, Regulatory and Ethical Requirements. Stud. Health Tech-
nol. Inform. 614–618 (2012).
5. Sahama, T., Simpson, L., Lane, B.: Security and Privacy in eHealth: Is it possible? 5 (2013).
6. Ekblaw, A., Azaria, A., Halamka, J.D., Lippman, A.: A Case Study for Blockchain in
Healthcare:“MedRec” prototype for electronic health records and medical research data. In:
Proceedings of IEEE open & big data conference. p. 13 (2016).
7. Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system. 1–9 (2008).
8. Antonopoulos, A.M.: Mastering Bitcoin: Programming the open blockchain. “ O’Reilly
Media, Inc.” (2017).
9. Mohan, C.: State of Public and Private Blockchains: Myths and Reality. In: Proceedings of
the 2019 International Conference on Management of Data - SIGMOD ’19. pp. 404–411.
ACM Press, Amsterdam, Netherlands (2019).
10. Azaria, A., Ekblaw, A., Vieira, T., Lippman, A.: MedRec: Using Blockchain for Medical
Data Access and Permission Management. In: 2016 2nd International Conference on Open
and Big Data (OBD). pp. 25–30. IEEE, Vienna, Austria (2016).
11. Fan, K., Wang, S., Ren, Y., Li, H., Yang, Y.: MedBlock: Efficient and Secure Medical Data
Sharing Via Blockchain. J. Med. Syst. 42, 136 (2018).
12. Xia, Q., Sifah, E.B., Asamoah, K.O., Gao, J., Du, X., Guizani, M.: MeDShare: Trust-Less
Medical Data Sharing Among Cloud Service Providers via Blockchain. IEEE Access. 5,
14757–14767 (2017).
13. Crosby, M., Pattanayak, P., Verma, S., Kalyanaraman, V., others: Blockchain technology:
Beyond bitcoin. Appl. Innov. 2, 71 (2016).
14. Steichen, M., Fiz, B., Norvill, R., Shbair, W., State, R.: Blockchain-Based, Decentralized
Access Control for IPFS. In: 2018 IEEE International Conference on Internet of Things. pp.
1499–1506. IEEE, Halifax, NS, Canada (2018).
15. Sun, J., Yao, X., Wang, S., Wu, Y.: Blockchain-Based Secure Storage and Access Scheme
For Electronic Medical Records in IPFS. IEEE Access. 8, 59389–59401 (2020).

View publication stats