2020 IEEE International Conference on Software Architecture Companion (ICSA-C)

Scalable Architecture for sharing EHR using the

Hyperledger Blockchain
Andressa Fernandes Vladimir Rocha Arlindo F. da Conceição
Federal University of ABC – UFABC Federal University of ABC – UFABC Universidade Federal de São Paulo
[email protected] [email protected] [email protected]

Flavio Horita
Federal University of ABC – UFABC
[email protected]

Abstract—Blockchain technology has been applied in several the domain where the Blockchain is applied. In this case, the
areas, ranging from financial to health. Although this technology state not only needs to be an account balance in the financial
offers benefits, for instance the immutability, anonymity, and context but any information, a patient medical record in the
decentralization of information, its use presents some problems,
been the scalability in terms of storage size one of them. This
context of HIS [5].
paper presents a scalable architecture for sharing electronic Blockchain is expected to have a significant impact over
health records using a multi-channel hyperledger blockchain. the next few years [7], and to be used in several areas,
The architecture uses one blockchain to record patient visits and for instance, supply chain management, Internet of Things
one blockchain for each health institution to record links that (IoT) [8], Health [9], among others.
point to Electronic Health Records (EHRs) stored in external
systems. Among the main conclusions, the final results highlight
In the health domain, Blockchain can be applied in several
the scalability of the proposed architecture, when compared to contexts, for example, to control the access of sensitive data,
the related work models in the heterogeneous network. to audit the medical financial payments, to allow transparency
Index Terms—Blockchain, EHR, Hyperledger, Healthcare on the inventory drugs movements, to register the patients’
appointments and visits, among others. Recent research, how-
I. I NTRODUCTION ever, points out that despite its potential, Blockchain cannot
Health Information Systems (HIS) are essential for improv- be applied in all cases [10].
ing efficiency in patient care. HIS provides health professionals A problem that arises in Blockchain is the lack of scalability
the means to gather, compile, and analyze patients’ data given by the amount of information that must be transmitted
to make the best decision of its treatments. However, the and stored on computers that are part of the system. To put
information unavailability (by theft, loss or server outage) or in perspective, in the financial domain, the total financial
how reliable is it (by modifying its integrity) in a distributed transactions made by Bitcoin have reached 400 million trans-
and unreliable system are still open problems to overcome [1]. actions in ten years [11], Although this size is not a problem
Blockchain is a technology that enables reliable and secure for today’s hard disks, while the total transactions exceeds
information storage using a combination of distributed consen- billions of transactions, the required space will become a
sus procedures with cryptography techniques [2], [3]. The use problem, as analyzed in section VI. In this context, in Brazil’s
of this technology started in 2008 with the creation of Bitcoin health domain, there were 1.4 billion patient visits just in
cryptocurrency by Satoshi Nakamoto [4]. The main objective 2018 carried out by its Unified Health System (SUS) to
of Bitcoin was to allow anonymous, auditable, reliable and the government report [12]. In China, to [13], there were
secure financial movements, preventing trusted third parties, approximately 7 billion patient visits in 2017. In this context,
like banks, to intermediate these movements. if each patient visit is considered one transaction in the chain,
The concept used in Blockchain is the distributed ledger, the total amount of space and the architecture to support it
representing an ordered and consistent chain of financial must be considered to successfully apply the Blockchain in
transactions, distributed across multiple nodes on an untrusted this domain.
peer-to-peer network, using the proof of work to perform the The discussion above is the main motivation for this pa-
consensus among them. per, in which we propose a scalable architecture for shar-
Following Bitcoin’s success, other Blockchain technologies ing Electronic Health Records (EHR) among patients, health
were developed to expand its usage beyond the financial professionals, and health institutions. For that, we define
context. In this sense, technologies as Ethereum [5] and the components necessary to record the patient visits in the
Hyperledger [6], include the use of smart contracts [3], small chain, and how these components must be related to support
programs stored in Blockchain, that allow performing opera- the access of EHRs stored in external storage systems, for
tions on it. The use of smart contracts expands the power of example, clouds or HIS.
Bitcoin’s Blockchain, allowing to store states depending on The rest of the paper is organized as follows. Section II

978-1-7281-4659-1/20/$31.00 ©2020 IEEE 130

DOI 10.1109/ICSA-C50368.2020.00032

Authorized licensed use limited to: Frankfurt University of Applied Sciences. Downloaded on December 04,2020 at 19:50:59 UTC from IEEE Xplore. Restrictions apply.
 presents the general concepts with regards to the Blockchain emerges as an alternative to the client/server architecture,
and the Hyperledger. Section III discusses related works. whose main problem is the server failure, which lets resources
Section IV presents the proposed scalable architecture and inaccessible for requesting them. Thus, the main objective
Section V focuses on the components interaction through three of the P2P network is to increase the availability of the
common usage scenarios. Section VI compares the architecture resources [16].
with some existing alternatives in terms of size scalability. In this goal, each time a peer downloads a file, e.g., the
Finally, we conclude our work and point out some future chain of blocks, this file will be replicated on both, that can be
directions in Section VII. downloaded by a third peer. Note that the resource availability
will increase each time it is downloaded.
II. B LOCKCHAIN P2P networks are currently used not only for chain repli-
Blockchain is a technology that implements this similar to cation in the Blockchain technology but also in many other
a distributed ledger, whose main characteristics are decentral- systems. The best-known example of its application is in file
ization, availability, integrity, auditability, and privacy [14]. sharing via BitTorrent [17] and Skype video conference [18].
Decentralization allows information stored in the
Blockchain to be replicated across multiple computers, C. Permissioned and Permissionless
avoiding a single point of failure of centralized servers. To Buterin [19], there are two types of Blockchains: permis-
Availability permits to access the information whenever it is sioned and permissionless. In a permissioned Blockchain, any
needed, regardless of whether some computers fail. Integrity entity (whether to be a person, institution, etc.) could perform
is related to information preservation, protecting it from operations in the chain. In this sense, the Blockchain must al-
improper changes. Auditability offers the ability to track low those mutually unreliable entities to perform modifications
all information that has been stored in Blockchain. Finally, on the chain without relying on a centralized trusted third-
privacy allows members to remain anonymous. party. On the other hand, permissionless Blockchains were
In the following subsections, we present the concepts that proposed with the objective that only a set of entities perform
comprise the Blockchain that allow implementing the afore- operations in the chain. In this sense, the permissionless
mentioned characteristics. Blockchain mainly operates with a known and frequently
verified set of participants.
A. Blocks and Transactions In the permissionless Blockchain, the entity becomes a par-
From a technological point of view, the Blockchain consists ticipant of the network after joining it and can execute all the
of an orderly and consistent chain of blocks, each one having activities allowed, for instance audit or propose transactions,
a header and the data to be stored. among others. Examples of technologies that implement a
The header contains several attributes, some of them were permissionless Blockchain are Bitcoin [4] and Ethereum [5].
the identifier, the previous block, and the signature. The In the permissioned Blockchain, the entity must be authen-
identifier represents a globally unique value, created with a ticated and authorized before to join the system, after which it
mathematical function (hash function) that encloses all block will be transformed into a participant. As a participant, he can
information. The previous block is responsible for chaining the execute just specific activities, as view the blocks or audit the
blocks. For this, each new block added in the chain will have chain. Validation of an entity is usually performed by a trusted
the value of the identifier of the previous block, thus creating entity for managing permissions, called a certificate authority.
a logical chain of links. The signature allows identifying the An example of the technology that implements a permissioned
creator of the block. Blockchain is the Hyperledger Fabric [6].
The data registers the transactions belonging to the block.
These transactions can represent any type of information. For D. Smart contracts
example, in a financial system, the transaction would be a The evolution of Blockchain has been classified into two
monetary transfer between two people. In health information generations. The first generation (used in Bitcoin) was ori-
systems, in turn, the transaction could be the document (or ented towards financial transactions, where value is transferred
a URL address) that contains the patient’s electronic health from one entity to another. For this, the features (hard-coded
record. statically in the Blockchain) need to ensure that the entity has
the necessary balance to perform the transaction. Thus, when
B. Replication in peer-to-peer (P2P) networks a computer receives the transaction, it uses these features to
Offering resources (documents or media files) has been maintain system consistency.
deployed since the very beginning of the internet with the The second-generation (used by Ethereum and Hyperledger)
client/server architecture [15]. In this architecture, a computer appears around 2015. The main innovation is that new features
called server provides the resources to client computers, which can be dynamically added, meeting business requirements of
are responsible for requesting them. different contexts, not only the financial one. For example, in
A P2P network, used by Blockchains, is a connected net- health information systems, it is used to record the patient’s
work of computers where each of them, called peer, can be health records. These features are called smart contracts, a
both client and server at the same time. The P2P network concept proposed by Szabo in 1996 [20].

131

Authorized licensed use limited to: Frankfurt University of Applied Sciences. Downloaded on December 04,2020 at 19:50:59 UTC from IEEE Xplore. Restrictions apply.
 E. Hyperledger (who uses the system through an application), or other systems
(who use the system through communication interfaces).
Hyperledger 1 is an organization that provides several open-
source Blockchain, been the Hyperledger Fabric one of them.
Its goal is to provide a decentralized platform that allows III. R ELATED WORK
creating specific functionalities for each kind of business This section describes relevant works that use the Hyper-
through the use of smart contracts. ledger Blockchain for sharing EHRs. Although this citation-
The Hyperledger Fabric is composed of certificate author- sequence is not extensive, it explain chronologically how the
ities, committing peers, endorser peers, orderers, and clients. state of the art evolved in this research field.
Also, the components communicate among them using chan- In [23], the authors propose an architecture that uses a
nels, that are structures specifically created to allow transac- blockchain for sharing data in a mobile environment. The
tions privately and confidentially, isolating different domain architecture focuses on the user, as a centerpiece of data
applications. Thus, a channel is how components can commu- sharing, and is comprised by six entities: users, wearable
nicate securely and reliably within the Blockchain. devices, healthcare providers, health insurance companies, the
Fabric certificate authorities are responsible for two tasks: hyperledger blockchain, and a database cloud. The user is
first, to make sure that any component (user or smart contract) the owner of the data, responsible for securing, denying and
that wants to use the system is whom it claims to be (in other revoking access to other entities. The wearable devices entity
words, by recognizing the authenticity of the component); format the data collected by the devices and send it to the user
second, to authenticate the component and authorize it to use account and the blockchain entity. The healthcare providers (a
certain functionalities (e.g., perform transactions) or access physician or a nurse) take care of users and can visualize its
other components after certification. EHRs given the consent provided by them. The insurers’ entity
Committing peers are responsible for persisting the chains is used by the user to request some quotes to the insurers’
transmitted through the channels created in the system. Thus, companies, choosing the most appropriate health plan. On
they store the various Blockchains, one for each channel the other hand, the companies may request access to user
created. This ‘one chain per channel’ approach brings two data also. The blockchain network is used for collecting data
benefits: privacy and scalability. from wearables and healthcare providers, for recording the
Concerning privacy, a component will not be able to access permission access generated by the user, and for accessing the
(i.e., viewing or modifying) a chain from a committing peer EHRs stored in the database cloud. The database cloud stores
associated with the channel if the component does not have user information, data requests, data access information, and
access to that channel. In this context, privacy and confiden- privacy policies.
tiality of the information are safe from components that did In [24], the authors propose a Hyperledger-based architec-
not. ture focusing on managing the user identity and privacy over
With regards to scalability, note that having several the network. For that, the architecture distinguishes patients
Blockchains, one per channel will allow distributing the from doctors and third-party users. Besides, the architecture
number of transactions and information stored among several uses an external storage system to store the EHRs, while
committing nodes, increasing both the number of requests the Blockchain only registers pointers (as links) to the EHR
that a node could fulfill and the amount of data stored, thus location. To access these records, the architecture deploys
increasing the system scalability. Hyperledger’s smart contracts for verifying patient’s read or
Endorsing peers are responsible for two tasks: first, for write policies.
collecting transactions from customers; second, for analyzing, In [25], the authors propose a conceptual architecture fo-
using smart contracts, whether the transaction has any associ- cusing on identity and access management. The architecture
ated policies or rules that must be followed. is comprised of four modules: the clients, an application server,
Ordering peers are responsible for two tasks: first, for a database, and an authentication server. The client (a mobile
receiving client transactions; second for ordering these trans- or web app) communicates with the application server, which,
actions to maintain the Blockchain consistent (i.e., the same in turn, sends the user credentials to the authentication server
on all committing peers). In this sense, all ordering peers to verify the client. If the verification is succeeded, the client
acting on a specific chain must agree on the order in which could access the database (for retrieving the EHRs) through the
transactions will be added to it by committing peers. For that, application server. The purpose of separating authentication
transactions are received using Apache Kafka [21] technology, and application servers is to decouple the logic and allow
which allows them to be stored in a distributed and fail-tolerant modularity. Thus, different application servers could access a
way. Ordering, in turn, is achieved using Zookeeper [22]. different database using the same authentication server. In this
Client applications are responsible for performing transac- architecture, the Hyperledger Blockchain is used to register
tions in the system, sending them to the endorsing and ordering the permissions (grant and revoke) given by the client to other
peers. In Hyperledger Fabric, a client could be a real person clients to access its EHRs. Although the work also analyses
the architecture scalability, it was deployed only in a single
1 https://www.hyperledger.org
organization.

132

Authorized licensed use limited to: Frankfurt University of Applied Sciences. Downloaded on December 04,2020 at 19:50:59 UTC from IEEE Xplore. Restrictions apply.
 In [26], the authors propose the EMRShare, a three-layer IV. P ROPOSED A RCHITECTURE
architecture for sharing electronic medical records. The layers Figure 1 presents the overall architecture used by our work.
(Blockchain, Service, and Dispatcher) are used to facilitate the The architecture is comprised of four components, connected,
integration of the architecture with existing external systems. which are the clients, the Blockchain, the storage system, and
In EMRShare, the dispatcher layer is responsible for receiving the certificate authorities. In the following, we present the
client requests and to start the corresponding service in the details of each component.
service layer. The service layer encapsulate all blockchain
requests coming from the dispatcher and is responsible for
sending the requests to the blockchain. The Blockchain layer is
responsible for registering access permissions, allowing reads
and writes to the chain, and for storing the record metadata.
It is important to note that EMRShare uses an external
storage system to store the EHR. This work also analyses the
architecture scalability, deploying it in four organizations.
In [27], the authors propose an architecture-specific to
monitor patients that are using IoT and wearable devices. The
architecture is comprised of two blockchain groups: medical Fig. 1. Architecture for sharing EHR based on Hyperledger Blockchain.
devices blockchain and consultation blockchain. The former
is responsible for recording all health data collected by the
devices, and the latter is responsible for recording all patient’s A. Client component
EHRs. It is important to note that in the blockchain of the first The client component is an electronic device (a smartphone
group, each patient creates and has access to its blockchain, or a laptop) that represents a real-world entity in the healthcare
but is persisted only during the period of treatment. The second context. For example, it may be a person (a patient or a
blockchain, in turn, will be always available, but only for physician) or a health institution (a hospital or a clinic).
health professionals. The component is responsible for: (i) sending and receiving
In [28], the authors describe a layered software architecture patient electronic health records; (b) allowing or denying the
for supporting emerging healthcare and life science use cases, access of its records to other clients. As the client must
being sharing EHR’s one of them. The architecture is com- interact with all other components, it communicates with them
prised of a front-end layer, API services layer, smart contract through reliable and secure APIs (Application Programming
layer, the hyperledger blockchain layer, and the HIPAA cloud Interfaces). Reliable in the sense that the information will not
layer. The front-end layer is responsible for capturing the client be modified and secure in the sense that the information will
requests and call specific services defined in the API layer. not be accessed by clients without permission. Besides, the
The API layer provides REST APIs to access the business- component stores the client’s public and private keys. The
specific rules implemented in the Smart Contract layer. The former represents a unique entity identifier that will be used
Smart Contract layer is divided into contracts specific to the for other entities to validate the entity’s information. The latter
core business and in reusable modular components, transversal is used by the entity for signing the events performed by it.
to the contracts aforementioned, as that data encryption, per- In this paper, the credential loss issue is not being analyzed.
mission access, notifications, among others. The hyperledger
and the cloud layer, both are deployed in a cloud computing B. CA component
environment. The former is used as a smart contract container The Certificate Authority (CA) component is responsible
and the latter is responsible for register all health data, based for creating the entity credential (i.e., both public and private
on the Health Insurance Portability and Accountability Act keys) and for delivering it to the entity, which will store them
(HIPAA). This architecture only uses one blockchain, which into the client component. For this, first, the CA must validate
can lead to some scalability issues but could be enhanced to if the entity that wants to use the architecture present valid
use several blockchains. and trusted information. In our architecture, we divide the
For a more recent review, please see [29] and [30] that also CA component into three sub-components: Patient CA, Health
address the use of Blockchain in Healthcare for sharing EHR Professional CA, and Health Institution CA.
from a research perspective. Patient CA (PatientCA) component is responsible for vali-
Although the alternatives use hyperledger for sharing EHRs, dating patient’ information before delivering the keys. If the
our architecture focus on system scalability in a multi- information presented is valid, the CA generates the keys and
institution environment, each one having a different and re- send them to the patient. From this point, the patient becomes
stricted infrastructure to support the blockchain deployment. a client of the system. Note that the patient anonymity holds
To the best of our knowledge, none of the previous works in that it will use only an identifier (the public key) to validate
analyses the scalability in terms of storage and how the its actions and not real-world information, as its name or its
Hyperledger components could be related to allowing sharing social security number. In our architecture, this component can
EHRs in this environment. be deployed by each health institution but is more common

133

Authorized licensed use limited to: Frankfurt University of Applied Sciences. Downloaded on December 04,2020 at 19:50:59 UTC from IEEE Xplore. Restrictions apply.
 to be deployed by a more country-wide organization, as a its devices’ processing power, network connectivity, and IT
federal government ministry of health. If both alternatives employees.
are deployed, the latter will be responsible for validating the • Large health institution: it has a cluster of 5 or more
entities information and creating its access credentials (i.e., servers; 8 GB or more of RAM for each server; dis-
the keys) and the former will be responsible for allowing tributed hard disk of 5 TB or more; 100 Mbps of
access to the institution’s information (i.e., giving access bandwidth. Besides, it has a fixed IT team.
to the communication channel and therefore its associated • Small health institution: it has 5 or fewer servers (not
blockchain). configured as a cluster); 2 GB or more of RAM; a hard
Health Professional CA (ProfessionalCA) and Health Insti- disk of 1 TB; 10 Mbps of bandwidth. Besides, it does
tution CA (InstitutionCA) both also need to validate health not has a fixed IT team.
professional and institution information, respectively. Both
could be deployed by each state (or region, depending on the V. C OMPONENTS I NTERACTION
country), or also by the ministry of health.
To understand how the components interact, we analyze the
C. Storage Component architecture lifecycle based on three common usage scenarios
for sharing EHRs as defined in [1].
The storage component is an external system responsible for
providing the storage of electronic documents, specifically the A. Assumptions for demonstration scenarios
patients’ electronic health records (EHRs). This component is For all scenarios described below, we assume the following
divided into two sub-components: a personal storage module initial conditions: (i) both health professionals and institutions
and a HIS storage module. were registered by the Professional CA and Institution CA,
In the personal storage module, the client could storage respectively; (ii) A Patient CA CAwc was deployed, but
EHRs in its cloud storage account, for instance DropBox, each institution could have deployed its Patient CA also;
Google Drive, Microsoft OneDrive. among others. With this (iii) Each institution has created its communication channel
approach, the architecture provides the means to allow patients with the registered health professionals that work on it. As a
for owning their information, instead of trusting in third-parties consequence, there is one Blockchain per institution.
to do it. Note that at any moment the patient can deny access Besides, we assume that a global Blockchain bwc was
to its EHRs without asking permission from anyone. deployed. As mentioned, it is responsible for registering only
In the HIS storage module, we assume that health in- the institutions visited by the patient. Thus, even if a patient
stitutions already have repositories to storage their patients’ visits the same institution multiple times, this Blockchain will
information. Also, it is assumed that the module allows both register only one of them. It is worth noting that all entities
searching medical records (e.g., using SQL queries or REST have access to it.
methods) and transferring them in a scalable way.
Besides, independently of the sub-component used, we B. Scenario 1: Patient visiting a hospital
assume that the storage system has a module that allows the
In the first scenario, a person (not registered in the system)
client authentication and authorization for accessing its stored
visits a physician m1 who works in hospital h1 . Note that, as
resources (e.g., using OAuth2, OpenID, among others) and an
the person is not registered, she does not have any previous
access point (e.g., an URL through a REST service) to obtain
EHR. Figure 2 shows the steps required for the physician treats
the EHRs.
the person.
D. Hyperledger component In step 1, the person (using a mobile app app1) is registered
in CAwc as a patient, obtaining a unique identifier p1 and its
Our architecture is comprised of a global blockchain and public and private keys. At the end of this process, the patient
several smaller local blockchains, one for each health institu- will become a client, whose access credential will be stored
tion. on its electronic device (mobile phone). In step 2, patient
The global blockchain is responsible for recording all pa- p1 request a read-only access to hospital’ Patient CA CAh1
tients visits to a health institution. For this blockchain to be (specifically for accessing the EHRs that will be created at the
deployed, each health institution must have a committing peer end of the visit). In step 3, the physician m1 treats the patient
that stores the chain. It is important to note that even if a and creates an EHR using the institution’s HIS. Next, the HIS
patient visits the same institution several times, this blockchain register the visit metadata in the hospital’s local Blockchain
will store just one of these visits. b1 , for instance the patient identifier and how to access the
The blockchain for each health institution (called local created electronic document ehr1 . To access the EHR, it is
Blockchain) is responsible for recording all EHRs associated possible to use a REST service with a URL (url1 ) that receives
to its patients. For this blockchain to be deployed, we assume the patient’s credential and returns the encrypted documents
that the health institution has the minimal infrastructure re- associated with it (encrypted with the patient’s private key).
quired just to run a hyperledger network. Our work defines In step 4, the HIS will register in bwc that patient p1 visited
the health institution infrastructure in two groups, based on h1 , only if it was the first time.

134

Authorized licensed use limited to: Frankfurt University of Applied Sciences. Downloaded on December 04,2020 at 19:50:59 UTC from IEEE Xplore. Restrictions apply.
 Fig. 2. A person, becoming a patient, visiting a hospital h1 .

Fig. 3. Patient visiting a heart clinic h2 with access to h1 .

C. Scenario 2: Patient visiting a Blockchain-connected heart
clinic
In the second scenario, patient p1 will perform an electrocar- In step 2, the nurse request the credential to p1 and an access
diogram at heart clinic h2 with the same physician m1 . Note code, in order to access the EHRs stored in the hospital and
that m1 works in both hospital h1 and clinic h2 , therefore heart clinic’s HIS. This code, encrypted with p1 ’s private key,
with access to both local Blockchains b1 and b2 , respectively. informs an HIS to allow the access to patient’s EHR. In step 3,
Figure 3 shows the steps required for the physician to visualize the nurse, using the code, obtains the encrypted EHRs (ehr1
the EHR ehr1 created in the previous scenario and perform and ehr2 ) from REST services deployed at the hospital h1 and
the exam. the heart clinic h2 , and decrypt them with p1 ’ public key. In
In step 1, the physician m1 requests to Blockchain bwc the step 4, the nurse treats the patient and creates an EHR ehr3 .
institutions that the patient p1 visited, obtaining h1 . In step 2, Next, the HIS register the visit metadata in the clinic’s local
the physician requests to Blockchain b1 for the metadata of Blockchain b3 . In step 5, the HIS will register in bwc that
all documents associated with p1 . Specifically, she will obtain patient p1 visited h3 . Finally, in step 6, patient p1 request a
the visit metadata with a link to access the ehr1 . Next, the read-only access to clinic’ Patient CA CAh3 .
physician performs the electrocardiogram and gives the result
to the patient p1 as an electronic document ehr2 (e.g., a PDF
or Word document).
In step 3, p1 sends ehr2 to its personal storage module, in
this example will be the Dropbox 2 . At the end of this process,
the storage system will return a URL link url2 that will allow
accessing the document via the Internet. It is important to
highlight that it is essential to encrypt the document with the
patient’s private key. In step 4, the physician register in b2 ,
through the HIS at h2 , the exam metadata, for instance the
patient identifier and the link url2 . In addition, in step 5, the
HIS also register in bwc that patient p1 visited h2 (only for
the first time). Finally, in step 6, patient p1 request a read-only
access to hospital’ Patient CA CAh2 .
D. Scenario 3: Patient visiting a non-connected clinic
In the third scenario, patient p1 will be treated at a walk-
in clinic h3 by a nurse m2 who only works at hospital h3
Fig. 4. Patient visiting a walk-in clinic h3 without access to h1 nor h2 .
(therefore, he has no access to local Blockchains b1 and b2 ).
Figure 4 shows the steps for the nurse to visualize the patient’s
EHRs ehr1 and ehr2 created in the previous scenarios. VI. A RCHITECTURE ANALYSIS
In step 1, the nurse m2 requests to Blockchain bwc the In this section, we analyze the proposed architecture in
institutions that the patient p1 visited, obtaining h1 and h2 . terms of storage size scalability, comparing our multi-channel
solution with the most used approach, which is to have just
2 https://www.dropbox.com
one Blockchain to records all events.

135

Authorized licensed use limited to: Frankfurt University of Applied Sciences. Downloaded on December 04,2020 at 19:50:59 UTC from IEEE Xplore. Restrictions apply.
 As mentioned in Section IV-B, the architecture needs the TABLE III
P ROJECTION OF B LOCKCHAIN SIZE IN L ARGE HEALTH INSTITUTIONS
Certificate Authorities (i.e., PatientCA, ProfessionalCA) for
being deployed until it is proper used. This prerequisite is not Years Patient Visits Average year size (MB)
an easy task to do. To the best of our knowledge there are only 1 26,000 5.25
5 130,000 26.28
very few countries using blockchain technology for health on 10 260,000 52.56
a national scale, Estonia (with an estimated population of 1,3 20 520,000 105.13
million people [31]) was the first country adopting it [32].
For larger and decentralized countries, as Brazil, in which the
country is divided into states and each of them has its own In the worst case, Table II shows that the entire chain fits in
autonomy, it could be difficult to deploy a national CA. This a normal hard disk because the higher value is approximately
difficulty arises because it is necessary to align the federal and 79 GB (assuming, as mentioned, that a normal hard disk has
state public policies, as well as the infrastructure designated 1 TB of size). This result indicate that the global blockchain
to health. Of course, this behavior is inherent to all systems could be deployed in both small and large health institution
that use a permissioned Blockchain approach. infrastructures.
For estimating the storage scalability size of the architecture,
composed by the global Blockchain and the local Blockchains,
it is necessary to define the information that these Blockchains Listing 2. Data model for Institution Blockchain
s t r u c t NewRecord {
will store in its blocks, based on the primitive data types and DateTime t i m e s t a m p ;
sizes. Table I shows the main Hyperledger primitive data types, String [20] publicKeyPatient ;
with its size, obtained from [33]. String [20] publicKeyDoctor ;
String [50] healthRecord ;
TABLE I String [50] link ;
P RIMITIVE DATA SIZE ON H YPERLEDGER S t r i n g [64] hashData ;
}
Data Size Frequent uses
Int 256 bits numbers in general In the institutional local Blockchain, we store the data model
Bool 8 bits flags suggested by [1] whose purpose is to aggregate the patient
String 8 bits for each char names and descriptions visiting metadata, i.e., the patient and doctor entities, as well
DateTime 64 bits dates and hours
as the link pointing to the EHR. The data model is shown in
Listing 2.
The data model stored in the global Blockchain is shown
In this model, the attribute timestamp represents the date that
in Listing 1 that is responsible for aggregating the patient’s
the patient visits the doctor, each of them has its own identifier
identification (PatientID) with the institution’s identification
(publicKeyPatient and publicKeyDoctor, respectively). While,
(InstitutionID).
the attribute healthrecord represents some keywords that could
be added to the record, e.g., electrocardiogram or blood exam.
Listing 1. Data model for global Blockchain The third attribute link represents a URL that allows retrieving
s t r u c t UniqueVisit { the EHR, associated with the visit, which is stored in some
String [20] PatientID ; external storage system. Finally, the attribute hashData allows
String [20] InstitutionID ; ensuring the EHR integrity by storing the hash value made
}
from the document. As shown in Table I, the total cost of the
In this data model, each identification has 20 bytes (based NewRecord model is 212 bytes.
in the data size of Table I), representing the public key of the When estimating the total amount of data stored in each
entity. The total cost of this model, which will be persisted as local blockchain, we first need to determine how many patient
a transaction in the block, is 40 bytes. visits are in a large and small health institution. To [35], a
Now, we assume that a person visits one-to-ten different large health institution in Brazil has 26,000 visits per year.
health institutions in his lifetime. As previously mentioned, the On the basis of these data, Table III shows the projection of
patient could visit several times the health institution, but the patient visits from one to twenty years, with the respective total
global Blockchain just persists in one of them. Table II shows blockchain size to store them, using the model of Listing 2.
the best- and worst-case scenarios to store all Blockchain visits When relying on a small health institution that may have
transactions for Brazil, with a population estimated in 211 10,000 or fewer visits per year [36], Table IV details the
million people [34]. projection for one to twenty years versus the Blockchain size.
Note that in both cases (i.e., large and small health insti-
TABLE II tutions), the entire blockchain size has at maximum 100 MB,
G LOBAL BLOCKCHAIN MODEL SIZE fitting in normal hard disks.
Visits / Qty. Institutions Visits x UniqueVisit (40 bytes) In GB
On the other side, it is important to comprehend that the size
211,836,829 / one 8,473,473,160 7.89 required by the related works that use just one Blockchain for
2,118,368,290 / ten 84,734,731,600 78,91 storing all patient visits. In Brazil, to the management report

136

Authorized licensed use limited to: Frankfurt University of Applied Sciences. Downloaded on December 04,2020 at 19:50:59 UTC from IEEE Xplore. Restrictions apply.
 TABLE IV R EFERENCES
P ROJECTION OF B LOCKCHAIN SIZE IN S MALL HEALTH INSTITUTIONS

Years Patient Visits Average year size (MB) [1] A. F. da Conceição, F. S. C. da Silva, V. Rocha, A. Locoro, and J. M. M.
1 10,000 2.02 Barguil, “Eletronic Health Records using Blockchain Technology,” in
5 50,000 10.10 Anais do I Workshop em Blockchain: Teoria, Tecnologias e Aplicações.
Porto Alegre, RS, Brasil: SBC, 2018.
10 100,000 20.21
20 200,000 40.43 [2] M. Swan, Blockchain: Blueprint for a new economy. O’Reilly Inc.,
2015.
[3] F. Greve et al., “Blockchain e a revolução do consenso sob demanda,”
Minicursos do SBRC), vol. 36, 2018.
of 2018 [12], there were 1,4 billion patient visits through [4] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.
[5] G. Wood, “Ethereum: A secure decentralised generalised transaction
its public healthcare system called SUS [37]. Based on this ledger,” Ethereum Project Yellow Paper, 2014.
information, Table V shows the projection for one to twenty [6] E. Androulaki et al., “Hyperledger Fabric: A Distributed Operating
years using Listing 2. System for Permissioned Blockchains,” in Proceedings of the Thirteenth
EuroSys Conference, ser. EuroSys ’18. New York, NY, USA: ACM,
2018, pp. 30:1–30:15.
TABLE V [7] D. Tapscott and A. Tapscott, Blockchain Revolution: How the Tech-
P ROJECTION OF SIZE USING JUST ONE B LOCKCHAIN nology Behind Bitcoin Is Changing Money, Business, and the World.
Brilliance Audio, 2016.
Years Average size (TB) [8] S. Huh et al., “Managing IoT devices using blockchain platform,” in
1 0.26 Advanced Communication Technology. IEEE, 2017, pp. 464–467.
5 1.34 [9] P. Zhang et al., “Blockchain technology use cases in healthcare,” ser.
10 2.69 Advances in Computers. Elsevier, 2018.
20 5.39 [10] C. Monteil, “Blockchain and health,” in Digital Medicine. Springer,
2019, pp. 41–47.
[11] B. Luxembourg, “Blockchain total number of transactions,”
Regarding the results of Table V, in the first year, large https://www.blockchain.com/charts/n-transactions-total, 2019, last
and small health institutions will be able to store the entire access: 02/07/2019.
Blockchain in its hard disks. However, from the fifth year and [12] M. da Saúde, “Relatório de Gestão (in portuguese),” 2018,
http://bvsms.saude.gov.br/bvs/publicacoes/relatorio gestao 2018.pdf.
forward, only the larger health institutions could store this [13] Y. Chen et al., “Blockchain-Based Medical Secure Storage and Medical
model without made infrastructure changes, because of the 1 Service Framework,” Journal of Medical System, 2019.
TB hard disk size limit of the smaller ones. From the twentieth [14] D. Drescher, Blockchain Basics: A Non-Technical Introduction in 25
Steps. Apress, 2017.
year, even the large ones will have to increase its distributed
[15] M. v. Steen and A. S. Tanenbaum, Distributed Systems: Principles
storage servers. This finding thus provide evidence that it is and Paradigms (3rd Edition). CreateSpace Independent Publishing
necessary to divide the entire Blockchain into several smaller Platform, 2017.
ones as proposed in our architecture, using the global and the [16] A. Oram, Peer-to-Peer: Harnessing the Power of Disruptive Technolo-
gies. O’Reilly Media, 2001.
local Blockchains. [17] B. Cohen, “The BitTorrent protocol specification,” 2008.
[18] S. Baset and H. Schulzrinne, “An Analysis of the Skype Peer-to-Peer
Internet Telephony Protocol,” Proceedings - IEEE INFOCOM, 2005.
VII. C ONCLUSIONS AND F UTURE W ORK
[19] V. Buterin, “On public and private blockchains,” Ethereum blog, 2015.
[20] N. Szabo, “Smart contracts: Building blocks for digital markets,”
HIS is essential for providing relevant information about http://www.alamut.com/subj/economics/nick szabo/smartContracts.html,
patients to support decision-making of health professionals. 1996, last access: 28 Mar. 2019.
Blockchain is a technology that allows reliable and secure data [21] J. Kreps, N. Narkhede, and J. Rao, “Kafka: A distributed messaging sys-
tem for log processing,” in Proceedings of 6th International Workshop
storage and has been used in several areas, including health. on Networking Meets Databases (NetDB), Athens, Greece, 2011.
One of the problems using Blockchain in HIS is the size [22] P. Hunt et al., “Zookeeper: Wait-free coordination for internet-scale
scalability for storing medical records that may arise when just systems,” in Proceedings of the 2010 USENIX Conference, 2010, pp.
1–14.
one chain is used. To increase the scalability, we propose a [23] X. Liang, J. Zhao, S. Shetty, J. Liu, and D. Li, “Integrating blockchain
multi-chain architecture and formulate the interactions of the for data sharing and collaboration in mobile healthcare applications,” in
components necessary to share EHRs. Through analysis, our 2017 IEEE 28th Annual International Symposium on Personal, Indoor,
and Mobile Radio Communications (PIMRC), Oct 2017, pp. 1–5.
architecture behaved in a more scalable way than the works
[24] A. Juneja and M. Marefat, “Leveraging blockchain for retraining deep
using just one chain. learning architecture in patient-specific arrhythmia classification,” in
As future work, we will analyze the performance scalability 2018 IEEE EMBS International Conference on Biomedical Health
Informatics (BHI), March 2018, pp. 393–397.
of the architecture, that is, what should be the Hyperledger net-
[25] T. Mikula and R. H. Jacobsen, “Identity and access management with
work needed to manage patient visits in terms of transactions blockchain in electronic healthcare records,” in 2018 21st Euromicro
per second. Conference on Digital System Design (DSD), Aug 2018, pp. 699–706.
[26] Z. Xiao et al., “Emrshare: A cross-organizational medical data sharing
and management framework using permissioned blockchain,” in 2018
ACKNOWLEDGEMENTS IEEE 24th International Conference on Parallel and Distributed Systems
(ICPADS), Dec 2018, pp. 998–1003.
FH would like to thank the financial support provided by [27] O. Attia, I. Khoufi, A. Laouiti, and C. Adjih, “An IoT-Blockchain
Architecture Based on Hyperledger Framework for Healthcare Monitor-
CNPq (Grant Nro. 437937/2018-6) and FAPESP (Grant Nro. ing Application,” in 2019 10th IFIP International Conference on New
2018/25805-5). Technologies, Mobility and Security (NTMS), June 2019, pp. 1–5.

137

Authorized licensed use limited to: Frankfurt University of Applied Sciences. Downloaded on December 04,2020 at 19:50:59 UTC from IEEE Xplore. Restrictions apply.
 [28] F. Curbera et al., “Blockchain: An enabler for healthcare and life
sciences transformation,” IBM Journal of Research and Development,
vol. 63, no. 2/3, pp. 8:1–8:9, March 2019.
[29] M. H. Kassab, J. DeFranco, T. Malas, P. Laplante, g. destefanis, and
V. V. Graciano Neto, “Exploring research in blockchain for healthcare
and a roadmap for the future,” IEEE Transactions on Emerging Topics
in Computing, pp. 1–1, 2019.
[30] S. Cichosz, M. Stausholm, T. Kronborg, P. Vestergaard, and O. Hejlesen,
“How to use blockchain for diabetes health care data and access
management: An operational concept,” Journal of Diabetes Science and
Technology, vol. 13, p. 193229681879028, 07 2018.
[31] Worldometers, “Estonia Population ,” https://www.worldometers.info
/world-population/estonia-population/, 2020, last access: 08/01/2020.
[32] Nortal, “Blockchain and healthcare: the Estonian experience,”
https://nortal.com/blog/blockchain-healthcare-estonia/, 2018, last access:
02/01/2020.
[33] H. Composer, “Hyperledger composer modeling language,”
https://hyperledger.github.io/composer/v0.19/reference/cto language,
2019, last access: 17/01/2019.
[34] Worldometers, “Brazil Population ,” https://www.worldometers.info
/world-population/brazil-population/, 2020, last access: 08/01/2020.
[35] InCor, “Numbers of the Heart Institute - InCor (in portuguese),”
http://www.incor.usp.br/sites/incor2013/index.php/conheca-estrutura
/numeros, 2019, last access: 02/07/2019.
[36] J. Mendes, M. Cecı́lio, and V. Osiano, “Small sized hospitals
from SUS in the state of São Paulo (in portuguese),” BEPA
[internet], vol. 11, no. 128, pp. 25–40, 2014, avaliable from:
http://portal.saude.sp.gov.br/resources/ses/perfil/profissional-da-saude/
destaques//saude em dados gais 17 hospitais de pequeno porte.pdf.
[37] S. Silva and M. Santos, “Sistemas emergentes no ecossistema digital
brasileiro de saúde pública: Uma abordagem sociotécnica,” in Anais
Estendidos do XV Simpósio Brasileiro de Sistemas de Informação. SBC,
2019, pp. 63–68.

138

Authorized licensed use limited to: Frankfurt University of Applied Sciences. Downloaded on December 04,2020 at 19:50:59 UTC from IEEE Xplore. Restrictions apply.