Journal of Medical Systems (2018) 42:136

https://doi.org/10.1007/s10916-018-0993-7

SYSTEMS-LEVEL QUALITY IMPROVEMENT

MedBlock: Efficient and Secure Medical Data Sharing Via Blockchain

Kai Fan 1 & Shangyang Wang 1 & Yanhui Ren 1 & Hui Li 1 & Yintang Yang 2

Received: 27 February 2018 / Accepted: 12 June 2018

# Springer Science+Business Media, LLC, part of Springer Nature 2018

Abstract
With the development of electronic information technology, electronic medical records (EMRs) have been a common way to
store the patients’ data in hospitals. They are stored in different hospitals’ databases, even for the same patient. Therefore, it is
difficult to construct a summarized EMR for one patient from multiple hospital databases due to the security and privacy
concerns. Meanwhile, current EMRs systems lack a standard data management and sharing policy, making it difficult for
pharmaceutical scientists to develop precise medicines based on data obtained under different policies. To solve the above
problems, we proposed a blockchain-based information management system, MedBlock, to handle patients’ information. In this
scheme, the distributed ledger of MedBlock allows the efficient EMRs access and EMRs retrieval. The improved consensus
mechanism achieves consensus of EMRs without large energy consumption and network congestion. In addition, MedBlock also
exhibits high information security combining the customized access control protocols and symmetric cryptography. MedBlock
can play an important role in the sensitive medical information sharing.

Keywords Medical data sharing . Blockchain . Security . Privacy preserving . Openness . Efficiency

Introduction are not available to provide the doctor their detailed past med-
ical records, because their past records were stored in some-
The era of information has arrived. Due to the development of where else. Interoperability challenges between different hos-
digitization and cloud storage, more and more data is trans- pital systems pose tough hurdles to data sharing. It is difficult
ferred from paper to the electronic equipment [1]. The digiti- for people to obtain the data they want because of lack of
zation storage of information in medical institutions is popu- unified data management and sharing.
lar. Electronic medical records are usually stored in a private On the one hand, data requestors want to acquire the
database, which brings a problem that patients leave data patients’ past medical records in order to determine their
scattered across various hospitals because life events take treatment plans [3]. On the other hand, the medical records
them away from one hospital and into another. It is notewor- stored in private databases contain much privacy related to
thy that these records are generated in hospitals after patients hospital and patient. Therefore, querying data and sharing
visit them by recording in electronic medical records. may bring serious risk of confidentiality for data providers.
Therefore, patients lose easy access to past data even if it It is not everyone can access to the EMRs. To meet the high
belongs to them [2]. When they visit other hospitals, they demands on data sharing [4], some researchers have pro-
posed some relative schemes about cloud storage and com-
puting technologies to provide suitable solutions to com-
This article is part of the Topical Collection on Systems-Level Quality pression storage and processing demands. However, cloud
Improvement
service providers (CSP) face some significant hurdles in
persuading hospitals to use centralized cloud services due
* Kai Fan
[email protected] to the adverse risks posed on exposing the contents on
data. Some cryptographic schemes have been proposed to
1 solve these problems about medical data sharing. But they
State Key Laboratory of Integrated Service Networks, Xidian
University, Xi’an 710071, China are insufficient, the disadvantages still exist [5, 6]. For the
2 hospital, the sheer volume of data stored in third parties is
Key Lab. of Minist. of Educ. for Wide Band-Gap Semicon. Materials
and Devices, Xidian University, Xi’an 710071, China not reassuring [7]. These semi-trusted third parties may
misuse and disclose providers’ privacy. Article 17 of the
136 Page 2 of 11 J Med Syst (2018) 42:136

soon-enforceable General Data Protection Regulation in algorithm [13, 14], group signature and zero-knowledge proof
the EU has strengthened the rights of individuals and im- scheme [15] are used to enhance the anonymity of data. We
posed many restrictions on the storage of personal data by achieve the same effect in MedBlock based on access control
third parties. Personal medical data would come under the protocols by hiding the signature information and encrypting
protection of privacy laws and many of legal provisions summaries for unauthorized users.
would not allow personal data to be kept perpetually. In The rest of the article is organized as follows: in Section II,
the face of the legal disputes caused by data leakage, hos- we review the related work about privacy protection of infor-
pitals lack a reason to provide data to third parties. mation and medical information sharing process, and then
For the government, medical records need to be monitored discuss their limitations. The scheme and system model of this
to find illegal medical procedures. In the meantime, re- paper will be described in Section III. Next in Section IV, we
searchers also hope to analyze past medical data to make a will analyze the performance of the MedBlock in detail.
breakthrough for the discovery of new techniques and thera- Finally, Section V concludes the paper and illustrates future
pies for curing diseases [8]. The Institute for Business Value at extensions.
IBM issued a whitepaper titled, BHealthcare rallies for
blockchains: Keeping patients at the center^ [9]. The survey
predicts that blockchain technology will be used to manage Related works
clinical trial records, supervised compliance and EHRs. The
Chinese government recently set up a blockchain industrial In this section, research trends about medical data sharing via
park in Hangzhou and hopes that more institutions and com- cloud service and blockchain technology are outlined.
panies can tap the value of blockchain technology in more Zyskind et al. proposed a blockchain usage for access con-
field. trol management and secure data storage [16]. In the paper,
Motivated by the above issues, a further research was made encrypted data is stored in trusted third party hosting services
on the sharing of medical information. When designing new and logging log of events on the blockchain. There is no
system to overcome these barriers, the patients’ needs are credible third party in the real world, which brings the risk
obliged to be placed in the first place. We must ensure that of data disclosure.
patients using the system can easily query their past medical Asaph Azariaet al. presented a blockchain-based data shar-
records even if they are stored in different hospitals’ database. ing system which was used as decentralized record manage-
Therefore, the blockchain would be very suitable for provid- ment system to handle EMRs. They provide miners with ac-
ing an appropriate solution for this problem through its attrac- cess to aggregate, and reward the data to bookkeepers [17].
tive features such as openness and verifiability. The However, the efficiency of data usage is not satisfactory. And
decentralized nature of the blockchain avoids performance it is illegal to gather patient data together and share them as
bottlenecks coming from frequent network requests and re- rewards.
sponses [10]. Recently, Xia et al. proposed a system to manage and pro-
Considering the disquiet of the hospitals themselves, hos- tect medical records effectively. The system is blockchain-
pitals have the right to store data in their original way instead based and provides data protection and management for
of uploading data to semi-trusted third parties. What they need shared medical data in cloud repositories among big data en-
to do is just upload the encrypted summary data and hash tities. They ensure data security through verifying their iden-
value to the blockchain so that users can retrieve and verify tities and cryptographic keys [18]. But the scheme does not
the data. When patients query the information on the take the concerns of the risk of data disclosure. That is, the
blockchain, the retrieval mechanism on the ledger can help hospital is reluctant to give the data to the third party, which
us quickly retrieve the location of encrypted information, makes the scheme untenable at the beginning.
which greatly improve the efficiency of the system [11, 12]. Esposito et al. [19] detailed the drawbacks of using cloud
The design employs a way to submit requests by turns and a storage technology to establish a data sharing system in the
hybrid consensus mechanism which can effectively avoid net- medical field. They also raised the possible challenges of
work congestion caused by data flood peak, and reach a con- using blockchain technology in medical data sharing (such
sensus with few resources to realize low-power green commu- as privacy protection). However, the article does not propose
nication. To assure the security and the privacy of medical practical schemes to address these challenges.
data, we need to develop an effective data encryption solution. Li et al. proposed a novel patient-centric framework and a
The asymmetric cryptography is adopted to encrypt these data suite of mechanisms for access control of data to PHRs stored
in this paper, which is efficient and low cost. If someone tries in semi-trusted servers. They leverage ABE techniques to en-
to read a record, he must know the corresponding decryption crypt each patient’s PHR file [20]. However, ABE has many
key. On condition that attackers don’t have decryption key, disadvantages. Once a user modifies his access polices, sys-
what they get is meaningless. In many fields, ring signature tem needs extra computational expenditures to execute
J Med Syst (2018) 42:136 Page 3 of 11 136

attribute revocation and encrypt data again. The non-tampered User layer
nature of the blockchain also makes CP-ABE-based access
control unable to be modified in ledger, so it is unsuitable The user layer consists of all the users who want to access data
for this scheme [21, 22]. To reduce the computational cost, from the system, such as patients. As the owner of informa-
Gu et al. [23] proposed a more efficient ABS scheme with the tion, patients are more concerned about the data privacy and
monotone predicates. Unfortunately, their general form cannot the convenience during information querying. When a patient
solve the problems caused by the modification of access pol- visits a hospital that can intervene in the system, he can get the
icies. Guo et al. [24] introduced an attribute-based signature summaries of the past medical records stored on the chain and
scheme with multiple authorities to guarantee the validity of find a detailed electronic medical record according to the sum-
EHRs encapsulated in blockchain. After treatment, all patient maries by his private key. Before leaving, he can use public
information including EHRs, consumption records, insurance key to encrypt the medical information generated by this visit
records, etc. is encapsulated in one block. Medical data, such and sign the data through his private key.
as imaging and treatment plans, however, can be large and
relational that requires searching. Ferdous et al. [25] presented Processing layer
DRAMS, a blockchain-based decentralized monitoring infra-
structure for a distributed access control system. The scheme The processing layer is composed of the servers and databases
provides a solution to data security, but it does not solve the of the hospital. Community hospitals generally do not have
problem of efficient sharing of data. the database to store detailed patient information. Their func-
In this paper, we propose a secure system based on tion is relatively simple, namely uploading the encrypted med-
blockchain to share electronic medical records among autho- ical information through system clients and helping the patient
rized users. The retrieval mechanism on the ledger allows the to query the summaries on the block. Before uploading the
users easily to get involved and actively find the information encrypted summaries to the superior hospital, the community
they want in an efficient way. We use a simple and effective hospital also needs to sign the data by its private key.
access control and encryption strategy to ensure the security Authorized community hospitals can also serve as consensus
and privacy of information with smaller delay and energy cost. nodes(orderers) in the system to increase the fault-tolerant
This mechanism ensures that the patients’ identity information capability of the system.
is not leaked out which achieves the same effect as the ring The various departments in the hospital assume the same
signature. tasks as community hospitals in the system. It is worth men-
tioning that EMRs are stored in the hospitals’ database, only
the summaries and the hash value of EMRs are encrypted and
The overview of medblock uploaded.
National hospitals bear the major task in the system. The
This section discusses the MedBlock model. Firstly, we intro- hospital needs to arrange the encrypted summaries of
duce the overall data flow and components of the system. Then, EMRs uploaded by the sub-area community hospitals and
the details of the blockchain are introduced. Finally, we show the various departments. After sorting the data, the hospital
the business rules, such as the access control protocols, consen- will pack sorted data into blocks and send a request to
sus mechanism, and the detailed format of the ledger. consensus nodes to add blocks. After reaching a consen-
sus, the committers will add the blocks to their own ledger.
System architecture In our framework, hospitals need to undertake the task of
sending requests and the tasks of consensus nodes.
The architecture of system is represented in Fig. 1. Hospitals can choose to maintain the ledger or not accord-
ing to their own respective realities because this is not a
Certificate authority task that must be undertaken. However, the consensus
tasks and initiating request tasks are borne by them, which
CA is both a system administrator and an authority manage- means that they should serve as orderers and endorsers.
ment agency. It will promptly remove malicious nodes from Links between each other are shown in Fig. 2.
the system to ensure the health of system. At the same time, it
is responsible for the generation, distribution and management Medblock
of digital certificate. The patients’ public-private key () is also
generated by the CA. In order to facilitate the state regulation Components
of the information on the block and medical research, the CA
may use the patients’ private key to decrypt the data on block The MedBlock consists of six modules: client, endorser, or-
in certain circumstances. derer, committer, database and ledger.
136 Page 4 of 11 J Med Syst (2018) 42:136

Fig. 1 The architecture of system

User layer Upload processing layer
pSeries

query

Download

Key distribution
Supervision

ledger

CA MedBlock

Database refers to the hospitals’ data storage method for the efficiency of the system and configure the number of
storing EMRs. It can be a database or cloud storage. When an different nodes as needed, which is very important for the
authorized user requests to access EMRs, the Database will scalability of the system. Clients exist in the various de-
provide the relevant data to the user. partments of hospitals to upload and download data.
We divide the tasks of nodes into four parts that each Endorsers are responsible for initiating the proposal.
node only takes a single task. In this way, we can increase Orderers are in charge of reaching consensus. Committers

Fig. 2 Schematic diagram of

tasks undertaken by different database committer ledger
hospitals

orderer

endorser orderer

client

Node tasks undertaken by

Other hospitals Community Hospital
national hospitals
J Med Syst (2018) 42:136 Page 5 of 11 136

committer ledger
are responsible for adding the data to ledger based on con-
sensus. Meanwhile, committers also need to be responsible
for the consistency of the ledger by broadcasting the hash Step6
client
value of the ledger to the whole network periodically.
Committers need to find out the problematic nodes to keep
the consistency of the whole network ledgers.
National hospitals need to undertake the tasks of all nodes,
while community hospitals can only become endorsers or op-
tional orderers. The complete process is as follows (shown as Step1 Step2
Fig. 3):
Step3
Step1: After collecting the users’ EMRs and organizing Step4
the summary M, the client encrypts it with the patients’ Step5
public key. And then the client uses the private key of the
patient and the private key of the department to sign the endorsor
for assuring the information is correct. Adding the hash
value of the EMRs to the top of, the client sends the to
endorser.
Step2: The endorser checks whether the signature of
orderer
the is complete. If completed, the endorser saves data
to the local cache and sends the receipt to the client. Fig. 3 The function of each node and the process of adding blocks
After this, the client continues to wait for the receipt of
the orderers.
Step3: The endorser sorts all the uploaded and packs
sorted into blocks according to the upload time. When endorser of the region, acting on behalf of them in a respon-
it is the endorser’ turn to become the primary, the sible position for verification and sending proposals. The se-
endorser would send proposals of adding blocks to lected node is granted a view ((Kpub; Kpri; Viewnum) to mark
orderers. the node so that the entire network receives the nodes’ infor-
Step4: Consensus nodes reach a consensus based on con- mation. If more than half of the nodes assume that the existing
sensus algorithm and send the consensus to committers. endorser is already crashed, they may re-initiate the election to
Step5: After collecting enough confirming receipts, the elect a new endorser. All endorsers will submit the proposal in
endorser sends the successfully uploaded information to turn according to a certain order. If we choose to submit med-
the client. ical data in real time, it is obvious that peaks and valleys of
Step6: The committer adds the blocks into the ledger data traffic may arise. After all, few people visit the hospital
according to the consensus result. from midnight to dawn. Compared to the system efficiency,
Step7: If the client has not received a confirmation receipt real-time data upload is not very important. When an endorser
for a long time, it could choose another endorser to initi- becomes the primary, MedBlock needs to select the consensus
ate the request again. nodes under the current primary. We use the beacon continu-
Step8: When all the blocks to be uploaded have been ously generate random numbers to determine which nodes can
confirmed, endorser will broadcast information to the be orderers. These orderers also need to recalculate when the
whole network, so that the next endorser will become primary node is changed. When the orderers receive the re-
the primary. quest, they will reach a consensus based on the Practical
Byzantine Fault Tolerance Algorithm.
The algorithm allows data to be uploaded in turn and
effectively avoids network congestion caused by patients
Consensus mechanism visiting the hospital in a centralized time. If a new joining
node wants to become an endorser or orderer, the node
In order to avoid excessive consumption of energy and cen- needs to be authenticated first, which ensures that most of
tralization of power, the mechanism of traditional Practical the nodes in the system are trustworthy. If most nodes of
Byzantine Fault Tolerance and Delegated Proof of Stake are the system are honest, the system can reach the correct
not suitable. We have developed an efficient hybrid-consensus consensus. Using the hybrid consensus mechanism, we
mechanism based on the actual situation. Like a board vote, can avoid unnecessary waste of resources and achieve
nodes within the same region vote to determine a node as the green communication.
136 Page 6 of 11 J Med Syst (2018) 42:136

Fig. 4 The Structure of

Block header
MedBlock
Version number:1.0.1 Timestamp:2017.10.10.18.48.51 Signature:XXXXX Access control policy:XX
Block hash:d44c035835f1c5e0668b7d186a2ff5b0dc2e3137ec3c50b12a34c47b7af51e44
Previous Block hash:7773a5eaad2e53acced09994005e57823fc7ea5d2f0e9a3a5550bb7923326712
Signature collection:XXX;XXXX;XXXX
Hidden
Event 1 Information
Signature:XXXXX;XX
Timestamp:2017.10.10.08.25.17 Sequence number:2017101008251707281793
Event hash:f54b0d3f911b33744549a1390e0e65010b8f22a52683d48bffc0ce9b60dcfccc
Breadcrumbse:XXXXX;XXXXX;XXXXXX;XXXXX Encrypted
Encrypted summary:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Information.

Event 2
Signature:XXXXX;XX
Timestamp:2017.10.10.08.25.25 Sequence number:2017101008252507281794
Event hash:7655ae385345c316659c407a8cc60c6362cf287a998c5fd7ec19a07874dd2b3c
Breadcrumbse:XXXXX Encrypted
Encrypted summary:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Information.

Ledger structure Signature: The digital signatures of patient and provider

to assure the source and authenticity of data.
We show the format of a block containing data in Fig. 4. Just Sequence number: This value is a unique index of data.
like the Bitcoin, our block is a Merkle Tree-based structure. Event hash: The SHA256 hash of the encrypted summa-
The first structure is block header. The items included in the ry. The integrity and authenticity of the encrypted infor-
header are as follows: mation can be verified by the hash value.
Version number Encrypted summary.

Signature: The digital signature of endorser to assure the Finally, we discuss the composition of the encrypted
source of the block. summary, which is also the most important part of the
Signature collection: Signatures of events on the block to ledger. The encrypted summary is made up of following
improve the efficiency of information retrieval. modules.
Access control protocol: A policy to filter illegal users. Diagnostic information is written in plaintext to reduce the
Block hash: The SHA256 hash of the current block. The size of data which contains disease description, examination
value is calculated by hashing all hash values of events to results and treatment plan.
ensure the immutability of the block. Pointer of record and the hash value of EMRs. This is a
record to find the true storage address of information and
Hashblock ←HashðHashevent1 þ Hashevent2 þ Hashevent3 þ …Þ ð1Þ ensure the EMRs not tampered.

Bread crumbs mechanism

Previous block hash: The hash value of previous block,
used to connect and verify. Bread crumbs mechanism is also an important part of the
Timestamp: Signifying the time that the block is legiti- ledger. However, the problem of how to efficiently find the
mate to add to the blockchain. The timestamp is added by encrypted information that users add to the ledgers needs to be
orderers. solved. By comparing the encrypted keywords, users can find
the information they are interested in, but it needs to retrieve
A block will contain multiple events which are inde- the entire ledger, which is inefficient. We can make a retrieval
pendent and have nothing with each other. We will in- directory for the users’ past EMRs by classifying the patients’
troduce the format of events including the following past encrypted summaries based on the departments of hospi-
sections. tal and recording the location of the data. Used to improve
index efficiency, Bread crumbs records the hash value of the
Timestamp: A timestamp of when the summary was re- patient-related blocks which are classified according to the
ceived by the endorser. hospital departments. If the patient has not visited some
J Med Syst (2018) 42:136 Page 7 of 11 136

departments, the relevant hash value record is null. After that,

the patient only needs to update the relevant hash value re-
cords, which brings great efficiency improvement for data
querying. When a user wants to look for some information
about a past EMR, he can quickly find the corresponding
block based on the crumbs. The bread crumbs record hash
values are in a tabular format. (Table 1).

Data downing

This section describes how to download and read information.

Openness of the ledger means everyone can supervise and
browse information. But they can obtain the signature collec-
tion and encrypted summary only if users can satisfy access
control protocol on the public blockchain ledger. Authorized
users can view the latest blocks related to them and use their
private key to decrypt the encrypted data. Users can quickly
query the information they want based on the bread crumbs
records and judge whether to view the EMR based on the
diagnostic information. According to the pointer of record,
patients can send a request to query the corresponding data-
base for his EMRs. (Fig.5) Performace analysis
Access control protocol In this section, we discuss the security and efficiency of the
system.
In addition to caring whether the system is easy to use,
users are also concerned about the privacy contained in Security analysis
the records. So the formulate suitable access control pro-
tocol is needed to avoid unauthorized users from getting If a user wants to access data successfully, he must meet the
sensitive information. access control protocol and decrypt the data. In our scenario,
The openness of the blockchain means that everyone we suppose that user never exposes his identity credential to
can view the content on the block. However, due to pri- others, and the key cannot be recovered by the adversary. We
vacy reasons, we will conceal the signatures collection in assume that A is a user, B is a ledger server, S is an authenti-
the title of the ledger, the bread crumbs, the signature of cation server and C is an adversary. K is defined as a public-
event and the encrypted summaries to unauthorized users. private key, E k −1 ðmÞ is defined as a signed message, E k a ðmÞ is
For unauthorized users, we only allow them to verify the a

a message encrypted by Ka. C(A) indicates that the C is dis-

hash value to ensure that the information has not been
guised as A to send a message.
tampered with.
Attack on security protocols.
We require visitors to provide their signature as the
mainly identification of their identity. The system tra-
verses the block until it finds the right block by compar-
ing the signature with signature collection on the ledger.
Table 1 Record of bread crumbs mechanism
Whether the user can see the encrypted content on the
block depends on the result of the comparison. After the Number Department Hash Value
user is authorized, the system allows the user to view the
hidden information. If the user wants to view the I Oncology Null
encrypted summary, they can use their private key to de- II Orthopaedics c3929c7ea117fe3cce028b7b87491a99c
ae014746c41d2b6436e1363490bbd25
crypt the data. Although, this access control protocol is
III Dentistry 239dd2fec70f90c8c84d235c9190a824
relatively simple, its security, efficiency and granularity b7fff731bb4c2ff2467187d9b36f2ae2
have met our needs. We can achieve the same effect of … … …
ring signature and zero knowledge proof.
136 Page 8 of 11 J Med Syst (2018) 42:136

ledeger database Table 3 Comparison between proposed system and other systems

SCHEME TAMPER ANONYMOUS PRIVACY ATTACK

PROOF RESISTANCE

MedRec Y N N Y
Medshare Y Y N Y
DACC Y N N Y
MedBlock Y Y Y Y

access control protocols access control protocols

C ðAÞ→S : A; C; N a ; ð7Þ

S→C ðAÞ : S; Ek −1
S
ðS; A; N a ; C; K c Þ; ð8Þ

C ðS Þ→A : S; EK −1
S
ðS; A; N a ; C; K c Þ; ð9Þ

client
Assuming that the public key of B is Kb, and the public key
Fig. 5 User access to data flow schematic
of the attacker C is Kc. And the attacker wants the user A to
believe that the public key of B is Kc, so that the binding attack
is implemented. However, the returned information contains
Situation 1:
C identity information, A will find that the target is in consis-
C→B : E ðK ð−1Þ Þ ðE K b ðN a ; C ÞÞ; ð2Þ tent and avoid binding attacks.
c
Situation 3:
If the adversary without identity credential tries to access
the ledger, he will not see the signature collection and A→C ðBÞ : E ðK ð−1Þ Þ ðE K b ðN a ; AÞÞ; ð10Þ
a
encrypted summary. It is no benefit to the adversary.
Situation 2:
C→B : E ðK ð−1Þ Þ ðE K b ðN a ; AÞÞ; ð11Þ
a

A→C ðBÞ : E ðK ð−1Þ Þ ðE K b ðN a ; AÞÞ; ð3Þ

a
B→C ðAÞ : E ðK ð−1Þ Þ E ðK a Þ ðM Þ ; ð12Þ
b
  0 
C ðAÞ→B : E ðK ð−1Þ Þ ðE K b ðN a ; AÞÞ; ð4Þ C ðBÞ→A : E ðK ð−1Þ Þ E ðK a Þ M ; ð13Þ
a
c

B→C ðAÞ : E ðK ð−1Þ Þ E ðK a Þ ðM Þ ; ð5Þ
b Even if the adversary wants to send false information to the
patient, it will be judged as false information due to the lack of
We allow adversaries to intercept messages sent by users authentication information of ledger server.
and perform replay attacks. And we assume that C can suc- Analyzing the overall security of the system, we can start
cessfully deceived B,which leads B to regard C as A. Also, with two parts.
they can query the information on the blockchain. But as a A is a user, B is a ledger server, K is defined as a public-
result, they can only get a piece of encrypted information private key, m is defined as a signed message.
without decryption method. Authentication stage:

A→C ðS Þ : A; B; N a ; ð6Þ B Received m1 SignedWith K a −1 ; x in m1 ; B IsTrustedOn K a

B CanProveðA Says xÞ
ð14Þ
Table 2 List of system resistance attack
Reception stage:
SCHEME IDENTITY REPLAY BINDING FORWARD
DISGUISE ATTACK ATTACK SECURITY A Receives m2 SignedWith K −1
b ; A CanProveðK Authenticates BÞ
A CanProveðB Says m2 Þ
MedBlock Y Y Y N
ð15Þ
J Med Syst (2018) 42:136 Page 9 of 11 136

A IsTrustedOnB; A CanProveðB Says m2 Þ; A CanProveðB IsTrustedOn m2 Þ

ð16Þ
A CanT rust m2

The conclusion is that the system can resist identity dis- block according to the records of bread crumbs. The original
guise, replay attack, binding attack and so on (Table 2). search method needs to traverse the data on the block until
finding the useful data. Although the bread crumbs will bring
Attack on blockchain additional amount of data, compared to the traditional way of
data retrieval, its efficiency increases too much. We compare
Blockchain is the core of acquiring data and ensures integrity our scheme with some new schemes such as MedRec [15] and
and reliability of information. It has tamper-proof and open Medshare [16]. With the number of access increases, MedRec
class verification features to ensure that the information on the uses less time. The results show that the efficiency of data
block cannot be tampered. Even if the adversary tampered retrieval is greatly improved (Table 4 and Fig. 6).
with some of the ledger information, it would be quickly When the number of users is small, the effective date of
corrected by the system. each user accounts for a relative high proportion of all data.
Adversary may try to submit a large number of requests to The original search method can also quickly find relevant
endorsers in order to cause network congestion. It’s similar to information. However, as the number of users’ increases, the
denial of service attacks. It’s pointless because endorser only advantages of MedBlock over the original methods become
handles requests from clients by checking the signature of the more and more obvious. The bread crumb records can directly
data. The cost is enormous but the effect is minimal. guide the users to find the corresponding blocks. Even if the
Nodes of the system may also be attacked, crashed or even proportion of valid information is low, it will not be a con-
become adversaries. Consensus mechanism and endorsers’ straint on efficiency.
election mechanism can ensure the stability of the system so When an endorser sends a proposal to add blocks to the
as to ensure that opponents will not cause great damage. system, we change the method from real-time upload to alter-
The access control mechanism on the ledger can realize the nate upload. The time that patients visit hospitals is relatively
anonymity of data and achieve the same effect of ring signa- concentrated. If an endorser chooses to upload the data in real
ture and zero knowledge proof. This is a very effective way to time, the system will bear significant high load, which may
protect the privacy of patients. cause data congestion. Avoiding this situation is helpful to
Table 3 below compares our MedBlock system to other improve the stability of the system. Through the comparison
existing systems. The result shows that proposed scheme is we can easily find the improvements of our scheme in this
outstanding in privacy and security. aspect (Table 5 and Fig. 7).
Uploading data asynchronously makes the system load
Efficiency analysis smoother and helps to avoid data congestion in the system.
The analysis and simulation results show that the scheme is
The efficiency of the system is mainly reflected by three effective to avoid significant high load that may cause data
aspects. congestion.
In our scheme, we adopt bread crumbs to enhance infor-
mation retrieval efficiency. If a user wants to retrieve some
specific information, he can directly find the corresponding

Table 4 Latency of
service provider requests NUMBER LATENCY(SEC)

MEDBLOCK MEDSHARE

5 83.4 53.4
10 122.51 145.26
15 146.78 178.24
20 188.75 226.78
30 304.51 351.36
40 374.73 447.94
50 459.31 553.81
100 925.12 1286.73
Fig. 6 Comparison of data delay
136 Page 10 of 11 J Med Syst (2018) 42:136

databases. Data sharing and collaboration via blockchain can

help hospitals get a prior understanding of patients’ medical
history before the consultation.
We propose an efficient privacy-preserving and sharing
scheme based on blockchain, which can guarantee users’ pri-
vacy contained in his data by utilizing the combination of
access control protocol and encryption technology. This meth-
od of uploading no data to a semi-trusted third party ensures
that other agencies cannot access the original medical data of
patients. The design which employs bread crumbs on the led-
ger can quickly retrieve the location of encrypted information
and improves the efficiency of system.

Fig. 7 Diagram of data flow in different periods Funding This study was funded by the National Key R&D Program of
China (No. 2017YFB0802300), the National Natural Science Foundation
of China (No. 61772403 and No. U1401251), Natural Science Basic
Compared with CP-ABE-based access control, our strategy Research Plan in Shaanxi Province of China (No. 2017JM6004), and
is more appropriate. We analyze the reasons as the following National 111 Program of China B16037 and B08038.
aspects: First, the overhead of revocation in ABE scheme is
too large to be ignored. In addition to the need to perform Compliance with Ethical Standards
cryptographic operations, all the ledgers need to be changed
when new patches need to be added. However, these problems Conflict of Interest Kai Fan declares that he has no conflict of interest.
in our strategy do not exist. Second, after the users get the Shangyang Wang declares that he has no conflict of interest. Yanhui Ren
declares that he has no conflict of interest. Hui Li declares that he has no
encrypted information, they only need one exponential oper-
conflict of interest. Yintang Yang declares that he has no conflict of
ation to decrypt ciphertext that doesn’t contain encrypted in- interest.
formation about attributes. It is a kind of efficiency improve-
ment for users to obtain information. Ethical approval This article does not contain any studies with human
participants or animals performed by any of the authors.

Conclusion
References
Leveraging blockchain technology, MedBlock successfully
resolved the problem of large-scale data management and 1. Perera, G., Holbrook, A., Lehana, T. et al., Views on health infor-
mation sharing using electronic medical records. Int. J. Med.
sharing in an EMR system. Patients can easily access the
Inform. 80, 2011. https://doi.org/10.1016/j.ijmedinf.2010.11.005.
EMRs of different hospitals through the MedBlock avoiding 2. Kish, L. J., and Topol, E. J., Unpatients– why patients should own
the previous medical data being segmented into different their medical data. Nat. Biotechnol. 33(9):921–924, 2015. https://
doi.org/10.1038/nbt.3340.
3. Wang, Y., Li, P.-F. et al., A shared decision-making system for
Table 5 Diagram of data
PERIODS DATA FLOW(GB/H)
diabetes medication choice. IEEE Journal of Biomedical and
flow in different periods
Health Informatics. 21(5):1280–1287, 2017. https://doi.org/10.
MEDBLOCK OTHERS
1109/JBHI.2016.2614991.
4. Lee, S. J., Larson, E. B., Dublin, S., Walker, R. L., Marcum, Z., and
00–02 2.478 0.041 Barnes, D. E., Electronic medical record (EMR) predictors of un-
diagnosed dementia. Alzheimer's and Dementia. 13(7):1040–1041,
02–04 2.122 0.021 2017. https://doi.org/10.1016/j.jalz.2017.06.1469.
04–06 2.045 0.017 5. Thilakanathan, D., Chen, S., Nepal, S., Calvo, R. A., Liu, D., and
06–08 2.045 0.022 Zic, J., Secure multiparty data sharing in the cloud using hardware-
08–10 2.145 4.545 based TPM devices. In: Proc. IEEE 7th Int. Conf. on Cloud
Comput. (CLOUD), pp. 224–231, 2014. https://doi.org/10.1109/
10–12 2.437 7.822 CLOUD.2014.39.
12–14 2.411 6.953 6. Khan, A. N., Kiah, M. L. M., Ali, M., Madani, S. A., Khan, A. U.
14–16 2.542 8.421 R., and Shamshirband, S., BSS: Block-based sharing scheme for
16–18 2.642 3.211 secure data storage services in mobile cloud environment. J. Super
Comput. 70(2):946–976, 2014. Springer US. https://doi.org/10.
18–20 2.423 0.978
1007/s11227-014-1269-8.
20–22 2.437 0.721 7. Jena, D., Mishra, B., et al. Securing Files in the Cloud. Presented at
22–24 2.425 0.245 2016 IEEE International Conference on, 2016. 10.1109/
J Med Syst (2018) 42:136 Page 11 of 11 136

CCEM.2016.016. Available: http://ieeexplore.ieee.org/document/ Conference on Open & Big Data. 2016. Available: http://
7819669/ ieeexplore.ieee.org/document/7573685/
8. O’Driscoll, A., Daugelaite, J., and Sleator, R. D., ‘Big data’, 18. Xia, Q., Sifah, E. B. et al., MeDShare: Trust-Less Medical Data
Hadoop and cloud computing in genomics. J. Biomed. Inform. Sharing via Blockchain. IEEE Access. 5, 2017. https://doi.org/10.
46(5):774–781, 2013. https://doi.org/10.1016/j.jbi.2013.07.001. 1109/ACCESS.2017.2730843.
9. The Economist Intelligence Unit of IBM Institute for Business 19. Esposito, C., Santis, A. D. et al., Blockchain: A panacea for
Value. Healthcare rallies for Blockchains: Keeping patients at the healthcare cloud-based data security and privacy? IEEE Cloud
center. Healthcare and Blockchain Executive Report. 2017. Computing. 5(1):31–37, 2018. https://doi.org/10.1109/MCC.
Available: http://www.ibm.biz/blockchainhealth. 2018.011791712.
10. Fan, K., Ren, Y., Wang, Y., Li, H., and Yang, Y., Blockchain-based 20. Li, M., Yu, S., Zheng, Y., Ren, K., and Lou, W., Scalable and secure
efficient privacy preserving and data sharing scheme of content- sharing of personal health records in cloud computing using
centric network in 5G. IET Commun. 12(5):527–532, 2018. attribute-based encryption. IEEE Transactions on Parallel &
https://doi.org/10.1049/iet-com.2017.0619. Distributed Systems 24(1):131–143, 2013. https://doi.org/10.
11. Shen, Z., Shu, J., and Xue, W., Keyword search with access control 1109/TPDS.2012.97.
over encrypted cloud data. IEEE Sensors J. 17(3):858–868, 2016. 21. Li, W.-M., Li, X.-L. et al., Flexible CP-ABE Based Access
https://doi.org/10.1109/JSEN.2016.2634018. Controlin in Hybrid Cloud System. J. Comput. Sci. Technol. 32,
12. Liu, Z., Li, T. et al., Verifiable searchable encryption with aggregate 2017. https://doi.org/10.1007/s11390-017-1776-1.
keys for data sharing system. Futur. Gener. Comput. Syst. 78:778–
22. Goyal, V., Pandey, O. et al., Attribute-based encryption for fine
788, 2017. https://doi.org/10.1016/j.future.2017.02.024.
grained access control of encrypted data. In: Proc. 13th ACM conf.
13. Kim, K., and Zhang, F., ID-based blind signature and ring signature
on Computer and communications security. pp. 89–98, 2006.
from pairings. International Conference on the Theory &
https://doi.org/10.1145/1180405.1180418.
Application., 2002. https://doi.org/10.1007/3-540-36178-2_33.
14. Salazar, J. L., Tornos, J. L., and Piles, J. J., Efficient ways of prime 23. Gu, K., Jia, W., Wang, G., and Wen, S., Efficient and secure
number generation for ring signatures. Information Security, IET. attribute-based signature for monotone predicates. Acta
10, 2016. https://doi.org/10.1049/iet-ifs.2014.0547. Informatica 54(5):521–541, 2017. Springer Berlin Heidelberg.
15. Hardjono, T., and Smith, N., Cloud-based commissioning of https://doi.org/10.1007/s00236-016-0270-5.
constrained devices using permissioned blockchains. In: Proc. 24. Guo, R., Shi, H., Zhao, Q., and Zheng, D., Secure attribute-based
2nd ACM Int. WorkshopIoT Privacy, Trust, Secur. (IoTPTS), pp. signature scheme with multiple authorities for Blockchain in elec-
29–36, 2016. 10.1145/2899007.2899012 tronic health records systems. IEEE, 2018. https://doi.org/10.1109/
16. Zyskind, G., Nathan, O., and Pentland, A., Decentralizing privacy: ACCESS.2018.2801266.
Using blockchain to protect personal data. Proceedings of IEEE 25. Ferdous, S., Margheri, A., Paci, F., and Sassone, V., Decentralized
Security and Privacy Workshops:180–184, 2015. https://doi.org/ runtime monitoring for access control systems in cloud federations.
10.1109/SPW.2015.27. Proc. IEEE Int. Conf. Distrib. Comput.:1–11, 2017. https://doi.org/
17. Lippman, A., Vieira, T., Ekblaw, A., Azaria, A., et al., MedRec: 10.1109/ICDCS.2017.178.
Using blockchain for medical data. Presented at International