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, U.S.A.

Keywords:

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

Abstract:

Protected Health Information (PHI) sharing signiﬁcantly enhances patient care quality and coordination, con-

tributing to more accurate diagnoses, efﬁcient 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 pref-

erences and legal requirements.

1 INTRODUCTION

Acquiring patient consent for healthcare information

sharing is paramount for adhering to policy com-

pliance, particularly concerning regulations like the

Health Insurance Portability and Accountability Act

(HIPAA) in the U.S. and the General Data Protec-

tion Regulation (GDPR) in the E.U (Hutchings et al.,

2021). These regulatory frameworks emphasize pro-

tecting 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 con-

sent before sharing healthcare data for purposes be-

yond 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 de-

cide how their data is used and shared. From a policy

compliance perspective, proper patient consent acqui-

sition is a legal requirement and a trust-building mea-

sure, reinforcing the patient-provider relationship. It

ensures transparency in data handling and builds pa-

tient conﬁdence, knowing their sensitive information

is shared respectfully and responsibly. As healthcare

https://orcid.org/0000-0003-1700-7201

https://orcid.org/0009-0007-7778-5845

https://orcid.org/0009-0005-5658-0950

https://orcid.org/0000-0002-3612-7738

continues to integrate with various technologies, up-

holding these consent protocols is crucial for main-

taining 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 in-

crease security and privacy concerns. Table 1 shows

the number of compliance complaints received by

the U.S. Department of Health and Human Services

(HHS) Ofﬁce for Civil Rights (OCR) (Rights (OCR),

2008). 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 elec-

tronic PHI, and (v) use or disclosure of more than the

minimum necessary PHI. These issues can be mini-

mized by enforcing patients’ consent for data access

and sharing decisions and employing proper data pro-

tection 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 (Timmermans, 2020).

Enhanced security and privacy technologies are

essential for protecting patient data from being com-

promised, misused, or disclosed. However, substan-

tial evidence indicates that the root of many unau-

thorized EHR access and sharing lies in inadequate

policy adoption, implementation, and enforcement

(Lopez Martinez et al., 2023; Aljabri et al., 2022).

Often, users are granted access privileges inappropri-

Al Amin, M., Tummala, H., Shah, R. and Ray, I.

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

DOI: 10.5220/0012767400003767

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 21st International Conference on Security and Cryptography (SECRYPT 2024), pages 211-223

ISBN: 978-989-758-709-2; ISSN: 2184-7711

211

Table 1: 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

ately, whether intentionally or not. Policy compliance

frequently falls short, and access control measures are

not rigorously monitored or executed on time. A com-

mon oversight is the blanket assignment of identical

roles and privileges to all employees, neglecting the

nuances of individual patient-level policies. More-

over, auditing and monitoring practices are typically

reactive, triggered only by serious complaints or le-

gal mandates, rather than proactive and consistent.

These policy speciﬁcation and enforcement ﬂaws sig-

niﬁcantly impact informed consent policies, under-

scoring 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 contrac-

tual obligations for sharing PHI: (i) Patient-level poli-

cies or consents are often not properly or timely en-

forced 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 medi-

ums 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 veriﬁable, unaltered record for con-

sent 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 re-

quirements, 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 en-

sures that PHI sharing occurs only when the sender

has obtained the necessary consent from the patient

and the sharing aligns with speciﬁc, predeﬁned pur-

poses. 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 (Chung et al.,

2006). However, the proposed approach does not di-

rectly guarantee security mechanisms like encryption

for data protection. Instead, it leverages an honest

broker who acts as a blind and secure entity to evalu-

ate the intended PHI and certify its status as required

protection mechanisms are satisﬁed or not (Alarcon

et al., 2021) . The broker’s attestation is then recorded

in blockchain-based audit trails with other relevant

activity data to support future compliance evalua-

tions and validation. It supports using audit trails or

provenance mechanisms based on blockchain, which

is essential for keeping track of PHI-sharing activi-

ties. Moreover, the proposed framework provides a

compliance-checking mechanism in data-sharing ac-

tivities, ensuring adherence to applicable policies.

Smart contracts, (Buterin et al., 2014), offer an au-

tomated, transparent system that upholds the integrity

and accountability of the consent for sharing PHI.

Through this smart contract-based approach, the pro-

posed framework not only automates processes but

also guarantees the accurate execution of informed

consent, thereby enhancing the security and reliabil-

ity of PHI sharing. Blockchain technology ensures

the immutability of submitted records, safeguarding

the integrity of the audit trail and enabling the detec-

tion of any unauthorized alterations. Blockchain se-

curity features, including non-repudiation, ensure that

participants cannot deny their actions (Le and Hsu,

2021).

This work is the ﬁrst to capture patients’ informed

consent for PHI sharing to ensure policy compliance

through preserving provenance and conducting com-

pliance checking. It also considers and enforces other

applicable security policies and industry best prac-

tices mandated by the various laws, regulations, stan-

dards, and contractual obligations to meet the compli-

ance requirements. Signiﬁcant contributions include

(i) implementing a mechanism to capture patients’

consent for sharing healthcare data beyond the treat-

ment team members. (ii) Storing obtained consents in

decentralized and distributed networks (blockchain)

to overcome a single point of truth sources and fail-

ure. (iii) Considering applicable security and pri-

vacy policies, regulatory requirements, and contrac-

tual obligations to ensure compliance-based sharing.

(iv) Enforcing informed consent and applicable poli-

cies while making authorization decisions to share

health records. (v) Equipping blockchain-based au-

dit trail mechanisms to guarantee data provenance.

(vi) Incorporating compliance assessment methods to

identify compliance and non-compliance PHI shar-

ing. (vii) Offering consent services to provide precise

and comprehensive insights into the consent granted

and the extent of its execution.

SECRYPT 2024 - 21st International Conference on Security and Cryptography

212

2 RELATED WORK

Blockchain technology has increasingly been adopted

in healthcare for various services, particularly for

sharing protected health information among health-

care providers, patients, and other stakeholders.

Blockchain facilitates a more efﬁcient, transparent,

and patient-centered delivery of healthcare services,

making it an essential component in modern health-

care infrastructure. Fan et al., (Fan et al., 2018), pro-

posed 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., (Shah et al., 2019), proposed a med-

ical 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., (Zhuang et al., 2020), addressed a

blockchain-based patient-centric health information-

sharing mechanism protecting data security and pri-

vacy, ensuring data provenance, and providing pa-

tients full control over their health data. However,

consent structure and compliance requirements are

not addressed, which are very important to give pa-

tients conﬁdence in how their consent is executed and

how data is protected.

Alhajri et al., (Alhajri et al., 2022), explored the

criticality of implementing legal frameworks to safe-

guard privacy within ﬁtness apps. By examining how

various ﬁtness apps handle consent and privacy poli-

cies, their research highlighted the crucial role of con-

sent 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 ﬁtness data, ensuring a process centered

around human needs and compliant with legal stan-

dards. Nonetheless, the study failed to present a tech-

nical architecture for their blockchain-based proposal.

Amofa et al. approached a blockchain-based per-

sonal health data sharing framework with an underly-

ing mechanism to monitor and enforce acceptable use

policies attached to patient data (Amofa et al., 2018).

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., (Balistri et al., 2021),

designed the BlockHealth solution for sharing health

data with tamper-prooﬁng 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.

The above-mentioned papers summarized the ap-

plication and beneﬁts of using blockchain for health-

care data sharing and essential services. However,

they failed to address the security and privacy re-

quirements mandated by various laws and regula-

tory agencies, such as HIPAA and GDPR. The ma-

jor 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 poli-

cies. This paper proposes sharing informed consent as

the smart contract for authorization with provenance

and compliance-checking mechanisms.

3 PROPOSED APPROACH

The main objective is to ensure compliance with ap-

plicable security and privacy policy for PHI shar-

ing. To ensure compliance, we need proper pol-

icy enforcement, including maintaining provenance

and performing compliance status checks promptly

and properly. For enforcement, this paper considers

patient-informed consent, where the sender has per-

mission from the patient to share the intended PHI

with the receiver for speciﬁc purposes. Also, proper

data protection mechanisms are considered. How-

ever, 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 reﬂects their ac-

tual occurrence. A private blockchain-based approach

is proposed (Section 4). Finally, a blockchain con-

sensus mechanism called Proof of Compliance (PoC)

is approached, Section 5, for performing auditing.

This audit rigorously examines the enforcement ac-

tions against the policy standards and informed con-

sent, 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.

3.1 Patient-Provider Agreement (PPA)

The patient-provider agreement, or PPA, aims to de-

termine 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,

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

213

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 struc-

ture of a PPA, and Algorithm 1 illustrates the gradual

processes for creating a PPA with the required com-

ponents. The main concept of PPA is adopted from

(Al Amin et al., 2023). The authors focused on con-

sent management for medical treatment and diagno-

sis purposes, mainly for the treatment team members.

They did not include patient consent and other re-

quirements for health data sharing beyond the treat-

ment team. This paper extends the PPA structure to

analyze the requirements and formalize the consent

components for PHI sharing. A PPA is formally com-

posed of ﬁve tuples:

PPA = (PC, PrC, T IC, SIC, ROC)

satisfying the following requirements:

(A) PC is a ﬁnite set of patient components contain-

ing the patient’s personal information, contact in-

formation, mailing information, pharmacy infor-

mation, billing and insurance information, emer-

gency contact, and others. The patient is respon-

sible for providing and maintaining these compo-

nents’ valid, accurate, and updated information.

(B) PrC is a ﬁnite set of provider components, includ-

ing the treatment team, prescription, and others.

The provider is responsible for creating an effec-

tive team to provide appropriate care. Everything

from treatment to insurance coverage and billing

is considered during the patient treatment period.

sent components. It denotes that the patient has

permitted the designated treatment team to ac-

cess medical records. Treatment team members

include doctors, nurses, support staff, lab tech-

nicians, billing ofﬁcers, emergency contact per-

sons, and others assigned by the authority. Some

outsider members are insurance agents, phar-

macists/pharmacy technicians, doctors/lab techni-

cians from another hospital, etc.

(D) SIC is a ﬁnite set of sharing informed consent

components. It denotes the patient’s consent

to sharing medical data for a speciﬁc purpose.

Both the sender and the receiver must have con-

sent. 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) deﬁning and

capturing provenance information with the en-

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

forced consents to maintain audit trails, (iv) per-

forming compliance checking using consensus

mechanisms; (v) providing services for both given

and executed consents, etc. It does not consider

other components: PC, PrC, T IC, and ROC.

(E) ROC is a ﬁnite set of regulatory and other com-

ponents. It has applicable security and privacy

policies to comply with the requirements of lo-

cal government, state government, federal govern-

ment, foreign government, and regulatory agen-

cies (HIPAA, GDPR) if necessary. It also includes

contractual obligations in some cases.

3.2 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 dur-

ing transmission over the network. Figure 2 shows

the SIC conceptual framework structure. Sharing in-

formed consent is formally composed of four tuples:

SIC = (S, R, PHI, P)

satisfying the following requirements:

(a) S is a ﬁnite set of authorized senders denoted as

, 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 treat-

ment team or anyone from the provider.

SECRYPT 2024 - 21st International Conference on Security and Cryptography

214

Algorithm 1: Patient-Provider Agreement (PPA) Formation.

Input : (i) PC, (ii) PrC, (iii) T IC, (iv) SIC, (v) ROC, (vi) R

PPA

(vii) BN

1 /* R

PPA

: secured PPA repository, BN

blockchain network smart contract */

Result: A formal PPA

2 Input Parameters Initialization

PPA

← {PC

, PrC

, T IC

, SIC

, ROC

} where i is patient identity

(i) PC ← {PC

, PC

......................PC

}

3 (ii) PrC ← {PrC

, PrC

..........PrC

}

4 (iii) T IC ← {T IC

, T IC

........T IC

}

5 (iv) SIC ← {SIC

, SIC

..............SIC

}

6 (v) ROC ← {ROC

, ROC

...ROC

}

7 PPA Components Integrity Calculation /* H(∂)

calculates hash of ∂ */

8 (a) H

← H(PC

, PC

....................PC

)

9 (b) H

PrC

← H(PrC

, PrC

.........PrC

)

10 (c) H

T IC

← H(T IC

, T IC

........T IC

)

11 (d) H

SIC

← H(SIC

, SIC

.............SIC

)

12 (e) H

ROC

← H(ROC

, ROC

..ROC

)

13 (f) H

PPA

← H(H

, H

PrC

, H

T IC

, H

SIC

, H

ROC

)

14 PPA Finalization if PPA

is complete then

15 /* presence of PC, PrC, T IC, SIC, ROC */

16 if (R

PPA

+ PPA

) contains no conﬂicts then

17 (i) do R

PPA

← (R

PPA

+ PPA

)

18 (ii) add ID

PPA

to patient proﬁle, P

19 (iii) call BN

(ID

PPA

, H

PPA

)

20 /* PPA integrity verification reference */

21 Return: Success (PPA

added to R

PPA

)

22 else

23 Error: (R

PPA

+ PPA

) contains conﬂicts

24 /* PPA

revision required to add */

25 end if

26 else

27 Error: PPA

cannot be created (incomplete PPA)

28 end if

(b) R is a ﬁnite set of authorized users who re-

ceive protected health information from autho-

rized senders. A ﬁnite set of r number authorized

receivers denoted as {R

, R

, ......R

}. The re-

ceiver may be from other hospitals, labs, medi-

cal research institutes, pharmaceutical companies,

marketing departments, government ofﬁcials, etc.

noted by {PHI

, PHI

, ......PHI

}. 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 2 shows ten (10) types of PHI,

considered for each patient, with PHI ID, name,

description, and potential creators.

(d) P is a ﬁnite set of purposes. It indicates the ob-

jective of the PHI sharing by the senders with the

receivers. Receivers must use the received PHI for

the intended purposes. A ﬁnite set of purposes, a

Figure 2: Sharing Informed Consent (SIC) Structure.

p number, can be denoted as {P

, P

, ......P

The objective of sharing protected health informa-

tion outlines the speciﬁc reasons for its sharing. The

recipient must utilize the shared PHI exclusively for

its designated purpose. The potential reasons for shar-

ing 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 ma-

chinery, 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. Pa-

tients’ 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 treat-

ments or products, and improve patient engage-

ment. 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 pur-

poses holds signiﬁcant potential for advancing

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

215

Table 2: 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 Ofﬁcer

PHI-1010 Payer Transactions Bills of doctor visit, lab works, and medications Billing Ofﬁcers, Insurance Agent

medical knowledge, leading to breakthroughs in

understanding diseases, improving and develop-

ing 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 na-

ture and requirements of the treatment, patient condi-

tions, provider business policy, etc. This study con-

siders only the four purposes mentioned above. After

receiving shared data, the receiver performs speciﬁed

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 speciﬁcally,

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 de-

tailed mechanisms or techniques for preventing data

sharing without patients’ consent at the receiver end.

3.3 SIC Smart Contract Deployment

Once a Patient-Provider Agreement, or PPA, is cre-

ated 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 proﬁle and hospi-

tal systems. The contract address is an identiﬁer for a

smart contract in the blockchain network. This smart

contract-based approach provides an automated sys-

tem 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, or-

ganizational policies, regulatory frameworks, etc.

Upon ﬁnalizing the PPA, it transforms and secures

storage in a PPA repository. Subsequently, an in-

tegrity marker, such as a hash (H

PPA

) generated by

Patient Profile

Hospital System

Patient

Provider

1 Agreement

Sharing Informed Consent (SIC)

§ Sharing Informed Consent 1

§ Sharing Informed Consent 2

§ Sharing Informed Consent 3

……………………....

§ Sharing Informed Consent N

Secured PPA Repository

Smart Contract Deployment

Unit (SCDU)

2 Format

Translation

4 SIC Components

Patient Provider Agreement

(PPA)

5 SIC Integrity Check

6 SIC Smart Contract

3 PPA Integrity

7 Update SIC

Information

8 Consent Query

Response

Public Blockchain

Network

Figure 3: SIC Smart Contract Deployment Process.

the Algorithm 1, is stored on the blockchain alongside

the PPA ID for later modiﬁcation 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 veriﬁes their integrity to ensure no de-

liberate or accidental alterations have occurred (Step

5). As a secure entity, the SCDU does not alter con-

sent components, noting that any modiﬁcation inval-

idates the consent. If the consents remain unmodi-

ﬁed, the SCDU creates and deploys the correspond-

ing smart contracts on the blockchain network (Step

6) and then updates the patient’s proﬁle and the hospi-

tal system (Step 7). Users can make queries with the

required credentials regarding informed consent and

get responses in Step 8 from the blockchain network.

3.4 Honest Broker, Applicable Policies

and Industry Best Practices

Alongside patient consent, the proposed approach in-

corporates relevant security policies and industry best

practices before sharing protected health information.

For instance, a security policy might require a data

SECRYPT 2024 - 21st International Conference on Security and Cryptography

216

protection mechanism during data transfer between

systems. For treatment and diagnosis purposes, en-

cryption is a recommended protection method.

Similarly, anonymity is a recommended protec-

tion method for marketing and research purposes,

where patient identiﬁers 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 en-

cryption algorithm, key size, and data anonymity sta-

tus (Alarcon et al., 2021). After checking, the hon-

est broker certiﬁes or attests to the status, which is

recorded in audit trails as proof for policy compliance

veriﬁcation, along with other components like sharing

informed consents, timestamps, etc.

3.5 PHI Sharing Authorization Process

Consent enforcement ensures that related consents are

executed while making decisions for the PHI shar-

ing requests. All consents are stored on the public

blockchain network as smart contracts and cannot be

enforced until they are called. The authorization mod-

ule (AM) considers sharing informed consent with

applicable policy and required attributes while mak-

ing decisions. The attributes may be subject, object,

operation, and environmental attributes. The sender

must provide the necessary credentials for identiﬁca-

tion 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 in-

tended 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 poli-

cies and required attributes in Steps 3b and 3c. It re-

ceives 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 re-

quest 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 4 dis-

cusses block structure and others. The compliance

status checking is done in Steps 9a, 9b, and 9c by the

Proof of Compliance consensus mechanism. Compli-

ance status reports are produced in Step 10. Section 5

discusses the required mechanism. For this study, it is

considered that the authorization module is not com-

promised or tampered with. It is the reference moni-

tor for making access decisions and must be tamper-

proof (Mulamba and Ray, 2017). Also, the commu-

nication channel between AU and the smart contract

access points or apps is secured from malicious users.

4 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 quantiﬁed or conﬁrmed in iso-

lation. An independent auditor conducts a thorough

policy audit to verify compliance with the policy, uti-

lizing 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.

4.1 Consent and Policy Lineage

Policy lineage involves a comprehensive record of all

policies that guide the authorization module’s deci-

sions. 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 poli-

cies, such as physical security, provider training, etc

(Chung et al., 2006).

4.2 PHI Sharing Activity Audit Trails

Integrity in policy enforcement ensures that events are

documented faithfully, reﬂecting the sequence and na-

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

217

1 PHI Sharing Request

Private

Audit

Blockchain

Protected Health

Information (PHI)

Storage

Authorization

Module (AM)

Honest

Broker

Receiver

Sender

2b PHI

2 Decision

Request

5 Decision

Response

3 EN/AN PHI

Audit Trails

Recording Unit

3a Consent Query

4a Consent Return

EN: Encrypted

AN: Anonymous

3b: Policy Query

3c: Attribute Query

4b: Policy Return

4c: Attribute Return

4 PHI EN/AN Status Report

Protocol/Email

EN/AN PHI

6c Audit Trails

EN/AN PHI

Encryption

Anonymity

Mechanism

Provider Healthcare System

Proof of Compliance

(PoC)

Compliance Checking

PHI

Sharing

Unit

EN/AN PHI

Compliance Status

2a PHI

6b Honest Broker Logs

6a AM Logs

9a Audit Trails

9b Policy

9c Informed

Consents

10 Report

Public Blockchain

Network

Policy

Repository

Attribute

Repository

3c 4c 4b 3b

Figure 4: Compliance-based PHI Sharing Authorization Process.

ture of actions taken. This authenticity is crucial for

transparency and accountability. Provenance plays a

key role by offering a detailed and unalterable his-

tory 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 as-

surance. If integrity is compromised, checking com-

pliance status to ﬁnd 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 au-

dit trail has ﬁve 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 identiﬁers; the in-

formed 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, re-

ceiver, PHI, and purpose. The honest broker ID indi-

cates which broker certiﬁes or attests to the intended

PHI’s protection status (encryption or anonymity). Fi-

nally, the timestamp means the time when the sharing

authorization is done. Steps 6a, 6b, and 6c in Figure

Genesis Block

…

Block

Block Header

Previous Block Hash

Hash Difficulty Target

ATT Unit Hash

Block Hash

Block Nonce

Block Timestamp

Audit Trail Data

Audit Trail - 1

Audit Trail - 2

Audit Trail - 3

Audit Trail - M

Audit Trail Transaction (ATT) Unit

…

Bloc Hash

Block Data

Block Hash

Block Data

Block Hash

Block Data

Previous Block Hash

Audit Trail

Informed

Consent

Honest

Broker

Honest

Broker

Report

Timestamp

Data

Sender

Receiver

PHI

Purpose

Figure 5: Audit Blockchain Block Structure.

Public

Blockchain

Network

Policy

Enforcement

Unit

Private Audit Blockchain

Audit

Trai ls

Audit Block

ID and Hash

Figure 6: Storing Audit Blockchain Block ID and Hash.

4 show the process of capturing audit trails from the

authorization module and honest broker.

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 author-

SECRYPT 2024 - 21st International Conference on Security and Cryptography

218

ity, 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 main-

tain trust and transparency. Storing audit trails on the

public blockchain gives trust and transparency, which

is another issue to consider. Firstly, audit trails con-

tain sensitive information like user activities, and stor-

ing them on a public blockchain creates security and

privacy concerns. Secondly, audit trails produce enor-

mous 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 and treatment costs and service charges.

To overcome the aforementioned issues, this re-

search stores audit trail data on a private blockchain

called the private audit blockchain. Then, it stores

the private audit blockchain block ID and block hash

as integrity on the public blockchain. Storing block

ID and integrity requires a small cost and provides

trust and transparency. Any modiﬁcations 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 conﬁgured a private blockchain that is based

on the Ethereum client (Samuel et al., 2021) with the

necessary smart contracts and API for capturing and

storing audit trail data in the audit blockchain.

5 COMPLIANCE VERIFICATION

Enforcing applicable policies and maintaining au-

dit trails are not enough to ensure policy compli-

ance. There must be some mechanism to check

compliance status using deployed and enforced poli-

cies with audit trails. The compliance checker must

be an independent and separate entity from the pol-

icy enforcer and audit trail unit. This paper pro-

poses a blockchain consensus mechanism to perform

compliance-checking operations on the audit trails us-

ing 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 au-

ditor nodes. Section 3 discusses the sharing informed

consent structure and deployment process as the smart

contract in the public blockchain. Section 4 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) hon-

est broker ID, (iv) honest broker report, and (v) times-

tamp 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 indi-

cates there are no security and privacy policy viola-

tions; (ii) non-compliant means there is a policy vio-

lation, and (iii) non-determined deﬁnes that required

information is not available to check status.

Audit

Trail ID

Informed

Consent

Honest

Broker

Honest

Broker

Report

Timestamp

Data

Sender

Receiver

PHI

Purpose

Audit Trail ID

Compliance Status

Proof of Compliance (PoC)

Compliant

Non-Compliant

Not-Determined

Audit

Trails

Private Audit

Blockchain

Public

Blockchain

Network

Policy

Repository

Informed Consents

Policy

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

The auditor nodes can be hospitals, various gov-

ernments, 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

ﬁnal decision. Algorithm 2 shows the core func-

tionalities of PoC: signature veriﬁcation and order,

transaction validation, policy compliance veriﬁcation,

and ledger modiﬁcation. Due to page constraints,

we do not include detailed protocols, communication

mechanisms, and synchronization techniques. They

are our future research communications with perfor-

mance evaluations for compliance accuracy measure-

ments, data security and privacy, and others.

6 SIC PROVENANCE SERVICES

Patients need to be provided with the speciﬁcs of their

given sharing informed consent: who can share what

PHI with whom, and for what purposes? Addition-

ally, patients should understand the execution of their

consent, including the details of who shares which

healthcare data, the timing of these actions, and oth-

ers. They should also know whether those sharing

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

219

Algorithm 2: Proof of Compliance (PoC) Consensus

Method.

Input : (i) list of transactions (T xns) and (ii) set of policy Plcy

Output: (i) list of accepted/rejected transactions (T xns) and (ii)

list of transactions that are policy compliance

1 Initialization (i) N

Order

: order nodes, (ii) N

Validator

validator/endorser nodes, (iii) N

Audit

: audit nodes, and (iv)

Committer

: committer nodes

2 Signature Veriﬁcation and Order

3 T xn

Valid

= [] /* accepted transaction list */

4 T xn

Invalid

= [] /* rejected transaction list */

5 for i ← T xns

Start

to T xns

End

by 1 do

6 if ζ(PK

, T nx

) == Signed

T nx

then

7 T xn

Valid

← Txn

Valid

+ T xn

8 else

9 T xn

Invalid

← Txn

Invalid

+ T xn

10 end if

11 end for

12 Transaction Validation T xn

Accepted

= [] /* accepted

transaction list */

13 T xn

Re jected

= [] /* rejected transaction list */

14 for i ← T xn

Valid

Start

to T xn

Valid

End

by 1 do

15 if ζ(PK

, T nx

) == Signed

T nx

then

16 T xn

Accepted

← Txn

Accepted

+ T xn

Valid

17 else

18 T xn

Re jected

← Txn

Re jected

+ T xn

Valid

19 end if

20 end for

21 Policy Compliance Veriﬁcation

22 T xn

Compliance

= [] /* compliance transactions */

23 T xn

NonCompliance

= [] /* noncompliance transactions */

24 for i ← T xn

Accepted

Start

to T xn

Accepted

End

by 1 do

25 if ζ(PK

, T nx

) == Signed

T nx

then

26 T xn

Compliance

← Txn

Compliance

+ T xn

Accepted

27 else

28 T xn

NonCompliance

← Txn

NonCompliance

+ T xn

Accepted

29 end if

30 end for

31 Ledger Modiﬁcation

32 T xn

Compliance

= [] /* compliance transactions */

33 T xn

NonCompliance

= [] /* noncompliance transactions */

34 for i ← T xn

Accepted

Start

to T xn

Accepted

End

by 1 do

35 if ζ(PK

, T nx

) == Signed

T nx

then

36 T xn

Compliance

← Txn

Compliance

+ T xn

Accepted

37 else

38 T xn

NonCompliance

← Txn

NonCompliance

+ T xn

Accepted

39 end if

40 end for

activities comply with the applicable security and pri-

vacy 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 creden-

tials. The primary goal of provenance services is to

ensure patients receive accurate and comprehensive

information and have conﬁdence regarding their given

and executed informed consent.

6.1 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 de-

cisions. Patients can see the list where each con-

sent contains information about who the sender is,

who the receiver is, what the protected healthcare

information is, and the purpose of sharing health-

care 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.

Donald

PHI-1003

PHI-1005

PHI-1007

PHI-1008

[

Lucy, Research

]

[Sam, Diagnosis]

[

Audrey, Treatment

]

[Steve, Treatment]

[Sam, Treatment]

[Steve, Diagnosis]

[

Hazel, Marketing

]

[

William, Diagnosis

]

Figure 8: Sender-oriented Given Consents.

PHI-1008

Diagnosis

Marketing

Treatmen t

Research

[Donald, Sam]

[Donald, Steve]

[Donald, Sam]

[Willow, Lena]

[Willow, Arden]

[Edith, Jane]

[Edith, James]

Figure 9: PHI-Oriented Given Consents.

6.2 Executed Consent Services

After generation, all consents may or may not be ex-

ecuted to share healthcare data. A consent is ex-

ecuted when a sender wants to share PHI with the

receiver when there is a need that serves the pur-

pose 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 certiﬁed, a timestamp, etc. Exe-

cuted 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. Fig-

ure 11 depicts purpose-oriented executed consents for

treatment with sender, receiver, and timestamp.

SECRYPT 2024 - 21st International Conference on Security and Cryptography

220

Steve

PHI-1003

PHI-1008

PHI-1007

PHI-1005

[Edith, Research , 02-25-23, 2:42 PM]

[Donald, Treatment , 02-03-24, 10:42 AM]

[Donald, Diagnosis , 02-02-24, 2:42 PM]

[Willow, Treatment , 02-03-24, 10:42 AM]

[Donald, Diagnosis , 02-02-24, 2:42 PM]

[Donald, Treatment , 02-03-24, 10:42 AM]

[Edith, Research , 02-25-23, 2:42 PM]

[Willow, Treatment , 02-03-24, 10:42 AM]

Figure 10: Receiver-oriented Executed Consents.

Tre atm ent

PHI-1007

PHI-1008

PHI-1003

PHI-1005

[Donald, Steve , 02-05-24, 11:28 AM]

[Donald, Sam , 01-25-24, 03:22 PM]

[Donald, Hazel , 01-28-24, 04:42 PM]

[Donald, Audrey , 02-03-24, 10:55 AM]

Figure 11: Purpose-oriented Executed Consents.

6.3 Service Delivery to Patients

Patients will interact with the system through inter-

faces 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 ac-

commodates various user types, including those re-

quiring tailored interfaces, such as seniors, physically

disabled individuals, minors, and others. Healthcare

providers may address the speciﬁc needs of these di-

verse users and can develop apps and software to pro-

vide services. Patients’ devices and apps are assumed

to be secure against unauthorized access, and commu-

nication with the blockchain is also protected.

7 EXPERIMENTAL EVALUATION

The Ethereum Virtual Machine (EVM) based three

blockchain test networks (Arbitrum, Polygon, and

Optimism) are chosen for the experiments. We de-

veloped 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 con-

tracts and performing transactions on these networks

(Kim and Hwang, 2023). Utilizing public RPC elim-

inates the need to maintain a blockchain node for

contract interaction, assuming minimal resource us-

age (CPU, HDD, bandwidth) on the local machine.

We used Metamask wallet to sign and authorize trans-

actions using ETH and MATIC faucet tokens as gas.

Healthcare providers may invest in infrastructure such

as blockchain nodes, web interfaces, and mobile ap-

plications 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 follow-

ing discusses gas consumption and time requirements.

7.1 Gas Consumption

Gas is needed for any activity on the Ethereum net-

work involving writing data or changing the state of

the blockchain. Smart contract deployment and func-

tion calling costs to write data on the blockchain net-

work are considered in this work. A contract is de-

ployed for each patient separately to manage consent-

related queries efﬁciently. The cost of smart contract

deployment is proportional to the size of the code

(Albert et al., 2020). 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.

7.2 Time Requirements

Blockchain-based applications require block data

writing and reading time requirements. Writing time

includes smart contract deployment and data addition.

Table 3 shows the writing time for various consent

numbers for the test networks. The reading time in-

dicates the required time to get data from the block

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

221

Figure 14: Contract Deployment USD Cost.

Figure 15: Consent Storage Gas Cost.

Figure 16: Consent Storage USD Cost.

of the blockchain ledger. All the read calls of smart

contracts are gas-free. Table 4 shows the test net-

work’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.

8 CONCLUSIONS

Sharing patient health data is beneﬁcial for improv-

ing medical care, diagnosis, and other essential ser-

vices. 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

Table 3: 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 4: 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

that safety measures are working. Getting patients’

informed consent is also critical to protecting their

privacy and giving them control over sharing their in-

formation. Patients need to understand fully how their

data is shared. Patients should also feel conﬁdent 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, efﬁciency, decentralization, trans-

parency, and immutability. This enhances the trust-

worthiness and responsibility of sharing healthcare

data among everyone involved.

Looking forward, our objective is to provide func-

tional mechanisms for essential consent management

operations for data sharing and enhancing patient care

and services. Management operations generate, mod-

ify, 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 pur-

poses. In this situation, a modiﬁed new consent must

be deployed, while the old consent must be moved to

the achieving repository.

SECRYPT 2024 - 21st International Conference on Security and Cryptography

222

ACKNOWLEDGEMENTS

This work was partially supported by the U.S. Na-

tional Science Foundation under Grant No. 1822118

and 2226232, the member partners of the NSF IU-

CRC Center for Cyber Security Analytics and Au-

tomation – Statnett, AMI, NewPush, Cyber Risk Re-

search, NIST, and ARL – the State of Colorado (grant

#SB 18-086), and the authors’ institutions. Any opin-

ions, ﬁndings, conclusions, or recommendations ex-

pressed in this material are those of the authors and

do not necessarily reﬂect the views of the National

Science Foundation or other organizations and agen-

cies.

REFERENCES

Al Amin, M., Altarawneh, A., and Ray, I. (2023). Informed

consent as patient driven policy for clinical diagno-

sis and treatment: A smart contract based approach.

In Proceedings of the 20th International Conference

on Security and Cryptography-SECRYPT, pages 159–

170.

Alarcon, M. L., Nguyen, M., Debroy, S., Bhamidipati,

N. R., Calyam, P., and Mosa, A. (2021). Trust model

for efﬁcient honest broker based healthcare data ac-

cess and processing. In 2021 IEEE International Con-

ference on Pervasive Computing and Communications

Workshops and other Afﬁliated Events (PerCom Work-

shops), pages 201–206. IEEE.

Albert, E., Correas, J., Gordillo, P., Rom

an-D

ıez, G., and

Rubio, A. (2020). Gasol: Gas analysis and opti-

mization for ethereum smart contracts. In Interna-

tional Conference on Tools and Algorithms for the

Construction and Analysis of Systems, pages 118–125.

Springer.

Alhajri, M., Salehi Shahraki, A., and Rudolph, C. (2022).

Privacy of ﬁtness applications and consent manage-

ment in blockchain. Proceedings of the 2022 Aus-

tralasian Computer Science Week, pages 65–73.

Aljabri, M., Aldossary, M., Al-Homeed, N., Alhetelah, B.,

Althubiany, M., Alotaibi, O., and Alsaqer, S. (2022).

Testing and exploiting tools to improve owasp top ten

security vulnerabilities detection. In 2022 14th In-

ternational Conference on Computational Intelligence

and Communication Networks (CICN), pages 797–

803. IEEE.

Amofa, S., Sifah, E. B., Kwame, O.-B., Abla, S., Xia, Q.,

Gee, J. C., and Gao, J. (2018). A blockchain-based

architecture framework for secure sharing of personal

health data. In 2018 IEEE 20th international confer-

ence on e-Health networking, applications and ser-

vices (Healthcom), pages 1–6. IEEE.

Balistri, E., Casellato, F., Giannelli, C., and Stefanelli,

C. (2021). Blockhealth: Blockchain-based secure

and peer-to-peer health information sharing with data

protection and right to be forgotten. ICT Express,

7(3):308–315.

Buterin, V. et al. (2014). A next-generation smart contract

and decentralized application platform. white paper,

3(37):2–1.

Chung, K., Chung, D., and Joo, Y. (2006). Overview of ad-

ministrative simpliﬁcation provisions of hipaa. Jour-

nal of medical systems, 30:51–55.

Fan, K., Wang, S., Ren, Y., Li, H., and Yang, Y. (2018).

Medblock: Efﬁcient and secure medical data shar-

ing via blockchain. Journal of medical systems,

42(8):136.

Hutchings, E., Loomes, M., Butow, P., and Boyle, F. M.

(2021). A systematic literature review of attitudes to-

wards secondary use and sharing of health administra-

tive and clinical trial data: a focus on consent. System-

atic Reviews, 10:1–44.

Kim, S. and Hwang, S. (2023). Etherdiffer: Differential

testing on rpc services of ethereum nodes. In Pro-

ceedings of the 31st ACM Joint European Software

Engineering Conference and Symposium on the Foun-

dations of Software Engineering, pages 1333–1344.

Le, T.-V. and Hsu, C.-L. (2021). A systematic literature re-

view of blockchain technology: Security properties,

applications and challenges. Journal of Internet Tech-

nology, 22(4):789–802.

Lopez Martinez, A., Gil P

erez, M., and Ruiz-Mart

ınez, A.

(2023). A comprehensive review of the state-of-the-

art on security and privacy issues in healthcare. ACM

Computing Surveys, 55(12):1–38.

Mulamba, D. and Ray, I. (2017). Resilient reference moni-

tor for distributed access control via moving target de-

fense. In Data and Applications Security and Privacy

XXXI: 31st Annual IFIP WG 11.3 Conference, DBSec

2017, Philadelphia, PA, USA, July 19-21, 2017, Pro-

ceedings 31, pages 20–40. Springer.

Rights (OCR), O. f. C. (2008). HIPAA Enforcement. Last

Modiﬁed: 2021-06-28T08:59:34-0400.

Samuel, C. N., Glock, S., Verdier, F., and Guitton-

Ouhamou, P. (2021). Choice of ethereum clients for

private blockchain: Assessment from proof of author-

ity perspective. In 2021 IEEE International Con-

ference on Blockchain and Cryptocurrency (ICBC),

pages 1–5. IEEE.

Shah, M., Li, C., Sheng, M., Zhang, Y., and Xing, C.

(2019). Crowdmed: A blockchain-based approach to

consent management for health data sharing. In Smart

Health: International Conference, ICSH 2019, Shen-

zhen, China, July 1–2, 2019, Proceedings 7, pages

345–356. Springer.

Timmermans, S. (2020). The engaged patient: The

relevance of patient–physician communication for

twenty-ﬁrst-century health. Journal of Health and So-

cial Behavior, 61(3):259–273.

Zhuang, Y., Sheets, L. R., Chen, Y.-W., Shae, Z.-Y., Tsai,

J. J., and Shyu, C.-R. (2020). A patient-centric health

information exchange framework using blockchain

technology. IEEE journal of biomedical and health

informatics, 24(8):2169–2176.

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

223