Blockchain for Electronic Health Records

Dr. Priyanka Tyagi

Pratyush Prashar Shubham Kumar Mishra
Department Of Computer Science And
Department Of Computer Science And Department Of Computer Science And
Engineering
Engineering Engineering
School Of Engineering And
School Of Engineering And School Of Engineering And
Technology(SET)
Technology(SET) Technology(SET)
Sharda University
Sharda University Sharda University
Greater Noida, India
Greater Noida, India Greater Noida, India

201900578.pratyush@ug.sharda.ac.in 2019576062.shubham@ug.sharda.ac.in
Priyanka.tyagi@sharda.ac.in

Abstract—Systems for managing electronic health records
(EHRs) demand the use of efficient technology for
exchanging health data. Medical record storage solutions
could potentially be exposed to numerous security attack
vectors under current management practices. Blockchain
solutions for the healthcare industry, however, can offer a
decentralized, personal, and secure method of processing
EHRs. In this study, we introduce PREHEALTH, a
distributed ledger technology and Identity Mixer-based EHR
management solution that protects patient privacy (Idemix).
The permission blockchain foundation of the Hyperledger
Fabric is used in the proof-of-concept execution described in
the paper. The recommended procedure securely keeps
patient records while upholding confidentiality and
unlinkability. The effectiveness and viability of the plan for
deployment on a large scale in the actual world are
demonstrated by experimental performance evaluation
findings.
Keywords—component, formatting, style, styling, insert
(key words)
I. INTRODUCTION
The use of paper-based medical records has frequently had
an impact on traditional healthcare practices, and
electronic patient records have developed from these
documents. [1]. As a result, electronic health records
(EHRs) frequently include extremely personal medical
data that is shared with patients, pharmacists, and
healthcare professionals [2]. Data storage on distributed or
cloud servers is a feature of current EHR management
strategies; this practice can have a variety of functionality
and financial repercussions. Additionally, in line with
Coventry and Branley [3], health maintenance institutions
are exposed to a variety of cybersecurity dangers, such as
malware and ransomware.
EHR management and storage providers can be
successfully attacked via ransomware, which encrypts
data until a ransom is paid, or by compromising the EHR
repository. [3]. The National Health Service (NHS) lost
£92 million as a result of the WannaCry cyberattack,
which infected unprotected servers and computers and 70
out of 236 NHS foundations have encrypted medical data.
[4]. Additionally, the Medjack (Medical Device Hijack)
cyberattack employed malware which contaminated
numerous unsecured medical equipment, undermined
network security, broke client privacy, and gained access
to
health records [3]. Compared to other data sources,
healthcare information is frequently much more valuable
for trade on the black market: The average price of a
medical record breach is about $380, which is double the
average price of all data breaches related to industries [3].
Because of popular attack methods for standard EHR
record, incidents like the one above show that the
healthcare industry can sustain significant financial
loss[5].
A expandable, irreversible, clear, and secure remedy
needs to be put in place quickly in order to meet the above
difficulties given the growing push toward EHR. Avoiding
the possibility of a single point of failure or single point of
attack, medical data could be handled in a decentralised
manner using a cutting-edge technique that is impervious
to common attack vectors. Getting all participating
healthcare providers on the same page is essential to
preventing or appropriately responding to insider threats
and inadequate security.
In order to combat the aforementioned security issues,
current EHR storage and delivery methods make use of
specific technologies. They specifically use access control
rules like role-based access control (RBAC) and attribute-
based access control (ABAC), which limit unauthorised
clients' entry to the system based on predetermined
positions and qualities [6]. Additionally, a personal, three-
factor authentication that is personal mechanism could be
utilized in relation to the wireless sensor networks geared
toward healthcare (WSNs)[7]. To further hide clients'
identities and maintain secerecy, encryption in conjunction
with pseudonymization approach is used.However, access
control procedures may leak personal data, and encryption
procedures may adversely impact system performance.
[7].
XXX-X-XXXX-XXXX-X/XX/$XX.00 ©20XX IEEE

CONTRIBUTIONS
In this article, we suggest Healthcare That the Respects
Privacy (PREHEALTH), an EHR management system
that protects patient privacy. Patients and other
healthcare professionals can use PREHEALTH to keep
medical records on an unchangeable the distributed
ledger protects Data security. This unchangeable record
safeguards facts from exploitation and abuse while
enabling authorised blockchain participants, such as
medical professionals, to query non-personal
data.Keeping the collected personal data's privacy
personal as well as isolating data for auditing and
compliance checks are other features of PREHEALTH.
A. The following is a summary of the contributions made
by our work:
B. Creation of PREHEALTH, a medical record system
that protects privacy. This makes use of Identity Mixer
(Idemix) software and distributed ledger technologies.
Idemix is a cryptographic protocol that uses zero-
knowledge proof (ZKP) and offers preserving your
privacy features like unlinkability and secerecy.
C. An assessment of PREHEALTH's security and
robustness against common attack vectors.
D. The performance of PREHEALTH is empirically
compared to analogous blockchain technology solutions
and to a conventional record that provides applicable
context for column-level encryption.
E. The Idemix suite is still being created and has not been
some present drawbacks which would have to be solved in
subsequent liberate, as the use of the mentioned
condition-of-the- architecture as art inside a health
document dissemination access is a vital benefaction. A
client using Idemix as a blockchain client can study,
change, and quota confidential clinical data while
maintaining their secerecy and isolation.
F. The remaining portions of the essay are structured as
follows. Information about the history of the used
distributed ledger technology is provided in Segment 2
and is necessary to ensure the paper's sustainability. In
Segment 3, the pertinent literature is discussed. The
PREHEALTH proof-of-concept execution,this also serves
as our testbed for evaluation, is provided in Segment 4.
Prehealth evaluation process and findings are presented
in Segment 5 and discussed in Segment 6, respectively.
Finally, Segment 7 summarises our findings and offers
ideas for additional research.
G.
BACKGROUND
One of the latest technologies that has caused the most
disruption is blockchain. The phrase refers to a
decentralized coeval-to-coeval network where non-trusted
parties update an auditable, append-only ledger. Although
the platform allows for the choice of both open and
anonymous(permissionless) access, it also allows for the
specification of the number of end clients and validators.
It has been suggested to construct a electronic
couponing method using a network of blockchains without
authorization built based on the Ethereum blockchain.
Scalability and secerecy are still lacking, but effective
non- repudiation and decentralization have been
accomplished. Sub chains is a modern blockchain
technology created on the public ledger for Bitcoin that
enables data storage through third-party services in their
records and synchronises them with the Bitcoin blockchain
network. Longo, Podda, and Saia [12] studied Subchains.
However, synchronisation and security issues have an
impact on the proposed scheme's scalability and secerecy.
 On the other hand, Hyperledger Fabric, a blockchain
platform that is open source that has robust security and
identification capabilities, is an illustration of a
permissioned ledger[13]. In the cycle shown below for the
execute-order-validate step, Hyperledger Fabric's
innovative planning [14,15] selects where business is
conducted handled by running a piece of programming
code (referred to as chaincode) created in Go, Java, or
JavaScript.
1. Execution. Using the appropriate endorsement
policy, a client application sends a transaction
proposal to endorsing coevals in order to call a
chaincode function for interacting with the
blockchain ledger. The endorsement is returned
to the client as soon as the endorsers have
completed the chaincode successfully. After that,
a agreement is put together and inscribe using
character received from a Provider of
Membership Services (MSP), a party that
manages all of the mates and accreditors
identities inside each organisation.
2. Sequence. The ordering service receives
constructed transactions from a client after that.
The groups of nodes in question are known as
ordure’s, and their function is to tranmit the
sorted agreement to all other the network's
coevals after essentially combining several
transactions into a single block.
3. Validation Phase. The local ledger state is then
updated once each coeval confirms received
transactions in light of the endorsement policy. In
particular, Hyperledger Fabric exhibits distinctive
security techniques including individual data sets,
which permit sure authorised clients to view just
particular data[16]. Coevals employ local state
records [14,16] like CouchDB, MongoDB, and
LevelDB to store data. [15]. Docker containers
can participate in Hyperledger Fabric as
participants. A successful application execution
requires the following factors and consistently in
a digital environment, these containers [17] are a
device for software that encapsulates dependents
and programming code. Applications are also
developed in a secure, isolated environment
thanks to Docker's robust security features. On
top of Hyperledger Fabric, a number of
technologies can be added to improve privacy
and safety. This also applies to Idemix suite of
cryptographic protocols [18], which makes use of
ZKP to offer unlinkability and secerecy. Each
participant must utilise an IDemix identification
certificate to conduct absolutely every transaction
on an electronic ledger, or.
Abbreviations and Acronyms
Define abbreviations and acronyms the first time they
are used in the text, even after they have been defined in
the abstract. Abbreviations such as IEEE, SI, MKS, CGS,
sc, dc, and rms do not have to be defined. Do not use
abbreviations in the title or heads unless they are
unavoidable.
Occupational work:
Highly sensitive medical information is frequently
contained in electronic health records (EHR), which are
periodically shared with patients, pharmacists, and
healthcare professionals for clinical diagnosis and
treatment[2]. Furthermore, where the patient has given
their necessary consent, important medical information
needs to be updated frequently and shared. Robust
accessibility, quick entrance, and the proper the records'
encryption are also necessary in addition to this[2,19].
There are presently a number of strategies for
improving EHR management using blockchain technology
[20,21]. In their discussion of the differences between
distributed and cloud designs for EHR storage, Yüksel et
al. [6] suggest that a centralised model may be constructed
by utilising the pertinent decentralised situation and
methodologies architectures for the cloud. Architecture of
clouds, in its broadest sense, speaks of the organised
storehouse and distribution of enormous amounts of
medical history among distant unaffiliated service
providers. By implementing appropriate identity
management-based security measures, restriction of
access, integration of policy, and compliance supervision,
healthcare organisations and individuals can access the
data within the Cloud, fulfilling common requirements
like ascendible, accessibility, and worthwhile[1].
Sharma, Chen, and Sheth [22] looked at kHealth, a
useful a system in the cloud manages health data obtained
originating from Internet of Things (IoT) gadgets while
protecting privacy. Since their method makes use of a
variety of differential encryption and homomorphic
privacy techniques, it intends to create individualised
health predicting models by applying effective but
computation- intensive privacy protections. As a side note,
a scalability improvements compromise privacy-protection
procedures.
An efficient and personal e-medical cloud system was
presented by Dubovitskaya et al. [8] in which medical data
is securely disseminated utilising patient-specified access
control mechanisms over local and cloud-stored records
using public-key cryptography. This execution's drawback
stems from the potential wrongdoing of reputable cloud
server providers who might compromise secerecy by
inferring sensitive data obtained from the IP address of the
client. A patient made it potentially be linked to a
pseudonym by a pretextual assault.
Casino et al. [23] explored how using blockchain
technology might benefit a variety of healthcare-related
applications, such as the control of electronic medical
records,the fight against prescription fraud, and medical
study that is patient-focused.
With the new attribute-based signcryption (ABSC)
technology called the cuckoo filter, Ming and Zhang [24]
established effective PPAC (privacy-preserving access
control) method cloud-based technologies for EHR to
ensure efficiency and confidentiality of calculation. They
offered comprehensive privacy protections in addition to
comparative performance evaluation findings. But no
inquiry has been made into whether the GDPR is being
followed.
 Information from personal health records (PHRs) was
dispersed into data blocks by Roehrs et al. [25]. Although
the data storage appears to be centralised from a logical
perspective, it is actually decentralised across the
participating devices. The authors stated that many
businesses can implement their suggested protocol,
openPHR, because it is practical, adaptable, and elastic.
Although their planning is depicted in great points, the
usefulness of their ideas is called into question. The
writers also pointed out that their solution still lacks
security and privacy. It should be highlighted that an EHR
is administered by a healthcare facility, but the patient has
control over a PHR.. EHRs and PHRs can both be
evaluated based on speed and adaptability indicators,
protecting your privacy features, however, as they are both
stored and distributed electronically.
There are other methods that make use of a backbone
technology comparable to ours[26,27]. Using the
permissioned blockchain Hyperledger Fabric, Ichikawa et
al. [26] demonstrated options for storing medical records
gathered through mobile devices. The previous
Hyperledger Fabric v0.5 version, nevertheless, on which
the authors based their model and which PREHEALTH is
based lacks the personal information collecting
attributes.Furthermore, the Idemix suite is not supported
by their model, making it impossible to generate the
required privacy warranty. Their system is generally
capable of storing information in a permanent ledger, yet
without providing end clients with any privacy protection.
It should be emphasised that a system update would not be
possible without a complete redesign of their architecture
in order to include the personal data collection feature.
Similar to this, Liang et al. [27] simulated a actual
situation with numerous collaborating parties using Hyper
ledger Fabric.End clients, apparel technology, health
professionals, assurance firms, block chain systems, and
Online record are among the entities represented in their
system. However, as Hyper ledger Fabric developed, new
issues emerged that they did must now address in the
event that the planning is revised as well as updated to
include the personal data collection functionality in a later
release. The authors provide useful indicators on the
viability of each query on their system in the conclusion,
but crucial practical facts are omitted.
Although MeDShare [28] uses lots of ideas from our
job, the fundamental blockchain structure is not
deliberately chosen. A proposed solution is not given as
much attention by the writers as they do the basic smart
contracts and data blocks are the fundamental units of the
blockchain system..
Developed on the Ethereum blockchain system, the
permission less blockchain execution known as MedRec
[29] illustrates auditable and decentralized EHR
management. It compromises data and client confidentiality
by introducing both problematic transaction scalability
and a chance that a transaction can be linked to a specific
person. Other authors have been inspired by MedRec to
improve upon it and work to fix its flaws [30].
The MediBchain system [31] is built on the Ethereum
network and offers a permissioned coeval-to-coeval
method. To provide adequate scalability, it makes use of a
server infrastructure hosted in the cloud. Linkability is still
a problem, even if the participating parties' data is still in
encrypted form. The transaction cost, which is not
quantifiable, is another issue. Modum.io [32] is another
Ethereum-based system that focus on the supply-chain for
pharmaceuticals. The architecture created by Bocek et al.
[32]The warmth data that IoT sensors collect in this study
is used to enable mobile devices to unite to an HTTP
server. The HTTP server functions as a blockchain node
and use smart contracts to store the data in PostgreSQL
records. Even though it is not decentralised at every level,
their realistic scenario is capable plus could be modified
for an EHR exercise folder. The gathered information is
exposed and susceptible in cases where the HTTP server is
taken over by intruders or breaks down. Therefore, given
the sensitive nature of EHR data, its use in an EHR
scheme is not recommended.
Blockstack is an important and well-known distributed
record platform that explains blockchain technology [33].
By default, Blockstack uses the Gaia dispersed record,
which can accumulate record locally in consumer web
browsers rather than on a centralised server, improving
confidentiality. The Blockstack structure can be switched
to another platform; it is presently developed on top of the
Bit coin complex.
The creation of an innovative hybrid EHR
administration method is explored in [34] in the context of
a decentralized confidentiality blockchain explanation
created on a permission less blockchain system that
combines cloud storeroom for health information from
Internet of Things devices. The use of encryption with
symmetric and asymmetric keys that is not too heavy to
ensure efficient client authorization and secerecy is one of
the suggested solution's main benefits; nevertheless,
performance effectiveness and GDPR observance possess
not been investigated
Features of PREHEALTH:
In contrast to earlier methods, PREHEALTH allows
for the efficient and secure management of extremely
sensitive health data across the permissioned blockchain
network of Hyperledger Fabric. The levels of consent and
right of entry arrange that Hyper ledger Fabric provides
make it ideal for handling medical report since it offers a
personal, extensible, and vastly configurable
communications explanation [35]. Another benefit of
PREHEALTH is that its protecting your privacy features
comply with GDPR [36], particularly because it chains the
right to be elapsed and uses various stages of information
anonymization as well as the ability to set a fixed lifetime
for kept records. Similar to this, clients can request a
removal operation on the blockchain system if they prefer
to delete their data [37]. A hash demonstrating the
existence of the data in the ledger would also continue to
exist, but it is computationally unfeasible under reasonable
time limitations to correlate with the identity of the
information owner..
Table one contrasts PREHEALTH with other
machines in the literature whose demonstrations provide
either proof- of-principle applications that can be applied
in real-world settings or in-depth suggestions..This chart
summarises the underlying technology for each proposal
and includes Checkmarks or Xmarks to indicate whether
or not the proposal complies with GDPR requirements, as
well as whether or not presentation and extensibility
evaluation results similar to those in part 3 have been
completed.
 EXPERIMENTATION ENVIRONMENT
The creation of a system that provides secerecy, security,
and tolerable scalability is the main goal of the study. In
order to do this, it was decided to execute numerous
Docker containers, each of which included a fundamental
component of the Hyperledger Fabric network, in a mass
situation, as shown in outline two. In exacting, to build
up a system using Hyperledger Fabric composed of
individuals and organisations that have set up distributed
Couch DB ledgers and the chaincode for them[14,15], a
Debian Stretch mass situation [38] runs a dockerized a
command-line environment.
Outline three shows the summary for each Hyper ledger
Fabric action involving a distributed ledger. Three
different organisations, each with three coevals and a
different MSP, are deployed. Except for those from
Organization 1's coevals, who look after a secret data
collection, every coeval keeps a duplicate of the ledger
book. This is meant to serve as an example of a extensible
and secrecy-protecting EHR administration resolution.
The primary features of the projected test bed are as
follows, as outlined in segment 2:
 The proposed transaction is sent to the ordering
service after a coeval has been verified by the
MSP.
 A transaction is verified by the ordering service
using the corresponding chaincode, and the
public ledger is updated.
 To check, recognize, and revise their localized
version of the ledger, all coevals are informed of
public ledger changes.
The following are the technical requirements for the
proof-of-concept deployment: Intel Core i7 6th
Generation processor, running at 2.4 GHz, with 8GB
of RAM and a 256GB solid state drive . Each data
record, exactly, has six spheres, two of which depict
delicate patients. Information and are encrypted as part
of the personal data gathering. The variables are
specifically divided into the patient's Name, Address,
Country of Residency, DOB, a Test sphere that can
contain record relating to each use case, and lastly a
created system-
specific ID. Additionally, Organization 1 is the only
entity with access to the data from a personal collection,
which comprises of the patient's Name and Address in the
first two fields. Only the remaining non-sensitive
information may be accessed by Organizations 2 and 3.
Last but not least, coeval times for study and inscribe
queries are quantified as a component of assessment of
the suggested remedy.
Assessment:
(a) Protection Assessment
The weakest link is typically a person with regard to
technology like Hyper ledger Fabric that deal with
uniformity and authorizes; this is a legacy from old IT
systems. It is susceptible to hostile client to make arbitrary
study and inscribe queries to the blockchain ledger in
situations when a blockchain client's personal certificates
are stolen or exposed. The system's security may be
jeopardised in accordance with stated policy. Since no
one, not even the administrators, has full authorization or
authority over the ledger in our situation, this scenario is
implausible. The chaincode that is being run by every
coeval in the blockchain network could also pose a risk to
the systems. Although Chaincode operates independently
from outside interference, it could have problems. For the
purpose of finding defects at the pre-production stage,
thorough inspection and testing are essential [14]. Last but
not least, given that blockchain technology is still
relatively new and provides advanced security measures
that were previously impractical, it is still feasible that
additional faults and attacks will be found in the
future.Utilizing quantum computing, which undergone
significant development during the recent years, is one
potential threat. The aforementioned issue may put at risk
all methods depending on standard encryption techniques
and hashing techniques. Utilizing quantum-robust
techniques as a preventative countermeasure is therefore
recommended [39].
(b) Secerecy Assessment
Extraction of pertinent data obtained through dealings with
blockchain clients and chaincode is the main focus of the
assessment of the confidentiality and disconnected
between modern users and communication. The client
identity library is used in particular to examine exposed
identity information in interactions between common
clients and Idemix-based clients [40]. placed within the
chaincodeIt It should be remembered that the library listed
above offers a unique way to learn about the validators'
personal information because the outlined communication
route makes use of the TLS cryptographic procedure,
which effectively encrypts pertinent data. In contrast,
blockchain transactions only use a public key encryption
for signature, which is not disclosed any personal
information.
Additionally, the authors of [15] emphasised that because
Hyper ledger basics offers a wide arrangement liberty,
specific boundary must be changed in order for secerecy
and the efficiency of the block chain system measures to
be correctly identified plus evaluated. These parts are
separated into fixed and dynamic variables, and the
current segment inspect them as follows.
Fixed variables:
1. Number of institution, coevals and authorities: Three
organizations were created, each involving three coevals
who served as certifiers and a three-person instructing
repair due to complexity and technical restrictions.
2. Endorcment: The transaction request for each
transaction proposal must be signed by at least one coeval
from any corresponding organisation, cutting down on
unneeded coordinating with other countersign parties.
Vibrant variables

1. Provider of association services: Unlike the current
X.509 public key certificate process, Idemix expertise
requires a unique validation contributor [41].
2. Client registration process: Idemix client registration
necessitates specific CLI commands. To allow for a client
to sign up as well as engage the block chain system, a
suitable CLI docker bud vase was created, as shown in
outline two. In this container, pertinent Idemix options
were treated as argument lines for commands.
Performance Evaluation
For different volumes of EHRs, we designed inquiry
period for PREHEALTH, a PostgresSQL record
imitating a typical EHR administration explanation, and
the experimentation prototypes for MedRec and Block
stack (10, 100, 1000, 10,000, 100,000 and 1,000,000).
Table 2
and Figure 4 present the findings. Even though both
blockchain technologies, notably Medrec and
Blockstack, as well as a conventional PostgreSQL
record, enforce increased over time, cost per inquiry,
PREHEALTH shows resourceful study and inscribe
query time metrics.
Notably, PREHEALTH performs significantly better
when there are a lot of records. From the experiments that
have been done, it is clear that the contract time for each
interpret query using a PostgreSQL record is increasing
directly and will surpass PREHEALTH at roughly
1,200,000 records. Therefore, it is evident that
PREHEALTH is capable of handling each query in a
actual situation where there are countless entries that
have been stored.
Additionally, it should be mentioned that the Proof of
Authority consensus technique was used to construct the
MedRec prototype in an experimental setting in order to
successfully deploy local nodes. Contrastingly, the
commercial MedRec programme operates using a tedious
evidence of job consensus method [29], resulting in more
accurate measures of query time.
Normative experiments were also run on our suggested
PREHEALTH solution's CPU and Memory performance.
Table 3 and Figure 5 show the microchip consumption of
PREHEALTH coevals during the process for study and
inscribe queries over different EHR measures (1000,
10,000, and 100,000). PREHEALTH inaugurated 3
institutions, specifically the Health center, sanatorium,
and CommunityHealth, as seen in Figure 3. There are
three blockchain coevals for each company, namely
Coeval 0, Coeval 1, and Coeval 2, accordingly. The
blockchain coevals' average CPU utilization for read
queries is fair, hovering around 30%, whereas write
queries only manage a maximum CPU presentation of
15.4%.The CPU presentation of the block chain coevals
is often constant, with brief swings that are likely due to
equipment restrictions. As a result, it is not depicted in a
plot because the typical memory overhead of every
blockchain coeval across our experiments with different
size of EHRs was negligible (below 2%).
Discussion
In the previous section, an experiential contrast of
PREHEALTH to the cutting-edge methods of the
Hyperledger Fabric structure, that were used to achieve
explicit secerecy and seclusion of contact, was made.
Additionally, experimental performance indicators for
blockchains, including their extensibility, stability, review,
and economical, be evaluated in relation to particular
ecological conditions along with factors. The deployment
of an investigational proof-of-notion to a report context
was examined after testing.
Additionally taken into consideration were the
calculation and evaluation of quantifiable characteristics
and performance indicators in relation to the experimental
execution. Extensibility, stability, review, and economical
of the blockchain were effectively authenticated, in addition
to the use of cutting-edge Idemix technology. Our findings
specifically show that the suggested EHR management
strategy enables the contract history of medicinal report
shall not be altered and adequately inspected, even on a
vast scale, lacking a major presentation slide.
Information was effectively encrypted using effective
encryption techniques; as a result, a malevolent another
party cannot contact important data. Additionally, a
blockchain ledger is immune to specialised command
injection threats like SQL injection, which specifically
targets a particular information record format. [42].
Additionally, each relative blockchain coeval was
mounted with the MSP directory having the necessary
cryptographic material, making it impossible for an
attacker to negotiation the gathered system by using
forged cryptographic components by pretending to be a
blockchain coeval. The solution also included a personal,
isolated blockchain topology that was immune to external
security threats and where recognised blockchain coevals
and orderers would directly reveal their identities in the
case of misbehavior. All validator identities are made
public in the case of a consent personal blockchain
consortium that would deploy PREHEALTH. Therefore, if
the actor tried to alter with the EHRs or blockchain contact
them, they would be identified. Last but not least, the
execution was connected to a personal, inaccessible
blockchain topology that was impervious to outside safety
intimidation and where recognized blockchain coevals and
orderers would immediately divulge their identities in the
event of misbehavior. Every validator's identity is made
public under the scenario of a authorized personal
blockchain association using PREHEALTH. As a result,
the actor would disclose their individuality upon making
an attempt to alter EHRs or blockchain transactions
themselves.
Conclusion and Future Work
EHR administration is essential now and will remain so in
the future. Responsive medical information of individuals,
whose isolation is required respected, is contained in
EHRs. We suggested PREHEALTH, a method for storing
EHRs while protecting patient isolation. We conducted an
experiential contrast of our proof-of-concept execution
with other another ideas that have been made in the
literature and discovered that PREHEALTH, when the
amount of data stored is substantial, delivers stronger
privacy assurances while imposing less query overhead. In
fact, Any number of EHRs can be interpreted by
PREHEALTH with a comprehend query time of 183 ms;
whereas the other compared workings comprehend query
times are longer or increasing exponentially. In particular,
 On the MedRec platform, a read query in ten lakh EHRs
takes 210 milliseconds, A Blockstack comprehend query
takes 360 milliseconds., and a read query in a
PostgreSQL record takes 136 millisecond. Additionally,
we have suggested and used quantifiable measures to
assess the presentation, extensibility, review, and stability
of the scheme.
In a future release, a potential extension of this work
might concentrate on using enhanced Idemix
credentials. Technical issues with the Idemix technology
would be resolved if a credential is revoked and the
including unique identity characteristics are made
possible. At that point, a useful exploring new territory
could be started conducive to create a manufacturing
EHR managing solution that protects patient privacy.
Additionally, a minimal Kubernetes cluster with a
blockchain solution could be used as a performance
benchmarking strategy, and a variety of customizable
guideline might be studied within relation to their
impact on the extensibility of blockchain. In particular, a
performance-oriented cloud environment might be used
to create a complicated blockchain network that includes
many blockchain coevals, orderers, backing plans, and
simultaneous interactions on the blockchain, effectively
assessing criterions and looking at the extensibility as a
whole.
REFERENCES
1. Abbas, A.; Khan, S.U. A review on the state-of-
the-art privacy-preserving approaches in the e-
health clouds. IEEE J. Biomed. Health Inform.
2014, 18, 1431–1441. [CrossRef] [PubMed]
2. Dubovitskaya, A.; Xu, Z.; Ryu, S.; Schumacher,
M.; Wang, F. Secure and trustable electronic
medical records sharing using blockchain. AMIA
Annu. Symp. Proc. 2017, 2017, 650–659.
[PubMed]
Sensors 2020, 20, 6587 14 of 16
3. Coventry, L.; Branley, D. Cybersecurity in
healthcare: A narrative review of trends, threats
and ways forward. Maturitas 2018, 113, 48–52.
[CrossRef] [PubMed]
4. Smart, W. Lessons Learned Review of the
WannaCry Ransomware Cyber Attack;
Department of Health and Social Care: London,
UK, 2018; Volume 1, pp. 10–1038.
5. Alvarez, M. Security Trends in the Healthcare
Industry; Somers IBM: Somers, NY, USA, 2017;
pp. 2–18. Available online:
https://www.ibm.com/downloads/cas/PLWZ76M
M (accessed on 17 November 2020).
6. Yü ksel, B.; Kü pç ü , A.; Özkasap, Ö. Research
issues for privacy and security of electronic
health services. Future Gener. Comput. Syst.
2017, 68, 1–
13. [CrossRef]
7. Renuka, K.; Kumar, S.; Kumari, S.; Chen, C.M.
Cryptanalysis and improvement of a privacy-
preserving three-factor authentication protocol
for wireless sensor networks. Sensors 2019, 19,
4625. [CrossRef] [PubMed]
8. Dubovitskaya, A.; Urovi, V.; Vasirani, M.;
Aberer, K.; Schumacher, M.I. A cloud-based
ehealth architecture for privacy preserving data
integration. In Proceedings of the IFIP
International Information Security and Privacy
Conference, Hamburg, Germany, 26–28 May
2015; pp. 585–598.
9. Angelis, S.D.; Aniello, L.; Baldoni, R.;
Lombardi, F.; Margheri, A.; Sassone, V. PBFT vs
proof-of- authority: Applying the CAP theorem
to permissioned blockchain. In Proceedings of the
Italian Conference on Cyber Security, Milan, Italy,
6 February 2018.
10. Kuo, T.T.; Kim, H.E.; Ohno-Machado, L.
Blockchain distributed ledger technologies for
biomedical and health care applications. J. Am.
Med. Inform. Assoc. 2017, 24, 1211–1220.
[CrossRef] [PubMed]
11. Podda, A.S.; Pompianu, L. An overview of
blockchain-based systems and smart contracts for
digital coupons. In Proceedings of the
IEEE/ACM 42nd International Conference on
Software Engineering Workshops, Seoul, Korea,
24 June– 16 July 2020; pp. 770–778.
12. Longo, R.; Podda, A.S.; Saia, R. Analysis of a
Consensus Protocol for Extending Consistent
Subchains on the Bitcoin Blockchain.
Computation 2020, 8, 67. [CrossRef]
13. 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, p. 4.
14. Androulaki, E.; Barger, A.; Bortnikov, V.;
Cachin, C.; Christidis, K.; De Caro, A.; Enyeart,
D.; Ferris, C.; Laventman, G.; Manevich, Y.; et
al. Hyperledger fabric: A distributed operating
system for permissioned blockchains. In
Proceedings of the Thirteenth EuroSys
Conference, Porto, Portugal, 23–26 April 2018;
pp. 1–15.
15. Thakkar, P.; Nathan, S.; Viswanathan, B.
Performance benchmarking and optimizing
hyperledger fabric blockchain platform. In
Proceedings of the 2018 IEEE 26th International
Symposium on Modeling, Analysis, and
Simulation of Computer and Telecommunication
Systems (MASCOTS), Milwaukee, WI, USA,
25– 28 September 2018; pp. 264–276.
16. Papadopoulos, P.; Pitropakis, N.; Buchanan,
W.J.; Lo, O.; Katsikas, S. Privacy-Preserving
Passive DNS. Computers 2020, 9, 64. [CrossRef]
17. Boettiger, C. An introduction to Docker for
reproducible research. ACM SIGOPS Oper. Syst.
Rev. 2015, 49, 71–79. [CrossRef]
18. Androulaki, E.; De Caro, A.; Neugschwandtner,
M.; Sorniotti, A. Endorsement in Hyperledger
 Fabric. In Proceedings of the 2019 IEEE
International Conference on Blockchain
(Blockchain), Atlanta, GA, USA, 14–17 July
2019; pp. 510–519.
19. Abramson, W.; Hall, A.J.; Papadopoulos, P.;
Pitropakis, N.; Buchanan, W.J. A Distributed
Trust Framework for Privacy-Preserving
Machine Learning. arXiv 2020,
arXiv:2006.02456.
20. Hölbl, M.; Kompara, M.; Kamiš alic ́, A.; Nemec
Zlatolas, L. A systematic review of the use of
blockchain in healthcare. Symmetry 2018, 10,
470. [CrossRef]
21. Mayer, A.H.; da Costa, C.A.; da Rosa Righi, R.
Electronic health records in a blockchain: A
systematic review. Health Inform. J. 2020, 26,
1273–1288. [CrossRef] [PubMed]
22. Sharma, S.; Chen, K.; Sheth, A. Toward practical
privacy-preserving analytics for IoT and cloud-
based healthcare systems. IEEE Internet Comput.
2018, 22, 42–51. [CrossRef]
23. Casino, F.; Dasaklis, T.K.; Patsakis, C. A
systematic literature review of blockchain-based
applications: current status, classification and open
issues. Telemat. Inform. 2019, 36, 55–81.
[CrossRef]
Sensors 2020, 20, 6587 15 of 16
24. Ming, Y.; Zhang, T. Efficient privacy-preserving
access control scheme in electronic health
records system. Sensors 2018, 18, 3520.
[CrossRef] [PubMed]
25. Roehrs, A.; da Costa, C.A.; da Rosa Righi, R.
OmniPHR: A distributed architecture model to
integrate personal health records. J. Biomed.
Inform. 2017, 71, 70–81. [CrossRef] [PubMed]
26. Ichikawa, D.; Kashiyama, M.; Ueno, T. Tamper-
resistant mobile health using blockchain technology. JMIR
MHealth UHealth 2017, 5, e111. [CrossRef] [PubMed]
Sensors 2020, 20, 6587 16 of 16
27. Liang, X.; Zhao, J.; Shetty, S.; Liu, J.; Li, D.
Integrating blockchain for data sharing and
collaboration in mobile healthcare applications.
In Proceedings of the 2017 IEEE 28th Annual
International Symposium on Personal, Indoor,
and Mobile Radio Communications (PIMRC),
Montreal, QC, Canada, 8–13 October 2017; pp.
1–
5.
28. Xia, Q.; Sifah, E.B.; Asamoah, K.O.; Gao, J.; Du,
X.; Guizani, M. MeDShare: Trust-less medical
data sharing among cloud service providers via
blockchain. IEEE Access 2017, 5, 14757–14767.
[CrossRef]
29. 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.
30. Yang, H.; Yang, B. A blockchain-based approach
to the secure sharing of healthcare data. In
Proceedings of the Norwegian Information
Security Conference 2017, Oslo, Norway, 11–15
September 2017.
31. Al Omar, A.; Rahman, M.S.; Basu, A.; Kiyomoto,
S. Medibchain: A blockchain based privacy
preserving platform for healthcare data. In
Proceedings of the International Conference on
Security, Privacy and Anonymity in
Computation, Communication and Storage,
Guangzhou, China, 12–15 December 2017; pp.
534–543.
32. 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.
33. Ali, M.; Shea, R.; Nelson, J.; Freedman, M.J.
Blockstack: A New Decentralized Internet.
Whitepaper. May 2017. Available online:
https://pdos.csail.mit.edu/6.824/papers/blockstack
-2017.pdf (accessed on 17 November 2020).
34. Dwivedi, A.D.; Srivastava, G.; Dhar, S.; Singh,
R. A decentralized privacy-preserving healthcare
blockchain for
IoT. Sensors 2019, 19, 326. [CrossRef] [PubMed]
35. Albeyatti, A. White Paper: Medicalchain.
MedicalChain Self-Publication, 2018. Available
online:
https://medicalchain.com/en/whitepaper/ (accessed on
17 November 2020).
36. Voigt, P.; Von dem Bussche, A. The eu general
data protection regulation (gdpr). In A Practical
Guide, 1st ed.;
Springer International Publishing: Cham, Switzerland,
2017.
37. Davari, M.; Bertino, E. Access control model
extensions to support data privacy protection
based on GDPR.
In Proceedings of the 2019 IEEE International
Conference on Big Data (Big Data), Los Angeles, CA,
USA, 9–12
December 2019; pp. 4017–4024.
38. Krafft, M.F. A Delphi Study of the Influences on
Innovation Adoption and Process Evolution in a
Large Open Source
Project: The Case of Debian; University of Limerick,
Department of Computer Science & Information Systems:
Limerick, Ireland, 2010. Available online:
http://193.1.102.107/handle/10344/427 (accessed on 17
November 2020).
39. English, E.; Kim, A.D.; Nonaka, M. Advancing
Blockchain Cybersecurity: Technical and Policy
Considerations for the Financial Services Industry.
2018. Available online:
https://www.microsoft.com/en-us/cybersecurity/
 content-hub/advancing-blockchain-cybersecurity
(accessed on 17 November 2020).
40. Hyperledger Fabric. Client Identity Chaincode
Library, 2017. Available online:
https://github.com/hyperledger/
fabric/blob/release-
1.1/core/chaincode/lib/cid/README.md
(accessed on 17 November 2020).
41. Chokhani, S.; Ford, W.; Sabett, R.; Merrill, C.;
Wu, S. RFC 2527: Internet X.509 Public Key
Infrastructure Certificate Policy and
Certification Practices Framework; Internet
Engineering Task Force (IETF), RFC: Fremont,
CA, USA, 1999.
Available online:
https://tools.ietf.org/html/rfc2527 (accessed on 17
November 2020).
42. Halfond, W.G.; Viegas, J.; Orso, A. A
classification of SQL-injection attacks and
countermeasures. In Proceedings of the IEEE
International Symposium on Secure Software
Engineering, Washington, DC, USA, March
2006; Volume 1, pp. 13–15.