You are currently viewing a new version of our website. To view the old version click .
Electronics
  • Article
  • Open Access

7 May 2019

A Novel Medical Blockchain Model for Drug Supply Chain Integrity Management in a Smart Hospital

,
,
and
1
Department of Computer Engineering, Jeju National University, Jejusi, Jeju Special Self-Governing Province 63243, Korea
2
Daegu-Gyeongbuk Research Center, Electronics and Telecommunications Research Institute, Daegu-si 42994, Korea
*
Author to whom correspondence should be addressed.
This article belongs to the Special Issue Advances in Blockchain and Distributed Ledger Technology (DLT) for Industry 4.0 Technologies

Abstract

At present, in pharmacology one of the most serious problems is counterfeit drugs. The Health Research Funding organization reported that in developing countries, nearly 10–30% of the drugs are fake. Counterfeiting is not the main issue itself, but, rather, the fact that, as compared to traditional drugs, these counterfeit drugs produce different side effects to human health. According to WHO, around 30% of the total medicine sold in Africa, Asia, and Latin America is counterfeit. This is the major worldwide problem, and the situation is worse in developing countries, where one out of every 10 medicines are either fake or do not follow drug regulations. The rise of Internet pharmacies has made it more difficult to standardize drug safety. It is difficult to detect counterfeits because these drugs pass through different complex distributed networks, thus forming opportunities for counterfeits to enter the authentic supply chain. The safety of the pharmaceutical supply chain has become a major concern for public health, which is a collective process. In this paper, we propose a novel drug supply chain management using Hyperledger Fabric based on blockchain technology to handle secure drug supply chain records. The proposed system solves this problem by conducting drug record transactions on a blockchain to create a smart healthcare ecosystem with a drug supply chain. A smart contract is launched to give time-limited access to electronic drug records and also patient electronic health records. We also carried out a number of experiments in order to demonstrate the usability and efficiency of the designed platform. Finally, we used Hyperledger Caliper as a benchmarking tool to conduct the performance of the designed system in terms of transactions per second, transaction latency, and resource utilization.

1. Introduction

In the current era, every human being has the right to good health facilities. The emergence of an increasing number of diseases on a daily basis has also introduced new drugs into the market with different new labels. These drugs help the patient to get instant relief from pain, but despite the advantages, these drugs also have disadvantages. These drugs are manufactured by different pharmaceutical companies, and the authenticity of these organizations is unknown. According to the World Health Organization (WHO), tens of thousands of deaths occur in developing countries due to fake drugs, and many of the victims are children [1,2]. According to statistics, the annual business loss of US pharmaceutical industries is approximately $200 billion due to drug counterfeiting [3,4]. Counterfeiting is not the main reason itself; rather, as compared to traditional drugs, these counterfeit drugs produce different side effects to human health. These drugs may not help patients at all: Instead of curing the patient, they affect their health, and the side effects are even more dangerous to a person’s antibiotic resistance cells. It is difficult to detect counterfeits because these drugs pass through different complex distributed networks, thus forming opportunities for counterfeits to enter the authentic supply chain. In 2016, healthcare spending in the United States reached a record level of about $3.2 trillion [5]. It is estimated that about a quarter of this amount will be used for management costs. Several new companies, including Hashed Health, are trying to transform the healthcare industry to significantly reduce redundancy while preserving privacy by utilizing the cryptography hash function [6].
Currently, when someone is suffering from a disease, he or she goes to see a doctor. The doctor then examines the patient and, if needed, prescribes medication, which the patient can buy at a pharmacy or drug store. The list of medication is written on a special paper (called a prescription), usually signed or stamped by the doctor. The medical staff then goes to the pharmacy with the prescription. The pharmacist deciphers the prescription and hands over the required drug to the medical staff. This entire process is unsafe because it is relatively easily to forge a prescription. As the health factor is a main concern for everyone, many healthcare organizations emphasize drug traceability to avoid drug counterfeiting by using the latest IT technology (i.e., Blockchain) [7,8,9].
Blockchain is a decentralized ledger that is shared by all network participants. Because of its nature, modifying an existing ledger is not mathematically possible. This is achieved through the use of cryptographic algorithms. Blockchain data structure is a list of data blocks that are timestamped, immutable, and in strict order [10]. Immutability is implemented using a hash, a digital fingerprint of data. Every block has a reference to a previous block’s hash and thus gives a strict order to the blockchain. Following hashes from the current block ends with block 0—called the genesis block. It is the first created block on a specific blockchain. Blocks contain a list of transactions. This type of data structure enables provenance, that is, a single place of origin for any transaction. Since all blockchain transactions are timestamped and immutable, fraudulent drug traffickers can be easily identified. There are two types of blockchains: Public and private. Reliable healthcare companies need to register their products in private blockchain systems to ensure the reliability and quality of their products [11]. The fact that the private blockchain is hosted by a central entity and the specific manufacturer or supplier has access to the so-called drug blockchain proves its authenticity. The transparency of this blockchain is very helpful. Once the drug/medicine is manufactured and transferred from the manufacturer to the vendor, operational data are recorded in the blockchain. The entire process of checking the drug is very easy, and all links in the chain can be determined at any time. In the past, many blockchain systems were built on a permissionless network, which was unable to keep the ethnicity and privacy of the user data. In permissionless blockchain, anybody can interact with the network by creating their own address. However, in the case of healthcare, the permissionless blockchain network failed to manage the integrity and privacy of data related to patient information, drug management, and medical reports. As the primary goal of healthcare-based solution is to keep medical data secure and transparent, many permissionless healthcare blockchains are designed by applying some additional access control policy to maintain the integrity of data. However, these additional access control policies affect the efficiency of these healthcare systems. Many existing systems use the native cryptocurrency like token, which increases the mining cost. Regardless, the dispensation rate is limited (i.e., Ethereum cryptocurrency and is capable of up to 20 transactions per second only, which is very limited). Nevertheless, many challenges exist in the current blockchain-based healthcare system using a permissionless blockchain network as shown in Figure 1.
Figure 1. Challenges in current blockchain.
As the complexity of the supply chain becomes more important than it was a decade ago, visibility in accessible, reliable, and secure supply chains is becoming increasingly important. Moreover, this increasing complexity affects the cost of goods and their availability to consumers. The recent advancement in information systems and evolution of the blockchain technology has shifted the traditional drug supply chain approach in healthcare to secure automated systems. To enable a software platform to be used without a trusted third party, one of the possibilities is to use Hyperledger Fabric and smart contracts. One of the latest platforms is open-source Hyperledger Fabric, a modular system that uses conventional programming languages for smart contracts [12]. This opens up vast possibilities for using product-centric enterprise systems. In this paper, the main focus is the design and implementation of a secure drug delivery system based on blockchain using Hyperledger Fabric in a smart hospital. The system will show how blockchain using Hyperledger Fabric technology can be used to securely share and control drug delivery record information among different departments of the hospital. The following are the overview of the contributions being made: Initially, we developed a novel drug delivery blockchain platform in which electronic prescription along with drug dose, doctor, and patient information is stored and shared in a secured permissioned chain of network in an efficient way across different departments of the hospital. This blockchain platform is moving towards a new web-based model for a user-friendly interface using front-end programming languages such as JavaScript and HTML5 to enhance the usability of the management of assets and participants within the organization. Moreover, we used the Composer REST APIs to visualize the product-specific services. We also used smart contracts in order to provide the data consistency of the drug and other heath-related information. The access control policy was also defined to authenticate and authorize the request for the transactions in the proposed system. For cases of a large number of transactions and medical information, we present a new approach to incorporate and deploy Couch DB for each node to avoid data redundancy across the blockchain file system. Finally, we checked the hands-on experience of the system by applying a factual case study in a smart hospital based on Hyperledger Fabric.
The remaining paper is categorized into seven sections which are as follows: Section 2 explains the related work on drug delivery blockchain-based solutions and also gives a critical analysis on existing healthcare systems based on blockchain. Section 3 gives the detailed system methodology, design architecture, smart contract design, and overall transaction process of the proposed system. Section 4 elaborates on the implementations, smart contract modeling, and distributed ledger storage design of the proposed system. Section 5 presents the results of the proposed system. Section 6 enlightens the implications of the proposed work through benchmarking with current healthcare solutions, and Section 7 concludes the paper.

3. System Architecture of Drug Supply Chain Management

3.1. Scenario of Drug Supply Chain Management

Blockchain has revolutionized the healthcare industry by its unique decentralized distributed technology. The scenario of proposed drug supply chain management based on blockchain is shown in Figure 2. The graphical description represents the medical blockchain which manages and updates the complete supply chain, storing data related to drug, pharmacy, pharmacist, medical prescription, doctor, patient, nurse, and drug dose. The drug delivery data lakes act as a separate repository also called a stored-off blockchain. The data lake is a useful tool used for tasks such as analytics, visualization, and reporting of medical data. It would be beneficial not only for a hospital but also for other healthcare-related organizations that require medical data for their daily transactions. Furthermore, doctors can also view patient data with the patient’s permission and the patient can also share their data with any doctor within the network. These permissions can be set by defining the access control policy in the smart contract in order to maintain the privacy and integrity of patients’ data.
Figure 2. Scenario of drug delivery supply chain management in a medical blockchain.
The developed system contains reliable nodes which are responsible for executing a consensus protocol for the purpose of distributed ledger consistency. Initially, the doctor examines the patient and defines a therapy, drug dose, and other advice in the form of a computerized prescription. Then, the computerized prescription is sent to pharmacy personnel who analyze the authenticity of the prescription and request the pharmacist to prepare the drug cart. The pharmacist then sends the drug cart to the pharmacy personnel for cross-verification with the computerized prescription. The prepared drug cart along with the computerized prescription is sent to the head nurse, who verifies and updates the drug inventory of the ward and requests the nurse to start the patient therapy procedure. Finally, the nurse administers the therapy to the patient in accordance with the doctor prescription. The complete structure of the proposed drug supply chain management is shown in Figure 3.
Figure 3. Structure of the proposed drug supply chain management.

3.2. Proposed System Architecture of Drug Supply Chain Management

The primary concern for a blockchain network is to record information in a distributed manner. Each block comprises a number of transactions that are hashed and encrypted. The proposed blockchain-based structure of drug supply chain management is shown in Figure 4. The developed application is based on a user service framework that uses a smart contract and distributed ledger as middleware. In the proposed system, the transaction proposal is sent by the end user (i.e., doctor, nurse, pharmacist, and patient) through the application to call backend services like medical prescription, profile management, appointment, EDR (electronic drug record), data sharing, pharmacy management, etc., provided by the proposed blockchain network. The blockchain transaction has complete CRUD (create, read, update, and delete) operations that transform the ongoing data between the connected nodes. However, in cases of private and secure transactions, we introduce the subnetwork concept to distinguish the entire network into a separate private network. The main purpose of this private network is to share confidential data directly with the concerned department without exposing them to other departments. The proposed drug delivery system allows each department to create their own subnetworks for the purpose of secure data sharing.
Figure 4. System architecture of the proposed drug supply chain management.
The unique feature of the proposed system is that it is built on a permissioned network which differentiates it from other blockchain-based systems. This feature allows only the valid participant to participate and enroll in the blockchain network through a user identity manager. The user identity manager provides certificates for user enrollment and user authentication. Moreover, these services are related to user identity validations, verification, and signature generation for individual users who participate in the blockchain network. The consent manager represents the consensus that is responsible for connecting a department with a subnetwork through a provided interface and also controlling the transaction order. Each department in a drug delivery blockchain contains nodes and a distributed ledger. The node is capable of storing data and also contains a smart contract that is responsible for endorsing the transaction proposal or write transaction block to the ledger. The goal of the consensus algorithm is to ensure that only a single history of transactions exists, and the history does not contain invalid or contradictory transactions. The distributed ledger technology records the immutable and transparent transactions, logs, and histories of all the events and actions into the network. In order to keep the consistency of every ledger, a copy different cryptographic and consensus protocols have been employed, e.g., digital signatures and hashing.
The responsibility of a node in a network is to sustain the replica of a blockchain, and it is also responsible for processing the transaction. Figure 5 gives the inside view of a blockchain node. The node in blockchain comprises a smart contract, blocks, state database, and policies. The state database is used to represent and store the state of the ledger at a given point and time. The sample white box representation of a node indicates the relation between the state database and block.
Figure 5. White-box representation of a blockchain node in a drug delivery supply chain network.
Each ledger entry represents the states corresponding to the drug data. A drug has attributes like name, quantity, expiry-date, etc. that are stored with their values. The blockchain ledger contains a block where the first block is called a genesis block and others represent the transactions corresponding to drugs like ( T x 1 , d r u g 1 ), ( T x 2 , d r u g 2 ), ( T x 3 , d r u g 3 ), and ( T x n , d r u g n ) in the ledger state. The last part is the endorsement policy that decides which transaction is to be added to the ledger based on node agreement, i.e., AND (‘Dept1.member’, ‘Dept2.member’); both departments are required to accept the transaction, and OR (‘Dept1.member’, ‘Dept2.member’); one is required to accept the transaction.

3.3. Smart Contract of Drug Supply Chain Management

A smart contract adds functionality to blockchain, as it is a computer program that can execute transactions and access blockchain blocks and the history.
It is a computer program that is stored in the distributed database. A smart contract allows the addition of constraints, validations, and business logic to transactions. They could be considered similar to database triggers. A smart contract is not just a computer program, it is an agreement between parties. It contains parts for entering the contract, executing operations, and exiting. There are main challenges faced by blockchain developers while writing smart contracts. For instance, smart contracts are primarily implemented by relatively newer programming languages like Solidity, and therefore, the learning curve is very steep, and maintenance is hard. Furthermore, the performance of transaction execution is very limited because transactions are executed by all nodes in a sequence. In order to resolve these issues, we installed smart contracts only to define subsets of a node instead of all nodes, due to which, transactions are only executed on a specified set of nodes. This technique can improve the performance and execution scale of the proposed system and will also achieve higher parallelism and concurrency for the network. Moreover, we used different known programming languages like Java and Node.js to program the smart contract in order to provide ease to developers. The proposed system contains several functions that make it possible for the user to interact with the ledger. For example, the doctor can check the complete information related to drugs, such as the stock in inventory, and the patient can check his or her prescription; in other words, the user has complete access of CRUD operations and can query only those information which the user is authorized to access. Users can retrieve their information by acquiescing a transaction to the smart contract. The smart contract-based application takes the transaction and executes several kinds of queries and updates the ledger state by appending the transaction in blocks and returning the updated result to the application as a response. Figure 6 illustrates the ledger queries and updates using a smart contract in the proposed drug supply chain system.
Figure 6. Querying and updating a ledger using a smart contract.

3.4. Transaction Process of Drug Supply Chain Management

Transaction management is split between peers and orderers. This allows higher parallelism and concurrency for the network. Every transaction is executed in the peer using the world state. If the transaction succeeds, it is signed with a Peers certificate. Executing transactions prior to ordering allows each node to process multiple transactions at the same time. The orderer will not re-execute the transaction: They will just order them and will not maintain the ledger. This also enables the peers to trust all orderers and vice versa, so they can run independently. Figure 7 shows the overall transaction process and role of every individual component of the network inside the proposed blockchain-based drug supply chain management. The user manager issued the credentials to client application in order to authorize for sending transaction proposals. The transaction process starts when the client application sends a transaction proposal to nodes, due to which the communication starts over the client SDK. The nodes which participates in the network can be either committers or endorsers. The responsibility of an endorser node is to sign and authorize the proposal for transactions, while the committer node validates the results in responses to the transaction and writes a transaction block to the ledger. The endorser node also acts as a committing node and is used for receiving and executing a proposal for the transaction by invoking a smart contract without updating the ledger. The endorser node collects and reads the RW (read–write) sets from the present world state during the transaction. The endorser node then signs these RW sets and returns the response to the client application for further processing. The client application then compiles the signed transaction in the form of a package and submits it to the consensus manager along with the RW sets.The consensus occurs in parallel throughout the transaction process with the RW sets and signed transaction and then is sent to committer nodes in the form of blocks. After that, each transaction is validated by comparing its RW set with the present world state. The validated transaction is then written into the ledger, and the endorser will also update the current world state from the RW sets. Finally, the committing node generates an asynchronous alert for the submitted transaction on whether it is successful or not. The committer node also gets notified for every event by registering events through the client application.
Figure 7. Transaction flow in the proposed drug supply chain management in a medical blockchain platform.

4. Implementation for Drug Supply Chain Management in a Medical Blockchain Platform

4.1. Development Environment

The development environment of the proposed case study is categorized into two parts, as illustrated in Figure 4. The front-end and back-end were developed in separate environments. The back-end implementation for drug supply chain management in a docker environment is described in Table 1. All the implementation and experimental work of this study was carried out on Ubuntu Linux 18.04 LTS with an Intel Core i5-8500 @ 3.00GHz processor and 8 GB memory. Moreover, for the docker running environment, we used a Docker engine (version 18.06.1-ce), and for the configuration of the container and the docker image and in the virtual machine, we used docker-compose (version 1.13.0). We used an open-source framework Hyperledger Fabric (v1.2) project hosted by Linux Foundation. Python (v2.7.15) and Node (v8.11.4) are a prerequisite of a Fabric network to develop client SDK. We used a Composer web-playground to design and develop the business network definition, and for deployment, we used a Composer CLI tool for the proposed blockchain platform. We used a Composer REST server to create the REST-API for the participant, assets, queries, and transactions to visualize the back-end business logic to the graphical user interface (GUI). The tool and technologies for GUI implementation for the drug supply chain management are mentioned in Table 2. The web application for the front-end was developed using HTML5, CSS3, and for dynamic programming, we used Java-script. In order to make the web application more efficient and user-friendly, we used third-party toolkits like jQuery and Bootstrap. The back-end and front-end interact with each other using a REST API server. The client performs some action on the web application that will trigger the HTTP method like POST, GET, PUT, and DELETE, which in response perform according to the client HTTP request.
Table 1. Development environment for the proposed drug supply chain management in a medical blockchain platform.
Table 2. Front-end development environment for the proposed drug supply chain management.

4.2. Network Topology for Drug Supply Chain Management in a Medical Blockchain Platform

The network topology for the drug supply chain management in a medical blockchain platform is presented in Figure 8. The key design features woven in Hyperledger Fabric were used to design and develop the proposed system architecture as illustrated in Figure 4. The fundamental element of the blockchain network is the peer that is responsible for hosting a ledger and smart contract to perform basic operations on the ledger (e.g., READ, WRITE). Hyperledger Fabric also supports creating multiple blockchains called channels. A channel is a secure blockchain which is used to provide confidentiality and data isolation. The ordering service is the nodes which are responsible for ordering the transaction into a block.
Figure 8. Network topology for drug supply chain management based on Hyperledger Fabric in a medical blockchain platform.
In this section, we explained the network topology of the proposed system in reference to channels, peers, and ordering services. The network topology for the proposed system is categorized into three departments, i.e., Cardiology as D 1 , Neurosurgery as D 2 , and Medicine as D 3 . These three departments are grouped into one channel, which is represented as C 1 . Moreover, these three departments together are involved in an agreement to make a network policy for setting up and initializing a blockchain network. The private communication between departments D 1 , D 2 , and D 3 is carried out in a C 1 . The C 1 is administrated according to the rules described in the channel policy ( C P 1 ) created by D 1 , D 1 , and D 3 . The smart contract ( S C 1 ) and Ledger( L 1 ) are hosted on Peers (i.e., P 1 , P 2 , and P 3 ). The role of the ordering service is to create channels and allow other nodes to participate in a specific channel. Client applications ( A 1 , A 2 , and A 3 ) connect with other network entities with the help of C 1 . Each department is linked with a certificate authority ( C A ), e.g., A 1 belongs to D 1 issued by C A 1 , A 2 belongs to D 2 issued by C A 2 , A 3 belongs to D 3 issued by C A 3 , etc. Every department member and user is issued with a public key infrastructure ( P K I )-based certificate by C A .

4.3. Building Component of the Business Network

In Hyperledger Fabric, there are three main components for building a business network, i.e., participants, assets, and transaction. The proposed business network is shown in Figure 9.
Figure 9. Hyperledger Fabric-based business network for the proposed system.
The participants in the proposed network are the doctor, patient, nurse, and pharmacist. The assets include the drug, prescription, order, and repository. Lastly, the transaction contains u p d a t e P r e s c r i p t i o n T i m e , u p d a t e D r u g D o s e , u p d a t e D o c t o r C o m m e n t , s h a r e D r u g R e c o r d W i t h D o c t o r , u p d a t e D r u g D e t a i l s , U p d a t e D r u g o r d e r S t a t u s , and S h a r e R e p o s i t o r y R e c o r d w i t h N u r s e . Initially, the doctor examines the patient and defines a therapy, drug dose, and other advice in the form of a computerized prescription. Then, the computerized prescription is sent to the pharmacy personnel, who analyze the authenticity of the prescription and request the pharmacist to prepare the drug cart. The pharmacist then sends the drug cart to the pharmacy personnel for cross-verification with the computerized prescription. The prepared drug cart along with the computerized prescription are sent to the head nurse, who verifies and updates the drug inventory of the ward and requests the nurse to start the patient therapy procedure. Finally, therapy is administered to the patient in accordance with the doctor’s prescription.

4.4. Smart Contract Modeling of Drug Supply Chain Management in a Medical Blockchain Platform

Hyperledger Composer [50] is an open-source framework and toolkit for developing blockchain applications. It is used to design and implement a smart contract in blockchain application. The smart contract in Hyperledger comprises four components, i.e., model, query definition, script, and access control rules. In blockchain technology, the business network is run by the participants, and every participant owns a number of assets and can submit transactions. However, in the proposed blockchain platform, the participants are doctors, pharmacists, nurses, and patients. Every participant is modeled as an identifier and has some properties. Similarly, assets are also represented like participants, and assets can be anything, like services, goods, property etc. The summarized drug supply chain management definition in a medical blockchain is mentioned in Table 3, containing information related to drug, medical history, and personal information.
Table 3. Drug supply chain management definition in a medical blockchain.
Transactions are also defined during smart contract modeling, which aims to interact with assets, similarly to transactions, participants, and events, which are also defined and can also interact with the entities involved in multiple blockchain networks. Once the events are defined, they also become a part of transaction processor functions and process in a similar way as transactions will be processed. Table 4 presents the definition of transactions and events used in the proposed blockchain.
Table 4. Transaction and event definition of the proposed drug supply chain management in a medical blockchain.
In Figure 10, the script file contains a transaction process function which is triggered. It contains functions like CREATE, DELETE, UPDATE, etc. to modify the values of assets and participants in the blockchain network. Transaction processor functions are written in JavaScript and confined in an isolated file as a portion of a smart contract definition. The ShareRecord function updates the drug record asset in the registry and then triggers an event.
Figure 10. Transaction processor function in the proposed drug supply chain management in a medical blockchain platform.
The access control language (ACL) provides declarative access control over the elements of the domain model. By defining ACL rules, we can determine which users/roles are permitted to create, read, update or delete elements in a business network’s domain model. Figure 11 illustrates the ACL rules in which all participants access all operations and commands in the business network, including network access and business access.
Figure 11. Access control definition in the proposed drug supply chain management in a medical blockchain platform.
In Hyperledger Composer, queries are also defined in a separate file and written in a bespoke query language. Queries are used to retrieve data from a world state. The query is divided into two parts, i.e., statement and a description. In the description, we describe the function of the query, which is composed of a string, and in the statement, we use statement operators like, e.g., SELECT, FROM, WHERE, AND, OR, CONTAINS, and ORDER BY for defining specific rules in a query. Figure 12 describes the queries used in drug supply chain management in a medical blockchain.
Figure 12. Queries definition in the proposed drug supply chain management in a medical blockchain platform.
Figure 13 represents the REST APIs generated by the Composer REST server for interaction between the client end and back-end. The Composer REST server API comprises three parts i.e., resource, verb, and action. The resource contains the request path, and the verb signifies the action performed on a particular resource, e.g., POST, GET, PUT, and DELETE. The list of resources that are used in the proposed solution is presented in Figure 13.
Figure 13. Hyperledger Fabric-based business network for the proposed system.

4.5. Distributed Ledger Storage Structure of Drug Supply Chain Management in a Medical Blockchain Platform

The ledger technology in Hyperledger Fabric comprises two distinct parts, i.e., a world state and a blockchain. The world state database is capable of storing cache of the current value of the set of the ledger state. The world state by default stores the current value of ledger state; because of this, developers can easily access the current state without traversing the entire transaction log. The data in the world state are stored in a key–value pair. The world state is so flexible that each time a state is changed, it automatically updates the state value, e.g., ownership of some assets or transfer of record to others. There are two appropriate choices of state database that are selected based on the format of the data. The default state database used is LevelDB, which is used to store smart contract data in a key–value pair. The default database is located within the node of a network and embedded within the same process of the operating system. The second one is CouchDB, which is used to format smart contract data in a JSON document. CouchDB is an optional alternate state database that supports rich queries when chaincode data values are modeled as JSON. Rich queries are more flexible and efficient against large indexed data stores, when you want to query the actual data value content rather than the keys. CouchDB is a JSON document datastore rather than a pure key-value store therefore enabling indexing of the contents of the documents in the database. In CouchDB, content-based JSON data can be retrieved from queries. CouchDB supports all types of requests through which data can be accessed through REST APIs. Figure 14 represents the record of the drug assets as a ledger state. D r u g 1 is stored in CouchDB and has a key–value pair. CouchDB stores both single key–value pairs and multiple key–value pairs as a simple and complex state. If you have a mix of JSON and binary data values, you can still use CouchDB; however, the binary values can only be queried based on key, key range, and composite key queries.
Figure 14. Distributed ledger of the proposed drug supply chain management in a medical blockchain platform.
Similarly, in the case of blockchain, the records are always stored as a file. As the blockchain is only capable of storing small sets of operations, blockchain records all the changes occurring in the world state as a transaction log. These transactions are then composed as an encrypted block that is cryptographically linked to form a chain-like structure. This chain structure is used to store transactions on the ledger in a sequence, ordered by time. The main advantage of blockchain is data immutability: Once written, the stored data cannot be changed or deleted even by administrator.

5. Execution Results

This section illustrates the execution of the proposed system and provides some snapshots illustrating the process of execution. Table 1 and Table 2 show the implementation environment of both the front-end and the back-end of the proposed system, which were investigated and discussed in an earlier section. Similarly, Figure 13 shows the detailed API request and response of different modules of the proposed system with the Hyperledger Composer REST server. Firstly, the network authorizes the user by validating the user ID, then the request will be initiated by the client to the REST server in order to submit the transaction to the proposed blockchain platform. In order to perform the transactions, the smart contract functions are triggered by the blockchain platform, which returns a response to the client after successful execution of a transaction.
Figure 15 shows the doctor dashboard showing a web form to allow the doctor to add their profile. The entered data have been validated, and if the form field is not filled out or contains an invalid value, an exception is thrown, and as a result, the form does not proceed further. Data validation is crucial in any system design, since if the parameters are given wrong values, this will have a drastic effect on the overall results of the system, and there will be endless anomalies in the overall flow of the system. The proposed doctor dashboard user interface allows the users to perform CRUD on a selected doctor.
Figure 15. Doctor management dashboard.
Similarly, in Figure 16, the user can update the existing doctor information by sending a request to the blockchain platform, and on successful response, the doctor information will be repopulated on the user interface. Doctor attributes like username, specialization, firstname, lastname, and department will be updated on successful response from the Hyperledger Composer REST server.
Figure 16. Update doctor record.
In Figure 17, the doctor record can also be verified by providing D o c t o r I d as a parameter to doctor API in the Hyperledger Composer REST server. The query request is sent to rhe blockchain platform and on successful response, it will generate r e s p o n s e c o d e as 200, r e s p o n s e b o d y which contain the meta-data (i.e., department, specialization, firstname, lastname, username, and email address) of the specific doctor against the requested id, and r e q u e s t e d U R L on which the request was sent. The response of request can be viewed as a json format on the Hyperledger Composer REST server. The request URL contains the address of the API along with the port on which it is running.
Figure 17. Fetching doctor record through the Composer REST server.
Figure 18 illustrates the details of an individual drug along with the patient and doctor. The drug management dashboard allows the user to add information of a specific drug. The entered drug data have been validated, and if the form field is not filled out or contains an invalid value, an exception is thrown, and as a result, the form does not proceed further. The proposed drug management interface allows the user to perform CRUD on a selected drug by specifying DrugId. Moreover, drug management also keeps the record of individuals’ prescribed medicine by the corresponding doctor. Additionally, drug description, expiry date, manufacture date, and manufacturer are also stored to describe the overall behavior of the drug.
Figure 18. Drug management dashboard.
Similarly, in Figure 19, the user can update the existing drug information by sending a request to the blockchain platform, and on successful response, the drug information will be repopulated on the user interface. Drug attributes like drugname, price, description, makers, expiryDate, manufacturerDate, and unitofMeasure will be updated on successful response from the Hyperledger Composer REST server.
Figure 19. Update drug record.
The authenticity of a record can also be verified by querying directly on the Hyperledger Composer REST server. In Figure 20, the query request “ / a p i / q u e r i e s / s e l e c t D r u g R e c o r d B y N a m e ? d r u g n a m e = T r a m a d o l ” is initiated by the client to the REST server in order to submit the transaction. The Hyperledger Composer REST server responds to the query request in the form of a R e s p o n s e B o d y , which contains the meta-data related to the drug. The response of the request can be viewed in a json format on the Hyperledger Composer REST server. The request URL contains address of the API along with the port on which it is running.
Figure 20. Fetching drug record through the Composer REST server.
Figure 21 demonstrates the prescription dashboard in which details of an individual prescription are recorded. The prescription holds the record of a patient with the assigned doctor and the number of drugs prescribed by the doctor along with doctor notes, all stored in prescription management. The prescription management dashboard allows the doctor to add the information of a specific patient during patient examination.The entered data have been validated, and if the form field is not filled out or contains an invalid value, an exception is thrown, and as a result, the form does not proceed further. The proposed prescription management interface allows the doctor to perform CRUD on a selected prescription by specifying PrescriptionID. Moreover, the doctor can also update the drug dose and doctor notes of a specific patient. Additionally, prescription management also keeps track of individual drugs which are prescribed by the doctor in prescription.
Figure 21. Prescription management dashboard.
Similarly, in Figure 22, the user can update the existing prescription information by sending a request to the blockchain platform, and on successful response, the prescription information will be repopulated on the user interface. Prescription attributes like prescriptionID, PrescriptionTime, doctor, drugdose, and DoctorComment will be updated on successful response from the Hyperledger Composer REST server.
Figure 22. Update prescription record.
The record authenticity of a prescription can also be verified by querying directly on the Hyperledger Composer REST server. In Figure 23, the query request “ / a p i / P r e s c r i p t i o n / P r e s c r i p t i o n 3 ” is initiated by the client to the REST server in order to submit the transaction. The Hyperledger Composer REST server responds to the query request in the form of a R e s p o n s e B o d y , which contains the meta-data related to the prescription. The response of the request can be viewed in a json format on the Hyperledger Composer REST server. The request URL contains the address of the API along with the port on which it is running.
Figure 23. Fetching the prescription record through the Composer REST server.
Figure 24 shows the snapshot related to transaction history. The transaction history represents the complete log of activities performed through the web to blockchain platform. The log contains attributes like timestamp, which represents the time of transaction and is unalterable, type, which represents the type of transaction performed, and participant, which is the user of the system who performed that specific transaction.
Figure 24. Transaction history.
Figure 25 represents the details of a specific transaction in which transactionID, TransactionType, TransactionInvoked, ParticipantInvoking, IdentityUsed, and transactionTimeStamp are mentioned. Every single activity performed in the system can be verified from the history dashboard.
Figure 25. Detailed view of transaction history.

6. Performance Evaluation

We used Hyperledger Caliper as an open-source performance benchmark framework for a blockchain-based solution [51]. The Hyperledger Caliper project is an initiative of Linux Foundation and is used for benchmarking blockchain solutions. Hyperledger Caliper currently supports many blockchain solutions like Fabric v1.0, Sawtooth 1.0, Iroha 1.0, Burrow 1.0, and also Hyperledger Composer. The Hyperledger Caliper benchmarking tool supports many performance indicators like success rate, transaction throughput, and transaction latency (minimum, average, maximum, and percentile). It also indicates the resource allocation of the proposed system (e.g., CPU, Memory, IO). The performance benchmark tool environmental setup is represented in Table 5. We calculated the results against the following metric. A brief description of each metric is given below.
Table 5. Hyperledger Caliper environmental setup.
  • Transaction Response Time: It is the time in which a success is measured by the amount of time a transaction takes to request and get response from a blockchain platform.
  • Transaction Throughput: The rate at which a success is measured by valid transactions which are committed by the blockchain system under testing (SUT) in a defined time period.
  • Transaction Latency (Min, Max, Average): Time taken for a transaction effect to be used across the network is referred to as transaction latency. The total time includes the time from the point of submission to the available result in the network.
  • Resource Utilization: It is a process to utilize resources while processing transaction request and response. Resource utilization can be measured by checking the utilized resources by CPU, Memory, Network, and IO by the blockchain SUT in a defined time period.

Simulation Results

Figure 26 provides a comparison between three different user groups in order to investigate the response time of the proposed system. We ran the simulation for a time period of 100 ms. In general, the response time increases as the number of users increase querying the system at a same time. The three categories of user groups are 100 users at first round, 300 users at second round, and in the end, we evaluated the performance by increasing users to 500. Figure 26 illustrates the response of the system for the first two groups that are almost the same but when we increase the number of users to 500; the response time increases only 15 ms for the first 500 transactions. Although the number of user increases, the response time of the system remains stable.
Figure 26. Response time for different simultaneous requests.
Figure 27 investigates the transaction per second (TPS). Similarly to Figure 26, we also used the same number of user groups in order to evaluate the TPS of the proposed system. In general, if we have one user sending a request to the server, it responds after 100 ms, and the TPS is calculated as Number of user = 1000 ms/100 ms, which is 1 × 1000 ms/100 ms = 10 TPS. As illustrated in Figure 27, the user-group with 100 users has an average of 40 tps for an elapsed time of 100 s. However, if we increase the number of users, the tps also increases. In the case of a group with 300 users, the average tps is 70, and with 500 users. the average tps is 115 with an elapsed time of 100 s.
Figure 27. Transaction per second at different simultaneous request.
Figure 28 and Figure 29 describe the average, min, max, and percentile latency to execute the invoke process and query function of the proposed system. We calculated the latency of the proposed blockchain system by querying the transaction with three different user-groups. As illustrated in Figure, the user-group with 100 users has an average latency of 154 ms. Similarly, in the case of a group with 300 users, the average latency is 172, and with 500 users, the average latency is 436. In general, if the number of users increases, the latency of the system also increases. In the case of 90% percentile latency, it can be clearly seen that if we increased the user number from 90% to 95%, the latency of the system also increased by 5 ms, and the same applies for the 95% and 99% line. The minimum latency of a group with 100 users is 108 ms, for 300 users, it is 107 ms, and for 500 users, it is 127 ms. Likewise, for a group with 100, 300, and 500 users, the maximum latency is 228 ms, 443 ms, and 1147 ms, respectively.
Figure 28. Latency in query transaction (Get Request).
Figure 29. Latency in invoking transaction (Post Request).
Figure 29 demonstrates the case of invoking transaction latency is higher than querying transactions because invoking transaction requires peers to perform endorsement, which requires additional time. The user-group with 100 users has an average latency of 1519 ms. Similarly, in the case of a group with 300 users, the average latency is 1472, and with 500 users, the average latency is 1393. In the case of 90% percentile latency, we clearly see that if we increase the user number from 90% to 95%, the latency of the system is also increased by 199 ms, and the same is also the case with the 95% and 99% line. The minimum latency of a group with 100 users is 243 ms, for 300 users, it is 293 ms, and for 500 users, it is 344 ms. Likewise, for a group with 100, 300, and 500 users, the maximum latency is 2540 ms, 2964 ms, and 2471 ms, respectively.
The resource utilization of the proposed system is present in Table 6 in terms of CPU (max), CPU (avg), Memory (max), Memory (min), Traffic In, and Traffic Out, carried out in 10 iterations by the proposed system. As we see in the table, the local client consumes an average CPU of 8.76% and maximum of 14.64%, which is the normal usage of CPU by any process. If we investigate memory allocation of the proposed system for local-client maximum memory, the utilization is 105.2 MB, and average memory utilization is around 90.5 MB. Moreover, if we see the average resource utilization of all peer nodes in terms of CPU and memory, then the average CPU consumption of all peer nodes is approximately 6.68%, and the average maximum CUP consumption is 11.83%. In terms of memory allocation, the average maximum memory allocation of peer nodes is 107.69 MB, and the average is 99.91 MB. If we analyze the orderer node, then the maximum CPU utilization is 14.95%, and average CPU utilization is 6.75%. In terms of memory, the maximum memory allocation of the orderer node is 93.6 MB, and the average memory allocation is 88.7 MB. In the case of the ca_node, the average and average maximum CPU utilization is 0%; however, average memory and average maximum memory allocation is 3.66%. The resource utilization of CPU and memory is neither too high nor too low in the designed platform; therefore, if user requests exceed, this will not effect the SUT, although if the CPU utilization is more than 30%, then we consider system performance as low or poor.
Table 6. Resource utilization analysis of the proposed system.

7. Conclusions

Blockchain has shown its capability to transform the traditional supply chain industry into a secure, automated, anonymous, persistent, audible, and decentralized supply chain. In this paper, we described the design, implementation, and performance evaluation of the proposed drug supply chain integrity management in a smart hospital based on Hyperledger Fabric. The proposed system is a proof-of-concept application that keeps track of individual drug records using blockchain technology in a decentralized way. It enables doctors, nurses, patients, and pharmacists to manage, access, and share personal medical records and also a complete individual drug life cycle in a secure and accountable way through comprehensive logs. In order to achieve the transparency, security, and privacy of the proposed system, we used a smart contract developed in the solidity programming language in combination with permissioned blockchain architecture (i.e., Hyperledger Fabric). Furthermore, we also designed a web application which interacts with the blockchain platform to expose the services to the front-end. A number of experiments were carried out in order to test the performance analysis of the proposed system in terms of transaction response time, throughput, latency, and recourse utilization. Our results indicated that using blockchain technology increases the performance in terms of throughput and also minimizes latency of the proposed system with less utilization of resources. The potential future direction could be to increase the network size and then to check the performance and feasibility by deploying the system in a real environment.

Author Contributions

Data curation, F.J.; Formal analysis, F.J.; Funding acquisition, D.K.; Investigation, F.J.; Methodology, D.K.; Software, L.H.; Supervision, D.K.; Validation, K.K; Visualization, L.H.; Writing—original draft, F.J.; Writing—review & editing, K.K. and D.K.

Funding

This work was supported by Electronics and Telecommunications Research Institute (ETRI) grant funded by the Korean government. [19ZD1100, Development of ICT Convergence Technology for Daegu-GyeongBuk Regional Industry], and this research was supported by the MSIT (Ministry of Science and ICT), Korea, under the ITRC (Information Technology Research Center) support program (IITP-2017-2016-0-00313) supervised by the IITP (Institute for Information & communications Technology Promotion).

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. Daniela Bagozzi, C.L. 1 in 10 Medical Products in Developing Countries Is Substandard or Falsified. 2017. Available online: https://www.who.int/news-room/detail/28-11-2017-1-in-10-medical-products-in-developing-countries-is-substandard-or-falsified (accessed on 12 March 2019).
  2. The Guardian. 10% of Drugs in Poor Countries Are Fake, Says WHO. 2017. Available online: https://www.theguardian.com/global-development/2017/nov/28/10-of-drugs-in-poor-countries-are-fake-says-who (accessed on 12 March 2019).
  3. Akunyili, D. Fake and counterfeit drugs in the health sector: The role of medical doctors. Ann. Ib. Postgrad. Med. 2004, 2, 19–23. [Google Scholar] [CrossRef]
  4. Funding, H.R. 20 Shocking Counterfeit Drugs Statistics. 2017. Available online: https://healthresearchfunding.org/20-shocking-counterfeit-drugs-statistics/ (accessed on 13 March 2019).
  5. Blackstone, E.A.; Fuhr, J.P., Jr.; Pociask, S. The health and economic effects of counterfeit drugs. Am. Health Drug Benefits 2014, 7, 216–224. [Google Scholar] [PubMed]
  6. Metcalf, D. Blockchain in Healthcare: Innovations that Empower Patients, Connect Professionals and Improve Care; Taylor & Francis: Abingdon, UK, 2019. [Google Scholar]
  7. Stanway-Williams, C. How Blockchain Could Eliminate Counterfeit Medicine: Blockchain Technology Can Be Utilized to Ensure Transparency from Start to Finish in the Pharmaceutical Supply Chain. 2018. Available online: https://channels.theinnovationenterprise.com/articles/how-blockchain-could-eliminate-counterfeit-medicine (accessed on 13 March 2019).
  8. Technology, P. Blockchain in Pharma: Opportunities in the Supply Chain. 2017. Available online: https://www.pharmaceutical-technology.com/digital-disruption/blockchain/blockchain-pharma-opportunities-supply-chain/ (accessed on 14 March 2019).
  9. Ram, P. Real World Use Cases of Blockchain in Pharma and Healthcare. 2017. Available online: https://hackernoon.com/top-5-use-cases-of-blockchain-in-pharma-and-healthcare-that-you-should-know-about-77ccdd76369b (accessed on 14 March 2019).
  10. Swan, M. Blockchain: Blueprint for a New Economy; O’Reilly Media, Inc.: Sebastopol, CA, USA, 2015. [Google Scholar]
  11. Pilkington, M. 11 Blockchain technology: Principles and applications. In Research Handbook on Digital Transformations; Edward Elgar Publishing: London, UK, 2016; Volume 225. [Google Scholar]
  12. Cachin, C. Architecture of the hyperledger blockchain fabric. In Proceedings of the Workshop on Distributed Cryptocurrencies and Consensus Ledgers, Chicago, IL, USA, 25 July 2016; Volume 310. [Google Scholar]
  13. Ekblaw, A.; Azaria, A.; Halamka, J.D.; Lippman, A. A Case Study for Blockchain in Healthcare: “MedRec” prototype for electronic health records and medical research data. In Proceedings of the IEEE Open & Big Data Conference, Vienna, Austria, 22–24 August 2016; Volume 13, p. 13. [Google Scholar]
  14. Azaria, A.; Ekblaw, A.; Vieira, T.; Lippman, A. Medrec: Using blockchain for medical data access and permission management. In Proceedings of the 2016 2nd International Conference on Open and Big Data (OBD), Vienna, Austria, 22–24 August 2016; pp. 25–30. [Google Scholar]
  15. Medicalchain. Medicalchain, Medicalchain Whitepaper 2.1. Tech. Rep. Medicalchain. 2018. Available online: https://medicalchain.com/Medicalchain-Whitepaper-EN.pdf (accessed on 14 March 2019).
  16. Medicalchain. MeFy, MeFy Whitepaper. 2018. Available online: https://icosbull.com/whitepapers/3576/MeFy_whitepaper.pdf (accessed on 15 March 2019).
  17. MedicoHealth. MedicoHealth, MedicoHealth Whitepaper. 2018. Available online: https://medicohealth.io/supporters/documents/wp_beta.pdf (accessed on 15 March 2019).
  18. MediBloc. MediBloc, MediBloc Technical Whitepaper. 2018. Available online: https://github.com/medibloc/whitepaper/blob/master/old_whitepaper/medibloc_whitepaper_en.pdf (accessed on 15 March 2019).
  19. Hulseapple, C. Block Verify Uses Blockchains to End Counterfeiting and ‘Make World More Honest’. 2015. Available online: https://cointelegraph.com/news/block-verify-uses-blockchains-to-end-counterfeiting-and-make-world-more-honest (accessed on 15 March 2019).
  20. Tseng, J.H.; Liao, Y.C.; Chong, B.; Liao, S.W. Governance on the drug supply chain via gcoin blockchain. Int. J. Environ. Res. Public Health 2018, 15, 1055. [Google Scholar] [CrossRef] [PubMed]
  21. Farmatrust. Fake Drugs: Real Problem. 2017. Available online: https://www.farmatrust.com/news/fake-drugs-real-problem/ (accessed on 17 March 2019).
  22. Li, P.; Nelson, S.D.; Malin, B.A.; Chen, Y. DMMS: A Decentralized Blockchain Ledger for the Management of Medication Histories. Blockchain Healthc. Today 2019, 2. [Google Scholar] [CrossRef]
  23. Yue, X.; Wang, H.; Jin, D.; Li, M.; Jiang, W. Healthcare data gateways: Found healthcare intelligence on blockchain with novel privacy risk control. J. Med Syst. 2016, 40, 218. [Google Scholar] [CrossRef] [PubMed]
  24. Dalianis, H.; Henriksson, A.; Kvist, M.; Velupillai, S.; Weegar, R. HEALTH BANK-A Workbench for Data Science Applications in Healthcare. In Proceedings of the CAiSE’15, 27th International Conference on Advanced Information Systems Engineering, Stockholm, Sweden, 8–12 June 2015; pp. 1–18. Available online: http://ceur-ws.org/Vol-1381/paper1.pdf (accessed on 20 March 2019).
  25. Arsene, C. Hyperledger Project Explores Fighting Counterfeit Drugs with Blockchain. 2019. Available online: https://healthcareweekly.com/blockchain-in-healthcare-guide/ (accessed on 20 March 2019).
  26. Mettler, M. Blockchain technology in healthcare: The revolution starts here. In Proceedings of the 2016 IEEE 18th International Conference on e-Health Networking, Applications and Services (Healthcom), Munich, Germany, 14–16 September 2016; pp. 1–3. [Google Scholar]
  27. Brennan, B. Gem Health Developing Blockchain Solutions for the Healthcare Ecosystem. 2018. Available online: https://blockchainhealthcarereview.com/gem-health-developing-blockchain-solutions-for-the-healthcare-ecosystem/ (accessed on 20 March 2019).
  28. Buntinx, J. ‘Blockchain Technology Has A Bright Future in Healthcare’, Tierion. 2016. Available online: https://btcmanager.com/blockchain-technology-has-a-bright-future-in-healthcare-tierion/?q=/blockchain-technology-has-a-bright-future-in-healthcare-tierion/& (accessed on 20 March 2019).
  29. Bocek, T.; Rodrigues, B.B.; Strasser, T.; Stiller, B. Blockchains everywhere-a use-case of blockchains in the pharma supply-chain. In Proceedings of the 2017 IFIP/IEEE Symposium on Integrated Network and Service Management (IM), Lisbon, Portugal, 8–12 May 2017; pp. 772–777. [Google Scholar]
  30. Allison, I. Skuchain: Here’s How Blockchain Will Save Global Trade a Trillion Dollars. Available online: https://www.ibtimes.co.uk/skuchain-heres-how-blockchain-will-save-global-trade-trillion-dollars-1540618 (accessed on 18 March 2019).
  31. Abeyratne, S.; Monfared, R. Blockchain Ready Manufacturing Supply Chain Using Distributed Ledger. Int. J. Res. Eng. Technol. 2016, 5, 1–10. [Google Scholar]
  32. De Filippi, P. Blockchain-based Crowdfunding: What Impact on Artistic Production and Art Consumption? Available online: https://www.archives-ouvertes.fr/hal-01265211/document (accessed on 12 March 2019).
  33. Schlegel, M.; Zavolokina, L.; Schwabe, G. Blockchain Technologies from the Consumers’ Perspective: What Is There and Why Should Who Care? In Proceedings of the 51st Hawaii International Conference on System Sciences, Hilton Waikoloa Village, HI, USA, 3–6 January 2018. [Google Scholar]
  34. Spielman, A. Blockchain: Digitally Rebuilding the Real Estate Industry. Ph.D. Thesis, Massachusetts Institute of Technology, Cambridge, MA, USA, 2016. [Google Scholar]
  35. YouTeam Editorial Team. 14 Blockchain Startups in Real Estate to Watch. 2018. Available online: https://youteam.co.uk/blog/14-blockchain-startups-in-real-estate-to-watch/ (accessed on 25 March 2019).
  36. Peck, M.E.; Wagman, D. Energy trading for fun and profit buy your neighbor’s rooftop solar power or sell your own-it’ll all be on a blockchain. IEEE Spectr. 2017, 54, 56–61. [Google Scholar] [CrossRef]
  37. Ojo, A.; Adebayo, S. Blockchain as a next generation government information infrastructure: A review of initiatives in D5 countries. In Government 3.0–Next Generation Government Technology Infrastructure and Services; Springer: Berlin/Heidelberg, Germany, 2017; pp. 283–298. [Google Scholar]
  38. Fletcher, K. Circle Brings Social Payments App to UK. 2016. Available online: https://coinreport.net/circle-brings-social-payments-app-uk/ (accessed on 20 March 2019).
  39. D’Cunha, S.D. Dubai Sets Its Sights on Becoming The World’s First Blockchain-Powered Government. 2017. Available online: https://www.forbes.com/sites/suparnadutt/2017/12/18/dubai-sets-sights-onbecoming-the-worlds-first-blockchain-powered-government/#17ad2c4454ba (accessed on 20 March 2019).
  40. Jacomet, N. Democracy Earth, the Promise of a Safe and Independent Online Voting System. 2017. Available online: https://medium.com/open-source-politics/democracy-earth-the-promise-of-a-safe-independant-online-voting-system-37366935db5e (accessed on 20 March 2019).
  41. Osgood, R. The Future of Democracy: Blockchain Voting. Available online: http://www.cs.tufts.edu/comp/116/archive/fall2016/rosgood.pdf (accessed on 23 March 2019).
  42. Jayasinghe, D.; Cobourne, S.; Markantonakis, K.; Akram, R.N.; Mayes, K. Philanthropy on the Blockchain. In Proceedings of the IFIP International Conference on Information Security Theory and Practice, Heraklion, Greece, 28–29 September 2017; Springer: Berlin/Heidelberg, Germany, 2017; pp. 25–38. [Google Scholar]
  43. Zheng, Z.; Xie, S.; Dai, H.; Chen, X.; Wang, H. An overview of blockchain technology: Architecture, consensus, and future trends. In Proceedings of the 2017 IEEE International Congress on Big Data (BigData Congress), Honolulu, HI, USA, 25–30 June 2017; pp. 557–564. [Google Scholar]
  44. Yuan, Y.; Wang, F.Y. Towards blockchain-based intelligent transportation systems. In Proceedings of the 2016 IEEE 19th International Conference on Intelligent Transportation Systems (ITSC), Rio de Janeiro, Brazil, 1–4 November 2016; pp. 2663–2668. [Google Scholar]
  45. Hess, Z.; Malahov, Y.; Pettersson, J. Æternity Blockchain. 2017. Available online: https://www.aeternity.com/aeternity-blockchain-whitepaper.pdf (accessed on 23 March 2019).
  46. Cohn, J.M.; Finn, P.G.; Nair, S.P.; Panikkar, S.B.; Pureswaran, V.S. Autonomous Decentralized Peer-to-Peer Telemetry. U.S. Patent App. 15/138,619, 26 October 2017. [Google Scholar]
  47. Peterson, J.; Krug, J. Augur: A decentralized, open-source platform for prediction markets. arXiv 2015, arXiv:1501.01042. [Google Scholar]
  48. Singh, S.; Singh, N. Blockchain: Future of financial and cyber security. In Proceedings of the 2016 2nd International Conference on Contemporary Computing and Informatics (IC3I), Noida, India, 14–17 December 2016; pp. 463–467. [Google Scholar]
  49. Guo, Y.; Liang, C. Blockchain application and outlook in the banking industry. Financ. Innov. 2016, 2, 24. [Google Scholar] [CrossRef]
  50. Dhillon, V.; Metcalf, D.; Hooper, M. The hyperledger project. In Blockchain Enabled Applications; Springer: Berlin/Heidelberg, Germany, 2017; pp. 139–149. [Google Scholar]
  51. Sukhwani, H. Performance Modeling & Analysis of Hyperledger Fabric (Permissioned Blockchain Network); Duke University: Duke, UK, 2018. [Google Scholar]

Article Metrics

Citations

Article Access Statistics

Multiple requests from the same IP address are counted as one view.