A PRELIMENERY REPORT ON

“DECENTRALISED OF ELECTRONIC HEALTH

RECORD USING BLOCKCHAIN TECHNOLOGY”

SUBMITTED TO THE SAVITRIBAI PHULE UNIVERSITY, PUNE

IN THE PARTIAL FULFILLMENT OF THE REQUIREMENTS
FOR THE AWARD OF THE DEGREE

OF
BACHELOR OF ENGINEERING (COMPUTER ENGINEERING)

SUBMITTED BY

KIRAN MAHAJAN Roll No: 09

TEJASWINI PATIL Roll No: 46
KARAN MAHAJAN Roll No: 07
VIVEK PATIL Roll No: 06

DEPARTMENT OF COMPUTER ENGINEERING

SANDIP INSTITUTE OF TECHNOLOGY AND RESEARCH CENTRE

Mahiravani, Trimbak Road, Nashik, Maharashtra 422213

SAVITRIBAI PULE PUNE UNIVERSITY

2023-2024

i
 CERTIFICATE
This is to certify that the project report entitles
“Decentralised OF ELECTRONIC HEALTH
RECORD USING BLOCKCHAIN TECHNOLOGY”
Submitted by

KIRAN MAHAJAN Roll No: 09

TEJASWINI PATIL Roll No: 46
KARAN MAHAJAN Roll No: 07
VIVEK PATIL Roll No: 06

is a bonafide student of this institute and the work has been carried out by him/her
under the supervision of Dr.Naresh Thoutam and it is approved for the partial
fulfillment of the requirement of Savitribai Phule Pune University, for the award of the
degrees of Bachelor of Engineering (Computer Engineering).

(Dr. Naresh Thoutam) (Dr. Ankita .V.Karale)

Guide Head
Department of Computer Engineering Department of Computer Engineering

Dr. M.M. Patil

Principal
SANDIP INSTITUTE OF TECHNOLOGY AND RESEARCH CENTRE
Nashik-422213
SAVITRIBAI PULE PUNE UNIVERSITY
2023-2024
 ACKNOWLEDGMENT
It gives us immense pleasure in presenting the project report on “DECENTRALISED OF
ELECTRONIC HEALTH RECORD UAING BLOCKCHAIN TECNOLOGY” The success and
the outcome of this report required a lot of guidance. We are very grateful to our guide
Dr. K. S. Wagh who has provided expertise and encouragement. We thank sir who
provided vision and knowledge that was very helpful throughout the research. All that
we have done is only due to the great guidance. We also express our gratitude to Dr. S.N.
Zaware Head of Computer Engineering Department, AISSMS’s Institute of Information
Technology, for the valuable support.
We would also like to extend our sincere thanks to Principal Dr.P.B. Mane, for his
dynamic and valuable guidance throughout the project and providing the necessary
facilities that helped us to complete our dissertation work.

VIVEK PATIL
KARAN MAHAJAN
KIRAN MAHAJAN
TEJASWINI PATIL

iii
 ABSTRACT

In this work the functioning of blockchain technology and the possible use or impact it
may have on current SCM Registry systems and the role of legal experts are described.
The spread of blockchains is bad for anyone in the trust business government
authorities that are deemed sufficiently trustworthy to handle transactions. The
proposed system maintains the blockchain base transaction management SCM records
and automatic data recovery from third party attacks, the system also address the issues
of data inconsistency during the transaction. The main objectives were to define how
blockchain can change the supply chain and logistics industry. The typical challenges in
these spheres were considered and the main key features of blockchain that can solve
these difficulties were marked. In survey we were find out possible challenges or
benefits of blockchain based applications. Considering the current situation in the
supply chain and logistics industry, this thesis can empower different businesses to start
working with the companies that are creating blockchain-based applications.
 TABLE OF CONTENTS
List of Figures..........................................................................................................viii
List of Tables.............................................................................................................ix
1 INTRODUCTION..................................................................................................... 1
1.1 Overview............................................................................................................... 1
1.2 Motivation.............................................................................................................2
1.3 Problem Definition and Objectives......................................................................2
1.4 Project Scope and Limitations.............................................................................3
1.5 Methodologies of Problem Solving......................................................................4
2 LITERATURE SURVEY........................................................................................... 5
3 SOFTWARE REQUIREMENTS SPECIFICATION...................................................8
3.1 Assumptions and Dependencies..........................................................................8
3.2 Functional Requirements.....................................................................................8
3.2.1 System Feature 1............................................................................................... 8
3.2.2 System Feature 2............................................................................................. 10
3.3 External Interface Requirements.......................................................................10
3.3.1 User Interfaces.................................................................................................10
3.3.2 Hardware Interfaces........................................................................................11
3.3.3 Software Interfaces..........................................................................................11
3.3.4 Communication Interfaces..............................................................................11
3.4 Non Functional Requirements...........................................................................11
3.4.1 Performance Requirements............................................................................11
3.4.2 Safety Requirements........................................................................................12
3.4.3 Security Requirements....................................................................................12
3.4.4 Software Quality Attributes............................................................................12
3.5 System Requirements.........................................................................................12
3.5.1 Database Requirements..................................................................................12
3.5.2 Software Requirements(Platform Choice).....................................................13
3.5.3 Hardware Requirements.................................................................................13

v
3.6 Analysis Models: SDLC Model to be applied......................................................13
3.7 System Implementation Plan.............................................................................14
4 SYSTEM DESIGN...................................................................................................16
4.1 System Architecture...........................................................................................16
4.2 Data Flow Diagrams............................................................................................17
4.3 UML Diagrams.........................................................Error! Bookmark not defined.
5 PROJECT PLAN..................................................................................................... 24
5.1 Project Estimate..................................................................................................24
5.1.1 Reconciled Estimates.......................................................................................24
5.1.2 Project Resources............................................................................................24
5.2 Risk Management............................................................................................... 24
5.2.1 Risk Identification............................................................................................25
5.2.2 Risk Analysis....................................................................................................25
5.2.3 Overview of Risk Mitigation, Monitoring, Management................................25
5.3 Project Schedule................................................................................................. 26
5.3.1 Project Task Set................................................................................................26
5.3.2 Timeline Chart................................................................................................. 27
5.4 Team Organization.............................................................................................28
5.4.1 Team Structure................................................................................................28
5.4.2 Management Reporting and Communication................................................28
6 PROJECT IMPLEMENTATION.............................................................................29
6.1 Overview of Project Modules.............................................................................29
6.2 Tools and Technologies Used.............................................................................30
6.3 Algorithm Details................................................................................................30
6.3.1 Algorithm 1: Hash Generation........................................................................30
6.3.2 Algorithm 2: Protocol for Peer Verification...................................................30
6.3.3 Algorithms 3: Mining Algorithm for valid hash creation...............................31
7 SOFTWARE TESTING...........................................................................................32
7.1 Principle of Testing:............................................................................................32
7.2 Testing scope:..................................................................................................... 32
7.2.1 Major Functionalities:......................................................................................32
7.3 Basics of Software Testing.................................................................................33
7.3.1 White-box testing:........................................................................................... 33
7.3.2 Black box Testing:............................................................................................33
7.3.3 Unit testing:......................................................................................................34
7.3.4 Integration testing:..........................................................................................34
7.3.5 Validation testing:............................................................................................34
7.3.6 System Testing:................................................................................................35
7.4 Test Strategy....................................................................................................... 35
7.4.1 Testing Process:...............................................................................................36
7.4.2 Functionality testing and non-functional testing:..........................................36
7.5 Test Cases and Results....................................................................................... 37
7.5.1 Test cases of system........................................................................................37
8 RESULTS................................................................................................................39
8.1 Screenshots.........................................................................................................39
8.1.1 Admin Login Page............................................................................................39
8.1.2 Admin Add Medicines Page.............................................................................40
8.1.3 Admin Accepts Order Page..............................................................................41
8.1.4 Distributor Register Page................................................................................42
8.1.5 Distributor Login Page....................................................................................43
8.1.6 Distributor Order Page....................................................................................44
8.1.7 Distributor Order Next Page...........................................................................45
8.1.8 Distributor QR Code Upload Page...................................................................46
8.1.9 Distributor Save Medicine Page......................................................................47
8.1.10 Distributor Accept Request Page..................................................................48
8.1.11 User Register Page.........................................................................................49
8.1.12 User Login Page.............................................................................................50
8.1.13 User Order Page.............................................................................................51

vii
8.1.14 User Order Next Page....................................................................................52
8.1.15 User QR Code Upload Page............................................................................53
8.1.16 User Save Medicine Page...............................................................................54
9 CONCLUSIONS AND FUTURE WORK.................................................................55
9.1 Conclusion...........................................................................................................55
9.2 Future work........................................................................................................ 55
9.3 Applications........................................................................................................ 55
Appendix A...............................................................................................................56
References............................................................................................................... 57

List of Figures
4.1 System Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 DFD Level Zero Diagram. . . . . . . . . . . . . . . . . . . . . . . 19
4.3 DFD Multi Level Diagram. . . . . . . . . . . . . . . . . . . . . . 20
4.4 Class Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.5 State Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.6 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.7 Sequence Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.8 Use Case Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.9 Entity Relationship Diagram. . . . . . . . . . . . . . . . . . . . . 26

7.1Testing view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.1 Admin Login Page. . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.2 Admin Add Medicines Page . . . . . . . . . . . . . . . . . . . . . . 46
8.3 Admin Accept Order Page . . . . . . . . . . . . . . . . . . . . . . . 47
8.4 Distributor Register Page. . . . . . . . . . . . . . . . . . . . . . . 48
8.5 Distributor Login Page . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.6 User Distributor Page. . . . . . . . . . . . . . . . . . . . . . . . . 50
8.7 Distributor Order Next Page . . . . . . . . . . . . . . . . . . . . . . 51
8.8 Distributor QR Code Upload Page. . . . . . . . . . . . . . . . . . 52
8.9 Distributor Save Medicine Page . . . . . . . . . . . . . . . . . . . . 53
8.10 Distributor Accept Request Page. . . . . . . . . . . . . . . . . . . 54
8.11 User Register Page . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.12 User Login Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
8.13 User Order Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
8.14 User Order Next Page. . . . . . . . . . . . . . . . . . . . . . . . . 58
8.15 User QR Code Upload Page . . . . . . . . . . . . . . . . . . . . . . 59
8.16 User Save Medicine Page . . . . . . . . . . . . . . . . . . . . . . . . 60

List of Tables
3.1 Project Schedule. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1 Risk Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 Risk Table1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3 Risk Table2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4 Project Schedule. . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5 Team Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7.1 Test cases of system. . . . . . . . . . . . . . . . . . . . . . . . . . 43

ix
 CHAPTER 1

INTRODUCTION
1.1 Overview

Blockchain technology or the distributed, secure ledger technology has gained

much attention in recent years. This paper presents a detailed survey of
blockchain technology literature and its applications. The sources of blockchain
literature examined for this survey include research papers, books and book
chapters, journal papers, specific cryptocurrency sites and wikis, conference
papers, company ‘Point of View’s (PoVs), whitepapers published by various
organizations implementing and experimenting in Blockchain. Blockchain being
a much hyped and experimented technology a lot of literature is found in content
hosted on proprietary forums such as company websites, web articles, etc. This
survey is extensive and covers the various aspects of blockchain including
consensus algorithms and their variations as well as currently implemented and
possible future applications. This survey will not cover the details of technical
aspects of blockchain, however, references that cover these aspects may be found
in bibliography.
1.2 Motivation

1. The world is changing incredibly fast, and we are not all aware of it.

2. Block chain technology and crypto currencies are an irreversible

advancement that is disrupting established industries and the ways in which
we interact financially.

3. Big data storage of decentralized data storage as well as information system.

4. The different attack issues in centralized database architectures.

5. There is no automatic attack recovery in central data architectures.

6. The decentralized architecture provides the automatic data recovery from

different attacks.

7. After the analysis of this system we move to develop the decentralized

system architecture.

1.3 Problem Definition and Objectives

Problem Definition
To design and developed a system for supply chain management using blockchain
technology, in this work system carried out three different modules like suppler,
vendor and admin as well. Each transaction has stored into the blockchain which
eliminate all network data attacks in P2P environment for health care systems.
Objectives

• To study and analysis the basic execution of blockchain in distributed

databases environment

• To develop system for supply chain management for medicine using custom
blockchain.

• To design new hash generation, smart contract and mining approach for
proposed blockchain.

• To validate the system with various consensus algorithm in Peer to Peer

(P2P) environment

2
1.4 Project Scope and Limitations

Scope
Blockchain, the digital ledger technology that can securely maintain continuously
growing lists of data records and transactions, has the power to potentially
transform medicine and health care supply chain management, according to
industry experts.By simplifying and expediting the way the transaction industry
processes data in such areas as revenue cycle management, health data
interoperability and supply chain validation, blockchain has the power to
dramatically reduce backoffice data input and maintenance costs and improve
data accuracy and security.
Limitations
If someone has more than 51% computing power, then he/she can find Nonce
value quicker than others, means he/she has authority to decide which block is
permissible. What it can do is:

• Modify the transaction data, it may cause double spending attack .

• To stop the block verifying transaction.
• To stop miner mining any available block.

A majority attack was more feasible in the past when most transactions were
worth significantly more than the block reward and when the network hash rate
was much lower and prone to reorganization with the advent of new mining
technologies
1.5 Methodologies of Problem Solving

A System has represented by a 5-different phases, each phase works with own
dependency System S = (Q,P,δ,q0,F) where

• Q is a group of states with a finite number of possibilities.

• P the alphabet is a finite set of symbols..

• δ is the role of transformation where δ : Q ×P→ Q • q0 is the starting point for

processing any input. (q0 Q).

• F is a set of final state(s) of Q (F ⊆ Q).

All (n) data nodes will return 1 when each have the same blockchain. Q = initial
transactional data with genesis block
P
= {SHA-256, Consensus-Val, Mining}
δ = Validate all server(S1 ⊆ S2⊆S3⊆S4) all server validation process q0
= Initial transaction T[0]
F = {Commit Trans, Get-History-Record}
State ⇒
1: if all chains are validate or same
0: if any t(n) server consist the invalid chain

4
 CHAPTER 2

LITERATURE SURVEY
According to [1] a basic IoT Blockchain fusion model with four layers which
contains different types of IoT devices. Distributed file system is considered in
the model to store huge amount of IoT data. Then, a case study for
blockchainbased IoT application, a Machine-to-Machine(M2M) autonomous
trading system, is proposed on the Ethereum blockchain. We build smart
contracts for device registration, data storage, service provision and fair
payment, and the proof-ofconcept is implemented using two Raspberry Pis to
interact with smart contracts. The proposed system verifies that blockchain
could improve IoT applications in transparency, traceability and security.

According to [2] Edgence (EDGe + intelligENCE, Figure 1) is proposed to serve

as a blockchain-enabled edge-computing platform to intelligently manage
massive decentralized applications (dApps) in IoT usecases1. To extend the
range of blockchain to IoT-based dApps, Edgence adopts master node technology
to connect to a closed blockchain-based system to the real world. A master node
contains a full node of the blockchain and a collateral, and is deployed on an edge
cloud of mobile edge computing, which is convenient for the master node to use
resources of the edge cloud to run IoT dApps.

According to [3] introduces HCloud, a trusted JointCloud platform for IoT

systems using server less computing model. HCloud allows an IoT server to be
implemented with multiple servers less functions and schedules these functions
on different clouds based on a schedule policy. The policy is specified by the
client and includes the required functionalities, execution resources, latency,
price and so on. HCloud collects the status of each cloud and dispatches server
less functions to the most suitable cloud based on the schedule policy. By
leveraging the blockchain technology, we further enforce that our system can
neither fake the cloud status nor wrongly dispatch the target functions.

According to [4] introduce the concept of a decentralized gasified service

exchange platform where the solution providers can dynamically offer and
request services in an autonomous peer- to-peer fashion. Cost and decision to
exchange services are set during operation time based on gasification policies
according to business goals. The proposed concept is based on blockchain
technology to provide a tokenized economy where the IoT solution providers can
implement gasification techniques using smart contracts to maximize profits
during service offering and requesting.

According to [5] a gesture-based secure interaction system with smart home IoT
health devices to support elderly people or people with special needs. The
framework uses a decentralized blockchain consensus for storing the smart home
IoT health data and user identities. The framework leverages off-chain solution for
storing raw multimedia IoT sensory payload and gesture data. Using our proposed
health monitoring framework, a smart homeowner or service provider can create a
cyber-physical space with a secure digital wallet for each human resident and
authorized IoT health devices. Multiple authorized home residents can interact
with the IoTbased smart home monitoring sensors, carry out user and IoT health
sensory media registration, and transfer transactional values via secure tokens, as
well as raw IoT health data payload through gesture.

According to [6] a scheme to generate seed needed for key generation and a
scheme to manage the public key using blockchain. First is a random seed
generation scheme needed for key generation? In order to prevent the risk of a
manin-the-middle attack and reverse engineering, seeds are generated by using
out-ofband communication and hardware variation. Second is a key management
system for the IoT using blockchain? The scheme we propose is to distribute the
public key on the blockchain network. The public key is used to encrypt a session
key that will be used for communication between devices.

According to [7] initially reviewed and identified the security and privacy issue
exists in IoT system. Secondly, as per Blockchain technology provides some
security solutions. The details analysis, including enabling technology and
integration of IoT technologies, are explained. Lastly, a case study is
implemented using the Ethererum based Blockchain system in a smart IoT
system and the results are discussed.

According to [8] on one such implementation experience for Smart Toll

Transaction application in the domain of mobility. Our paper showcases a

6
possible solution by leveraging negotiations, decision making, distributed
learning capabilities at the devices level using AI-enabled Multi- Agent Systems
and the real-time smart contracts between the Cars and Tolls using Blockchain.
This solution also showcases the monetization of real time data coming from
various IoT devices which are part of vehicles and infrastructure. While
blockchain secures the privacy of the participants it also acts as an economic
transactional layer and governance layer between the devices in the network.

According to [9] a content selection algorithm of edge cache nodes. The

algorithm adopts markov chain model, improves the utilization of cache space
and reduces the content transmission delay. The hierarchical caching strategy is
adopted

AISSMS IOIT, Department of Computer Engineering 2020-2021

and the secondary cache stores slides of contents to expand the coverage of
cached content and to reduce user waiting time. Regional node cooperation is
adopted to expand the cache space and to support the regional preference of
cache content. Compared with the classical substitution algorithm, simulation
results show that the algorithm in this paper has higher cache hit ratio and
higher space utilization. Proposing a node selection strategy of content
deployment which aims to improve the quality of service and to reduce the waste
of bandwidth resources.

According to [10] Based on a sharing economy, this framework allows energy

trading between households, bringing flexibility and decreasing the dependency
on energy providers. In parallel, the increasing adoption of electric vehicles and
the development of vehicle-to-grid (V2G) technology open new ways to store,
transport and deliver renewable energy. V2G-enabled cars could contribute to
the flexibility of peer-to-peer energy marketplaces. Our physical demonstrator
illustrates the benefits of V2Genabled vehicles in the context of local energy
marketplaces in terms of economic gain, overall power balancing and consumed
renewable energy rate.
 CHAPTER 3

SOFTWARE REQUIREMENTS SPECIFICATION

3.1 Assumptions and Dependencies

We assume that there are several servers and clients attached to it. User system
supports TCP/IP protocols.
The key considerations of Java are

1. Object Oriented: Java purist’s “everything is an object” paradigm. The java

object model is simple and easy to extend.

2. Multi threaded: Java supports multi threaded programming which allows

you to write programs that do many things simultaneously.

3. Architecture-Neutral: the main problem facing programmers is that no

guarantee that if you write a program today, it will run tomorrow, even on
the same machine. Java language and JVM solves this problem, their goal is
to provide “Write once; Run anywhere anytime forever.

4. Distributed: Java is designed for the distributed environment of the Internet

because it handles TCP/IP protocols.

3.2 Functional Requirements

3.2.1 System Feature 1

The system contains following modules:

1. Admin

2. Make transaction

3. Block Generation and blockchain validation

4. Consensus Algorithm validation and block chain recovery

5. Results Generation

8
This system highlights the implementation of e-transaction system using
blockchain for such a proposal from a practical point view in both
development/deployment and usage contexts. Concluding this work is a potential
roadmap for blockchain technology to be able to support complex applications. In
the system carried out transaction system for online user, where end user easily
access the system and make the transaction without using any third party
validation . The system can’t be generating any high level hardware configuration
requirement, it possible to make vote using traditional configuration. The able to
perform the transaction without any hardware device with drastic security
manner. In this data is processed in multiple servers so the transactions are
processed in sequencing P2P distributed network. This illuminates the quality of
service issue and time limits. This is a middleware system in which the
processing environment in which the load will be balanced using threads. The
request generated will be parallels saved on all nodes in a Blockchain manner. We
use the Hash generation algorithm and the Hash will be generated for the given
string. Before executing any transaction, we use peer to peer verification to
validate the data. If any chain is invalid then it will recover or update the current
server blockchain. This will validate till the all nodes are verified and commit the
query. Mining algorithm is used for checking the hash generated for the query till
the valid hash is generated.
Implementation Procedure

• We create a multiple Distributed ledger and e-transaction transnational

data and stored all transnational data into multiple data nodes.

• Each node will holds the specific block for each transaction.
• Same block has replace for all nodes, and generates a valid block chain.
• System will retrieve data from all data nodes and commit the transaction, it
should be any kind of DDL, DML as well as DCL transactional query.

• If any block chain invalid during the validation of data servers, then system
will automatically recover whole blockchain using majority of servers.

• We will address and eliminate the runtime server attacks and recover it
using own blockchain.

9
3.2.2 System Feature 2

Decentralization:The dispersion of duties and controls from a central authority

to all the units concerned is decentralisation. There is no overarching authority in
the blockchain. Instead, a copy of the transaction ledger is given to any blockchain
user (miner), and a new block is added by validating transactions by the miners
involved. The network functions on a peer-to-peer (user-to-user) basis in a
decentralised environment. The researchers use this blockchain feature as one of
the key elements in creating the Ethereum digital currency.
Consensus model(s): The consensus model(s) help preserve the sanctity of data
recorded on blockchain. In , it is reported that various consensus mechanisms
and issues could result when the consensus mechanism fails including blockchain
forks, consensus failures, dominance issues, validating nodes and deficient
performance of the blockchain network.
Transparent: The blockchain network routinely checks in with itself every ten
minutes in order to self-audit the ecosystem of a digital value, which reconciles
transactions that happen in ten-minute intervals.
Open source: A decentralized and closed-source application needs user to trust
that the application is decentralized and the data cannot be accessed from a
central source. Closed-source applications act as a barrier to adoption by users.
Identity and Access:
The identity and accessibility of a blockchain are related to three main criteria
including public or permission less, private or permission, and consortium. These
criteria of blockchain was discussed in detail in.
Immutability:
Immutability is something that is unchanging over a period. In the context of
blockchain, immutability is relevant to data or information stored in the blocks.
Once the data or information is written in a block of blockchain nobody can alter
it. This is highly essentially beneficial for auditing data.

3.3 External Interface Requirements

3.3.1 User Interfaces

The Interface will be in the form of an application. It is designed to be functional

and minimal in its styling. All options will be displayed in a menu based format.

10
Web app will be used to setup the page layout and add minimal styling to make
the interface user friendly.

3.3.2 Hardware Interfaces

The hardware should have following specifications

• Ability to read gallery

• Ability to exchange data over network
• Touch screen for convenience
• Keypad (in case touchpad not available)
• Continuous power supply
• Ability to connect to network
• Ability to take input from user
• Ability to validate user

3.3.3 Software Interfaces

It will also have a MySQL relational database. The main backend processing will
be done using swing framework including connecting to and accessing the
database and processing requests.

3.3.4 Communication Interfaces

The main communication protocol will be Hyper Text Transfer Protocol (HTTP).
This will be used to transfer information back and forth from the client to the
server. HTTP GET and POST will be used to send the information.

3.4 Non Functional Requirements

3.4.1 Performance Requirements

The only way in which systems will meet their performance targets is for them to
be specified clearly and unambiguously. It is a simple fact that if performance is
not a stated criterion of the system requirements then the system designers will
generally not consider performance issues. While loose or incorrectly defined
performance specifications can lead to disputes between clients and suppliers. In
many cases performance requirements are never ridged as system that does not

11
fully meet its defined performance requirements may still be released as other
consideration such as time to market. In order to assess the performance of a
system the following must be clearly specified:

• Response Time
• Workload
• Scalability
• Platform
3.4.2 Safety Requirements

This Specification shall be sufficient detailed to allow the design and implement
to achieve the required safety integrity and allow an assessment of functional
safety.

3.4.3 Security Requirements

We provide authentication and authorization by passwords for each level of

access.
We implement IDEA algorithm for secure data transmission

3.4.4 Software Quality Attributes

Product is portable; it can run between only two connected systems or a large
Network of computers. Product is maintainable; i.e. in future the properties of the
product can be changed to meet the requirements.

3.5 System Requirements

3.5.1 Database Requirements

• It should be SQLite database on platform.

• Database must be integrated with key constraints
• It should be maintain the relational base on RDMS and normalization
• System will create database backup on periodic basis.
• It will execute all commands like DML, DDL and DCL as well as we required
some security measurements for sql injection.

12
3.5.2 Software Requirements(Platform Choice)

Technologies and tools used in Policy system project are as follows Technology
used:

Front End

• Operating System:-Windows XP/7/8

• Programming Language: JAVA/J2EE/
• Tools: Eclipse, Heidi SQL, JDK 1.7 or Higher
• Database: MySQL 5.1

Back-End

• Mysql

3.5.3 Hardware Requirements

• Processor:- Intel Pentium 4 or above

• Memory:- 2 GB or above
• Other peripheral:- Printer
• Hard Disk:- 500gb

3.6 Analysis Models: SDLC Model to be applied

SDLC model is a combination of iterative and incremental process models with

focus on process adaptability and customer satisfaction by rapid delivery of
working software product. Agile Methods break the product into small
incremental builds. These builds are provided in iterations. Each iteration
typically lasts from about one to three weeks. Every iteration involves cross
functional teams working simultaneously on various areas like

• Planning
• Requirements Analysis
• Design
• Coding

13
 • Unit Testing and
• Acceptance Testing.

3.7 System Implementation Plan

Table 3.1: Project Schedule

Sr. Task Name Begin date End date Remarks
No
1 Selecting project domain 15 July 2020 20 July 2020 Done
2 Understanding project need 21 July 2020 25 July 2020 Done
3 Understanding pre 26 July 2020 30 July 2020 Done
requisites
4 Information Gathering 1 Aug 2020 30 Aug 2020 Done
5 Literature Survey 1 Sept 2020 15 Sept 2020 Done
6 Refine Project Scope 16 Sept 2020 18 Sept 2020 Done
7 Concept Development 19 Sept 2020 20 Sept 2020 Done
8 Planning and Scheduling 21 Sept 2020 23 Sept 2020 Done
9 Requirements analysis 24 Sept 2020 25 Sept 2020 Done
10 Risk identification and 26 Sept 2020 27 Sept 2020 Done
monitoring
11 Design and modeling 28 Sept 2020 15 Oct 2020 Done
12 Design review and 16 Oct 2020 20 Oct 2020 Done
refinement
13 GUI design 21 Oct 2020 20 Nov 2020 Done
14 Implementation 21 Nov 2020 15 Feb 2021 Done
15 Review and suggestions for 15 Mar 2021 20 Mar 2021 Done
Implementation
16 Outcome assessment 21 Mar 2021 30 Mar 2021 Done
17 Testing and Quality 1 Apr 2021 10 Apr 2021 Done
Assurance
18 Review and suggestions for 11 Apr 2021 15 Apr 2021 Done
Testing and QA
19 Refined QA activities 16 Apr 2021 30 May 2021 Done

14
 CHAPTER 4

SYSTEM DESIGN
4.1 System Architecture

Figure 4.1: System Architecture

Process Module

• Admin
• Make transaction
• Block Generation and blockchain validation
• Consensus Algorithm validation and block chain recovery
• Results Generation
• The central outline of the proposed algorithm is the implementation of
supply chain management distribution data storage using block chain.

15
 • System creates the trustworthy communication between multiple parties
without using any third party interface.

• We use the Hash generation algorithm and the Hash will be generated for
the given string.

• Before executing any transaction, we use peer to peer verification to

validate the data.

• If any chain is invalid then it will recover or update the current server
blockchain.

• This will validate till the all nodes are verified and commit the query.
• Mining algorithm is used for checking the hash generated for the query till
the valid hash is generated.

4.2 Data Flow Diagrams

1. DFD Level 0

Figure 4.2: DFD Level Zero Diagram

2. DFD Level 1
Figure 4.3: DFD Multi Level Diagram
4.3 UML Diagrams

Class Diagram

Figure 4.4: Class Diagram

State Diagram

Figure 4.5: State Diagram

Activity Diagram
Figure 4.6: Activity Diagram
Sequence Diagram

Figure 4.7: Sequence Diagram

Uscase Diagram

Figure 4.8: Use Case Diagram

Entity Relationship Diagram

Figure 4.9: Entity Relationship Diagram
 CHAPTER 5

PROJECT PLAN
5.1 Project Estimate

Waterfall model is being used for the project estimation. It depicts the step wise
execution of the entire project.

5.1.1 Reconciled Estimates

Cost Estimate :

Not Applicable.

Time Estimate:

Approximately eight months.

5.1.2 Project Resources

Project resources includes People,Software like JSP,HTML, CSS, Servlet and Tools
like Eclipse

5.2 Risk Management

Risk identification is a systematic attempt to specify threats to the project plan

(estimates, schedule, resource loading, etc.). By identifying known and
predictable risks, the project manager takes a first step toward avoiding them
when possible and controlling them when necessary. There are two distinct
types of risks: Generic risks and Product-specific risks. Generic risks are a
potential threat to every software project. Product-specific risks can be identified
only by those with a clear understanding of the technology, the people, and the
environment that is specific to the project at hand.

23
5.2.1 Risk Identification

A risk is an uncertain event or condition that, if it occurs, has a positive or

negative effect on projects objectives. A Risk Management Plan is a document
that a project manager prepares to foresee risks, estimate impacts, and define
responses to issues. Risk management is an ongoing process that continues
through the life of a project. It includes processes for risk management planning,
identification, analysis, monitoring and control. Many of these processes are
updated throughout the project life-cycle as new risks can be identified at any
time. The objective of risk management is to decrease the probability and impact
of events adverse to the project. On the other hand, any event that could have a
positive impact should be exploited.

5.2.2 Risk Analysis

The risks for the Project can be analyzed within the constraints of time and
quality.

5.2.3 Overview of Risk Mitigation, Monitoring, Management

ID Risk Description Probability

Impact

Schedule Quality Overall

1 Usage of Product Low Low High High

Financial
2 Requirement Med Med High High
Table 5.1: Risk Table

Risk ID 1
Risk Discription Errors Aries due to dublicate data
Category System Gatway Enviornment
Source Dublicate Data Enter by User
Probability Medium
Impact Medium
 Response Mitigate
Strategy Data verification will resove the
issue
Risk Status Identified
Table 5.2: Risk Table1
Risk ID 2
Risk Discription Database Maintenance
Category Development
Environment
Source Registration of users
Probability Medium
Impact High
Response Serious
Strategy Access Control Methods
Risk Status Identified
Table 5.3: Risk Table2

5.3 Project Schedule

5.3.1 Project Task Set

Major aspects of the project:

• Task 1: Correctness
• Task 2: Availability
• Task 3: Integrity

5.3.2 Timeline Chart

Table 5.4: Project Schedule

Sr. Task Name Begin date End date Remarks

No
1 Selecting project domain 15 July 2020 20 July 2020 Done
 2 Understanding project need 21 July 2020 25 July 2020 Done
3 Understanding pre 26 July 2020 30 July 2020 Done
requisites
4 Information Gathering 1 Aug 2020 30 Aug 2020 Done
5 Literature Survey 1 Sept 2020 15 Sept 2020 Done
6 Refine Project Scope 16 Sept 2020 18 Sept 2020 Done
7 Concept Development 19 Sept 2020 20 Sept 2020 Done
8 Planning and Scheduling 21 Sept 2020 23 Sept 2020 Done
9 Requirements analysis 24 Sept 2020 25 Sept 2020 Done
10 Risk identification and 26 Sept 2020 27 Sept 2020 Done
monitoring
11 Design and modeling 28 Sept 2020 15 Oct 2020 Done
12 Design review and 16 Oct 2020 20 Oct 2020 Done
refinement
13 GUI design 21 Oct 2020 20 Nov 2020 Done
14 Implementation 21 Nov 2020 15 Feb 2021 Done
15 Review and suggestions for 15 Mar 2021 20 Mar 2021 Done
Implementation
16 Outcome assessment 21 Mar 2021 30 Mar 2021 Done
17 Testing and Quality 1 Apr 2021 10 Apr 2021 Done
Assurance
18 Review and suggestions for 11 Apr 2021 15 Apr 2021 Done
Testing and QA
19 Refined QA activities 16 Apr 2021 30 May 2021 Done

5.4 Team Organization

Team consists of four members. Proper planning mechanism is used and roles
are analyzed and defined.

5.4.1 Team Structure

Table 5.5: Team Structure

 SR No. Member Name
1 RITU NARAYANI
2 PRATIKSHA MUNOT
3 RACHANA GHODKE
4 SNEHAL GHODKE
Responsibility
Developer , Project analysis
Developer , Project Design
Developer ,Testing
Developer ,Documentation

5.4.2 Management Reporting and Communication

Well organized plans were been made and completed accordingly within time.
Progress reporting was been updated and completed. Communication as per
requirements were being done effectively.
 CHAPTER 6

PROJECT IMPLEMENTATION
6.1 Overview of Project Modules

• Admin

• Make transaction

• Block Generation and blockchain validation

• Consensus Algorithm validation and block chain recovery

• Results Generation

• The central outline of the proposed algorithm is the implementation of

supply chain management distribution data storage using block chain.

• System creates the trustworthy communication between multiple parties

without using any third party interface.

• We use the Hash generation algorithm and the Hash will be generated for
the given string.

• Before executing any transaction, we use peer to peer verification to

validate the data.

• If any chain is invalid then it will recover or update the current server
blockchain.

• This will validate till the all nodes are verified and commit the query.

• Mining algorithm is used for checking the hash generated for the query till
the valid hash is generated.

28
6.2 Tools and Technologies Used
Front End
• Operating System:-Windows XP/7/8

• Programming Language: JAVA/J2EE

• Tools: Eclipse, Heidi SQL, JDK 1.7 or Higher

• Database: MySQL 5.1

Back-End

• Mysql
6.3 Algorithm Details

6.3.1 Algorithm 1: Hash Generation

Input: data d,
Output: Generated hash H according to given data
Step 1: Input data as d
Step 2: Apply SHA 256 from SHA family
Step 3: CurrentHash= SHA256 (d)
Step 4: Return CurrentHash

6.3.2 Algorithm 2: Protocol for Peer Verification

Input: User Transaction query, Current Node Chain CNode[chain], Other

Remaining Nodes blockchain Node-Chain[Nodeid] [chain],
Output: Recover if any chain is invalid else execute current query.
Step 1: User generate the any transaction DDL, DML or DCL query
Step 2: Get current server blockchain
Cchain ← Cnode[Chain] (6.1)

Step 3: For each

) (6.2)

End for
Step 4: Foreach (read I into NodeChain)
If (!.Equals NodeChain[i] with (Cchain))
Flag 1
Else Continue Commit query
Step 5: if (Flag == 1)
Count = SimilaryNodesBlockchian ()
Step 6: Calculate the majority of server
Recover invalid blockchain from specific node
Step 7: End if
End for
End for

6.3.3 Algorithms 3: Mining Algorithm for valid hash creation

Input: Hash Validation Policy P[], Current Hash Values hash-Val

Output: Valid hash
Step 1: System generate the hash-Val for ith transaction using Algorithm 1
Step 2: if (hash-Val.valid with P[])
Valid hash
Flag =1
Else
Flag=0
Mine again randomly
Step 3: Return valid hash when flag=1

30
 CHAPTER 7

SOFTWARE TESTING
Software Testing is the process of executing every functionality and procedure of
the program or application with the intent to find the errors or bugs. Testing is
performed to investigate the entire project from every aspect. It deals with the
motto to make the model more robust and accurate. The results make the
developer aware of the issues that the program might go through in the future.
Software testing is important to understand the future risks.

7.1 Principle of Testing:

• To know the system performance.

• To recognize the functionality of each and every individual module.
• To verify whether system is functioning as per the user requirements.

7.2 Testing scope:

Testing is important in software engineering to validate, verify project. Main aim

of the testing is to verify the system by finding bugs or defect in the different
modules. Due to testing phase, system is analyzed for probable risks in project.

7.2.1 Major Functionalities:

Following are the some main functionalities of this project.

• User registration
• Data uploading
• Data store in DB
• Access by GUI
• Implementation various machine learning algorithm
• Classification results

31
7.3 Basics of Software Testing

7.3.1 White-box testing:

The White box testing is done by the tester who has knowledge o f the
programming language. White box testing done on algorithm or source code of
the project.

It is the procedure of giving the input to the project and verifying that how
system process input to produce result. In white box testing all, the interior
details are required to known to tester. White box testing is also called as
transparent testing. This test needs code to check so it is essential for tester to
have the knowledge coding. Following are the techniques of White Box testing:

• Programming style
• Control method
• Source language
• Database design

This type of a test is useful to beat defects at structural level. This test goes lower
the top or functional layer to expose defects.
Test case designing methods:
• Statement coverage
• Decision coverage
• Condition coverage
• Multiple Condition coverage
• Path coverage

7.3.2 Black box Testing:

This type of testing takes place by actual validating of requirement with actual
result. In the black box testing tester does not require knowing the internal logic
of the project. He concern with the actual result generated by the system.
Functional testing is performed in black box testing. Here, the knowledge about
how the program internally executes or the programming language does not
required. According test plan, Following are the functionality which cover under
the black box testing.
 • Server connection
• Data upload
• features extraction
• Machine learning algorithm process
• classification
• Results

7.3.3 Unit testing:

Unit testing is small part of a system to check it might be as methods, functions,

classes of code, interface and of system. Therefore here, tester will test every
small unit of the system to investigate whether the module is suitable for the
system. Software writes all units tests and carried out to verify that code
complete necessities, design and perform as per user requirement. Unit testing
cover a few advantages like those that error and bugs found at early stage.
Because of the issues found at very early stage and determined instantly is not
disturbing the other part of codes.

7.3.4 Integration testing:

In the Integration testing, different modules has combine together and tested. To
exchange information easily between distinct modules of the system, test that it
performance as per the given requirement. When all testing allied work is
completed, the software is deployed to the customer. Stress and load testing is
conducted in the integration testing. Here, how professionally and how many
reviews have been processed is been tested.

7.3.5 Validation testing:

In this testing, tester will verify the software that it covers all the requirements
as per the system requirement specification. It makes sure that the requirement
of software was at correct place. It also verifies whether we have built right
system or not. It checks the following: It justifies the execution and behavior of
the system. All probable input data given as input and capture projected output.
Test log is used for deployment
7.3.6 System Testing:

After performing the integration testing, the next step is output testing of the
proposed system. No system could be useful if it does not produce the required
output in a specified format. The outputs generated are displayed by the user.
Here the output format is considered in PPT format document.

7.4 Test Strategy

Figure 7.1: Testing view

This diagram is articulate trying out go with the flow. In step c it remember
design of machine and in keeping with that test Cycles, take a look at instances,
entrance and go out standards, predicted results, and so on is been
accomplished. We need to recognize test instances and the desired records. The
check steps received from the business layout and the files related to transaction.
The test methods require layout of techniques together with status reporting,
and making plans statistics tables. Step d. includes soliciting for/building takes a
look at database surroundings. Execute venture Integration check Run take a
look at cases from integration of the utility. Test all check cases after deployed on
the system. Signoff – this is ultimate stage whilst all end completed.
7.4.1 Testing Process:

There are extraordinary procedures for trying out the software. The diverse
steps been described underneath:

• A demand of device is to be examined.

• The expected time of results after each testing module is been diagnosed.

• Testing which is been associated with equipment’s and reference record

that are required to execute have to be listed.

• Deploy the setup for testing for check surroundings.

7.4.2 Functionality testing and non-functional testing:

Functionality Testing:
Capability checking out is accomplished to test the functionality of software
program as in keeping with layout specification of that software and is it
operating as per requirement or no longer. In functionality testing center
capability of the utility tested with the aid of tester. Middle level functionalities
like input given, methods and setup on machine. It promotes test and affirm a
specific approach or characteristic of the program. Useful trying out may be very
clean i.e. consumer can do it easily.
Project Aspect:
In the proposed system, all the function was tested by tester as well as developer.
The EBD has major functionality like user registration, file uploading and
downloading, selecting expiry date of file. All these are main functionality of the
EBD are implemented successfully and working as per the user expectation.
Non-Functional Testing:
Non-useful trying out is been related to the best and functions of the module of
software program. Non-useful not concerning to a specific feature or person
movement along with load control but it related to software program features.
Non-practical testing may be Reliability checking out, Usability trying out etc.
7.5 Test Cases and Results

After implementation section while tester assessments code it detects the a few
fault or disorder inside the code. The faults corrected through a few method in
short time. While testing the performed by means of creating the test instances.

There are person test cases performed for every state of affairs, and it tested
with the anticipated output by way of system or software. The following table
indicates that everyone the check cases which might be vital for project. Below
Table shows the suite of test cases which are executed and passed.

7.5.1 Test cases of system

During this project the system solution are investigating and presenting the new
framework for addressing the problem of finding relevant result. The aim of this
project was to improve the performance of algorithm presented in base system.
The results demonstrated in this project are showing the current state of work
done over practical implementation of this algorithm

Table 7.1: Test cases of system

Case Description Expected Actual Pass /
id outcome Outcome Fail
1 User and Register Suc- New Registered Pass
Distributor cessfully successfully
Register
2 Login Process Allow login to System allow Pass
Email-id and authenticated login to
user only authenticated
Password user only
3 Medicine Attribute must Medicine Pass
Information be and upload Information
upload
on server upload
successfully
4 Medicine Order Process Medicine Pass
Name,ID and and QR Code Information
General Send success- show
fully successfully
Information
 Show
5 Data Show and Transaction Block chain Pass
Transaction Update success success
 CHAPTER 8

RESULTS
8.1 Screenshots
8.1.1Admin Login Page

Figure 8.1: Admin Login Page

38
8.1.2 Admin Add Medicines Page

Figure 8.2: Admin Add Medicines Page

8.1.3 Admin Accepts Order Page

Figure 8.3: Admin Accept Order Page

40
8.1.4 Distributor Register Page

Figure 8.4: Distributor Register Page

8.1.5 Distributor Login Page

Figure 8.5: Distributor Login Page

42
8.1.6 Distributor Order Page

Figure 8.6: User Distributor Page

8.1.7 Distributor Order Next Page

Figure 8.7: Distributor Order Next Page

44
8.1.8 Distributor QR Code Upload Page

Figure 8.8: Distributor QR Code Upload Page

8.1.9 Distributor Save Medicine Page

Figure 8.9: Distributor Save Medicine Page

46
8.1.10 Distributor Accept Request Page

Figure 8.10: Distributor Accept Request Page

8.1.11 User Register Page

Figure 8.11: User Register Page

48
8.1.12 User Login Page

Figure 8.12: User Login Page

8.1.13 User Order Page

Figure 8.13: User Order Page

50
8.1.14 User Order Next Page

Figure 8.14: User Order Next Page

8.1.15 User QR Code Upload Page

Figure 8.15: User QR Code Upload Page

52
8.1.16 User Save Medicine Page

Figure 8.16: User Save Medicine Page

 CHAPTER 9

CONCLUSIONS AND FUTURE WORK

9.1 Conclusion

Because of the complexities of this area and the need for more stable and
efficient information management frameworks, there are several research
directions to apply Blockchain technology to the transaction industry. In several
cases of transaction usage that face similar data exchange and communication
problems, an interoperable architecture will certainly play a significant role.
Further research on safe and efficient software practise for the use of Blockchain
technology in transactions is also required to educate software engineers and
domain experts on the potential and also limitations of this new technology,
whether to build a decentralised application using an established Blockchain.
The algorithm has chosen the acceptable complexity, efficiency and complexity of
implementation to operate the system. Through empirical studies, we have a
better understanding of the pace of knowledge creation in the supply chain.
There are several important hurdles to getting on the blockchain reaching its full
potential and applying it to health is the most important issue technology
scalability and data controls.

9.2 Future work

To implement the proposed system on multiple peer to peer network, with fog
computing which reduce the transactional data processing time.

9.3 Applications

1. Peer to peer communication transaction applications.

2. Bitcoin transaction applications.

3. Zebpay transaction application

4. Bittrex app

5. Polonix

54
 APPENDIX A
NP-hard
A problem is NP-hard if solving it in polynomial time would make it possible to
solve all problems in class NP in polynomial time. Some NP-hard problems are
also in NP (these are called ”NP-complete”), some are not. If you could reduce an
NP problem to an NP-hard problem and then solve it in polynomial time, you
could solve all NP problems. Also, there are decision problems in NP-hard but are
not NP- complete, such as the infamous halting problem.
NP-complete
A decision problem L is NP-complete if it is in the set of NP problems so that any
given solution to the decision problem can be verified in polynomial time, and
also in the set of NP-hard problems so that any NP problem can be converted
into L by a transformation of the inputs in polynomial time. The complexity class
NP-complete is the set of problems that are the hardest problems in NP, in the
sense that they are the ones most likely not to be in P. If you can find a way to
solve an NP-complete problem quickly, then you can use that algorithm to solve
all NP problems quickly.

63
 References
[1] Gong, Xinglin, Erwu Liu, and Rui Wang. &Blockchain-Based IoT Application
Using Smart Contracts: Case Study of M2M Autonomous Trading.& 2020
5th International Conference on Computer and Communication Systems
(ICCCS). IEEE, 2020.

[2] Xu, Jinliang, et al. &Edgence: A blockchain-enabled edge-computing

platform for intelligent IoT-based dApps.& China Communications 17.4
(2020): 78-87.

[3] Huang, Zheng, Zeyu Mi, and Zhichao Hua. &HCloud: A trusted JointCloud
serverless platform for IoT systems with blockchain.& China
Communications 17.9 (2020): 1-10.

[4] Gheitanchi, Shahin. &Gamified service exchange platform on blockchain for

IoT business agility.& 2020 IEEE International Conference on Blockchain
and Cryptocurrency (ICBC). IEEE, 2020.

[5] Rahman, Md Abdur, et al. &A Natural User Interface and Blockchain-Based
In-Home Smart Health Monitoring System.& 2020 IEEE International
Conference on Informatics, IoT, and Enabling Technologies (ICIoT). IEEE,
2020.

[6] Choi, Jungyong, et al. &Random Seed Generation For IoT Key Generation
and Key Management System Using Blockchain.& 2020 International
Conference on Information Networking (ICOIN). IEEE, 2020.

[7] Mohanta, Bhabendu Kumar, et al. &Addressing security and privacy issues
of IoT using blockchain technology.& IEEE Internet of Things Journal
(2020).

[8] Abraham, Misha, Himajit Aithal, and Krishnan Mohan. &Blockchain and
Collaborative Intelligence based next generation Smart Toll Application.&
2020 2nd Conference on Blockchain Research & Applications for
Innovative Networks and Services (BRAINS). IEEE, 2020.

[9] Wang, Hongman, et al. &An algorithm based on markov chain to improve
edge cache hit ratio for blockchain-enabled IoT.& China Communications
17.9 (2020): 66-76.
 64
[10] Brousmiche, Kei, et al. &Peer-to-Peer Energy Market Place Powered by
Blockchain and Vehicle-to-Grid Technology.&2020 2nd Conference on
Blockchain Research & Applications for Innovative Networks and Services
(BRAINS). IEEE, 2020.
 65
AISSMS IOIT, Department of Computer Engineering 2020-2021