relsizeFont size

# Balancing Patient Privacy and Health Data Security: The Role of Compliance
in Protected Health Information (PHI) Sharing

Md Al Amin, Hemanth Tummala, Rushabh Shah, and Indrajit Ray  Computer Science
Department, Colorado State University, Fort Collins, Colorado, USA
{Alamin, Hemanth.Tummala, Rushabh.Shah2<EMAIL_ADDRESS>
###### Abstract

Protected Health Information (PHI) sharing significantly enhances patient care
quality and coordination, contributing to more accurate diagnoses, efficient
treatment plans, and a comprehensive understanding of patient history.
Compliance with strict privacy and security policies, such as those required
by laws like HIPAA, is critical to protect PHI. Blockchain technology, which
offers a decentralized and tamper-evident ledger system, hold promise in
policy compliance. This system ensures the authenticity and integrity of PHI
while facilitating patient consent management. In this work, we propose a
blockchain technology that integrates smart contracts to partially automate
consent-related processes and ensuring that PHI access and sharing follow
patient preferences and legal requirements.

###### Index Terms:

Consent, Patient Privacy, Data Security, PHI Sharing, Provenance, Compliance,
Blockchain, Smart Contract.

##  I Introduction

Electronic health record (EHR) systems have significantly improved healthcare
services, such as enhanced collaboration among healthcare professionals, more
accurate diagnoses, faster treatment, and convenient access to patient-
protected health information [1]. EHR systems greatly facilitate the access
and sharing of digitized healthcare information, allowing providers to easily
exchange sensitive medical data with other professionals. Data sharing is
essential for numerous aspects of patient care, including enhancing diagnosis
and treatment plans through consultations with specialists, leveraging
advanced technologies for more precise radiology and pathology analyses and
diagnosis, elevating the overall quality of patient care, and others [2].
Furthermore, there are instances where healthcare data is utilized for
research and marketing endeavors, provided specific requirements are fulfilled
[3]. Health records can be shared through the EHR system using health
information exchanges (HIE), specialized networks that rely on interoperable
systems to share electronic health information seamlessly and securely [4].
Providers also share PHI through email or other electronic mediums [5].
Regardless of the PHI sharing mechanism, ensuring health data security and
patient privacy is mandatory.

Acquiring patient consent for healthcare information sharing is paramount for
adhering to policy compliance, particularly concerning regulations like the
Health Insurance Portability and Accountability Act (HIPAA) in the U.S. and
the General Data Protection Regulation (GDPR) in the E.U [6]. These regulatory
frameworks emphasize protecting health information and upholding the patient’s
right to privacy. Patient consent is a cornerstone of these regulations,
ensuring individuals have control over their health data and its
dissemination. Under HIPAA, healthcare entities must obtain explicit consent
before sharing healthcare data for purposes beyond treatment, payment, or
healthcare operations. Similarly, GDPR enforces strict guidelines on data
consent, processing, and privacy, offering individuals the ’right to be
forgotten’ and the autonomy to decide how their data is used and shared. From
a policy compliance perspective, proper patient consent acquisition is a legal
requirement and a trust-building measure, reinforcing the patient-provider
relationship. It ensures transparency in data handling and builds patient
confidence, knowing their sensitive information is shared respectfully and
responsibly. As healthcare continues to integrate with various technologies,
upholding these consent protocols is crucial for maintaining the security and
privacy of patient data and adhering to global data protection standards.

Unauthorized health data access and disclosure are common events in healthcare
industries that increase security and privacy concerns. Table I shows the
number of compliance complaints received by the U.S. Department of Health and
Human Services (HHS) Office for Civil Rights (OCR) [7]. The primary reasons
for the complaints are (i) impermissible uses and disclosures of PHI, (ii)
lack of safeguards of PHI, (iii) lack of patient access to their PHI, (iv)
lack of administrative safeguards of electronic PHI, and (v) use or disclosure
of more than the minimum necessary PHI. These issues can be minimized by
enforcing patients’ consent for data access and sharing decisions and
employing proper data protection mechanisms like encryption and anonymity.
Consent lets patients control their healthcare journey, enabling them to make
choices that align with their best interests and well-being [8].

TABLE I: OCR HHS- Compliance Complaints. Year | Complains | Compliance Reviews | Technical Assistance | Total
---|---|---|---|---
2018 | 25089 | 438 | 7243 | 32770
2019 | 29853 | 338 | 9060 | 39251
2020 | 26530 | 566 | 5193 | 32289
2021 | 26420 | 573 | 4244 | 31237

Enhanced security and privacy technologies are essential for protecting
patient data from being compromised, misused, or disclosed. However,
substantial evidence indicates that the root of many unauthorized EHR access
and sharing lies in inadequate policy adoption, implementation, and
enforcement [9, 10]. Often, users are granted access privileges
inappropriately, whether intentionally or not. Policy compliance frequently
falls short, and access control measures are not rigorously monitored or
executed on time. A common oversight is the blanket assignment of identical
roles and privileges to all employees, neglecting the nuances of individual
patient-level policies. Moreover, auditing and monitoring practices are
typically reactive, triggered only by serious complaints or legal mandates,
rather than proactive and consistent. These policy specification and
enforcement flaws significantly impact informed consent policies, underscoring
the need for a more accurate and systematic approach to effectively protecting
patient healthcare data and preserving privacy.

It is essential to address the following concerns to guarantee compliance with
the applicable privacy and security policies, industry best practices, and
contractual obligations for sharing PHI: (i) Patient-level policies or
consents are often not properly or timely enforced in healthcare data sharing.
(ii) Patients lack assurance that consent for access or sharing purposes is
carried out strictly by designated users, and only if the stipulated
conditions are met are all other requests rejected. (iii) Data sharing over
email or other mediums is insecure due to the absence of encryption or the use
of inadequate and weak encryption algorithms and key sizes. (iv) The
centralized hospital system serves as a singular source of truth and a
potential single point of failure for managing audit trails. (v) The absence
of a verifiable, unaltered record for consent execution and sharing PHI
highlights the need for comprehensive consent provenance. (vi) Compliance
assessments and audits are not conducted accurately and timely to check
compliance status.

To address the aforementioned challenges and requirements, this paper proposes
a framework based on blockchain and smart contracts for managing and enforcing
informed consent when sharing PHI with entities outside the treatment team.
The approach ensures that PHI sharing occurs only when the sender has obtained
the necessary consent from the patient and the sharing aligns with specific,
predefined purposes. In addition to enforcing patient consent, this approach
integrates other relevant security policies and industry best practices to
ensure data protection. The HIPAA Security Rule mandates the requirements for
transmission security are outlined under 45 CFR § 164.312(e)(1) Technical
Safeguards [11]. However, the proposed approach does not directly guarantee
security mechanisms like encryption for data protection. Instead, it leverages
an honest broker who acts as a blind and secure entity to evaluate the
intended PHI and certify its status as required protection mechanisms are
satisfied or not [12]. The broker’s attestation is then recorded in
blockchain-based audit trails with other relevant activity data to support
future compliance evaluations and validation. It supports using audit trails
or provenance mechanisms based on blockchain, which is essential for keeping
track of PHI-sharing activities. Moreover, the proposed framework provides a
compliance-checking mechanism in data-sharing activities, ensuring adherence
to applicable policies.

Smart contracts, [13], offer an automated, transparent system that upholds the
integrity and accountability of the consent for sharing PHI. Through this
smart contract-based approach, the proposed framework not only automates
processes but also guarantees the accurate execution of informed consent,
thereby enhancing the security and reliability of PHI sharing. Blockchain
technology ensures the immutability of submitted records, safeguarding the
integrity of the audit trail and enabling the detection of any unauthorized
alterations. Blockchain security features, including non-repudiation, ensure
that participants cannot deny their actions [14].

This work is the first to capture patients’ informed consent for PHI sharing
to ensure policy compliance through preserving provenance and conducting
compliance checking. It also considers and enforces other applicable security
policies and industry best practices mandated by the various laws,
regulations, standards, and contractual obligations to meet the compliance
requirements. Significant contributions include (i) implementing a mechanism
to capture patients’ consent for sharing healthcare data beyond the treatment
team members. (ii) Storing obtained consents in decentralized and distributed
networks (blockchain) to overcome a single point of truth sources and failure.
(iii) Considering applicable security and privacy policies, regulatory
requirements, and contractual obligations to ensure compliance-based sharing.
(iv) Enforcing informed consent and applicable policies while making
authorization decisions to share health records. (v) Equipping blockchain-
based audit trail mechanisms to guarantee data provenance. (vi) Incorporating
compliance assessment methods to identify compliance and non-compliance PHI
sharing. (vii) Offering consent services to provide precise and comprehensive
insights into the consent granted and the extent of its execution.

The remainder of the paper is organized as follows: Section II discusses some
works that are related to this work. The proposed approach is explained in
Section III with the necessary components. Section IV gives the structure of
audit trails and consent provenance. The compliance verification mechanism is
explained in Section V. Section VI discusses essential services for given
executed consents. The experimental evaluations of the proposed approach are
provided in Section VII for PPA integrity storage, patient contracts
deployment, consent storage cost, and writing and reading time. Section VIII
concludes the paper with future research directions on consent management.

##  II Related Work

Blockchain technology has increasingly been adopted in healthcare for various
services, particularly for sharing protected health information among
healthcare providers, patients, and other stakeholders. Blockchain facilitates
a more efficient, transparent, and patient-centered delivery of healthcare
services, making it an essential component in modern healthcare
infrastructure. Fan et al., [15], proposed a blockchain-based secure system,
MedBlock, to share electronic medical records among authorized users. It
provides security and privacy with access control protocols and encryption
technology while sharing patient healthcare data.

Shah et al., [16], proposed a medical data management framework to facilitate
data sharing. It gives patients full control over access to their medical
data. It also ensures that patients know who can access their data and how it
is used. Zhuang et al., [17], addressed a blockchain-based patient-centric
health information-sharing mechanism protecting data security and privacy,
ensuring data provenance, and providing patients full control over their
health data. However, consent structure and compliance requirements are not
addressed, which are very important to give patients confidence in how their
consent is executed and how data is protected.

Alhajri et al., [18], explored the criticality of implementing legal
frameworks to safeguard privacy within fitness apps. By examining how various
fitness apps handle consent and privacy policies, their research highlighted
the crucial role of consent as outlined in the GDPR. The authors proposed the
adoption of blockchain technology as a means to govern user consent for
sharing, collecting, and processing fitness data, ensuring a process centered
around human needs and compliant with legal standards. Nonetheless, the study
failed to present a technical architecture for their blockchain-based
proposal.

Amofa et al. approached a blockchain-based personal health data sharing
framework with an underlying mechanism to monitor and enforce acceptable use
policies attached to patient data [19]. Generated policies are consulted with
smart contracts to make decisions on when the intended data can be shared or
otherwise. All entities cooperate to protect patient health records from
unauthorized access and computations. Balistri et al., [20], designed the
BlockHealth solution for sharing health data with tamper-proofing and
protection guarantees. They store the patient’s healthcare data in a private
database, and the hash of the healthcare data is stored in the blockchain to
ensure data integrity. Shen et al., [21], proposed MedChain, a blockchain-
based health data sharing approach where data streams are continuously
generated from sensors and other monitoring devices from various patients’
bodies. The collected data are shared with laboratories and health
organizations for diagnosis, advanced treatment, and further research.

The above-mentioned papers summarized the application and benefits of using
blockchain for healthcare data sharing and essential services. However, they
failed to address the security and privacy requirements mandated by various
laws and regulatory agencies, such as HIPAA and GDPR. The major requirements
demand patient consent and proper protection, such as encryption, while
sharing health records. In addition, it is crucial to maintain audit logs and
check that those activities did not violate any policies. This paper proposes
sharing informed consent as the smart contract for authorization with
provenance and compliance-checking mechanisms.

##  III Proposed Approach

The main objective is to ensure compliance with applicable security and
privacy policy for PHI sharing. To ensure compliance, we need proper policy
enforcement, including maintaining provenance and performing compliance status
checks promptly and properly. For enforcement, this paper considers patient-
informed consent, where the sender has permission from the patient to share
the intended PHI with the receiver for specific purposes. Also, proper data
protection mechanisms are considered. However, instead of ensuring data
protection directly, this work leverages an honest broker to verify and
certify the data protection mechanism. PHI-sharing activities are recorded as
audit trails to provide provenance and reconstruct events in a manner that
reflects their actual occurrence. A private blockchain-based approach is
proposed (Section IV). Finally, a blockchain consensus mechanism called Proof
of Compliance (PoC) is approached, Section V, for performing auditing. This
audit rigorously examines the enforcement actions against the policy standards
and informed consent, using the provenance data to verify and certify the
policy’s compliance status while sharing health records. The seamless
connection between policy enforcement, provenance, and the auditing process
forms the backbone of a secure and compliant system.

###  III-A Patient-Provider Agreement (PPA)

The patient-provider agreement, or PPA, aims to determine who is responsible
for what in treatment. A PPA is formed when a patient visits a hospital and is
properly documented to deliver healthcare services. It differs from
organization to organization. Healthcare organizations adjust what they need
from patients and what they expect from them to match those needs, treatments,
and responsibilities. This is done based on the nature and needs of treatment
and services. Also, the components and representation of the PPA depend on the
hospital or clinic. Figure 1 shows the structure of a PPA, and Algorithm 1
illustrates the gradual processes for creating a PPA with the required
components. The main concept of PPA is adopted from [22]. The authors focused
on consent management for medical treatment and diagnosis purposes, mainly for
the treatment team members. They did not include patient consent and other
requirements for health data sharing beyond the treatment team. This paper
extends the PPA structure to analyze the requirements and formalize the
consent components for PHI sharing. A PPA is formally composed of five tuples:

$PPA=(PC,PrC,TIC,SIC,ROC)$

satisfying the following requirements:

  * (A)

$PC$ is a finite set of patient components containing the patient’s personal
information, contact information, mailing information, pharmacy information,
billing and insurance information, emergency contact, and others. The patient
is responsible for providing and maintaining these components’ valid,
accurate, and updated information.

  * (B)

$PrC$ is a finite set of provider components, including the treatment team,
prescription, and others. The provider is responsible for creating an
effective team to provide appropriate care. Everything from treatment to
insurance coverage and billing is considered during the patient treatment
period.

  * (C)

$TIC$ is a finite set of treatment informed consent components. It denotes
that the patient has permitted the designated treatment team to access medical
records. Treatment team members include doctors, nurses, support staff, lab
technicians, billing officers, emergency contact persons, and others assigned
by the authority. Some outsider members are insurance agents,
pharmacists/pharmacy technicians, doctors/lab technicians from another
hospital, etc.

  * (D)

$SIC$ is a finite set of sharing informed consent components. It denotes the
patient’s consent to sharing medical data for a specific purpose. Both the
sender and the receiver must have consent. The primary purpose of this work is
$SIC$, including (i) identifying, capturing, and storing consent components,
(ii) enforcing consents with other applicable security policies and industry
best practices to ensure policy compliance while making PHI-sharing decisions,
(iii) defining and capturing provenance information with the enforced consents
to maintain audit trails, (iv) performing compliance checking using consensus
mechanisms; (v) providing services for both given and executed consents, etc.
It does not consider other components: $PC$, $PrC$, $TIC$, and $ROC$.

  * (E)

$ROC$ is a finite set of regulatory and other components. It has applicable
security and privacy policies to comply with the requirements of local
government, state government, federal government, foreign government, and
regulatory agencies (HIPAA, GDPR) if necessary. It also includes contractual
obligations in some cases.

Figure 1: Patient-Provider Agreement (PPA) Components.

1

Input : (i) $PC$, (ii) $PrC$, (iii) $TIC$, (iv) $SIC$, (v) $ROC$, (vi)
$\mathbb{R}_{PPA}$, (vii) $\mathbb{BN}_{SC}$

2

3 /* $\mathbb{R}_{PPA}$: secured PPA repository, $BN_{SC}$: blockchain network
smart contract */

Result : A formal $PPA$

4

5Input Parameters Initialization
$PPA_{i}\leftarrow\\{PC_{i},PrC_{i},TIC_{i},SIC_{i},ROC_{i}\\}$ where $i$ is
patient identity (i)
$PC\leftarrow\\{PC_{1},PC_{2},PC_{3},PC_{4},PC_{5},PC_{6}......................PC_{M}\\}$

6 (ii)
$PrC\leftarrow\\{PrC_{1},PrC_{2},PrC_{3},PrC_{4},PrC_{5},PrC_{6}..........PrC_{N}\\}$

7 (iii)
$TIC\leftarrow\\{TIC_{1},TIC_{2},TIC_{3},TIC_{4},TIC_{5},TIC_{6}........TIC_{T}\\}$

8 (iv)
$SIC\leftarrow\\{SIC_{1},SIC_{2},SIC_{3},SIC_{4},SIC_{5},SIC_{6}..............SIC_{S}\\}$

9 (v)
$ROC\leftarrow\\{ROC_{1},ROC_{2},ROC_{3},ROC_{4},ROC_{5},ROC_{6}...ROC_{R}\\}$

10

11PPA Components Integrity Calculation

12 /* $\mathbb{H}(\partial)$ calculates hash of $\partial$ */

13 (a)
$\mathbb{H}_{PC}\leftarrow\mathbb{H}(PC_{1},PC_{2},PC_{3},PC_{4},PC_{5},PC_{6}....................PC_{M})$

14 (b)
$\mathbb{H}_{PrC}\leftarrow\mathbb{H}(PrC_{1},PrC_{2},PrC_{3},PrC_{4},PrC_{5},PrC_{6}.........PrC_{N})$

15 (c)
$\mathbb{H}_{TIC}\leftarrow\mathbb{H}(TIC_{1},TIC_{2},TIC_{3},TIC_{4},TIC_{5},TIC_{6}........TIC_{T})$

16 (d)
$\mathbb{H}_{SIC}\leftarrow\mathbb{H}(SIC_{1},SIC_{2},SIC_{3},SIC_{4},SIC_{5},SIC_{6}.............SIC_{S})$

17 (e)
$\mathbb{H}_{ROC}\leftarrow\mathbb{H}(ROC_{1},ROC_{2},ROC_{3},ROC_{4},ROC_{5},ROC_{6}..ROC_{R})$

18 (f)
$\mathbb{H}_{PPA_{i}}\leftarrow\mathbb{H}(\mathbb{H}_{PC},\mathbb{H}_{PrC},\mathbb{H}_{TIC},\mathbb{H}_{SIC},\mathbb{H}_{ROC})$

19

20PPA Finalization if  _$PPA_{i}$ is complete_ then

21

22 /* presence of $PC$, $PrC$, $TIC$, $SIC$, $ROC$ */

23 if  _$(\mathbb{R}_{PPA}+PPA_{i})$ contains no conflicts_ then

24 (i) do $\mathbb{R}_{PPA}\leftarrow(\mathbb{R}_{PPA}+PPA_{i})$

25 (ii) add $\mathbb{ID}_{PPA_{i}}$ to patient profile, $\mathbb{P}_{i}$

26 (iii) call $\mathbb{BN}_{SC}(\mathbb{ID}_{PPA_{i}},\mathbb{H}_{PPA_{i}})$

27

28 /* PPA integrity verification reference */

29

30 Return:  Success ($PPA_{i}$ added to $\mathbb{R}_{PPA}$)

31

32 else

33 Error:  $(\mathbb{R}_{PPA}+PPA_{i})$ contains conflicts

34

35 /* $PPA_{i}$ revision required to add */

36

37 end if

38

39else

40 Error: $PPA_{i}$ cannot be created (incomplete PPA)

41

42 end if

Algorithm 1 Patient-Provider Agreement (PPA) Formation.

###  III-B Sharing Informed Consent (SIC)

Before approving, patients need to know clearly about the sharing informed
consent, particularly who can share which PHI with whom for what purposes—and
also the protection mechanism while sharing PHI during transmission over the
network. Figure 2 shows the SIC conceptual framework structure. Sharing
informed consent is formally composed of four tuples:

$SIC=(S,R,PHI,P)$

satisfying the following requirements:

  * (a)

$S$ is a finite set of authorized senders denoted as
$\\{S_{1},S_{2},S_{3},......S_{s}\\}$ for $s$ number of senders. The sender
can share certain healthcare data with the receiver, who has permission from
the patient. The sender may be a member of the patient treatment team or
anyone from the provider.

  * (b)

$R$ is a finite set of authorized users who receive protected health
information from authorized senders. A finite set of $r$ number authorized
receivers denoted as $\\{R_{1},R_{2},R_{3},......R_{r}\\}$. The receiver may
be from other hospitals, labs, medical research institutes, pharmaceutical
companies, marketing departments, government officials, etc.

  * (c)

$PHI$ is a finite set, $d$ number, of health data denoted by
$\\{PHI_{1},PHI_{2},PHI_{3},......PHI_{d}\\}$. It is an electronic version of
a patient’s medical data that healthcare providers keep over time. They are
protected health information and contain sensitive patient information. PHI
must be protected from any kind of unauthorized access, disclosure, and
sharing. Table II shows ten (10) types of PHI, considered for each patient,
with PHI ID, name, description, and potential creators.

  * (d)

$P$ is a finite set of purposes. It indicates the objective of the PHI sharing
by the senders with the receivers. Receivers must use the received PHI for the
intended purposes. A finite set of purposes, a $p$ number, can be denoted as
$\\{P_{1},P_{2},P_{3},......P_{p}\\}$.

Figure 2: Sharing Informed Consent (SIC) Structure. TABLE II: Sample Patient Protected Health Information (PHI) Structure. PHI ID | PHI Name | PHI Description | PHI Creator
---|---|---|---
PHI-1001 | Demographic Information | Basic personal information like name, date of birth, gender, contact | Patient, Support Staff
PHI-1002 | Previous Medical History | Old medical records from another hospitals and providers | Patient, Support Staff
PHI-1003 | Immunizations, Vaccinations | Immunization records that are administered over time | Patient, Pathology Lab Technician
PHI-1004 | Allergies | Various allergies sources, triggering condition, remediation | Patient, Support Staff, Path Lab Tech
PHI-1005 | Visit Notes | Physiological data, advises, follow-up, visit details | Doctor, Nurse
PHI-1006 | Medications, Prescription | Pharmacy information, prescribed medications like name, dosage | Doctor
PHI-1007 | Pathology Lab Works | Biological samples analysis like blood, tissue, other substances | Pathology Lab Technician
PHI-1008 | Radiology Lab Works | Imaging results such as X-rays, CT, MRI, Ultrasound, PET scans | Radiology Lab Technician
PHI-1009 | Billing, Insurance | Bank account, credit/debit card, and insurance policy information | Patient, Support Staff, Billing Officer
PHI-1010 | Payer Transactions | Bills of doctor visit, lab works, and medications | Billing Officers, Insurance Agent

The objective of sharing protected health information outlines the specific
reasons for its sharing. The recipient must utilize the shared PHI exclusively
for its designated purpose. The potential reasons for sharing PHI in this
study include, but are not limited to:

  * (i)

Treatment: Providers or patients need to share PHI with other providers from
external hospitals to provide better treatment. Also, patients must move to
different regions, like states or countries, due to family movement, job
transfers, or new jobs. Patients need to share or transfer healthcare data
from the previous providers to the current.

  * (ii)

Diagnosis: Present providers sometimes need more skilled human resources,
appropriate machinery, instruments, or sophisticated technology to diagnose
disease. But it is urgently required to do that to give proper treatment and
services to save patients’ lives or minimize damages. Patients’ health data
must be transferred or shared with other providers or labs to complete
diagnosis and make proper treatment plans for the patients.

  * (iii)

Marketing: Healthcare data sharing for marketing purposes involves using
patient data to promote healthcare services, products, or initiatives. This
can help healthcare providers tailor their services to patient needs, inform
patients about new treatments or products, and improve patient engagement.
Only the receiver entity can use the shared data as intended and should not
share it with other associates for extended business purposes.

  * (iv)

Research: Sharing PHI for medical research purposes holds significant
potential for advancing medical knowledge, leading to breakthroughs in
understanding diseases, improving and developing new treatments, improving
healthcare systems and services, and enhancing patient outcomes. Patients’
privacy and rights must be respected.

Other purposes might exist depending on the nature and requirements of the
treatment, patient conditions, provider business policy, etc. This study
considers only the four purposes mentioned above. After receiving shared data,
the receiver performs specified operations to complete the job. It is assumed
that the receiver cannot share data with other users who do not have
permission from the patients. More specifically, the receiver’s healthcare
system does not allow the sharing of PHI by any means, like printouts, email,
or screenshots. However, this paper doesn’t provide detailed mechanisms or
techniques for preventing data sharing without patients’ consent at the
receiver end.

###  III-C SIC Smart Contract Deployment

Once a Patient-Provider Agreement, or PPA, is created and stored in the
repository, all sharing informed consent components are deployed to the
blockchain network. For each patient, there is one smart contract that
contains all consents for that particular patient. If there isn’t a smart
contract, the authority deploys one, transfers ownership to the patient, and
updates the contract address to the patient’s profile and hospital systems.
The contract address is an identifier for a smart contract in the blockchain
network. This smart contract-based approach provides an automated system and
guarantees the integrity and accountability of the deployed consents. Once
consents are deployed or added to the smart contract, they cannot be altered.
The authorization module needs to access these smart contracts to make
decisions considering the sender, receiver, purpose attributes, environmental
factors, organizational policies, regulatory frameworks, etc.

Upon finalizing the PPA, it transforms and secures storage in a PPA
repository. Subsequently, an integrity marker, such as a hash
($\mathbb{H}_{PPA_{i}}$) generated by the Algorithm 1, is stored on the
blockchain alongside the PPA ID for later modification detection. These are
depicted in Steps 2 and 3 in Figure 3. The Smart Contract Deployment Unit
(SCDU) then gathers all components of the informed consent from the PPA (Step
4). It verifies their integrity to ensure no deliberate or accidental
alterations have occurred (Step 5). As a secure entity, the SCDU does not
alter consent components, noting that any modification invalidates the
consent. If the consents remain unmodified, the SCDU creates and deploys the
corresponding smart contracts on the blockchain network (Step 6) and then
updates the patient’s profile and the hospital system (Step 7). Users can make
queries with the required credentials regarding informed consent and get
responses in Step 8 from the blockchain network.

Figure 3: SIC Smart Contract Deployment Process.

###  III-D Honest Broker, Applicable Policies and Industry Best Practices

Alongside patient consent, the proposed approach incorporates relevant
security policies and industry best practices before sharing protected health
information. For instance, a security policy might require a data protection
mechanism during data transfer between systems. For treatment and diagnosis
purposes, encryption is a recommended protection method.

As an industry best practice, the Advanced Encryption Standard (AES) is
preferred over the Data Encryption Standard (DES). Furthermore, it advises
using a robust, lengthy encryption key (256 bits) rather than a weaker,
shorter one (64 or 128 bits). The sender must encrypt the intended PHI using
the AES-256 algorithm while leaving it in the system for treatment and
diagnosis. However, this proposed approach does not encrypt the healthcare
data directly or ensure a strong key size while encrypting the intended
healthcare data. Also, it does not address the key management mechanisms such
as creation, storage, sharing, updating, deleting, etc. It is assumed that the
key management is done securely and separately.

Similarly, anonymity is a recommended protection method for marketing and
research purposes, where patient identifiers must be removed before sharing.
The targeted PHI must be anonymous using proper techniques and tools before
sending the data from the host healthcare system to the receiver. The host
system indicates where patients’ PHI is created or presently stored.
Healthcare organizations deploy appropriate encryption and anonymity
mechanisms. This study does not directly ensure PHI encryption and anonymity.
Instead, this approach leverages an honest broker, a trusted entity that
evaluates the encryption algorithm, key size, and data anonymity status [12].
After checking, the honest broker certifies or attests to the status, which is
recorded in audit trails as proof for policy compliance verification, along
with other components like sharing informed consents, timestamps, etc.

Depending on the specific policies and practices of the healthcare
organization, this broker could be either a human or a non-human (automated)
entity. The honest broker’s role is confined; it does not share healthcare
data with other entities. It also does not analyze data to gain insights about
the patient or share those insights. Effectively, it functions as a ’blind’
entity, ensuring encryption standards and the anonymity status of the PHI
without engaging with the actual data content.

###  III-E PHI Sharing Authorization Process

Figure 4: Compliance-Based PHI Sharing Authorization Process.

Consent enforcement ensures that related consents are executed while making
decisions for the PHI sharing requests. All consents are stored on the public
blockchain network as smart contracts and cannot be enforced until they are
called. The authorization module (AM) considers sharing informed consent with
applicable policy and required attributes while making decisions. The
attributes may be subject, object, operation, and environmental attributes.
The sender must provide the necessary credentials for identification and
authentication. Figure 4 shows the informed consent enforcement for PHI-
sharing authorization.

A sender submits a data sharing request to the PHI sharing unit in Step 1.
Sharing unit forwards request to authorization module for decision in Step 2.
It also requests that the PHI storage unit send the intended PHI to the
protection mechanism unit in Steps 2a and 2b. The honest broker receives
encrypted or anonymized data in Step 3. After analyzing, it sends a report to
AM in Step 4. The AM queries the blockchain network through the corresponding
smart contract to get sharing informed consent information for the sharing
request in Step 3a and 4a. It also makes queries for requests related to
applicable policies and required attributes in Steps 3b and 3c. It receives
the policy and attributes in Steps 4b and 4c. After evaluating, it makes an
authorization decision and sends it to the sharing unit in Step 5. If the
request is approved, the sharing unit gets encrypted or anonymized data based
on the purpose in Steps 7a and 7b. Then, it delivers the intended PHI through
email or protocol to the receiver in Step 8.

The audit trail recording unit collects logs from AM in Step 6a and from the
honest broker in Step 6b. It combines logs and stores as an audit trail in
Step 6c in Private Audit Blockchain. Section IV discusses block structure and
others. The compliance status checking is done in Steps 9a, 9b, and 9c by the
Proof of Compliance consensus mechanism. Compliance status reports are
produced in Step 10. Section V discusses the required mechanism. For this
study, it is considered that the authorization module is not compromised or
tampered with. It is the reference monitor for making access decisions and
must be tamper-proof [23]. Also, the communication channel between AU and the
smart contract access points or apps is secured from malicious users.

##  IV PHI Sharing Provenance

Enforcing an applicable set of policies is crucial, but preserving data
provenance to show adherence to these policies is also essential.
Nevertheless, policy compliance cannot be quantified or confirmed in
isolation. An independent auditor conducts a thorough policy audit to verify
compliance with the policy, utilizing the available provenance data to
ascertain and certify the policy’s compliance status. For an accurate policy
compliance assessment, two critical elements must be diligently maintained:
(i) consent and policy lineage and (ii) PHI sharing activity audit trails.
This section contains the detailed provenance mechanisms dedicated to
preserving the policy lineage’s integrity and ensuring the audit trails’
authenticity.

###  IV-A Consent and Policy Lineage

Policy lineage involves a comprehensive record of all policies that guide the
authorization module’s decisions. It’s a transparent and traceable record of
the policy history and its application in decision-making processes. For this
study, sharing informed consent is mainly considered for decision-making.
Since all consents are deployed as smart contracts, blockchain networks can
create policy lineages. However, this paper does not consider other HIPAA-
related policies, such as physical security, provider training, etc [11].

###  IV-B PHI Sharing Activity Audit Trails

Integrity in policy enforcement ensures that events are documented faithfully,
reflecting the sequence and nature of actions taken. This authenticity is
crucial for transparency and accountability. Provenance plays a key role by
offering a detailed and unalterable history of policy enforcement actions as
they are carried out, safeguarding against any tampering of records. The
alteration of audit trails or unauthorized access to healthcare data is
strictly prohibited to maintain the sanctity of the process. Maintaining the
integrity of the audit trail is essential for policy compliance assurance. If
integrity is compromised, checking compliance status to find compliance and
non-compliance cases is questionable. The blockchain provides these
requirements as ledger properties. This work adopts private blockchain as an
audit trail storage system.

Figure 5 illustrates the private audit blockchain’s block components and
structure. Each block has a block header part that contains block metadata and
a data part that stores the audit trail data. Each audit trail has five
components: (i) audit trail ID; (ii) informed consent ID or SIC ID; (iii)
honest broker ID; (iv) honest broker report; and (v) timestamp data. The audit
trail ID provides unique identifiers; the informed consent ID, or SIC ID,
indicates the consent that is executed to share the intended PHI. From SIC ID,
it is possible to get the components: sender, receiver, PHI, and purpose. The
honest broker ID indicates which broker certifies or attests to the intended
PHI’s protection status (encryption or anonymity). Finally, the timestamp
means the time when the sharing authorization is done. Steps 6a, 6b, and 6c in
Figure 4 show the process of capturing audit trails from the authorization
module and honest broker.

Figure 5: Audit Blockchain Block Structure. Figure 6: Storing Audit Blockchain
Block ID and Hash.

Enforcement activity data is collected and stored in a private blockchain
known as an audit blockchain as immutable records to ensure consent provenance
and maintain compliance. The private blockchain network is managed and
maintained by an authority, which means reading and writing permissions are
given to limited participants or users. In this case, the trust and
transparency of the private blockchain are questionable. It doesn’t provide a
public eye to maintain trust and transparency. Storing audit trails on the
public blockchain gives trust and transparency, which is another issue to
consider. Firstly, audit trails contain sensitive information like user
activities, and storing them on a public blockchain creates security and
privacy concerns. Secondly, audit trails produce enormous amounts of data,
which requires a lot of money to store on the public blockchain. This is not
feasible from a business perspective, as it increases business operation,
treatment costs, and service charges.

To overcome the aforementioned issues, this research stores audit trail data
on a private blockchain called the private audit blockchain. Then, it stores
the private audit blockchain block ID and hash as integrity on the public
blockchain. Storing block ID and integrity requires a small cost and provides
trust and transparency. Any modifications to private audit blockchain data can
be detected by comparing the block’s current and stored hashes with those on
the public blockchain. Figure 6 shows the private and public blockchain
relationship for storing audit block ID and integrity in a public blockchain
like Ethereum. We have configured a private blockchain that is based on the
Ethereum client [24] with the necessary smart contracts and API for capturing
and storing audit trail data in the audit blockchain.

##  V Compliance Verification

Enforcing applicable policies and maintaining audit trails are insufficient to
ensure policy compliance. There must be some mechanism to check compliance
status using deployed and enforced policies with audit trails. The compliance
checker must be an independent and separate entity from the policy enforcer
and audit trail unit. This paper proposes a blockchain consensus mechanism to
perform compliance-checking operations on the audit trails using deployed
sharing informed consents (SIC) and other applicable policies. The consensus
mechanism, called Proof of Compliance (PoC), is governed by a set of
independent, distributed, and decentralized auditor nodes. Section III
discusses the sharing informed consent structure and deployment process as the
smart contract in the public blockchain. Section IV gives the audit trail
capturing and storing mechanism.

Figure 7 depicts the transaction structure of the Proof of Compliance
consensus mechanism. The PoC takes input from an audit trail that contains (i)
audit trail ID, (ii) informed consent ID or SIC ID, (iii) honest broker ID,
(iv) honest broker report, and (v) timestamp data. Applicable policy and
sharing informed consent are retrieved from the policy repository and public
blockchain to check the status of each audit trail. After verifying, each
auditor node determines the compliance status for each transaction. There are
three compliance statuses: (i) compliant, which indicates there are no
security and privacy policy violations; (ii) non-compliant means there is a
policy violation, and (iii) non-determined defines that required information
is not available to check status.

Figure 7: Proof of Compliance (PoC) Transaction Structure.

The auditor nodes can be hospitals, various governments, regulatory agencies,
insurance companies, business associates, and others. They do not store audit
trail data and are responsible for maintaining compliance status for each
transaction. Reports from all auditor nodes are collected and combined for the
final decision. Algorithm 2 shows the core functionalities of PoC: signature
verification and order, transaction validation, policy compliance
verification, and ledger modification. Due to page constraints, we do not
include detailed protocols, communication mechanisms, and synchronization
techniques. They are our future research communications with performance
evaluations for compliance accuracy measurements, data security and privacy,
and others.

1

2

Input : (i) list of transactions $(Txns)$ and (ii) set of policy $Plcy$

Output : (i) list of accepted/rejected transactions $(Txns)$ and (ii) list of
transactions that are policy compliance

3

4Initialization (i) $\mathbb{N}_{Order}$: order nodes, (ii)
$\mathbb{N}_{Validator}$: validator/endorser nodes, (iii)
$\mathbb{N}_{Audit}$: audit nodes, and (iv) $\mathbb{N}_{Committer}$:
committer nodes

5Signature Verification and Order

6$Txn_{Valid}=[]$

7 /* accepted transaction list */

8 $Txn_{Invalid}=[]$

9 /* rejected transaction list */

10

11for  _$i\leftarrow Txns_{Start}$ to $Txns_{End}$ by $1$_ do

12 if  _$\zeta(PK_{i},Tnx_{i})==Signed_{Tnx_{i}}$_ then

13 $Txn_{Valid}\leftarrow Txn_{Valid}+Txn_{i}$

14 else

15 $Txn_{Invalid}\leftarrow Txn_{Invalid}+Txn_{i}$

16 end if

17

18 end for

19

20Transaction Validation $Txn_{Accepted}=[]$

21 /* accepted transaction list */

22 $Txn_{Rejected}=[]$

23 /* rejected transaction list */

24

25for  _$i\leftarrow{Txn_{Valid}}_{Start}$ to ${Txn_{Valid}}_{End}$ by $1$_ do

26 if  _$\zeta(PK_{i},Tnx_{i})==Signed_{Tnx_{i}}$_ then

27 $Txn_{Accepted}\leftarrow Txn_{Accepted}+{Txn_{Valid}}_{i}$

28 else

29 $Txn_{Rejected}\leftarrow Txn_{Rejected}+{Txn_{Valid}}_{i}$

30 end if

31

32 end for

33

34Policy Compliance Verification

35$Txn_{Compliance}=[]$

36 /* compliance transactions */

37 $Txn_{NonCompliance}=[]$

38 /* noncompliance transactions */

39

40for  _$i\leftarrow{Txn_{Accepted}}_{Start}$ to ${Txn_{Accepted}}_{End}$ by
$1$_ do

41 if  _$\zeta(PK_{i},Tnx_{i})==Signed_{Tnx_{i}}$_ then

42 $Txn_{Compliance}\leftarrow Txn_{Compliance}+{Txn_{Accepted}}_{i}$

43 else

44 $Txn_{NonCompliance}\leftarrow Txn_{NonCompliance}+{Txn_{Accepted}}_{i}$

45 end if

46

47 end for

48

49Ledger Modification

50$Txn_{Compliance}=[]$

51 /* compliance transactions */

52 $Txn_{NonCompliance}=[]$

53 /* noncompliance transactions */

54

55for  _$i\leftarrow{Txn_{Accepted}}_{Start}$ to ${Txn_{Accepted}}_{End}$ by
$1$_ do

56 if  _$\zeta(PK_{i},Tnx_{i})==Signed_{Tnx_{i}}$_ then

57 $Txn_{Compliance}\leftarrow Txn_{Compliance}+{Txn_{Accepted}}_{i}$

58 else

59 $Txn_{NonCompliance}\leftarrow Txn_{NonCompliance}+{Txn_{Accepted}}_{i}$

60 end if

61

62 end for

Algorithm 2 Proof of Compliance (PoC) Consensus Method.

##  VI SIC Provenance Services

Patients need to be provided with the specifics of their given sharing
informed consent: who can share what PHI with whom, and for what purposes?
Additionally, patients should understand the execution of their consent,
including the details of who shares which healthcare data, the timing of these
actions, and others. They should also know whether those sharing activities
comply with the applicable security and privacy policies, regulatory
requirements, industry best practices, contractual obligations, etc. This
section outlines the services related to the given and executed consent that
patients can access within the proposed framework, provided they have the
necessary credentials. The primary goal of provenance services is to ensure
patients receive accurate and comprehensive information and have confidence
regarding their given and executed informed consent.

###  VI-A Given Consent Services

In this scope, patients can access the list of all the given consents for
sharing healthcare data to date. These consents are in their original state
and may or may not be executed for making data-sharing decisions. Patients can
see the list where each consent contains information about who the sender is,
who the receiver is, what the protected healthcare information is, and the
purpose of sharing healthcare data when the sharing informed consent is given.
Given consent services can be delivered: (i) sender-oriented, (ii) receiver-
oriented, (iii) PHI-oriented, and (iv) purpose-oriented. For example, patients
can have sender-oriented consent services that include all the consents given
to a particular sender or a group of senders. Figure 8 depicts sender-oriented
given consents for Donald, who has permission to share PHI with various
receivers. Figure 9 shows the PHI-oriented given consents for health record
PHI-1008.

Figure 8: Sender-Oriented Given Consents. Figure 9: PHI-Oriented Given
Consents.

###  VI-B Executed Consent Services

After generation, all consents may or may not be executed to share healthcare
data. A consent is executed when a sender wants to share PHI with the receiver
when there is a need for it to serve the purpose included in the consent. If
consent is executed, other information is stored in addition to the consent,
like an honest broker ID, a pertinent policy status that the broker has
certified, a timestamp, etc. Executed consent services can be provided: (i)
sender-oriented, (ii) receiver-oriented, (iii) PHI-oriented, and (iv) purpose-
oriented. For example, a patient may need to know the executed consent for a
particular receiver. Figure 10 shows receiver-oriented executed consents for
Steve with senders and timestamps. Figure 11 depicts purpose-oriented executed
consents for treatment with sender, receiver, and timestamp.

Figure 10: Receiver-Oriented Executed Consents. Figure 11: Purpose-Oriented
Executed Consents.

###  VI-C Service Delivery to Patients

Patients will interact with the system through interfaces like GUIs or apps
supported by wallets like Coinbase and MetaMask for transaction signing and
data access management. These wallets safeguard users’ private keys and
credentials. The system accommodates various user types, including those
requiring tailored interfaces, such as seniors, physically disabled
individuals, minors, and others. Healthcare providers may address the specific
needs of these diverse users and can develop apps and software to provide
services. Patients’ devices and apps are assumed to be secure against
unauthorized access, and communication with the blockchain is also protected.

##  VII Experimental Evaluation

The Ethereum Virtual Machine (EVM) based three blockchain test networks
(Arbitrum, Polygon, and Optimism) are chosen for the experiments. We developed
and deployed smart contracts for storing and retrieving PPA integrity and
informed consent in test networks. Ethereum’s Remote Procedure Call (RPC) API
services are employed for deploying smart contracts and performing
transactions on these networks [25]. Utilizing public RPC eliminates the need
to maintain a blockchain node for contract interaction, assuming minimal
resource usage (CPU, HDD, bandwidth) on the local machine. We used Metamask
wallet to sign and authorize transactions using ETH and MATIC faucet tokens as
gas. Healthcare providers may invest in infrastructure such as blockchain
nodes, web interfaces, and mobile applications for seamless service
interaction between patients and healthcare systems. Storing informed consent
on public blockchains like Ethereum incurs direct monetary costs. Patients,
insurance companies, and others can split these costs, like those for doctor
visits, medications, and laboratory tests. The following discusses gas
consumption and time requirements.

###  VII-A Gas Consumption

Gas is needed for any activity on the Ethereum network involving writing data
or changing the state of the blockchain. Smart contract deployment and
function calling costs to write data on the blockchain network are considered
in this work. A contract is deployed for each patient separately to manage
consent-related queries efficiently. The cost of smart contract deployment is
proportional to the size of the code [26]. This is a one-time cost for a
single-contract deployment. How much it costs to call a function depends on
how many times it is called and how much data needs to be stored or changed on
the blockchain network. Figure 12, 13, 14, 15, and 16 show the contract
deployment and consent storage costs in gas (token) and USD for three test
networks.

Figure 12: PPA Integrity Storage Cost. Figure 13: Contract Deployment Gas
Cost. Figure 14: Contract Deployment USD Cost. Figure 15: Consent Storage Gas
Cost. Figure 16: Consent Storage USD Cost.

###  VII-B Time Requirements

Blockchain-based applications require block data writing and reading time
requirements. Writing time includes smart contract deployment and data
addition. Table III shows the writing time for various consent numbers for the
test networks. The reading time indicates the required time to get data from
the block of the blockchain ledger. All the read calls of smart contracts are
gas-free. Table IV shows the test network’s reading time for various consent
numbers. The same smart contracts and consents are used for all test networks.
Maintaining a node locally can reduce the reading time from the network where
block data can be accessed in real-time. The system continuously synchronizes
with the blockchain network to update the ledger data. The providers can
maintain local nodes for faster authorizations.

TABLE III: Consent Writing Time to Blockchain Network. Consents # |  Polygon |  Arbitrum |  Optimism
---|---|---|---
4 |  6.719 Sec |  6.854 Sec |  8.459 Sec
8 |  5.961 Sec |  6.068 Sec |  7.785 Sec
12 |  5.972 Sec |  6.338 Sec |  7.738 Sec
16 |  6.309 Sec |  6.063 Sec |  7.762 Sec
20 |  6.085 Sec |  6.081 Sec |  8.163 Sec
24 |  6.015 Sec |  2.476 Sec |  7.482 Sec
28 |  10.117 Sec |  6.521 Sec |  7.718 Sec
32 |  10.041 Sec |  2.451 Sec |  8.268 Sec
36 |  10.045 Sec |  6.662 Sec |  7.736 Sec
40 |  14.039 Sec |  2.458 Sec |  7.797 Sec
44 |  10.048 Sec |  6.201 Sec |  7.881 Sec
48 |  10.138 Sec |  6.174 Sec |  8.971 Sec
TABLE IV: Consent Reading Time from Blockchain Network. Consents # |  Polygon |  Arbitrum |  Optimism
---|---|---|---
4 |  0.426 Sec |  0.234 Sec |  0.399 Sec
8 |  0.366 Sec |  0.201 Sec |  0.423 Sec
12 |  0.337 Sec |  0.239 Sec |  0.425 Sec
16 |  0.346 Sec |  0.259 Sec |  0.423 Sec
20 |  0.327 Sec |  0.288 Sec |  0.442 Sec
24 |  0.344 Sec |  0.241 Sec |  0.579 Sec
28 |  0.358 Sec |  0.221 Sec |  0.536 Sec
32 |  0.361 Sec |  0.288 Sec |  0.495 Sec
36 |  0.401 Sec |  0.225 Sec |  0.512 Sec
40 |  0.36 Sec |  0.206 Sec |  0.482 Sec
44 |  0.361 Sec |  0.233 Sec |  0.462 Sec
48 |  0.522 Sec |  0.224 Sec |  0.434 Sec

##  VIII Conclusions

Sharing patient health data is beneficial for improving medical care,
diagnosis, and other essential services. However, keeping this information
private and secure is important. Different policies from various authorities
help ensure the privacy and security of this health data. Complying with these
policies ensures that safety measures are working. Getting patients’ informed
consent is also critical to protecting their privacy and giving them control
over sharing their information. Patients need to understand fully how their
data is shared. Patients should also feel confident that strong safeguards are
in place to protect their data. Using smart contracts to manage patient
consent is a promising way to securely and privately share health data. These
systems let patients control their health records and agree to how doctors and
others use them. Blockchain technology improves these systems by providing
security, efficiency, decentralization, transparency, and immutability. This
enhances the trustworthiness and responsibility of sharing healthcare data
among everyone involved.

Looking forward, our objective is to provide functional mechanisms for
essential consent management operations for data sharing and enhancing patient
care and services. Management operations generate, modify, withdraw, expire,
and archive consent. Improper consent can cause sensitive data disclosure or
prevent getting services. Consent generation must be done carefully. It is
necessary to modify a given consent due to improper components like the
receivers or purposes. In this situation, a modified new consent must be
deployed, while the old consent must be moved to the achieving repository.

## Acknowledgements

This work was partially supported by the U.S. National Science Foundation
under Grant No. 1822118 and 2226232, the member partners of the NSF IUCRC
Center for Cyber Security Analytics and Automation – Statnett, AMI, NewPush,
Cyber Risk Research, NIST, and ARL – the State of Colorado (grant #SB 18-086),
and the authors’ institutions. Any opinions, findings, conclusions, or
recommendations expressed in this material are those of the authors and do not
necessarily reflect the views of the National Science Foundation or other
organizations and agencies.

## References

  * [1] C. S. Kruse, M. Mileski, A. G. Vijaykumar, S. V. Viswanathan, U. Suskandla, and Y. Chidambaram, “Impact of electronic health records on long-term care facilities: systematic review,” _JMIR medical informatics_ , vol. 5, no. 3, p. e7958, 2017.
  * [2] S. Kalkman, J. van Delden, A. Banerjee, B. Tyl, M. Mostert, and G. van Thiel, “Patients’ and public views and attitudes towards the sharing of health data for research: a narrative review of the empirical evidence,” _Journal of medical ethics_ , vol. 48, no. 1, pp. 3–13, 2022.
  * [3] G. Haddow, A. Bruce, S. Sathanandam, and J. C. Wyatt, “‘nothing is really safe’: a focus group study on the processes of anonymizing and sharing of health data for research purposes,” _Journal of evaluation in clinical practice_ , vol. 17, no. 6, pp. 1140–1146, 2011.
  * [4] E. Li, J. Clarke, A. L. Neves, H. Ashrafian, and A. Darzi, “Protocol: Electronic health records, interoperability and patient safety in health systems of high-income countries: A systematic review protocol,” _BMJ Open_ , vol. 11, no. 7, 2021.
  * [5] S. D. Lustgarten, Y. L. Garrison, M. T. Sinnard, and A. W. Flynn, “Digital privacy in mental healthcare: current issues and recommendations for technology use,” _Current opinion in psychology_ , vol. 36, pp. 25–31, 2020.
  * [6] E. Hutchings, M. Loomes, P. Butow, and F. M. Boyle, “A systematic literature review of attitudes towards secondary use and sharing of health administrative and clinical trial data: a focus on consent,” _Systematic Reviews_ , vol. 10, pp. 1–44, 2021.
  * [7] O. f. C. Rights (OCR), “HIPAA Enforcement,” May 2008, last Modified: 2021-06-28T08:59:34-0400. [Online]. Available: https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/index.html
  * [8] S. Timmermans, “The engaged patient: The relevance of patient–physician communication for twenty-first-century health,” _Journal of Health and Social Behavior_ , vol. 61, no. 3, pp. 259–273, 2020.
  * [9] A. Lopez Martinez, M. Gil Pérez, and A. Ruiz-Martínez, “A comprehensive review of the state-of-the-art on security and privacy issues in healthcare,” _ACM Computing Surveys_ , vol. 55, no. 12, pp. 1–38, 2023.
  * [10] M. Aljabri, M. Aldossary, N. Al-Homeed, B. Alhetelah, M. Althubiany, O. Alotaibi, and S. Alsaqer, “Testing and exploiting tools to improve owasp top ten security vulnerabilities detection,” in _2022 14th International Conference on Computational Intelligence and Communication Networks (CICN)_. IEEE, 2022, pp. 797–803.
  * [11] K. Chung, D. Chung, and Y. Joo, “Overview of administrative simplification provisions of hipaa,” _Journal of medical systems_ , vol. 30, pp. 51–55, 2006.
  * [12] M. L. Alarcon, M. Nguyen, S. Debroy, N. R. Bhamidipati, P. Calyam, and A. Mosa, “Trust model for efficient honest broker based healthcare data access and processing,” in _2021 IEEE International Conference on Pervasive Computing and Communications Workshops and other Affiliated Events (PerCom Workshops)_. IEEE, 2021, pp. 201–206.
  * [13] V. Buterin _et al._ , “A next-generation smart contract and decentralized application platform,” _white paper_ , vol. 3, no. 37, pp. 2–1, 2014.
  * [14] T.-V. Le and C.-L. Hsu, “A systematic literature review of blockchain technology: Security properties, applications and challenges,” _Journal of Internet Technology_ , vol. 22, no. 4, pp. 789–802, 2021.
  * [15] K. Fan, S. Wang, Y. Ren, H. Li, and Y. Yang, “Medblock: Efficient and secure medical data sharing via blockchain,” _Journal of medical systems_ , vol. 42, no. 8, p. 136, 2018.
  * [16] M. Shah, C. Li, M. Sheng, Y. Zhang, and C. Xing, “Crowdmed: A blockchain-based approach to consent management for health data sharing,” in _Smart Health: International Conference, ICSH 2019, Shenzhen, China, July 1–2, 2019, Proceedings 7_. Springer, 2019, pp. 345–356.
  * [17] Y. Zhuang, L. R. Sheets, Y.-W. Chen, Z.-Y. Shae, J. J. Tsai, and C.-R. Shyu, “A patient-centric health information exchange framework using blockchain technology,” _IEEE journal of biomedical and health informatics_ , vol. 24, no. 8, pp. 2169–2176, 2020.
  * [18] M. Alhajri, A. Salehi Shahraki, and C. Rudolph, “Privacy of fitness applications and consent management in blockchain,” _Proceedings of the 2022 Australasian Computer Science Week_ , pp. 65–73, 2022.
  * [19] S. Amofa, E. B. Sifah, O.-B. Kwame, S. Abla, Q. Xia, J. C. Gee, and J. Gao, “A blockchain-based architecture framework for secure sharing of personal health data,” in _2018 IEEE 20th international conference on e-Health networking, applications and services (Healthcom)_. IEEE, 2018, pp. 1–6.
  * [20] E. Balistri, F. Casellato, C. Giannelli, and C. Stefanelli, “Blockhealth: Blockchain-based secure and peer-to-peer health information sharing with data protection and right to be forgotten,” _ICT Express_ , vol. 7, no. 3, pp. 308–315, 2021.
  * [21] B. Shen, J. Guo, and Y. Yang, “Medchain: Efficient healthcare data sharing via blockchain,” _Applied sciences_ , vol. 9, no. 6, p. 1207, 2019.
  * [22] M. Al Amin, A. Altarawneh, and I. Ray, “Informed consent as patient driven policy for clinical diagnosis and treatment: A smart contract based approach,” in _Proceedings of the 20th International Conference on Security and Cryptography-SECRYPT_ , 2023, pp. 159–170.
  * [23] D. Mulamba and I. Ray, “Resilient reference monitor for distributed access control via moving target defense,” in _Data and Applications Security and Privacy XXXI: 31st Annual IFIP WG 11.3 Conference, DBSec 2017, Philadelphia, PA, USA, July 19-21, 2017, Proceedings 31_. Springer, 2017, pp. 20–40.
  * [24] C. N. Samuel, S. Glock, F. Verdier, and P. Guitton-Ouhamou, “Choice of ethereum clients for private blockchain: Assessment from proof of authority perspective,” in _2021 IEEE International Conference on Blockchain and Cryptocurrency (ICBC)_. IEEE, 2021, pp. 1–5.
  * [25] S. Kim and S. Hwang, “Etherdiffer: Differential testing on rpc services of ethereum nodes,” in _Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering_ , 2023, pp. 1333–1344.
  * [26] E. Albert, J. Correas, P. Gordillo, G. Román-Díez, and A. Rubio, “Gasol: Gas analysis and optimization for ethereum smart contracts,” in _International Conference on Tools and Algorithms for the Construction and Analysis of Systems_. Springer, 2020, pp. 118–125.