2022 6th International Conference On Computing, Communication, Control And Automation (ICCUBEA)

Pimpri Chinchwad College of Engineering (PCCOE), Pune, India. Aug 26-27, 2022

Electronic Health Record Management using

Hyperledger Fabric
2022 6th International Conference On Computing, Communication, Control And Automation (ICCUBEA) | 978-1-6654-8451-0/22/$31.00 ©2022 IEEE | DOI: 10.1109/ICCUBEA54992.2022.10010988

1st Rohit Kota 2nd Harsh Wadhawe 3rd Vishaal Prasaad

B.tech Computer Science College of B.tech Computer Science College of B.tech Computer Science College of
Engineering, Pune Engineering, Pune Engineering, Pune
Pune, India Pune, India Pune, India
kotar18.comp@coep.ac.in wadhawehr18.comp@coep.ac.in prasadv18.comp@coep.ac.in

Prof. Rohini Sarode

Assistant Professor
Department of Computer Science
College of Engineering, Pune
Pune, India
rys.comp@coep.ac.in

Abstract—In these modern times, receiving health care services
from various hospitals and clinics has become very common due
to the predominant increase in the specialization of health care
services and also as a consequence of people’s moving to different
cities and countries. Doctors who have a thorough understanding
of a patient’s medical history can more accurately make a
diagnosis and provide treatment for the patient in the right
timeframe. Despite improved medical services, healthcare service
providers face issues in sharing sensitive data. The major problem
faced by healthcare service providers right now is ensuring data
security, data integrity, and confidentiality of the data while
keeping the privacy of patients intact simultaneously. To solve this
problem, we propose a blockchain technology using Hyperledger
Fabric that allows patients to control their medical information
and access doctors for data. By creating a distributed database
of the patient’s medical records, the patient can switch hospitals
without bothering about the medical records. It also makes it
easier for a doctor to keep track of a patient’s medical history.
Index Terms—Electronic Health Record, blockchain, interop-
erability, hyperledger fabric, smart contracts, privacy, security,
Ethereum.
I. INTRODUCTION
As we know, blockchain provides a distributed database
framework through which we can make secure queries. Us-
ing Certificate Authorities, Member- ship Service Providers,
and smart contracts, we achieve data security and privacy
on the blockchain. Nowadays, sharing and storing personal
and medical data among network participants using unsecure
mechanisms may cause the leak of critical data. It is also
possible for unauthorized personnel to access and modify data.
In today’s systems, patient medical records are stored digitally,
called Electronic Health Records (EHR), which is shared with
different healthcare providers. EHRs hold the patient medical
information in the form of Electronic Medical Records (EMR).
Information about a patient’s medical diagnoses, diseases,
history, treatments, and reports is stored in Electronic Medical
Record (EMR). In current systems, patients hardly have any
control over their personal data. The most critical issue is that
they do not maintain interoperability among various involved
identities. Therefore, a trustworthy and safe medical storage
system is a necessity for us in the modern age.
To meet these criteria, a blockchain must include the fea-
tures stated above, as well as an enterprise-grade network to
prevent unauthorised access. As a permissioned blockchain,
Hyperledger Fabric (HLF) provides a network that uses smart
contracts to conduct network transactions. It enables all nodes
in the network to safely share data without relying on a central
authority to supervise all transactions. After other nodes have
verified a transaction, it is stored cryptographically. Features
of Hyperledger Fabric will be suited for building an integrated
EHR management platform with a high level of privacy and
confidentiality. We’ll explain how using Hyperledger Fabric to
store, administer, and maintain electronic medical records can
assure patient data security and privacy in this article.
II. BLOCKCHAIN AND HYPERLEDGER FABRIC
A. Why Blockchain and Hyperledger Fabric?
The blockchain stores data in a cryptographically secure
manner, which solves the problem of data security. CA and
MSP components provide secure identities like private keys,
certificates, and validation for the users that are connected
to the network, which solves the problem of authorization
and authentication. Fabric is a permissioned blockchain, so
the data remains confidential to the outside world. It comes
with the distributed nature of blockchain, which makes data
available to all permissioned systems. The blockchain records

978-1-6654-8451-0/22/$31.00 ©2022 IEEE 1

Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE GOIAS. Downloaded on December 13,2023 at 03:10:45 UTC from IEEE Xplore. Restrictions apply.
are immutable, and that’s why the data integrity problem has
been solved. The Fabric provides the consensus algorithm.
Practical Byzantine Fault Tolerance solves the problem of 51%
of nodes getting hacked, which we can see in Bitcoin because
all the approval from the peers, which is by default required,
can be configured in the channel configurations as well.
Scalability has no problem either, because any number of peers
or users can join the network. Because all the modules are
pluggable, we can use different databases as well. The Fabric
SDK is available in different programming languages like Go,
Java, Javascript, and Typescript. The major components for
constructing an EHR system using the Hyperledger Fabric
architecture are:
• Membership service provider (MSP): Using a member-
ship service provider, all network entities are enrolled in
the network with a unique identity. An individual MSP,
along with a general MSP, is used by every organisa-
tion to perform transactions, authorizations, and sign-in
operations across the network.
• Distributed ledger: Every time a peer commits, the
transaction data is appended to a distributed immutable
ledger. Each ledger also has two additional components:
the world state and the transaction log. A world state is
a representation of the ledger at any given time, whereas
a transaction log maintains a record of all transactions
recorded in that world state.
• Consensus: Transacting on Hyperledger Fabric only hap-
pens through specific peers. The endorsement policy de-
termines the minimal acceptance of peers for appending
transactional data to the ledger.
• Smart contracts: Smart contracts are predefined ways to
perform every task or function and are used to manage
and restrict the participants’ access to the ledger. There
are several general programming languages through
which they can be implemented, including Go, JavaScript,
and Java.
• Chaincode: Chaincode is defined at the time of the
creation of the channel, and its role is to initialise and
manage the ledger state. It consists of a set of smart
contracts as well as an endorsement policy. To engage
in any transaction through this channel, all channel par-
ticipants must first authorise the chaincode. All of the
tasks that can be executed across the network are stored
in Chaincode.
• Channel: Only authorised parties have access to a per-
missioned blockchain network. A channel is used to carry
out all transactions in Hyperledger Fabric.
• Orderer: It is the network entity in charge that manages
and ensures that the transactions are appended to the
ledger in a sequential manner. This was done after the
endorsement by the peers. An ordering service is formed
after coordinating multiple orderer’s to work efficiently
within a network.
• Peers: Peers are comprised of two components: Ledger
and smart contracts. They are directly involved in the
2
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE GOIAS. Downloaded on December 13,2023 at 03:10:45 UTC from IEEE Xplore. Restrictions apply.
transactions and are used by the organisations to connect
to the network. Peers are divided into two categories.
Endorsing Peers: For endorsing transactions while Com-
mitting Peers: To commit the transactions. This is done
according to the endorsement policy, which is predefined
within the network.
B. Fabric SDK
The Fabric SDK (Software Development Kit) is used to
communicate with the blockchain network. NodeJS and Ex-
pressJS provide routes and APIs that are to be used by
AngularJS for the frontend. The backend server then internally
calls the Fabric SDK to interact with the network. The
SDK provides multiple APIs to connect, invoke, retrieve, and
terminate transactions from the ledger. The “gateway” forms a
link between the SDK and the backend server through which
all the transactions within the network are to be routed. Each
transaction is signed by the user’s certificate, where it can
be verified and endorsed to the ledger. The SDK handles
the connection between the patient/ doctor and the triggers
they supply to the User Interface (UI). Whenever an API
is triggered, it establishes a network connection along the
channel and fetches the chaincode. This transaction will be
finally completed by invoking the gateway class’s termination
methods.
III. PROPOSED SOLUTION
To implement the blockchain solution for the EHR system,
we will map some components to the EHR system so the
organisations in the fabric components are the hospitals in
the real world. All the hospitals are connected on the same
channel, and if some hospitals want to connect or maintain
some other form of data, like cancer data, they will form
a new channel. The new hospitals will be connected to the
existing channel only after approving the hospitals that are
configured in the channel configurations. The patient data
will be treated as assets in the fabric, and all the data will
be stored in the blockchain database. The Fabric framework
provides a getHistory API which will be used to retrieve
the patient’s data and will be shown to the doctor so that
he can get a proper understanding of the patient’s condition.
There are three roles involved in the system: admin, patient,
and doctor. Each hospital has an admin who is responsible
for registering any new patient that visits the hospital and
the doctors working there. Every hospital would have the
patient’s EHR in their ledger. Patients have complete control
of their medical information and they can authorise doctors
who can view the patient medical details through grant and
revoke access mechanisms. When a patient grants access to the
doctor, only the doctor who has been granted access can read
the patient’s EHR and update only the EMR of the patient’s
health record when needed. Once the patient revokes access,
the doctor cannot access the patient’s EMR. Fabric will allow
patients to move more freely between doctors and hospitals
inside the network as a result.

Fig. 1. Web Application
Fig. 2. Hyperledger Fabric Network
A. Architecture
The architecture is very simple. The network has been
established by the blockchain administrator and all the peers in
the organisation are the Docker running containers. To connect
the network, the Fabric SDK is used, which is written in
multiple languages, but we have used Javascript. Along with
that, we are using ExpressJS as a server for the backend by
providing a REST API. We used the Angular 13 framework
for the user interface. Communication between the frontend
and backend is done using REST API calls with JSON web
tokens (JWT) for authentication, and Redis is a key-value pair
database which is used to store the doctor’s credentials (so
just a username and password). In the network, the orderer
organisation initiates the blockchain, which means it creates
the first block in the blockchain, which is called the “genesis
block.” The other two organisations, which are like hospitals
3
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE GOIAS. Downloaded on December 13,2023 at 03:10:45 UTC from IEEE Xplore. Restrictions apply.
1 and 2, come together and form a channel.
The public-private key pairs are generated by MSP and CA
which are also responsible for signing digital certificates. To
be trusted in the network, every hospital needs to have their
own MSP and CA. In our solution, every hospital has one peer
as they cannot directly interact with “HospitalChannel” in the
fabric network. A copy of the state database is associated with
every peer, which stores the current world state of the network.
When any CRUD transaction is carried out, the world state
is updated for all the peer ledgers. We have used the name
“HospitalChannel”, which is the only channel in our simple
network and it is connected with the help of the hospital
channel configuration. So in this case, it is shown in Figure
2 that Hospital 3 is an additional organization. If it wants to
connect this channel, hospitals 1 and 2 need to give approval.
Every hospital peer has one ledger and a smart contract on it.
The current options for databases provided by Hyperledger
Fabric are the default database, LevelDB, and an alternate
database, CouchDB. We have used CouchDB in our solution
because it can handle images and supports indexing. All the
patient data is stored in CouchDB, so there is no need to
have a separate EHR store. In the fabric network, the number
of Docker images of the peers will be the same as that of
CouchDB because each peer has one CouchDB and they both
run on the same server. We have used CouchDB for the world
state and all the transaction records that lead to the world state
have been stored in a log file called “transaction log”. Smart
contract is the main logic that helps the participants in the
fabric network interact with the database. We have 3 smart
contracts for every role: admin, patient, and doctor. These
smart contracts are packed into a chaincode, and this chaincode
is deployed on every peer node of the hospitals and on the
“Hospitalchannel” too. To create a transaction, the Fabric SDK
needs to invoke a smart contract, which then performs changes
to the ledger.
B. Implementation using Hyperledger Fabric Components
1) Smart contracts: As described in the architecture sec-
tion, our application is primarily comprised of three
smart contracts: admin, patient, and doctor. When the
chaincode is deployed, all smart contracts in it are
available to the application.
• Admin smartContract - Admins can add or delete
patient objects on this smart contract. The smart
contract also allows us to see patients available in
the network.
• Patient smartContract - This smart contract has
the logic for the patient to interact with the ledger.
In addition to updating or viewing personal infor-
mation, a patient can also see the history of the
doctors they have visited using the getHistory API.
A patient may also grant or revoke access methods
to the doctor that will allow him or her to see the
medical details of the patient, and finally, the patient
may set new login credentials while interacting with
the application.
 • Doctor smartContract - By using this smart con-
tract, the doctor can update or read the EMR of the
patient.
The goal of these three smart contracts is to ensure that
the appropriate role has invoked the appropriate smart
contract to interact with the ledger’s data. When one
role interacts with the application using its own methods,
other roles cannot access these same methods. They are
free to employ their own methods, which are specified
in their smart contracts. The method for reading patient
data is the same for all roles in our application, but the
method for retrieving data using smart contracts varies
depending on the role. For example, an admin can only
see the patient’s name, a doctor can see the patient’s
medical details if the patient has granted access to the
doctor, and a patient can see the entire object.
2) Database: We have used CouchDB as our database and
stored each patient health record as a JSON document,
shown below in Figure 3. We have grouped JSON
documents (in our instance, health records) by executing
grouped queries as CouchDB supports it. Each EHR
features a number of fields, including the patientId field,
which is used to identify the patient who owns the
medical record. Other areas are for the patient’s personal
information and the electronic medical record (EMR).
The last field is a list of doctors who have access to the
EMR. A doctor’s ID must be listed on the list to gain
access to the EMR; otherwise, it will be denied.
Fig. 3. Data Collection Configuration
3) Certificate Authority (CA): To make transactions in
the network, the participants need to prove that they can
be trusted. In our scenario, all hospitals have their own
CA where they distribute certificates that are digitally
signed. A public key with a set of rules and permissions
is given to each participant. After authenticating the
CA’s signature, if the CA is trusted and its public
key is known, that participant owning the public key
as mentioned in the certificate can be trusted. Each
hospital in the network has its own CA server producing
identities using the server’s client to prove that the
identity belongs to their hospital. With the Fabric SDK,
we made sure that our application leverages CAs to
allow patients and doctors to register and enrol.
4
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE GOIAS. Downloaded on December 13,2023 at 03:10:45 UTC from IEEE Xplore. Restrictions apply.
4) Membership Service Provider (MSP): In our applica-
tion, all the participants of the network, such as admins,
patients, and doctors, need to prove their identity to carry
out any type of transaction within the network, MSP is
the one to manage those identities. The MSP checks the
members’ private keys by comparing them to the public
key that has been stored. The hospital’s peers propose
a transaction by using the hospital’s private key in our
application. The public key, which is needed to ensure
that the private key associated with the transaction
is legitimate, is preserved in the MSP present at the
ordering service. Once the participant’s public key is
stored the hospital’s MSP, participants are connected as
hospital members to any other member of the hospital.
C. Features
Our application offers the following benefits:
• Blockchain technology can be used for the exchange of
patient information between hospitals, pharmacies, and
insurers. This technological advancement can optimise
the medical supply chain and make previous data manage-
ment systems obsolete for cross-verifying one’s medical
records and history.
• All data is shared within the ledger using smart contracts.
Access to the patient data is limited for collaborators, and
patients have the option of granting or rescinding their
access.
• The system is robust and secure due to the confidentiality
and immutability of the blockchain ledger.
• Hyperledger Fabric is a zero-knowledge protocol imple-
mentation, meaning that both the communicating parties
have no prior knowledge of each other. Thus, they need
to build trust only with the specific information provided,
without the use of any third-party authorization. Using
this method, the patient can interact with various stake-
holders while ensuring their privacy.
• Since blockchain is a universal technology, it will ensure
that the EHR architecture is interoperable and compatible
with a variety of healthcare applications.
• Blockchain technology ensures that chains of custody
remain transparent among participants.
D. Challenges encountered while developing the application
1) Since Nodejs doesn’t offer a good library for re- encryp-
tion, we have to write our own. While some libraries
exist, they don’t accept the usual forms of public and
private keys.
2) The public key is difficult to track since the wallet
contains the private key and certificate.
3) While starting the network, some Docker containers are
powered down due to scaling the number of peers.
E. Issues in HLF
1) Implementing private data collection is difficult since
the getHistoryForKey API, which retrieves a patient’s
history, works for public data, not private data.
 2) There are issues with configuring HLF when creating a • Cons:
user-defined role instead of grouping it under “client”. 1) HLFs complex architecture can be overwhelming
3) Since the doctor is not an asset, their details are being and difficult to deploy.
used as attributes of an identity. But in HLF, a client 2) Limited support for database management.
cannot read the details of another client. The admin can
read the client attributes. B. Conclusion
Although EHRs are used widely in healthcare services
IV. DIFFERENCES BETWEEN THE CURRENT AND
today, there are still many issues that need to be resolved
PROPOSED SYSTEMS
with respect to the security of medical data and the privacy
A. Current system in Place of patients’ information. So we proposed a solution, which
India has a population of over a billion people. People here is to use HLF, a blockchain-based solution for this purpose.
are segregated into different communities by a wide range By using HLF, patients can control access to their data and
of geographical, linguistic, religious, and ethnic factors. This medical records. It will also ensure that only verified and
clearly requires a robust and secure healthcare infrastructure authorised personnel can access the respective patient data.
that allows each citizen’s health data to be processed quickly HLF helps in sharing data among all network entities securely
and efficiently. Currently, hospitals in India still maintain their and limits the possibility of leakage of any personal data.
records in a centralised database storage. The data is rarely However, there are some issues that can be further im-
circulated among different hospitals to coordinate their treat- proved. Since we will be dealing with lots of data, the
ment. This can conceal a patient’s previous medical records support for the databases needs improvement. Also, certain
and history, such as allergies or other chronic disorders, which performance and security issues in HLF and blockchain can
can have severe repercussions. The establishment of a network be enhanced.
with HLF can considerably improve the security and efficiency C. Acknowledgements
for insurers, doctors, and patients to access medical data.
The authors sincerely thank Prof. Rohini Sarode for her
B. Comparing similar technologies mentorship and feedback that significantly enhanced the
manuscript.
Ethereum Fabric
The Ethereum network is a public Fabric is a permissioned
network that anyone can access blockchain, which implies REFERENCES
via the web. that without the MSP’s valid [1] Ahmed, M., Reno, S., Akter, N., & Haque, F. (2020, December). Secur-
It’s designed for the B2C credentials, no one can access ing medical forensic system using hyperledger based private blockchain.
(Business-to-Consumer) sector the network. In 2020 23rd International Conference on Computer and Information
and isn’t suitable for enterprise- Fabric allows us to construct pri- Technology (ICCIT) (pp. 1-6). IEEE.
grade product development. vate channels with specific peo- [2] Frauenthaler, P., Sigwart, M., Spanring, C., Sober, M., & Schulte, S.
ple as well as private transactions (2020, November). ETH relay: A cost-efficient relay for ethereum-based
Every transaction is made public
that are not accessible to all net- blockchains. In 2020 IEEE International Conference on Blockchain
and documented in a single chain
work users. (Blockchain) (pp. 204-213). IEEE.
that is open to the public which
[3] Alshalali, T., M’Bale, K., & Josyula, D. (2018, December). Security
encourages openness and fosters The lack of such digital to-
and privacy of electronic health records sharing using hyperledger
transparency. kens makes Hyperledger Fabric
fabric. In 2018 International Conference on Computational Science and
To function properly, the archi- more ergonomic and practical to
Computational Intelligence (CSCI) (pp. 760-763). IEEE.
tecture necessitates the use of a maintain, making it a preferable
[4] Vardhini, B., Dass, S. N., Sahana, R., & Chinnaiyan, R. (2021, January).
built-in cryptocurrency or digital choice for largescale enterprises.
A Blockchain based Electronic Medical Health Records Framework
token. using Smart Contracts. In 2021 International Conference on Computer
Communication and Informatics (ICCCI) (pp. 1-4). IEEE.
[5] Abeywardena, K. Y., Attanayaka, B., Periyasamy, K., Gunarathna, S.,
TABLE I Prabhathi, U., & Kudagoda, S. (2020, December). Blockchain based Pa-
ETHEREUM VS FABRIC tients’ detail management System. In 2020 2nd International Conference
on Advancements in Computing (ICAC) (Vol. 1, pp. 458-463). IEEE.
[6] “ Hyperledger Fabric, ” https://hyperledger-fabric.readthedocs.io/en/
release-2.2/ledger/ledger.html
V. RESULTS AND CONCLUSION [7] Fabric, H. (2021). The Ordering Service. Docs, Release-2.2,[Online].
Available: https://hyperledger-fabric. readthedocs. io/en/release-
A. Result 2.2/orderer/ordering service. html.
[8] Antwi, M., Adnane, A., Ahmad, F., Hussain, R., ur Rehman, M.
• Pros: H., & Kerrache, C. A. (2021). The case of hyperledger fabric as a
1) The Fabric architecture provides plugins for the blockchain solution for healthcare applications. Blockchain: Research
management of network identities. and Applications, 2(1), 100012.
[9] Stamatellis, C., Papadopoulos, P., Pitropakis, N., Katsikas, S., &
2) MSPs help with data security and confidentiality. Buchanan, W. J. (2020). A privacy-preserving healthcare framework
3) Since data mining is not being used, the perfor- using hyperledger fabric. Sensors, 20(22), 6587.
mance of the solution is optimized. [10] Li, D., Wong, W. E., & Guo, J. (2020, January). A survey on blockchain
for enterprise using hyperledger fabric and composer. In 2019 6th
4) Private channels can be created for a small number International Conference on Dependable Systems and Their Applications
of participants in the network. (DSA) (pp. 71-80). IEEE.

5
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE GOIAS. Downloaded on December 13,2023 at 03:10:45 UTC from IEEE Xplore. Restrictions apply.
[11] Metnitz, P. G. H., & Lenz, K. (1995). Patient data management systems
in intensive care—the situation in Europe. Intensive care medicine,
21(9), 703-715.
[12] J. Sousa, A. Bessani, and M. Vukolic, “A byzantine Fault-Tolerant
ordering service for the hyperledger fabric blockchain platform,” in
Proceedings - 48th Annual IEEE/IFIP International Conference on
Dependable Systems and Networks, DSN 2018, 2018, no. Section 4,
pp. 51–58
[13] FILIPPO BOIANI,”Blockchain Based Electronic Health Record Man-
agement For Mass Crisis Scenarios”,STOCKHOLM, SWEDEN 2018.
[14] Castro, M.,& Liskov, B. (1999, February). Practical byzantine fault
tolerance. In OsDI (Vol. 99, No. 1999, pp. 173-186).
[15] S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” J. Gen.
Philos. Sci., vol. 39, no. 1, pp. 53–67, 2008.
[16] Kotla, R., & Dahlin, M. (2004, June). High throughput Byzantine
fault tolerance. In International Conference on Dependable Systems and
Networks, 2004 (pp. 575-584). IEEE.

6
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE GOIAS. Downloaded on December 13,2023 at 03:10:45 UTC from IEEE Xplore. Restrictions apply.