Utilization of the Blockchain Network in The Public
Community Health Center Medicine Supply Chain
Hartanto Kumiawan
dep. Of computer engineering dep. Of computer engineering
Keimyung University
Daegu, Republic of Korea Daegu, Republic of Korea
hartantokumiawan@gmail.com 5341308@stu.kmu.ac.kr
Abstract—Distribution of medicine in the —œ‰“ŠG Œˆ“›G
community centers has been regulated and monitored in an
official distribution channel. However, counterfeit medications
still circulate in the community. Circulation of counterfeit
medicines is caused by factors from businesses, consumers, and
medicine distribution supervision. The use of blockchain
technology in supply-chain has shown new breakthroughs to
overcome these problems since it ensures immutability,
transparency, and decentralization of data. In this paper, we
proposed a new blockchain-based Medicine Supply Chain
Management (MSCM) system. The proposed system has been
applied to medicine distribution channels between public
community health centers in Indonesia. To evaluate the
proposed system, we used JMeter as a benchmarking tool to
measure the system performance in terms of transactions per
second, latency, and the utilization of resources.
Keywords - blockchain, supply chain management,
healthcare, Hyperledger fabric, performance analysis
I. INTRODUCTION
The World Health Organization (WHO) estimates that 10%
of the medicines in the world may be fake [1]. World Customs
Organization (WCO) also estimated that losses resulting from
counterfeit medicines reach $ 200 billion annually, as well as
counterfeit pharmaceuticals accounting for more than half of
the 24,000 confiscation cases related to illegal medicines in
2013 [2]. Indonesia assesses the value of counterfeit
medicines discovered in 2012 to be in the region of USD 61.6
million [3].
Indonesia had around 9,993 units of Puskesmas (public
community health center) in 2018, as many as 3,623 units
(36%) have inpatient services [4]. To improve services,
currently, several Puskesmas in cities and districts have begun
to use the health system that have MSCM features in
accordance with the regulations of the Republic of Indonesia's
Ministry of Health [5]. The existing health system in the
Puskesmas is diverse and still has weaknesses, especially in
the MSCM feature, for example, the low accuracy of data and
manipulation of medicine inventory data.
This study aims to use the blockchain technology in
pharmaceutical supply chains with true and reliable data for
Puskesmas. First, it aims to propose an integrated system for
conducting and recording medicine supply transactions on the
blockchain network with MSCM. Data is distributed to all the
participants in the network and it is measured according to the
time needed for fully propagated. Furthermore, we discuss the
issues related to access rights in the blockchain system to
maintain data security. Finally, the efficiency and reliability of
the system in the process of retrieving data to track historical
information in a chain are presented.
The paper is organized as follows: Section 2 introduces
the background of MSCM and blockchain with a discussion
of the application of the blockchain in the MSCM, section 3
&RS\ULJKW.,&6
Authorized licensed use limited to: University of Gothenburg. Downloaded on August 31,2021 at 15:36:00 UTC from IEEE Xplore. Restrictions apply.
JungYeon Kim Hongtaek Ju
dep. Of computer engineering
Keimyung University Keimyung University
Daegu, Republic of Korea
junt@kmu.ac.kr
provides the proposed system architecture, section 4 explains
the detailed implementation, section 5 discusses the conducted
experiments as well as the gotten results. Finally, Section 6
concludes the paper.
II. BACKGROUND
A. Brief description of MSCM
The Medicine Supply Chain Management (MSCM) is a
continuous multi-period process based on the patient's need
for medicines. Therefore, the amount of drug needed in a
certain period cannot be certain.
The problem that often occurs in MSCM is the
distribution of medicines that are not in accordance with the
needs of medicine stocks in each location. It results in the
possibility that the medicine stock will be canceled at the
location where it is needed, while there is an excess of
medicine stock at the unnecessary site [6]. The entry of
medicine from unofficial suppliers is a loophole in the
circulation of fake medicines.
B. Combining blockchain with MSCM
Blockchain is a distributed database that keeps a growing
list of blocks secured from disruptions and revisions.
Composed of blocks, holds a collection of individual
transactions. Each block contains a timestamp and a link to the
previous block [7]. This cryptographic technology offers a
way for people who do not know or do not trust each other to
make notes about who owns what will force the agreement of
all the people concerned. It is a way to build and preserve the
trust [8].
Another perspective on extracting potential blockchain as
a case of using "original" blockchain is source tracking. It
seems that tracking the origins along the MSCM can be one
of the blockchain applications.
III. SYSTEM DESIGN
A. The Schema of the Medicine Supply Chain
Figure 1 represents the block chain that manages the
supply chain and stores data related to medicines,
manufacturer, distributors, health office, public hospitals,
purchase orders, and commodity transfer data, among the
trusted partners who apply consensus to maintain the
consistency of the distributed ledger.
 $31206

Fig. 1. Medicine distribution supply chain management scenarios in
the proposed blockchain system.
B. The Proposed System Architecture of the Medicine
Supply Chain
Necessary data is stored on a distributed ledger in blocks,
were each block consists of several transactions with
encrypted hashes of previous blocks forming a chain of linked
blocks. Transaction proposals are submitted by end-users (i.e.
health offices, public hospitals, factories, distributors, retailers)
by calling back-end providers through the blockchain network
shown in Figure 2.
Fig. 2. System architecture of the proposed medicine supply chain
management.
The data access control can be defined by many parties,
depending on different scenarios. For instance, after initiating
the order, the public hospital needs to be able to define who
has access to the order results. The data viewer should be able
to define access to data if the data need to be transferred to
another individual. The service provider should also have
control over the data because it provides the service.
C. The Medicine Supply Chain Transaction Process
The activity diagram shows the flow of information
between the main entities in the system. Medicine supply
chain transactions are divided between peers, and transactions
are carried out by peers in the world state. Up to the order
transaction level, several transactions can be processed
simultaneously by each node. The role of each component in
the network in the drug supply chain is displayed and the
ordering transaction process is shown in Figure 3 where the
Health Service initiates an order.

Authorized licensed use limited to: University of Gothenburg. Downloaded on August 31,2021 at 15:36:00 UTC from IEEE Xplore. Restrictions apply.
Fig. 3. PO and commodity transfer activity diagram.
IV. IMPLEMENTATION.
A. . Development Environment
Table 1 describes the software and hardware used during
the implement of the blockchain-based MSCM system.
TABLE I. PROPOSED BLOCKCHAIN BACK-END SERVER MEDICINE
SUPPLY CHAIN
Component Description
IDE-tools Visual Studio Code v1.39.1
Hyperledger-Fabric version v1.2
Node-version v10.15.3
CLI Tool Composer REST server v0.19
Docker-Compose Version 1.13.0
Python v.2.7.15+
Docker-Engine version Version 19.03.12-rc1
CPU Intel Core i5-7500T CPU @2.70GHz
Operating Systems Ubuntu Linux 18.04 LTS
Memory 8GB
B. Network Requirements and Topology
The system requires a stable Internet connection with at
least 512kb/s, to create any blockchain transactions. The basic
elements of the blockchain network are peers, which write
ledgers and smart contracts to carry out operations.
Hyperledger Fabric also supports the creation of multiple
channels in the blockchain. Channels are blockchain safe
paths used to separate and differentiate data for a group of
peers.
C. The Chaincode of the Medicine Supply Chain
The proposed system uses the Hyperledger Composer
v0.19 for the implementation of the blockchain network. The
used blockchain network elements were created as composer
files. The participants, assets, and transactions proposed in the
solution structure were created as a model file (.cto) using the
Hyperledger Composer Modeling Language. The transaction
logic was created as a logic file (.js) using Javascript. The
access control rules were created as an access control file (.acl)
using the Hyperledger Composer Access Control Language.
The queries were created as the language used to return data
about the blockchain world-state (.qry) [9].
The initiatePurchaseOrder() function (Algorithm 1) is
invoked with InitiatePO. This function starts by calling the
getFactory() function to search and find network servers and
suppliers and then calls the getCurrentParticipant () function.
The order will ask for the network server with the ID from
InitiatePO, then enter the order item and provide the order
status if conditions are met to return to the assetRegistry to add
the order.
 Algorithm 1. Insert Purchase Order Information
1: Function initiatePurchaseOrder(InitiatePO)
2: factory <- getFactory()
3: NS <- 'org.sipchain.network'
4: me <- getCurrentParticipant()
5: order <- factory.newResource(NS, 'PO', InitiatePO.orderId)
6: order.itemList <- InitiatePO.itemList
7: if (InitiatePO.orderTotalPrice) then
8: order.orderTotalPrice <- InitiatePO.orderTotalPrice
9: order.orderStatus <- 'INITIATED'
10: order.orderer <- me
11: order.vendor <- InitiatePO.vendor
12: getAssetRegistry(order.getFullyQualifiedType()).then(function
(assetRegistry)
13: return assetRegistry.add(order)
D. Implementation Result
When query a medicine data, the REST composer of
Hyperledger server responds to the query in JSON format as
shown in Figure 4.
Fig. 4. Interface of REST Composer server for fetching medicine
records.
V. EXPERIMENT
The experiment uses two independent variables, the
request type and the number of clients. First, there are two
major HTTP methods related to the current application, and
they are Get and Post. Different methods may have different
performances. More specifically, the Get method should be
faster because it is acquiring information from the blockchain,
which does not change the world state of the common ledger.
The Post method should be slower because it requires that
information be written to the blockchain, which will change
the world state of the common ledger. Therefore, the type of
method was selected as an independent variable. Second, the
number of clients that are making requests can affect the
performance. When the number of clients increases, then the
performance may decrease. As a result, the number of clients
was selected as another independent variable. Note that the
number of nodes was not taken as a directly manipulated
variable for several reasons. Consequently, the time acquired
can be used as the estimation of the time to write information
to the blockchain for an additional node. This is because each
node functions similarly. For the Get request, because data can
be acquired from one node, there should not be a significant
difference between different numbers of nodes.
As mentioned above, the used HTTP methods are Get and
Post. The number of clients was divided into three levels: 25,
50, and 100 clients. The three levels here help to determine
whether the performance drops linearly or not when the
number of clients has increased. The performance under the

Authorized licensed use limited to: University of Gothenburg. Downloaded on August 31,2021 at 15:36:00 UTC from IEEE Xplore. Restrictions apply.
one client condition provides the baseline performance for the
solution.
A. . Experiment Method
The test plan was set up in the JMeter GUI mode and the
test was run in the no- GUI mode, as suggested by the JMeter
Manual. First, the server was set to run on the NGROK Cloud
service, then the 100 sample participants and sample initiate
PO were created. Afterwards, one client condition was
administered for the two Get methods and two Post methods.
Then the 25, 50 and 100-client condition was administered for
the two Get and two Post methods, each of the clients targeted
one unique resource under each request. each of the clients
targeted one unique resource under each request. For all the
measurements, the ramp-up period was set to 1s.
In addition, to estimate the difference between the Get
request and the Post request, the measurements under the three
levels of client numbers can be taken as three different
measurements to calculate the average, standard deviation
(SD), 95% confidence intervals (CI), and the 99% CI for the
difference.
B. Experiment Results
Overall, for the Get and Post methods, data were averaged
over each of the two requests for each number of client
conditions. It provides a more accurate measurement of the
overall performance compared with a measurement of a single
request. The overall performance is shown in Figure 5. First,
The relatively slower Post request compared with the Get
request can be seen across the whole range of the number of
clients tested. This confirms the prediction that Get requests
are faster than Post requests. Writing and updating the ledger
status on the blockchain is the first reason that new
information is a Post request, which requires extra time.
Second, if the number of clients increases, so will the latency.
Thus, the Get and Post requests confirm the second prediction,
which estimates that as the total number of clients increases,
performance will decrease (i.e., increase in response latency)
keeping in mind that each additional number of clients
requires a certain amount of time and resources.
Fig. 5. The overall performance by the number of clients and request
type
Figure 6 describes the average latency of the proposed
system, min, max, and percentile. By querying transactions
with three different groups, this test aims to measure the
blockchain network latency as proposed. As the results are
shown in the figure, if the number of clients increases, the
system latency will increase.

Fig. 6. The latency in a query transaction (Get Request)
In addition, the effect of the number of nodes was
estimated. The overall difference between the Post and Get
requests is shown in Figure 7. The figure was acquired by
subtracting the overall Get request latency from the overall
Post request latency. The overall average difference across the
whole number of clients is 21 seconds, with an SD of 22
seconds. The 95% CI (±1.96SE) calculated is from -4 seconds
to 46 seconds. The 99% CI (±2.58SE) calculated is from -12
seconds to 54 seconds. This is an estimate for the time taken
by the blockchain to write and change ledger status
information on one peer node. Thus, if an additional node is
added, it functions similarly as this node, given that different
nodes are running in parallel and independently. As a result,
there will not be a significant increase in latency.
Fig. 7. The overall difference between the Post and Get requests
In some of these experiments several steps have been
implemented to test and analyze transaction response times,
latency, and resource usage of the proposed system
performance. The results of these experiments have shown
that using the blockchain technology system for supply chain
can improve throughput performance while minimizing
latency by using fewer resources. The possibilities for future
testing include increasing the network size and testing its
efficiency and feasibility show in Figure 8.
Fig. 8. Latency and throughput measurement

Authorized licensed use limited to: University of Gothenburg. Downloaded on August 31,2021 at 15:36:00 UTC from IEEE Xplore. Restrictions apply.
VI. CONCLUSION
In this paper, we have introduced blockchain technology
in MSCM at Puskemas. Specifically, we studied the MSCM
requirements when adopting blockchain technology and also
show the technical challenges when designing blockchain for
drug supply chains. A Case study is presented to address the
problem and introduce the medicine safety tracking system
that we are proposing. We implemented this system based on
the permissioned supply chain for supply chain scenario
medicine. Performance of various types of requests and
numbers of clients has been evaluated. The results show that
Get requests are faster than Post requests and latency increases
as the number of customers do. The Get request latency is, on
average, 21 seconds (SD = 22 seconds, 95% CI [-4 seconds to
46 seconds]) faster than Post requests that reflect the time for
the blockchain system to write and change ledger status
information on one node colleague. The proposed solution
provides a new way of managing data in the medical supply
chain to achieve reasonable efficiency.
ACKNOWLEDGMENT
This research was supported by Basic Science Research
Program through the National Research Foundation of Korea
(NRF) funded by the Ministry of Education (NRF-
2018R1D1A1B07050380), and Institute for Information &
communications Technology Promotion (IITP) grant funded
by the Korea government (MSIP) (No.2018-0-00539,
Development of Blockchain Transaction Monitoring and
Analysis Technology).
REFERENCES
[1] Gibson, L.; Drug regulators study global treaty to tackle counterfeit
drugs. BMJ (Clinical research ed.).March 2004; 328(03):486.
[2] World Customs Organization. The illicit trade report 2014. report.
Hongkong: World Customs Organizations, Department of education.
2015.
[3] Mahadi, T. Counterfeit drugs control 20% of Indonesia’s drug
circulation. Available online: https://industri.kontan.co.id/news/obat-
palsu-kuasai-20-peredaran-obat-indonesia (accessed on 1 January
2019).
[4] Kusnandar, V.B. Berapa Jumlah Puskesmas di Indonesia?. Available
online: https://databoks.katadata.co.id/datapublish/2020/01/12/berapa-
jumlah-puskesmas-di-indonesia (accessed on 1 April 2020).
[5] Pusdatin. Sosialisasi Sistem Informasi Puskesmas. Available online:
https://pusdatin.kemkes.go.id/article/view/19110500001/sosialisasi-
sistem-informasi-puskesmas.html (accessed on 1 April 2020).
[6] Wahana, A; Maylawati, D; Irfan, M; Effendy, H. Supply chain
management using fp-growth algorithm for medicine distribution.
Journal of Physics: Conference Series. 978. 012018. 10.1088/1742-
6596/978/1/012018. 2018.
[7] Nakamoto, S. Bitcoin: a peer‐to‐peer electronic cash system. Available
online: https://bitcoin.org/bitcoin.pdf (accessed on 10 March 2020).
[8] The Economist Staff. The great chain of being sure about things. The
Economist. Available online:
https://www.economist.com/briefing/2015/10/31/the-great-chain-of-
being-sure-about-things (accessed on 27 February 2020).
[9] Dhillon, V; Metcalf, D; Hooper, M. Blockchain Enabled Applications:
Understand the Blockchain Ecosystem and How to Make it Work for
You. 1st ed. Springer, 2017.