Did You Break the Glass Properly? A Policy Compliance Framework for
Protected Health Information (PHI) Emergency Access
Md Al Amin
a
, Rushabh Shah
b
, Hemanth Tummala
c
and Indrajit Ray
d
Computer Science Department, Colorado State University, Fort Collins, Colorado, U.S.A.
Keywords:
Emergency Access, Patient Consent, Break Glass Protocol, Policy Compliance, Blockchain, Smart Contract.
Abstract:
HIPAA, HITECH, GDPR, and other data protection laws and regulations mandate patients’ consent to access
and share their data. They also impose compliance requirements for healthcare organizations. Non-compliance
cases or failure to comply come with financial, reputational, business, and other penalties. In emergency
medical situations, accessing a patient’s protected health information or records can be critical to saving lives,
especially when the patient is unconscious or unable to consent. This paper addresses the need for a secure,
compliant, auditable system for emergency PHI access. We propose a blockchain and smart contract-based
policy compliance framework where the emergency duty doctor requests access and must obtain approval
from the senior in charge, which is recorded through multi-signature transactions. Once access is granted, the
patient or their emergency contact is notified. To prevent unauthorized modifications, all actions are captured
as immutable audit logs within a private blockchain network. The compliance check uses a novel Proof
of Compliance (PoC) consensus mechanism, ensuring all access requests adhere to defined policies. This
framework offers transparency, accountability, and security for emergency PHI access requirements.
1 INTRODUCTION
The digitization of healthcare data brings numerous
benefits, including improved access to information
and enabling real-time and remote care, sophisticated
services, etc (King et al., 2014). It enhances pa-
tient outcomes by providing healthcare professionals
with a comprehensive medical history and support-
ing coordinated care. Efficiency increases as admin-
istrative processes are streamlined, reducing errors
and paperwork (Menachemi and Collum, 2011). As
healthcare data becomes increasingly digitized, dis-
tributed, and interactive, concerns about the patient
privacy and security of healthcare information and
systems are growing within the healthcare ecosys-
tem (Fern
´
andez-Alem
´
an et al., 2013). Various secu-
rity and privacy regulations are imposed worldwide
to protect patient privacy and data security. HIPAA
& HITECH (USA), GDPR (EU, UK), APPs (Aus-
tralia), PIPEDA (Canada), APPI (Japan), and others
are adequate data security and privacy laws. These
a
https://orcid.org/0000-0003-1700-7201
b
https://orcid.org/0009-0005-5658-0950
c
https://orcid.org/0009-0007-7778-5845
d
https://orcid.org/0000-0002-3612-7738
privacy and data protection laws and regulations com-
monly dictate that data subjects, particularly patients
in the healthcare industry, must provide consent to
process their data as required for the intended pur-
poses. Without permission, data should not be col-
lected, processed, used, or shared beyond the men-
tioned purposes while collecting data to avoid secu-
rity and privacy violations and lawsuits.
Healthcare providers and other users mainly ac-
cess patients’ healthcare data in three different cir-
cumstances: (i) accessed by the treatment team mem-
bers for providing treatment and services and per-
forming business operations; (ii) shared with oth-
ers beyond the treatment team, including enhancing
diagnosis and treatment plans through consultations
with specialists, research and marketing endeavors,
and others; (iii) emergency access when a patient
is unconscious or insured and admitted in an emer-
gency room in a life-and-death situation. Healthcare
providers usually take consent for treatment and shar-
ing purposes. Due to the uncertainty of the emer-
gency, permission is not taken in advance. Also, an
emergency may be far from the home or primary care
provider. However, getting consent from the admitted
or injured patient is impossible during an emergency
as the patient is unconscious or incapacitated. It is
Al Amin, M., Shah, R., Tummala, H. and Ray, I.
Did You Break the Glass Properly? A Policy Compliance Framework for Protected Health Information (PHI) Emergency Access.
DOI: 10.5220/0013527000003979
In Proceedings of the 22nd International Conference on Security and Cryptography (SECRYPT 2025), pages 195-208
ISBN: 978-989-758-760-3; ISSN: 2184-7711
Copyright © 2025 by Paper published under CC license (CC BY-NC-ND 4.0)
195
a life-and-death situation. Healthcare providers may
need to bypass traditional consent processes to access
PHI for life-saving treatment. The ”break glass” pro-
tocol or emergency access control is used (Ferreira
et al., 2006). However, this access must comply with
strict policy and regulatory requirements to protect
health records, patients’ privacy, and accountability.
Security and privacy policy compliance require-
ments for emergency access include, but are not lim-
ited to (A) patient must be experiencing a medical
emergency and unconscious or unable to give con-
sents to access PHI; (B) provider (hence known as
Requester) must get approval from seniors (hence
known as Approver) in charge to access PHI, (C) se-
niors in charge must determine the emergency and
give approval; (D) PHI access must be done from
the emergency room or patient carrying ambulance;
(E) PHI access activities (audit logs) must be stored
and not modified once recorded under any situations;
(F) compliance review or audit must be done after
treatment has been done without any delay according
to the applicable policies; (G) patient or emergency
contact person must be notified about PHI access;
(H) separation-of-duty must be maintained and en-
forced strictly to keep functionalities of the requester,
approver, audit log unit, and auditors; (I) Last but
not least, least privileges and need-to-know must be
maintained to make sure that the requester can access
no less-no more health records to provide treatment
and services to contain the situation and make the pa-
tient stable. In addition to these requirements, oth-
ers might be based on the organization’s business na-
ture, regulations, legal jurisdictions, contractual obli-
gations, etc.
Current research and practice focus on ensuring
compliance requirements in an isolated and not timely
manner. The following issues must be addressed for
compliance assurance: (a) requester and approver
must be accountable; (b) audit logs must be captured
as they happened and protected from modifications
under any situations by any users; (c) enforcing sep-
aration of duty to ensure that not a single entity can
manipulate every step; (d) maintaining least privilege
and need-to-know for protecting healthcare data and
patient privacy by not disclosing some PHI locked
by the patient; (e) assuring that after accessing PHI
compliance review must be done quickly to check the
compliance status and inform patient or emergency
contact personnel without any delays.
This paper proposes a policy compliance frame-
work for emergency PHI access to overcome the
abovementioned issues and ensure streamlined pol-
icy compliance assurance. The proposed approach
captures required information, stores it, and performs
compliance reviews. A provider or requester sub-
mits an emergency access request for an admitted pa-
tient. Then, the senior in charge or approver evalu-
ates the patient’s condition and determines the crit-
icality of the situation. If it is an absolute emer-
gency, then the approver endorses the request. At
this point, both the requester and approver sign the re-
quest as a multi-signature transaction using their cor-
responding private keys. A signed transaction is sub-
mitted to the blockchain network. Multi-signature-
based blockchain transactions ensure that no single
entity can submit transactions in the network. Emer-
gency PHI access activities are captured and stored
in a private audit blockchain to provide an immutable
access history for compliance review. Finally, a com-
pliance review process is proposed using a blockchain
consensus mechanism called Proof of Compliance.
Where a set of independent, decentralized, and dis-
tributed audit nodes perform compliance checking us-
ing provenance information.
Blockchain technology has inherent properties:
security, transparency, and immutability (Conte de
Leon et al., 2017). At its core, it is a distributed ledger
technology that records transactions across multiple
nodes so that the registered transactions cannot be
altered. This feature ensures the integrity of data
once it has been committed to the blockchain and sig-
nificantly increases the system’s fault tolerance and
reliability. Integrating multi-signature transactions
(Aitzhan and Svetinovic, 2016) at the core of the pro-
posed approach is essential for establishing a decen-
tralized and immutable record of interactions.
To the best of our knowledge, this work is the
first to capture and enforce a multi-signature-based
emergency PHI access policy compliance assurance
framework. This paper makes the following contribu-
tions: (i) Integrating patient consent into the patient-
provider agreement (PPA) and enforcing it while
making an emergency PHI access decision. (ii) Lever-
aging Approver to evaluate and determine the PHI
and access level for the submitted request by the Re-
quester to ensure the least privilege and need-to-know
basis emergency PHI access. (iii) Smart contract-
based separation-of-duties enforcement to ensure that
Requester, Approver, Provenance Unit, and Com-
pliance Reviewer are separate and independent en-
tities. (iv) Storing approval request information in
the public blockchain using a multi-signature transac-
tion scheme. So, the Requester and Approver cannot
deny their actions, making them accountable for prov-
ing compliance assurance. (v) Implementing audit
log provenance using a private blockchain to provide
immutable PHI emergency access activity data. (vi)
Performing compliance review using a decentralized
SECRYPT 2025 - 22nd International Conference on Security and Cryptography
196
and distributed consensus mechanism called Proof of
Compliance to determine the compliance status of ev-
ery emergency PHI access. (vii) Conducting exten-
sive experimental evaluations for the proposed ap-
proach on required smart contract deployment, PPA
integrity, and informed consent storage and retrieval.
(viii) Last but not least, performing and analyzing the
gas costs, in token and USD, for informed consent
and other required smart contract deployment, storing
PPA integrity, and informed consent. Also, analyz-
ing the time requirements for writing and reading data
to/from the blockchain network.
2 PHI ACCESS CLASSIFICATION
This section outlines different access scenarios for
healthcare data, including (i) treatment team access,
(ii) sharing beyond the team, and (iii) emergency ac-
cess, as depicted in Figure 1. Figure 2 shows sample
health records with PHI ID, name, and description.
01
03
PHI Access
Treatment Team
02
Sharing Beyond
Treatment Team
Emergency Access
Figure 1: PHI Access Classification.
2.1 Treatment Team Access
Authorized treatment team members access health-
care data within healthcare systems to provide re-
quired medical care and services and perform health-
care operations. This includes doctors, nurses, and
specialists collaborating to make informed decisions
about diagnosis, treatment plans, and ongoing care.
In addition to direct patient care, health records are
used to perform essential business operations such
as billing, insurance claims, scheduling, and quality
assurance processes. Ensuring seamless access for
healthcare providers while maintaining data privacy
and security is critical. Robust access controls and
encryption protocols are essential to safeguard sensi-
tive information from unauthorized access or poten-
tial data breaches. The authors propose a consent-
based PHI access compliance approach (Al Amin
et al., 2023) for this group.
Figure 2: Sample Protected Health Information (PHI).
2.2 Sharing Beyond Treatment Team
Healthcare data is often shared with others beyond di-
rect care providers to enhance patient outcomes and
drive broader healthcare initiatives. Consultations
with specialists, for instance, allow for more accurate
diagnoses and more effective treatment plans. Health-
care data is also leveraged in research to identify
trends, develop new treatments, and improve overall
healthcare quality. Furthermore, anonymized patient
information may be used for marketing purposes,
such as promoting relevant health services. How-
ever, these practices require strict compliance with
data protection regulations to maintain patient privacy
and consent. The authors in (Al Amin et al., 2024)
proposed a policy compliance assurance framework
using patient consent for PHI sharing.
2.3 Emergency Access
In life-and-death situations, such as when a patient is
unconscious or critically injured and admitted to the
emergency room, immediate access to their health-
care information becomes crucial for treatment. Un-
der normal circumstances, healthcare providers seek
consent from patients before accessing their medical
data or sharing it with other specialists. However, in
emergencies, consent cannot be obtained in advance
due to the unpredictable nature of the situation. Addi-
tionally, emergencies may occur far from a patient’s
home or primary care provider, further complicating
access to their medical history. In these scenarios, ob-
taining consent from the injured or incapacitated pa-
tient is impossible, as they may be unconscious or un-
able to communicate. This creates a unique challenge
for healthcare professionals, who must act swiftly to
provide life-saving care.
Emergency access protocols, such as the Break-
Glass Protocol, allow healthcare providers to bypass
consent temporarily, ensuring they can access essen-
tial information while maintaining compliance with
privacy regulations and audit controls. If a patient is
admitted to the same hospital, which is the primary
care provider. Transferring data is unnecessary since
doctors would access it from the same EHR system.
Data access can be done from the emergency room
Did You Break the Glass Properly? A Policy Compliance Framework for Protected Health Information (PHI) Emergency Access
197
while treating the patient or in the ambulance while
transferring a patient from the home or accident place
to the hospital. When a patient gets regular treatment
and medical services from one hospital but is admit-
ted to another hospital for emergency treatment. The
patient’s health data must be shared between the pri-
mary and current providers. Providers must satisfy
additional data protection and patient privacy require-
ments for transferring data. We assume data is trans-
ferred from the primary provider to the emergency
provider through the proper channel.
This paper does not focus on policy compliance
related to treatment team access and sharing of PHI.
Instead, it addresses emergency access policy com-
pliance, proposing a blockchain and smart contract-
based multi-signature approval system, with audit
logs stored on a private blockchain and compliance
status verified through a PoC consensus mechanism.
3 RELATED WORKS
Yang et al. (Yang et al., 2017) introduced a novel
lightweight break-glass access control (LiBAC) sys-
tem designed for the Healthcare IoT, enhancing the
security and accessibility of medical data. The sys-
tem employs a dual access method: attribute-based
for regular use and break-glass for emergencies, en-
suring timely access to patient information by autho-
rized personnel. The LiBAC is rigorously proven se-
cure under the standard model, with formal proof pro-
vided to substantiate its resilience against potential
cyber threats. Despite its efficiencies, the model re-
lies heavily on a predefined set of emergency contacts,
potentially limiting its effectiveness in unexpected sit-
uations where those contacts may not be available or
when new, unforeseen stakeholders need access.
Loos et al. (Loos, 2020) investigated the ten-
sion between emergency accessibility and security in
medical devices, highlighting the absence of com-
prehensive break-glass systems tailored for such de-
vices. They categorized break-glass mechanisms into
patient records and medical devices. The authors ex-
plore emergency access solutions such as proximity-
based access, biometric authentication, UV tattoos,
RFID chips, and passive radiopaque markers. De-
spite proposing innovative mechanisms, they under-
score challenges like balancing usability and security,
patient acceptance, and lack of standardization. The
paper urges further research into unified security pro-
tocols that reconcile emergency access needs with ro-
bust patient data protection.
Aski et al. (Aski et al., 2021) proposed integrating
break-glass mechanisms with attribute-based access
control (ABAC) to address emergencies in healthcare
IoT systems. In addition to authorizing users in nor-
mal situations, they introduced a break-glass mecha-
nism allowing emergency situation handlers (ESH) to
handle emergencies. The ESH bypasses standard au-
thentication and swiftly accesses critical patient data
when immediate medical action is required. Security
measures include data encryption and key manage-
ment, with ESH verification through pre-distributed
passwords to prevent misuse. Experimental analysis
indicates the scheme’s efficiency compared to exist-
ing access control systems.
Schefer-Wenzl et al. (Schefer-Wenzl et al., 2013)
surveyed to investigate the delegation and break-
glass-based emergency access control where the stan-
dard access policies are insufficient. In delega-
tion models, a user is allowed to transfer access
rights or roles to another, discussing role-based and
permission-based approaches while considering con-
straints like separation of duty (SoD) and binding of
duty (BoD). The break-glass models are designed for
emergencies, enabling temporary bypass of standard
access controls with actions logged to prevent mis-
use. Analyzing 329 articles and detailing 35 key ap-
proaches, the authors compare models based on pol-
icy enforcement, support for entailment constraints,
and integration with business processes.
Van Bael et al. (Bael et al., 2020) described a
new access control system that uses IoT sensors to
gather contextual data, making break-glass mecha-
nisms more flexible in an emergency. It includes
non-repudiation features by logging all actions during
a break-glass event, ensuring accountability through
evidence like biometric data or badge scans. A fail-
safe mechanism is also incorporated to cancel emer-
gency access if activated erroneously. However, the
prototype shows it is possible and has reasonable re-
sponse times. The proposed approach relies on the
availability and dependability of IoT sensors. It is
vulnerable if the integrity of contextual data is com-
promised, and it is hard to set up complete access poli-
cies for all emergencies.
The papers above summarized the application of
emergency access control mechanisms like the break-
glass protocol. However, they failed to address the
security and privacy compliance requirements man-
dated by various laws and regulatory agencies, such
as HIPAA and GDPR. This paper proposes a policy
compliance framework for emergency PHI access to
ensure that applicable security and privacy policies
are followed while accessing PHI and saving patient
life in a critical moment.
SECRYPT 2025 - 22nd International Conference on Security and Cryptography
198
4 PROPOSED APPROACH
The primary goal is to enforce necessary consents
and policies for emergency access, capturing essential
PHI access activity to verify compliance with security
and privacy requirements. Proper policy enforcement
is crucial to ensuring compliance with preserving
provenance records and conducting timely compli-
ance reviews to maintain a secure and compliant sys-
tem. For enforcement, this paper considers patient-
informed consent, where the patient locks any PHI to
keep it restricted from access during an emergency.
This work leverages multi-signature-based access re-
quest approval to ensure that PHI is not accessed un-
necessarily. The emergency PHI access activities are
captured and recorded in a private blockchain net-
work as audit logs to provide provenance and recon-
struct events that reflect their actual occurrence. Fi-
nally, a blockchain consensus mechanism (PoC) is ap-
proached to examine the enforcement actions against
the applied policy and informed consent, using the
provenance data to verify and certify the compliance
status.
4.1 Patient-Provider Agreement (PPA)
The patient-provider agreement (PPA) defines the re-
sponsibilities of each party in a treatment scenario
(Albrecht et al., 2015). It is established when a pa-
tient visits a hospital and is documented to facilitate
healthcare services. The specifics of a PPA vary by
organization and are tailored to match the treatment
needs and responsibilities required. The components
and format of the PPA also differ depending on the
hospital or clinic. Figure 3 shows the structure of
a PPA. The central concept of PPA is adopted from
(Al Amin et al., 2023; Al Amin et al., 2024). The
authors focused on consent management for medi-
cal treatment and diagnosis purposes, mainly for the
treatment team members and health data sharing be-
yond the treatment team. They did not include pa-
tient consent for emergency access. This paper ex-
tends the PPA structure to analyze the requirements
and formalize the consent components for emergency
PHI access.
A PPA is formally composed of six (6) tuples:
PPA = (PC, PrC, TIC, SIC, EIC, ROC)
satisfying the following requirements:
(A) PC is a finite 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-
Patient-Provider
Agreement (PPA)
Patient
Provider
Agreement
Patient Component (PC)
§Patient Component 1
§Patient Component 2
……………..............
§Patient Component M
Provider Component (PrC)
§Provider Component 1
§Provider Component 2
……….......................
§Provider Component N
Treatment Informed Consent (TIC)
§Trea tment Informed Consent 1
§Trea tment Informed Consent 2
…………………............…....
§Trea tment Informed Consent T
Regulatory and Others Component (ROC)
§Regulatory and Others Component 1
§Regulatory and Others Component 2
…………........................…………....
§ Regulatory and Others Component R
Sharing Informed Consent (SIC)
§Sharing Informed Consent 1
§Sharing Informed Consent 2
……………..........………....
§Sharing Informed Consent S
Emergency Informed Consent (EIC)
§Emergency Informed Consent 1
§Emergency Informed Consent 2
……………..........………....
§Emergency Informed Consent E
Figure 3: Patient-Provider Agreement (PPA) Components.
sible for providing and maintaining these compo-
nents’ valid, accurate, and updated information.
(B) PrC is a finite 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.
(C) T IC is a finite set of treatment-informed con-
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 officers, emergency contact per-
sons, and others assigned by the authority. Some
outsider members are insurance agents, pharma-
cists, pharmacy technicians, doctors, lab techni-
cians from another hospital, etc.
(D) SIC is a finite set of sharing informed consent
components for sharing PHI beyond the treatment
team to get better services. It denotes the patient’s
consent to sharing medical data for specific pur-
poses: treatment, diagnosis, marketing, and re-
search. Both the sender and the receiver must
have permission to share data.
(E) EIC is a finite set of emergency informed con-
sent components. It denotes that the patient has
permitted the designated treatment team to ac-
cess medical records. The primary purpose of
this work is EIC, including (i) identifying, captur-
ing, and storing consent components; (ii) enforc-
ing consents with other applicable security poli-
cies and industry best practices to ensure policy
Did You Break the Glass Properly? A Policy Compliance Framework for Protected Health Information (PHI) Emergency Access
199
compliance while making emergency PHI access
decisions; (iii) defining and capturing provenance
information with the enforced consents to main-
tain audit logs; (iv) performing compliance check-
ing using consensus mechanisms; (v) providing
services for both given and executed consents, etc.
It does not consider other components: PC, PrC,
T IC, SIC, and ROC.
(F) ROC represents a finite set of regulatory compo-
nents and other relevant elements. It encompasses
applicable security and privacy policies required
to meet the compliance standards of various gov-
ernmental levels—local, state, federal, and inter-
national—as well as regulatory bodies such as
HIPAA and GDPR. Additionally, it may incorpo-
rate contractual obligations where applicable.
4.2 Emergency Informed Consent (EIC)
Before approval, patients must know about the emer-
gency informed consent, particularly which PHI must
be locked from access. Figure 4 shows the EIC con-
ceptual structure. Emergency informed consent is for-
mally composed of two tuples:
EIC = (PHI, LS)
satisfying the following requirements:
(a) PHI is a finite set, d number, of health records de-
noted by {phi
1
, phi
2
, phi
3
, ......phi
d
}. It is a dig-
ital version of a patient’s medical history main-
tained by healthcare providers over time. Classi-
fied as protected health information (PHI), it con-
tains sensitive patient details that must be safe-
guarded against unauthorized access, disclosure,
and sharing. Figure 2 illustrates ten types of PHI
considered for each patient, including PHI ID,
name, and description. In emergencies, health-
care providers access these records to deliver life-
saving treatments.
(b) LS is the lock status of the intended PHI with
two values: Locked and Unlocked. A finite set
of lock statuses, a d number, can be denoted as
{ls
1
, ls
2
, ls
3
, ......ls
d
}. The Locked status indicates
the PHI cannot be accessed at any moment under
any circumstances. The providers cannot access
Locked PHI during an emergency. While PHI can
be accessed during an emergency if the lock sta-
tus is Unlocked. The patient must consult with the
corresponding providers to review before locking
PHI. It should not create any burden for giving
life-saving treatment during an emergency.
There is a one-to-one mapping between each PHI
and its lock status: (phi
1
, ls
1
), . . . , (phi
d
, ls
d
). This
Lock Status (LS)
attr
R
.....attr
3
attr
2
attr
1
----
LS
1
----
LS
2
----
.....
----
LS
d
Protected Health Information (PHI)
attr
D
.....attr
3
attr
2
attr
1
----
PHI
1
----
PHI
2
----
.....
----
PHI
d
Emergency Informed Consent (EIC)
LOCK STATUSHEALTH DATAEIC ID
--
EIC
1
--
EIC
2
--
.....
--
EIC
n
Figure 4: Emergency Informed Consent (EIC) Structure.
mapping ensures that patient privacy is respected and
health records security is maintained during emer-
gency access.
4.3 EIC Smart Contract Deployment
Once a PPA is established and stored in the repository,
all components of the emergency informed consent
are deployed as smart contracts within the blockchain
network. Figure 5 illustrates the deployment process
of the EIC smart contracts. The Smart Contract De-
ployment Unit (SCDU) first collects all components
of the informed consent from the PPA described in
Step 4. It then verifies the integrity of these compo-
nents in Step 5 to confirm that no deliberate or acci-
dental modifications have occurred. Operating as a
secure entity, the SCDU ensures that any alterations
would invalidate the consent. If the consent compo-
nents are confirmed to be unaltered, the SCDU cre-
ates and deploys the corresponding smart contracts
on the blockchain network in Step 6. Subsequently,
it updates the patient’s profile and the hospital sys-
tem in Step 7. In Step 8, users with the appropriate
credentials can query and receive responses regard-
ing informed consent directly from the blockchain
network. This smart contract-based approach offers
an automated system that ensures the integrity and
accountability of deployed consents. Once consents
are integrated into the smart contract, they become
immutable, preventing alterations. The authorization
module interacts with these smart contracts, utilizing
them alongside other components to make emergency
PHI access decisions.
4.4 Emergency Access Authorization
Consent enforcement ensures that related consents are
executed while making decisions for the emergency
PHI access requests. All consents are stored on the
public blockchain network as smart contracts and can-
SECRYPT 2025 - 22nd International Conference on Security and Cryptography
200
Patient Profile
Hospital System
Patient
Provider
1 Agreement
Emergency Informed Consent (EIC)
§ Emergency Informed Consent 1
§ Emergency Informed Consent 2
§ Emergency Informed Consent 3
……………………....
§ Emergency Informed Consent N
Secured PPA Repository
Smart Contract Deployment
Unit (SCDU)
2 Format
Translation
4 EIC Components
Patient Provider Agreement
(PPA)
5 EIC Integrity Check
6 EIC Smart Contract
3 PPA Integrity
7 Update EIC
Information
8 Consent Query
Response
Public Blockchain
Network
Figure 5: EIC Smart Contract Deployment Process.
not be enforced until they are called. The authoriza-
tion module (AM), like Break-Glass Protocol, con-
siders emergency informed consent with applicable
policy and required attributes while making decisions.
The attributes may be subject, object, operation, and
environmental attributes. The Requester must pro-
vide the necessary credentials for identification and
authentication. Figure 6 shows the informed consent
enforcement for the emergency PHI access authoriza-
tion and policy compliance assurance framework.
The Requester submits an emergency PHI access
request to the Approver in Step 1. The Approver
evaluates and determines the urgency of the admit-
ted patient. Then, the Approver approves the access
requests through the Multi-Signature Approval Sys-
tem (MSAS) in Step 2. Both Approver and Requester
use their private keys to sign the transaction. The
signed request is submitted to the public blockchain
networks like Ethereum in Step 3 to be added to the
distributed ledger. Later, this deployed transaction
is a source of truth to hold the signers accountable.
In Step 4, the approved request is forwarded to an
emergency authorization module (AM) like Break-
Glass Protocol for PHI access authorization decision.
The AM queries the blockchain network through the
corresponding smart contract to get emergency in-
formed consent information and signed request ap-
proval transactions for the submitted access request
in Step 6a. It also makes queries for requests related
to applicable policies and required attributes in Steps
6b and 6c.
After evaluating, it makes an authorization deci-
sion and sends it to the EHR in Step 7 and notification
to the patient’s emergency contact in Step 8. If the ac-
cess request is approved, the intended PHI is delivered
to the Requester in Step 11. The audit logs recording
unit, ALRU, collects logs from the MSAS in Step 5
and from the AM in Step 9. It combines logs and
stores them as audit logs in Step 6c in Private Audit
Blockchain. Section 5 discusses block structure and
others. The compliance review is done in Steps 12a,
12b, and 12c by the Proof of Compliance consensus
mechanism. Compliance status reports are produced
in Step 12d. Section 6 discusses the required mech-
anism. For this study, it is considered that the au-
thorization module is not compromised or tampered
with. It is the reference monitor for making access de-
cisions and must be tamper-proof (Mulamba and Ray,
2017). Also, the communication channel between AM
and the smart contract access points or apps is secured
from malicious users.
4.5 Separation-of-Duty Enforcement
There are four significant actors in the proposed ap-
proach: (i) the Requester who submits the request
to access patient data; (ii) the Approver who evalu-
ates the situation and determines the level of access
required by the Requester; (iii) the Provenance Unit
who maintains all audit logs and applied policies; and
(iv) the Compliance Reviewer who performs com-
pliance checking to determine the compliance status
for every emergency access. These four actors must
be different entities from each other. No one entity
should perform more than one task. Figure 7 depicts
the SoD requirements for emergency PHI access com-
pliance. This proposed approach delegates smart con-
tracts to enforce separation-of-duty among those enti-
ties to avoid conflicts of interest.
Figure 8 shows the SoD enforcement approach for
the entities that must be separated for various phases.
In Phase 1, the Requster and Approver must be dif-
ferent users. The MSAS checks and enforces this con-
dition during the request approval process by the Ap-
prover, as shown in Figure 6. In the next Phase 2, it is
ensured that the Provenance Unit is different from the
Requster and Approver. The ALRU ensures that while
collecting and storing audit logs in the private audit
blockchain. Finally, it is ensured that the Compli-
ance Reviewer is a separate entity from the Requster,
Approver, and Provenance Unit (Phase 3). The pro-
posed Proof of Compliance maintains the Phase 3
conditions while performing the compliance review.
5 PHI ACCESS 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 iso-
Did You Break the Glass Properly? A Policy Compliance Framework for Protected Health Information (PHI) Emergency Access
201
Proof of Compliance
(PoC)
Policy
Repository
Private Audit Blockchain
Requester
11 Requested PHI
Emergency
Contact
EHR - PHI
Compliance Review
10 Audit Logs
12a PHI Access
Approval Info
12d
Compliance
Report
Audit Logs
Recording Unit
(ALRU)
Public Blockchain
Network
Attribute
Repository
Approver
Multi-Signature
Approval System
(MSAS)
Authorization Module
(AM)
(Break-Glass Protocol)
4 Request
Approved
1 Emergency
PHI Access
Request
2 Request
Review and
Approval
3 Approved
PHI Access
Request
5 Multi-
Signature
Logs
6b Policy
6c Attributes
7 PHI Access Decision
8 Notifications
9 Authorization Logs
12b Audit Logs
12c
Applied
Policy
Healthcare System
6a Patient Consent and Approval Info
Figure 6: Proposed Emergency PHI Access Policy Compliance Assurance Framework.
Provenance
Unit
Compliance
Reviewer
ApproverRequester
SoD
Figure 7: Separation-of-Duty (SoD) Requirements.
Phase 1: Requester ≠"Approver
Phase 2: Requester ≠"Approver"≠ Provenance Unit
Phase 3: Requester ≠"Approver Provenance Unit Compliance Reviewer
Figure 8: Proposed Separation-of-Duty (SoD) Enforce-
ment.
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) emergency PHI ac-
cess request approval and (ii) emergency PHI access
audit logs. This section contains detailed provenance
mechanisms dedicated to preserving the integrity of
emergency PHI access request approvals and ensur-
ing the audit logs’ authenticity.
5.1 Emergency PHI Access Approval
After submitting the emergency access request, the
Approver evaluates and determines the situation to
make the decision. If conditions demand, the sub-
mitted request is approved and forwarded to the au-
thorization module for the final PHI access decision.
Both request and approval make a transaction signed
by the Requester and Approver using their private
keys or wallets. The signed transaction is submit-
ted and recorded in the public blockchain to pro-
vide an unaltered source of truth regarding emergency
PHI access compliance review. This is done through
the multi-signature scheme of blockchain technology
(Aitzhan and Svetinovic, 2016). Due to the crypto-
graphic properties, both Requester and Approver can-
not deny their actions regarding PHI access.
5.2 Emergency PHI Access Audit Logs
Integrity in policy enforcement ensures that events are
documented faithfully, reflecting the sequence and na-
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 find compliance and non-compliance
cases is questionable. The blockchain provides these
requirements as ledger properties. This work adopts a
private blockchain as an audit log storage system.
Figure 9 illustrates the private audit blockchain’s
SECRYPT 2025 - 22nd International Conference on Security and Cryptography
202
Block Hash
Block Hash
Genesis Block
.
1
st
Block
2
nd
Block
N
th
Block
Block Header
Previous Block Hash
Hash Difficulty Target
ALT Unit Hash
Block Hash
Block Nonce
Block Timestamp
Audit Log Data
Audit Log - 1
Audit Log - 2
Audit Log - 3
Audit Log - M
Audit Log Transaction (ALT) Unit
Block Data
Block Data
Previous Block Hash
Audit Log
ID
Approver
ID
Patient
ID
PHI
ID
Requester
ID
PHI Access
Location
Timestamp
Data
Figure 9: Audit Blockchain Block Structure.
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 log
has seven components: (i) audit log ID; (ii) patient
ID; (iii) PHI ID; (iv) Requester ID; (v) Approver ID;
(vi) PHI access location; and (vii) timestamp data.
The audit log ID uniquely identifies each access
log, while the patient ID refers to the patient receiv-
ing emergency life-saving treatment. The PHI ID
indicates the specific health records accessed during
treatment, as depicted in Figure 2. Patients can lock
any particular health record in EIC. The Requester ID
identifies the healthcare provider treating the admitted
patient who needs access to the patient data. The Ap-
prover ID belongs to the person responsible for eval-
uating and endorsing the access request based on the
current situation for authorization. These access re-
quests and endorsements are securely recorded on a
public blockchain network like Ethereum through a
multi-signature process, ensuring non-repudiation by
involved parties. The PHI access location identifies
the physical setting, such as an emergency room or
an ambulance, from which healthcare records are ac-
cessed. Finally, the timestamp means the time when
the access authorization is done. Steps 5 and 9 in Fig-
ure 6 show the process of capturing audit logs from
the MSAS and AM. The ALRU stores audit logs in a
private audit blockchain in Step 10.
6 COMPLIANCE REVIEW
Simply maintaining audit logs and enforcing in-
formed consent and policies does not guarantee com-
pliance. A mechanism that can verify compliance sta-
tus using these elements is crucial. This paper intro-
duces a blockchain-based Proof of Compliance (PoC)
consensus mechanism designed to validate compli-
ance through the utilization of audit logs, informed
consent (EIC), and other relevant policies. The PoC
is governed by independent, distributed auditor nodes,
which operate separately from the units, enforcing
policies and managing provenance, ensuring unbiased
compliance verification. Figure 10 shows the decision
mechanism of PoC.
6.1 Decision Counting Threshold
Assume s auditor nodes are in the PoC network. A
batch of transactions is processed to assess compli-
ance status, but it is not guaranteed to receive re-
sponses from all s nodes. Responses may be miss-
ing due to various reasons such as connectivity issues,
power failures, intentional non-submission, or auditor
nodes going offline unexpectedly due to system errors
(Haeberlen et al., 2007). Now, consider that m is the
number of responses from the auditors out of s. A
required threshold, η, must be satisfied to make the
compliance decision for an audit log. The following
conditions must be satisfied to make the compliance
decision:
(i)s m and (ii)s m η or s D
m
η
Where D
m
is the number of received decisions from
the m number of auditors (A), and η is the minimum
number of decisions that must be present to make the
decision. If there is no loss, this s = m is ideal. Then
the conditions became:
(i)m η or D
m
η
In the ideal case, all auditors receive the required
information and return results after the compliance
evaluation. The value of the η is determined and
influenced by the design decision, the organization’s
business nature, legal requirements, contractual obli-
gations, and others. If m < η or D
m
< η, the compli-
ance status is assigned as ”Not-Determined” to avoid
any policy violation, it must be further investigated to
check the reasons.
6.2 Auditors and Decisions
Let m be the total number of auditor nodes; the fol-
lowing information is given. The final compliance
decision is derived based on a majority rule among
decisions.
Let A = {α
1
, α
2
, α
3
, . . . , α
m
} is defined as a set
of auditors, where each α
i
represents an individ-
ual auditor node. These nodes are responsible
for checking the compliance requirements. Au-
ditor nodes can be hospitals, local governments,
Did You Break the Glass Properly? A Policy Compliance Framework for Protected Health Information (PHI) Emergency Access
203
Figure 10: Proof of Compliance Decision Mechanism.
state governments, the federal government, reg-
ulatory agencies, insurance companies, business
associates, accreditation bodies, independent au-
ditors, and others from contractual obligations.
Let D be a set of decisions correspond-
ing to each auditor in A, defined as D =
{δ
1
, δ
2
, δ
3
, . . . , δ
m
}, where δ
i
is the decision made
by the α
i
auditor node for a given transaction,
where δ
i
{Compliant, Non Compliant, Not
Determined}
There is a one-to-one mapping between each au-
ditor node and its decision: (α
1
, δ
1
), . . . , (α
m
, δ
m
)
since each auditor node α
i
in set A makes a com-
pliance decision δ
i
in set D. Therefore,. This
mapping allows us to analyze the decisions col-
lectively and apply the PoC decision combining
algorithm to determine the compliance status.
6.3 Decision Counting Process
The total counts for each type of decision are calcu-
lated as follows, where 𭟋(.) is an indicator function
that equals 1 if the inside condition is true and 0 oth-
erwise.
(a) C =
m
i=1
𭟋(D
i
= Complaint)
(b) N =
m
i=1
𭟋(D
i
= Non Complaint)
(c) U =
m
i=1
𭟋(D
i
= Not Determined)
6.4 Decision Combining Process
After counting, the final decision is made, and the
distinct combinations are given in Table 1. The Not-
Determined dictates to others if they are equal to it.
Table 1: PoC Decision Combining Scope.
SN Decision Counting Combination Final Decision (D
f inal
)
1 C > N > U C
2 C > U > N C
3 C > N = U C
4 N > C > U N
5 N > U > C N
6 N > C = U N
7 N = C > U N
8 U > C > N U
9 U > N > C U
10 U = C > N U
11 U > C = N U
12 U = N > C U
13 C = N = U U
The final decision D
f inal
can then be set based on pre-
defined majority rules, such as:
Compliant Majority: This decision is made
when the majority decision is Complaint or C >
N and C > U out of m decisions made by the au-
ditors regardless N > U or U > N or U = N.
Non-Compliant Majority: This decision is made
when the majority decision is Non-Complaint or
N > C and N > U out of m decisions made by the
auditors regardless C > U or U > C or C = U.
Not-Determined Majority: This decision is made
when the majority decision is Not-Determined
or (i) U > C and U > N, or (ii) U = C = U, or
(iii) U = C > U , or (iv) U = N > C out of m
decisions made by the auditors regardless C >
N or N > C or C = N.
6.5 PoC Compliance Report
After determining the compliance status, it is stored
in a private blockchain to ensure transparency, im-
mutability, and accountability. Figure 11 shows the
compliance block structure. Each compliance block
includes unique audit log IDs and corresponding
compliance statuses, categorized as compliant, non-
compliant, or not-determined. These blocks are then
stored within the private compliance blockchain, pro-
viding an immutable record of all verified compliance
checks.
1
st
Block
Genesis Block
Block Hash
2
nd
Block
Block Data
Block Hash
Previous Hash
Previous Hash
3
rd
Block
Block Data
Block Hash
Previous Hash
N
th
Block
Block Data
Block Hash
Previous Hash
Previous Block Hash
Block Header
Hash Difficulty Target
CTD Unit Hash
Block Hash
Block Nonce
Block Timestamp
Compliance
Transaction Data
Compliance Transaction - 1
Compliance Transaction Data (CTD) Unit
Compliance Transaction - 2
Compliance Transaction - 3
Compliance Transaction - M
Figure 11: PoC Compliance Blockchain Block Structure
SECRYPT 2025 - 22nd International Conference on Security and Cryptography
204
7 EXPERIMENTAL EVALUATION
The Ethereum Virtual Machine (EVM) based
blockchains are chosen for the proposed approach ex-
periments. It offers a Turing-complete smart contract
language, Solidity, which enables the implementation
of our model’s logic. We developed smart contracts
for storing and retrieving informed consent, testing
them on test networks: Ethereum and Optimism to
ensure reliability before deployment. Since smart
contracts, once deployed, are immutable and errors
can incur financial and reputational costs, rigorous
testing on these networks is crucial. Ethereum’s
Remote Procedure Call (RPC) API services are
employed for deploying smart contracts on these test
networks (Kim and Hwang, 2023). 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. Faucet ETH serves as gas to authorize
transactions using the Metamask wallet (Lee, 2023).
7.1 Private Audit Blockchain
We have chosen a private blockchain infrastructure
to manage the provenance of audit logs, specifically
utilizing an Ethereum private network deployed via
the Go Ethereum (geth) client. This approach en-
hances data security and provides centralized control
over policy-provenance activities. The private net-
work employs the Proof of Authority (PoA) consensus
algorithm, specifically the Clique protocol, to mine
and validate the audit trails. Additionally, as the Proof
of Compliance algorithm evolves, modifications to
the Clique algorithm can be implemented to adapt the
block structure to meet specific requirements.
Figure 12 shows the miner node responsible for
the end-to-end transaction handling process. Begin-
ning with the submission of transactions. Once a
transaction is submitted, the miner node includes it
in a block and uses the mining process to validate it.
Furthermore, the miner node actively publishes this
mined data to all other nodes within the network, en-
suring a synchronized and updated ledger.
7.2 Block Integrity Writing Cost
In the proposed approach, audit logs are stored in
the audit blockchain, and compliance status is stored
in the compliance blockchain. Both are private
blockchain networks, where participants are limited
to organizations. This doesn’t provide the public with
trust. To avoid this, block ID and hash as integrity
are stored in a public network like Ethereum. Fig-
ure 13 shows the block integrity storage cost in to-
kens for two public blockchain networks: Ethereum
and Optimism. The USD costs are depicted in Figure
13. Ethereum is Layer 1, and the optimism is Layer 2
(Gangwal et al., 2023; Gudgeon et al., 2020). Layer
1 is the core blockchain framework for implement-
Figure 12: Miner Node Operations.
Figure 13: Smart Contract Deployment Cost.
Did You Break the Glass Properly? A Policy Compliance Framework for Protected Health Information (PHI) Emergency Access
205
Figure 14: Multi-Signature Cost.
ing the network’s consensus mechanism, transaction
validation and storage, and native token functionality.
Layer 2 is a secondary framework built on top of an
existing Layer 1 blockchain to enhance the scalability
and efficiency of the Layer 1 blockchain without com-
promising its security or decentralization. It performs
transaction validation and storage outside the Layer
1 network but stores proof on it. The Layer 2 solu-
tion handles more transactions per second, reducing
transaction costs and speeding up confirmation times.
7.3 Multi-Signature Transaction Cost
The two entities must sign every access request.
It costs for each multi-signature operation. Figure
14 shows the costs of the Ethereum and Optimism
blockchain network. The prices fluctuate signifi-
cantly, with a maximum of $18.26 and a minimum of
$1.41 for Ethereum, as noted in Figure 14a. The aver-
age transaction cost over the 100 days is about $6.69.
The graph shows several spikes, suggesting periods
of high gas prices, possibly due to network conges-
tion. Figure 14b shows the cost for Optimism, which
is lower than on Ethereum, with values ranging from
$0.068 to $0.013. The average cost is much lower at
$0.03.
7.4 Time Requirements
Blockchain-based applications require block data
writing and reading time requirements. Writing time
includes smart contract deployment and data addition.
Table 2 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
of the blockchain ledger. All the read calls of smart
contracts are gas-free. Table 3 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.
Table 2: Writing Time to Blockchain Network.
Consents # Polygon Arbitrum Optimism
4 5.256 Sec 4.519 Sec 8.167 Sec
8 6.329 Sec 6.713 Sec 8.926 Sec
12 6.653 Sec 6.907 Sec 7.156 Sec
16 5.923 Sec 4.683 Sec 7.692 Sec
20 7.465 Sec 6.651 Sec 8.426 Sec
24 5.562 Sec 6.098 Sec 7.318 Sec
28 10.927 Sec 2.142 Sec 8.925 Sec
32 10.518 Sec 4.782 Sec 8.145 Sec
36 10.637 Sec 6.872 Sec 7.562 Sec
40 11.268 Sec 4.329 Sec 7.498 Sec
44 12.519 Sec 7.602 Sec 7.387 Sec
48 13.876 Sec 5.274 Sec 8.156 Sec
Table 3: Reading Time from Blockchain Network.
Consents # Polygon Arbitrum Optimism
4 0.357 Sec 0.265 Sec 0.378 Sec
8 0.352 Sec 0.231 Sec 0.329 Sec
12 0.467 Sec 0.276 Sec 0.398 Sec
16 0.394 Sec 0.246 Sec 0.571 Sec
20 0.331 Sec 0.276 Sec 0.603 Sec
24 0.354 Sec 0.215 Sec 0.613 Sec
28 0.329 Sec 0.234 Sec 0.423 Sec
32 0.426 Sec 0.247 Sec 0.612 Sec
36 0.353 Sec 0.265 Sec 0.376 Sec
40 0.436 Sec 0.291 Sec 0.602 Sec
44 0.524 Sec 0.221 Sec 0.421 Sec
48 0.462 Sec 0.237 Sec 0.342 Sec
SECRYPT 2025 - 22nd International Conference on Security and Cryptography
206
Figure 15: Compliance Block Construction Time.
Figure 16: Compliance Checking Throughput.
7.5 Compliance Block Creation Time
This time measurement pertains to the duration re-
quired to confirm a compliance block after complet-
ing compliance checking and block finalization. The
Auditor nodes perform compliance verification and
make final decisions regarding the compliance sta-
tus. In contrast, the Committer nodes are responsible
for finalizing the block by recording it on the compli-
ance blockchain ledger. This metric does not account
for the time the Orderer nodes need to retrieve au-
dit logs from the private audit blockchain, obtain in-
formed consent from the public blockchain network,
or gather relevant policies from the policy repository.
Figure 15 illustrates the compliance block construc-
tion times, with a maximum of 4.289, a minimum of
4.126, and an average of 4.170 seconds.
7.6 Compliance Checking Throughput
The throughput, measured as the number of transac-
tions per second (TPS), reflects the processing ca-
pacity after all required operations are completed
within the Proof of Compliance consensus mecha-
nism. These operations include compliance verifica-
tion and the finalization of compliance blocks by the
Auditor and Committer nodes. Figure 16 shows that
each transaction represents an audit log. The through-
put statistics show a maximum of 48.303, a minimum
of 46.507, and an average throughput of 47.709 TPS.
8 CONCLUSIONS
In conclusion, the proposed blockchain-based pol-
icy compliance framework for emergency access to
protected health information (PHI) addresses critical
challenges in ensuring data security and patient pri-
vacy during medical emergencies. By implementing
a multi-signature transaction system and maintaining
immutable audit logs, the framework enhances ac-
countability and transparency in accessing sensitive
data. Furthermore, integrating a Proof of Compliance
consensus mechanism ensures adherence to regula-
tory requirements, safeguarding patient rights while
facilitating timely medical interventions.
Future studies could investigate the integration of
advanced technologies, such as artificial intelligence
and machine learning, into existing blockchain-based
compliance frameworks. This research could enhance
the efficiency of compliance checking and auditing
processes and improve the detection of unauthorized
Did You Break the Glass Properly? A Policy Compliance Framework for Protected Health Information (PHI) Emergency Access
207
access attempts in real-time, thereby strengthening
the overall security of emergency PHI access.
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, findings, conclusions, or recommendations ex-
pressed in this material are those of the authors and
do not necessarily reflect the views of the National
Science Foundation or other organizations and agen-
cies.
REFERENCES
Aitzhan, N. Z. and Svetinovic, D. (2016). Security
and privacy in decentralized energy trading through
multi-signatures, blockchain and anonymous messag-
ing streams. IEEE transactions on dependable and
secure computing, 15(5):840–852.
Al Amin, M., Altarawneh, A., and Ray., I. (2023). 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, pages 159–
170. INSTICC, SciTePress.
Al Amin, M., Tummala, H., Shah, R., and Ray., I. (2024).
Balancing patient privacy and health data security:
The role of compliance in protected health informa-
tion (phi) sharing. In Proceedings of the 21st Inter-
national Conference on Security and Cryptography -
SECRYPT, pages 211–223. INSTICC, SciTePress.
Albrecht, J. S., Khokhar, B., Pradel, F., Campbell, M.,
Palmer, J., Harris, I., and Palumbo, F. (2015). Per-
ceptions of patient provider agreements. Journal of
Pharmaceutical Health Services Research, 6(3):139–
144.
Aski, V., Dhaka, V. S., and Parashar, A. (2021). An
attribute-based break-glass access control framework
for medical emergencies. In Innovations in Computa-
tional Intelligence and Computer Vision: Proceedings
of ICICV 2020, pages 587–595. Springer.
Bael, D. V., Kalantari, S., Put, A., and Decker, B. D. (2020).
A context-aware break glass access control system for
iot environments. In 7th International Conference on
Internet of Things: Systems, Management, and Secu-
rity (IOTSMS), pages 20–27. IEEE.
Conte de Leon, D., Stalick, A. Q., Jillepalli, A. A., Haney,
M. A., and Sheldon, F. T. (2017). Blockchain: prop-
erties and misconceptions. Asia Pacific Journal of In-
novation and Entrepreneurship, 11(3):286–300.
Fern
´
andez-Alem
´
an, J. L., Se
˜
nor, I. C., Lozoya, P.
´
A. O., and
Toval, A. (2013). Security and privacy in electronic
health records: A systematic literature review. Journal
of biomedical informatics, 46(3):541–562.
Ferreira, A., Cruz-Correia, R., Antunes, L., Farinha, P.,
Oliveira-Palhares, E., Chadwick, D. W., and Costa-
Pereira, A. (2006). How to break access control in
a controlled manner. In 19th IEEE Symposium on
Computer-Based Medical Systems (CBMS’06), pages
847–854. IEEE.
Gangwal, A., Gangavalli, H. R., and Thirupathi, A. (2023).
A survey of layer-two blockchain protocols. Journal
of Network and Computer Applications, 209:103539.
Gudgeon, L., Moreno-Sanchez, P., Roos, S., McCorry, P.,
and Gervais, A. (2020). Sok: Layer-two blockchain
protocols. In Financial Cryptography and Data Se-
curity: 24th International Conference, FC 2020, Kota
Kinabalu, Malaysia, February 10–14, 2020 Revised
Selected Papers 24, pages 201–226. Springer.
Haeberlen, A., Kouznetsov, P., and Druschel, P. (2007).
Peerreview: Practical accountability for distributed
systems. ACM SIGOPS operating systems review,
41(6):175–188.
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.
King, J., Patel, V., Jamoom, E. W., and Furukawa, M. F.
(2014). Clinical benefits of electronic health record
use: national findings. Health services research,
49(1pt2):392–404.
Lee, W.-M. (2023). Using the metamask crypto-wallet. In
Beginning Ethereum Smart Contracts Programming:
With Examples in Python, Solidity, and JavaScript,
pages 111–144. Springer.
Loos, M. (2020). Break-glass access control systems
in medical devices. RTDS, WS 2020, Institute of
Distributed Systems, Ulm University. This work
is licensed under a Creative Commons Attribution-
ShareAlike 4.0 International License.
Menachemi, N. and Collum, T. H. (2011). Benefits and
drawbacks of electronic health record systems. Risk
management and healthcare policy, pages 47–55.
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.
Schefer-Wenzl, S., Bukvova, H., and Strembeck, M. (2013).
A review of delegation and break-glass models for
flexible access control management. In Proceed-
ings of the International Conference on Security and
Trust Management, pages 1–12. University of Applied
Sciences Campus Vienna and WU Vienna, Austria,
Springer.
Yang, Y., Liu, X., and Deng, R. H. (2017). Lightweight
break-glass access control system for healthcare
internet-of-things. IEEE Transactions on Industrial
Informatics, 14(8):3610–3617.
SECRYPT 2025 - 22nd International Conference on Security and Cryptography
208