2020 IEEE International Conference on Systems, Man, and Cybernetics (SMC)
October 11-14, 2020. Toronto, Canada
Design and Implementation of a Blockchain-Based E-
Health Consent Management Framework
Cornelius C. Agbo
Department of Electrical, Computer and Software Engineering
Ontario Tech University
Oshawa, Ontario, Canada
cornelius.agbo@ontariotechu.ca
Abstract—Transformation of data into knowledge is the
hallmark of modern medicine. As an evolving field of medicine, e-
Health involves the electronic processing of a patient’s personal,
medical and other health-related data to improve healthcare
delivery. Data captured from clinical interactions between
patients and their care providers, as well as health data collected
through medical sensors, provide a rich source of data, known as
patient medical records (PMRs), which can be processed in
various ways to enhance the delivery of healthcare services.
However, indiscriminate processing of PMRs could potentially
result in the violation of the security or privacy of patients. To
ensure that PMRs are not processed in ways that could be harmful
to the security or privacy of the patients, modern data protection
regulations, such as the European General Data Protection
Regulation (GDPR), requires healthcare service provides to obtain
the consent of a patient for any processing operation on their
PMRs. The mechanism by which a patient exercises their right to
control who can process their PMRs, when and for what purpose,
is referred to as consent management in e-Health. Existing health
information technology systems do not provide adequate support
for consent management; there is a lack of transparency and
auditability in the existing systems to monitor and ensure that
healthcare service providers comply to the relevant data
protection regulations in processing PMRs. The emerging
blockchain technology offers an opportunity to design an e-Health
consent management system that is compliant with modern data
protection regulations such as GDPR. In this paper, we present the
design and implementation of an e-Health consent management
framework, based on the state-of-the-art blockchain technologies,
for processing PMRs. Our analysis confirms that our system
satisfies the requirements for consent management in e-Health.
Keywords—blockchain, distributed ledger, health care, consent
management, patient medical records (PMRs), Hyperledger Fabric.
I. INTRODUCTION
In modern medicine, the e-Health data generated by medical
sensors and the historical medical records of a patient have great
potentials to be utilized for personalized treatments [1] and in
predictive analytics for early disease detection [2], [3]. To
realize these advantages, the e-Health data usually have to be
stored, shared, or processed by relevant healthcare stakeholders
and systems.
However, the collection, storage, dissemination, and
processing of patient medical records (PMRs) raise concerns of
potential data abuse. The PMRs are usually collected and stored
in the provider’s private database, outside the control of the
978-1-7281-8526-2/20/$31.00 ©2020 IEEE
Authorized licensed use limited to: TU Delft Library. Downloaded on April 26,2021 at 14:43:42 UTC from IEEE Xplore. Restrictions apply.
Qusay H. Mahmoud
Department of Electrical, Computer and Software Engineering
Ontario Tech University
Oshawa, Ontario, Canada
qusay.mahmoud@ontariotechu.ca
patient. This means that the data can be shared or manipulated
in ways that violate the patient’s privacy or personal choices. A
consequence of this is that patients and other stakeholders are
reluctant to embrace data-based healthcare delivery, afraid of
the consequences of potential data abuses, thereby inhibiting
the full realization of the advantages of e-Health.
To encourage the collection and processing of PMRs,
regulations are being put in place to ensure that PMRs are not
misused to the detriment of patients or other stakeholders. One
of such regulations is the European General Data Protection
Regulation (GDPR) [4]. The central idea conveyed by data
protection regulations is that the processing of personal data
must conform to the wishes of the data owner. In particular, a
patient’s consent would be required before any data processing
activity can be carried out on their PMRs.
Consent management in e-Health is the mechanism that
enforces the ability of the patient to control who can have access
to their data, for how long this access can be had, and in what
form the access can be had. This means that a patient should be
able to grant access to a provider or any organization to access
some or all of their PMRs and should also be able to revoke the
access permission at any time. Additionally, operations on the
PMRs should be transparent and auditable. In other words, the
patient should be able to see who can access their data at any
time and should also be able to check who has accessed their
data in the past.
Current health information technology (HIT) systems do not
support these consent management requirements. In the first
place, the PMRs are usually stored in a centralized database,
managed by the healthcare service provider, such that the
patient cannot have access to their own PMRs or control how
they are used [5]. This makes transparency in the processing of
the PMRs difficult, thus lowering the confidence of the
stakeholders in the system. Secondly, data exposure in the
existing infrastructure is supported in “all or nothing” mode,
which means that it is usually not feasible to share some data
and withhold others. This is harmful to privacy. Thirdly, there
is no mechanism in the current data management systems to
audit past transactions or determine who has had access to the
data, when and for how long. These limitations call for a new
design approach to data management in e-Health to reflect the
consent requirements.
812
 Recently, a distributed ledger technology, known as
blockchain [6], has emerged with the potential to address the
challenges of consent management in e-Health. Blockchain is
the underlying technology for the Bitcoin cryptocurrency [7],
but its use has extended beyond the cryptocurrency applications
to other use cases [8], [9]. Its core features of decentralization,
transparency, immutability, and auditability, derived from
cryptographic primitives, can be employed to design an
efficient consent management framework for the processing of
PMRs in e-Health. In general, research in this field is still at its
infancy and prototype implementations are lacking to support
some of the proposed frameworks. This paper contributes to
this research domain by proposing a new blockchain-based e-
Health consent management framework, with a prototype
implementation.
The remainder of this paper is organized as follows: in
section II, we briefly discuss the related work; in section III, we
present the design of the proposed blockchain-based e-Health
consent management framework; this is followed by the
implementation of the proposed framework in section IV;
section V discusses the results and some implementation
challenges; and section VI concludes the paper and offers ideas
for future work.
II. RELATED WORK
Considerations for the application of blockchain for consent
management in distributed data sharing applications is
relatively novel [15]. Even though some papers have identified
the potential of blockchain for general data management in
distributed applications [10]–[14], [16], the focus in the area of
e-Health has remained mostly on the use of blockchain for
creating immutable records of patients’ medical history, as
against actual consent management in the processing of PMRs.
In addition, some studies in this field are based on earlier
generation of blockchain technologies which have limited
features for developing e-Health applications. For example,
Azaria et al. [14] describe the use of Ethereum framework to
manage access control to patients’ medical histories. However,
the permissionless blockchain frameworks, like Ethereum, are
not ideal for developing e-Health data applications because of
heightened security risks, among other reasons [17]. Some
authors [10] describe the use of the permissioned, Hyperledger
Fabric framework, for consent management in e-Health
environment but they do not provide a detailed design or
implementation procedure. Similarly, Dias et al. [18] propose
the use of consortium blockchain for electronic health records
consent management and access control, but their design lacks
implementation details.
III. PROPOSED FRAMEWORK
In the traditional healthcare settings, the patient medical
records (PMRs) are saved in various providers’ private
databases, thus the storage and the processing of the PMR data
is not patient-centric. In this arrangement, the patient is not
aware of what happens to their data and cannot control how
their data are being accessed or processed.
813
Authorized licensed use limited to: TU Delft Library. Downloaded on April 26,2021 at 14:43:42 UTC from IEEE Xplore. Restrictions apply.
Fig. 1. How blockchain provides patient-centric data management in e-Health
An example of such an e-Health system that is not patient-
centric is illustrated in Fig. 1 (a), where a patient’s medical
records data have been collected and saved separately by two
different healthcare service providers, Provider A and Provider
B, in their respective private databases. The patient has no
control of these medical records and has no direct access to any
of the records. Thus, the medical records can be shared to a third
party without the patient finding out. Additionally, Provider A
would need to retrieve the PMR saved at Provider B’s database
in order build a complete medical history of the patient and
vice-versa. The two providers can attempt to communicate with
each other through a trusted third party (TTP), such as the
Regional Health Information Organization [19]. However, the
TTP has some limitations; for example, it may be compromised,
being a single point of failure. The TTP may also be too slow
which may adversely impact the healthcare delivery or the
service fees charged by the TTP may be too high. So, provider
B may decide to forgo the medical history and conduct series of
tests, which may have been conducted in the past at provider A,
thereby increasing the cost of healthcare services to the patient
and degrading the efficiency and timeliness of healthcare
service delivery.
It, therefore, follows that patient-centricity should be an
integral part of an e-Health system to support consent
management, improve efficiency of healthcare delivery and
reduce the cost of health care. With the introduction of
blockchain in Fig. 1 (b), the PMRs are no longer stored at the
individual provider’s private databases. Instead, the records are
directly saved to the blockchain network that is decentralized.
More importantly, the patient is central to the e-Health data
storage and has complete control of how their PMRs are
accessed. So, when the patient visits any of the providers, the
provider will request the patient’s consent to retrieve their
medical record. The patient can then decide to grant consent for
a partial or total access to their medical record as they please.
What is more, the patient can withdraw the provider’s access
permission at any time, placing the patient in total control of
their medical records.
Fig. 2 illustrates the proposed framework in more detail,
using generic notations. The patients are denoted as the data
owners, and the healthcare service providers and other entities
which may want to consume the patient’s data are denoted as
the data consumers. As shown in Fig. 2, the data owners, O1 –
On, which represent the patients in the case of e-Health, are
connected to a blockchain network. The blockchain network is
made up of several peer nodes. Each peer mode has a ledger
which is used to store an identical copy of the PMRs. The ledger
cannot be accessed directly by external applications; data is
written to, and read from, the blockchain ledger through a smart
contract. The smart contract is, therefore, the access-control
interface to the blockchain ledgers that hold identical copies of
the medical records as well as the access rights to the data.
Consequently, each peer node on the blockchain network
exposes a smart contract interface through which applications
can write to or read from its ledger by executing a transaction,
as shown in the diagram. The concept of smart contract will be
discussed in more detail in the following section. In this section,
it suffices to discuss the various stages of consent management
in the framework.
Fig. 2. Proposed framework
First of all, the data owners must have the ability to visualize
the state of their data, as depicted in step 0. In other words, the
data owners should be able to see, at all times, what data they
have, the access rights to the data and the previous transactions
(data processing operations) that have been performed on the
data. In step 1, the data owners can grant or revoke consent by
sending a transaction to the smart contract. In step 2, the consent
transaction, which stipulates the data access policies over a set
of data records (PMRs), is validated by the various peer nodes
in the network and recorded on their respective ledgers.
Validation is a consensus mechanism by which the various
nodes ensure that the transaction is originating from the
legitimate user and that the ordering of transactions is consistent
across different nodes.
After the PMRs and their access rights have been recorded
on the blockchain ledger in step 2, the data consumers, C1 – Cn
(i.e., the healthcare providers, medical insurers, etc., that collect
and process the PMR data), can request access to these data in
step 3. The data access requests are also sent as transactions
from the data consumers. In step 4, the smart contract retrieves
the recorded data access rights from the blockchain ledger to
verify if the requesting entity has the access rights to the data or
not. It is based on the recorded access rights in step 2, based off
the consent transactions in step 1, that every data access request
from the data consumers are evaluated and access permission is
granted or denied accordingly. If permission is granted, then the
data consumers can access the data in step 5.
814
Authorized licensed use limited to: TU Delft Library. Downloaded on April 26,2021 at 14:43:42 UTC from IEEE Xplore. Restrictions apply.
In a nutshell, this framework allows the data owners (i.e. the
patients in the case of e-Health) to control access to their
personal data. First, a smart contract developer writes a smart
contract program which is instantiated on the blockchain
network to control access rights to the data records. Then, each
of the data owners in the network, depicted as O1 - On, submits
their consent to the blockchain in the form of transactions.
These consent transactions are evaluated by the network nodes
to determine their authenticity. Once validated, the consents
defined in the transactions are recorded on the blockchain
ledger. Since the blockchain records are immutable, these
consents cannot be modified or altered, unless they are
overwritten by subsequent valid consent transactions. Once the
data records have been created and the consents of the data
owners, submitted as transactions, have been recorded on the
blockchain network, other network entities, such as healthcare
service providers, depicted as data consumers, C1 - Cn, can
request access to the data. The data access requests are also
submitted as transactions to the blockchain network. The
network nodes validate the transaction requests against the data
owners consent as recorded on their ledger. Only when the
consents grant the requested access permission will the
requesting entity be allowed access to the data.
The proposed framework has a number of improvements
over classical data management solutions. In the first place, the
personal data of individuals are not saved on an organization’s
private database; rather, the data is saved on distributed nodes
in the blockchain network where operations on a data record
have to be approved by decentralized actors, which must reach
consensus to validate a transaction. This overcomes the lack of
transparency and trust inherent in centralized systems. The state
of the data is transparent to the data owners since they can see,
at all times, which organizations have access to their data and
the level of access. Most importantly, the data owner is able to
grant or revoke access permissions to their data as they please.
Lastly, the data records are immutable since the ledger cannot
be falsified, and the replication of the data among multiple
nodes creates redundancy that helps to protect the data from
security attacks on availability, such as the ransomware attack
[20].
To demonstrate the usability of this framework, a prototype
implementation has been conducted, using the state-of-the-art
blockchain technologies and platforms, as discussed in the next
section.
IV. IMPLEMENTATION
We start the implementation of the proposed system by
reviewing the various state-of-the-art blockchain technologies
and platforms to identify the relevant and suitable technologies
and components for the implementation.
In selecting the appropriate blockchain technology for the
development of this prototype, we take into consideration the
different types of blockchain, viz; the public and the
permissioned blockchains. Bitcoin and other first generation
blockchain technologies are often referred to as public or
permissionless blockchain. This is because participants can join
the network freely without any authorization and can take part
in updating the ledger by solving the Proof of Work (PoW)
problem [7]. By contrast, the permissioned blockchain requires
participants to be known and authenticated before they can
participate in the network. Permissioned blockchain platforms,
such as Hyperledger Fabric [21], also support flexible
consensus mechanisms that do not require solving the
computationally intensive PoW problem. Since permissioned
blockchain offers improved security and privacy, with a more
flexible and less compute-intensive consensus protocols, we
choose the permissioned blockchain for the e-Health use-case.
In particular, we choose the Hyperledger Fabric (HF) [21],
which is a blockchain implementation developed by the Linux
Foundation as one of its Hyperledger projects. With IBM’s
contributions, Hyperledger Fabric is among the most advanced
blockchain platforms. HF is a completely permissioned
network that provides private channels to keep sensitive data
confidential. Hyperledger Fabric has been selected for this
project because when compared to other frameworks (e.g.
Ethereum [22]), Fabric possesses the more relevant features that
make it most suitable for developing healthcare applications
[17]. The state-of-the-art Hyperledger Fabric technologies and
other related technologies are put together to realize a prototype
implementation of the proposed framework.
Fig. 3. Interaction diagram showing the featured technologies, actors and
components
The interaction diagram showing the relationship between
the relevant components, technologies and the actors involved
in the implementation of the blockchain-based e-Health consent
management system is shown in Fig. 3. In what follows, we
present the detailed steps involved in the prototype
implementation and how the components of the interaction
diagram come into play.
A. Setting up the Development Environment
We start by creating a Kubernetes service; the IBM Cloud
Kubernetes service [23] allows us to create a cluster of available
containers to host our compute nodes that form the network.
The IBM blockchain platform, which currently implements
Hyperledger version 1.4, enables the creation of a Hyperledger
Fabric blockchain network onto an IBM Kubernetes service as
illustrated in the Fig. 3.
815
Authorized licensed use limited to: TU Delft Library. Downloaded on April 26,2021 at 14:43:42 UTC from IEEE Xplore. Restrictions apply.
B. Building the Network
The next step is to build and configure the blockchain network
on the deployed e-Health platform console. For the purpose of
this prototype implementation, we consider a simple network
configuration in which there are three participants: a patient,
providerA, and providerB. In Hyperledger Fabric, each
participant must be identified as belonging to a specific
organization. So, the three network participants are grouped
into their respective organizations: patient organization,
providerA organization, and providerB organization. These
three organizations come together to form a network which
allows them to exchange data among themselves according to a
set of rules. Thus, various nodes belonging to these
organizations are created to form the blockchain network as
shown in Fig. 4.
Fig. 4. The e-Health network
To simplify the diagram of Fig. 4, the nodes for the patient,
providerA, and providerB, are respectively represented as 1, 2
and 3; such that A1, A2 and A3 represent the client applications
for the patient, provider A and provider B, respectively.
Also shown in Fig. 4 are the Certificate Authorities, CAs.
The role of a certificate authority is to dispense X.509
certificates that are used to identify network components and
nodes as belonging to the various organizations. The certificates
issued by CAs are also used to sign transactions, indicating that
an organization endorses the transaction. Therefore, the CAs,
namely CA1, CA2 and CA3, are responsible for issuing
certificates that identify network components as belonging to
the patient, providerA, and providerB, respectively. The CA
provides the keys to the nodes and applications and enables us
to register the node, admin and application identities that are
required to deploy, operate, and interact with the network.
Using the patient’s certificate authority, CA1, we can create the
peer and client application identities, Peer1 and A1, and
similarly for provider A and provider B. Each of the network
components we create in the network must have an
administrator with an identity associated to the organization
that owns the network component.
Another network component visible in Fig. 4 is the Orderer.
The Orderer is the network node that runs the ordering service
(i.e., ordering transactions sequentially before they are
committed to the ledger). An administrator in an organization,
Org0, which obtains its identity from CA0 is responsible for
configuring the Orderer node. The configuration, depicted as
the network configuration, NC, contains the policies that define
the administrative privileges of the different components in the
network.
After creating the various network nodes and defining the
administrative rights over these network components, using the
certificates issued by the various CAs, the next step is to define
a consortium. A consortium is a unit in a blockchain network
that binds together organizations that share the need to transact
with one another. In this case, a new consortium, X, is created
as shown in Fig. 4, that contains three organizations, Org1,
Org2 and Org3, which respectively refer to the patient,
providerA and providerB.
Following the creation of the consortium, a channel, C, is
created to provide a private communication interface by which
members of the consortium can communicate. The channel
configuration, CC, contains the administrative and access
privileges for the channel. At this stage of the network
development, the channel can be used to connect various
organizational components of the network. We connect to the
channel the three peers, Peer1, Peer2, and Peer3, belonging to
the patient, providerA, and providerB, respectively. The peers
are the network components that host the blockchain ledger, L,
and smart contract, S, as shown in Fig. 4. Each organization that
joins a consortium must deploy at least one peer node. The
ledger, L is identically hosted physically on all the peers and
logically on the channel, C.
So, by following the above steps, the network is fully
deployed on the IBM blockchain cloud platform, as depicted in
the diagram of Fig. 4.
C. Application and Smart Contract Development
Following the diagram of Fig. 3, we now develop the smart
contract chaincode to be deployed on the blockchain platform.
We use the IBM blockchain platform extension for VS Code to
develop and package the smart contract. The smart contract
allows us to define functions which the network actors can
invoke to execute a transaction. For example, a patient can give
a consent to a provider to access their health record by invoking
the grantPermission() function which takes the patient ID and
the provider ID as arguments and then add the provider to the
patient’s list of authorized providers. To be able to retrieve a
patient’s record, the provider has to invoke another function,
queryPateintRecord(), which takes as arguments the providers
ID and the ID of the patient and then check if the provider is
included in the patient’s authorized list of providers.
After developing and packaging the contract with the VS
Code extension, we deploy it on the IBM blockchain platform,
as illustrated in Fig. 3. Deploying the smart contract on the
network involves two processes: first, we install the smart
contract on the patient peer node which we created earlier, then
we instantiate the contract on the channel.
Once the smart contract is deployed, the client applications
belonging to the patient or provider organization can interact
with the network and submit transactions through the Node.js
server. This process involves downloading the connection
816
Authorized licensed use limited to: TU Delft Library. Downloaded on April 26,2021 at 14:43:42 UTC from IEEE Xplore. Restrictions apply.
profile for the respective member organizations that make up
the network. The connection profile contains the relevant
configuration information about the identity and credentials of
the user for the particular application interface, which the
Node.js server uses to interact with the network.
V. DISCUSSION
To test our system, we execute some transactions using the
patient’s ID, in which we grant access permissions to providerA
and providerB over a set of PMRs belonging to the patient.
Then using the providers’ IDs, we confirm that both providers
can access the PMRs. Then using the patient’s ID, we revoke
the access rights of providerA by invoking the
revokePermission() function with the relevant arguments. We
try again to access the PMRs from providerA’s account but we
can confirm that providerA no longer has access to the data,
whereas providerB can still query and retrieve the patient’s
PMRs.
This confirms that our system meets the core objective of
achieving consent management in the processing of PMRs.
Importantly, access to data is patient-centric, meaning that the
patient has the ultimate control over who can access their data.
Since consent is decentralized and distributed across the various
blockchain nodes, it’s difficult to fool the system or carry out
any security attack. Security attacks on availability such as the
denial of service attack or the ransomware attack [20] are
difficult to execute in this system since the replication of the
ledger across various nodes creates resiliency and data
redundancy.
One important data privacy requirement defined in the
GDPR is the Right to be Forgotten, which mandates
organizations to completely erase the personal data of
individuals should the data owners so desire. Ordinarily, this is
a difficult requirement to implement in blockchain since the
blockchain data are immutable, but by storing the actual patient
data in the world state and only the transactions on the
blockchain, our system is able to satisfy this requirement, as
well.
In conducting this research, we encountered certain
technical challenges. First, we considered setting up our
blockchain network using Hyperledger Composer which has
been used in some previous work [24]. However, we found out
that Hyperledger Composer has become deprecated and that
blockchain version 1.4 which is more current is integrated in
the IBM Blockchain Platform.
Settling with the IBM blockchain platform was not without
its own challenges; as a relatively new development framework,
it was difficult to find support and to troubleshoot problems.
For example, at the time of conducting this research, the latest
version of the IBM extension for VS Code is version 1.41, but
this version gives an error that we could not troubleshoot. After
trying unsuccessfully to fix the error, we figured out we could
avoid the problem altogether by downgrading to version 1.39.
Similarly, we ran into problems with the IBM blockchain cloud
platform; for example, we occasionally could not create CAs.
We, however figured that by recreating the Kubernetes cluster
and redeploying the blockchain platform, these issues could be
overcome. There were also other minor technical challenges we
faced in the course of implementing the project, such as the
error resulting from not properly editing the connection profile
(config.json file). In general, there was a lot of overhead in
learning how to use the new frameworks and technologies and
in dealing with technical issues.
VI. CONCLUSION AND FUTURE WORK
The emerging regulations around the use of personal data of
individuals necessitate a new design approach for health
information technology (HIT) systems. Modern HIT systems
must be designed to manage the consent of the patients such
that their privacy and security are not violated. In this paper, we
have presented the design and implementation of a blockchain-
based consent management framework for processing PMRs in
e-Health. Our implementation demonstrates the maturity in
blockchain technology through the use of various state-of-the-
art blockchain platforms and components that allow us to
implement a prototype of the proposed system. Our analysis
shows that our system meets the requirements for consent
management in the processing of PMR data in e-Health.
An interesting direction for future work will be to evaluate
the performance of our proposed framework with respect to
throughput and latency.
REFERENCES
[1] Z. Shae and J. Tsai, “Transform Blockchain into Distributed Parallel
Computing Architecture for Precision Medicine,” IEEE 38th Int. Conf.
Distrib. Comput. Syst., pp. 1290–1299, 2018,
10.1109/ICDCS.2018.00129.
[2] C. C. Agbo, Q. H. Mahmoud, and J. Mikael Eklund, “A Scalable Patient
Monitoring System Using Apache Storm,” in 2018 IEEE Canadian
Conference on Electrical & Computer Engineering (CCECE), 2018, pp.
1–6, doi: 10.1109/CCECE.2018.8447696.
[3] C. C. Agbo, Q. H. Mahmoud, and J. M. Eklund, “An Architecture for
Cloud-Assisted Clinical Support System for Patient Monitoring and
Disease Detection In Mobile Environments,” in Proceedings of the 12th
EAI International Conference on Pervasive Computing Technologies for
Healthcare - PervasiveHealth ’18, 2018, pp. 245–250, doi:
10.1145/3240925.3240944.
[4] “General Data Protection Regulation (GDPR) – Official Legal Text.”
[Online]. Available: https://gdpr-info.eu/. [Accessed: 13-Mar-2020].
[5] M. A. Engelhardt, “Hitching Healthcare to the Chain: An Introduction to
Blockchain Technology in the Healthcare Sector,” Technol. Innov.
Manag. Rev., vol. 7, no. 10, pp. 22–34, Oct. 2017, doi:
10.22215/timreview/1111.
[6] C. C. Agbo, Q. H. Mahmoud, and J. M. Eklund, “Blockchain Technology
in Healthcare : A systematic Review,” Healthcare, 2019.
[7] S. Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System. 2008.
[8] C. Burniske, E. Vaughn, A. Cahana, and J. Shelton, “Blockchain
Technology Can Enhance Electronic Health Record Operability,” 2016.
[Online]. Available: https://ark-invest.com/research/blockchain-
technology-ehr. [Accessed: 15-Aug-2018].
[9] X. Huang, D. Ye, R. Yu, and L. Shu, “Securing parked vehicle assisted
fog computing with blockchain and optimal smart contract design,”
IEEE/CAA J. Autom. Sin., vol. 7, no. 2, pp. 426–441, Mar. 2020, doi:
10.1109/JAS.2020.1003039.
[10] Jp. Genestier et al., “Blockchain for Consent Management in the eHealth
Environment: A Nugget for Privacy and Security Challenges,” J Int Soc
Telemed eHealth, vol. 5, pp. 24–25, 2017.
[11] M. Benchoufi, R. Porcher, P. Ravaud, M. Benchoufi, R. Porcher, and P.
Ravaud, “Blockchain protocols in clinical trials: Transparency and
Authorized licensed use limited to: TU Delft Library. Downloaded on April 26,2021 at 14:43:42 UTC from IEEE Xplore. Restrictions apply.
traceability of consent,” F1000, pp. 1–66, 2018, doi:
10.12688/f1000research.10531.3.
[12] O. Choudhury et al., “Enforcing Human Subject Regulations using
Blockchain and Smart Contracts,” Blockchain Healthc. Today, vol. 1, no.
0, Mar. 2018, doi: 10.30953/bhty.v1.10.
[13] G. Zyskind, O. Nathan, and A. S. Pentland, “Decentralizing privacy:
Using blockchain to protect personal data,” in Proceedings - 2015 IEEE
Security and Privacy Workshops, SPW 2015, 2015, pp. 180–184, doi:
10.1109/SPW.2015.27.
[14] A. Azaria, A. Ekblaw, T. Vieira, and A. Lippman, “MedRec: Using
blockchain for medical data access and permission management,” Proc. -
2016 2nd Int. Conf. Open Big Data, OBD 2016, pp. 25–30, Aug. 2016,
doi: 10.1109/OBD.2016.11.
[15] E. Chukwu and L. Garg, “A systematic review of blockchain in
healthcare: Frameworks, prototypes, and implementations,” IEEE Access,
vol. 8, pp. 21196–21214, 2020, doi: 10.1109/ACCESS.2020.2969881.
[16] P. Zhang and M. Zhou, “Security and Trust in Blockchains: Architecture,
Key Technologies, and Open Issues,” IEEE Trans. Comput. Soc. Syst.,
vol. 7, no. 3, pp. 790–801, Jun. 2020, doi: 10.1109/TCSS.2020.2990103.
[17] C. C. Agbo and Q. H. Mahmoud, “Comparison of blockchain frameworks
for healthcare applications,” Internet Technol. Lett., p. e122, Aug. 2019,
doi: 10.1002/itl2.122.
[18] J. P. Dias, H. Sereno Ferreira, and Â. Martins, “A Blockchain-Based
Scheme for Access Control in e-Health Scenarios,” in Advances in
Intelligent Systems and Computing, 2020, vol. 942, pp. 238–247, doi:
10.1007/978-3-030-17065-3_24.
[19] J. Adler-Milstein, D. W. Bates, and A. K. Jha, “U.S. regional health
information organizations: Progress and challenges,” Health Aff., vol. 28,
no. 2, pp. 483–492, Mar. 2009, doi: 10.1377/hlthaff.28.2.483.
[20] J. McCarthy, Jack McCarthy, J. McCarthy, Jack McCarthy, and J.
McCarthy, “MedStar attack found to be ransomware, hackers demand
Bitcoin | Healthcare IT News,” Healthcare IT News, 2016. [Online].
Available: https://www.healthcareitnews.com/news/medstar-attack-
found-be-ransomware-hackers-demand-bitcoin. [Accessed: 27-Aug-
2018].
[21] E. Androulaki Artem Barger Vita Bortnikov et al., “Hyperledger Fabric:
doi: A Distributed Operating System for Permissioned Blockchains,”
EuroSys, vol. 18, 2018, doi: 10.1145/3190508.3190538.
[22] C. Saraf, “Blockchain Platforms : A Compendium,” 2018 IEEE Int. Conf.
Innov. Res. Dev., no. May, pp. 1–6, 2018.
[23] “Getting started with IBM Cloud Kubernetes Service.” [Online].
Available: https://cloud.ibm.com/docs/containers?topic=containers-
getting-started. [Accessed: 15-Mar-2020].
[24] N. Aldred, L. Baal, G. Broda, S. Trumble, and Q. H. Mahmoud, “Design
and Implementation of a Blockchain-based Consent Management
System.”
817