Blockchain enabled policy-based access control mechanism to restrict unauthorized access to electronic health records

Problem statement

Access control systems are mechanisms, models, and devices designed to provide only relevant data and services to authorized users (Paul et al., 2023). Traditionally, access control systems mentioned by De Oliveira et al. (2022) and Fedrecheski et al. (2021) were static, granting access to entire datasets once permission was granted for medical data sharing. It has been seen from the past state of the art (Patil, Sangeetha & Bhaskar, 2021; Malik & Shah, 2022; Khan & Sakamura, 2020) in access control systems that access control privacy policies serve as the baseline that governs data access, usage, and security of healthcare data. Policies are essential for ensuring compliance, defining access rights, maintaining transparency, enabling auditability, and enforcing access control mentioned by Merlec & In (2024). Shrivastava & Srikanth (2021) recently highlighted the importance of an access control policy specification and enforcement mechanism that enables organizations to share distributed resources while complying with security and privacy requirements. However, in the existing literature, there have been excessive results about the other types of access controls, such as role bases, rule bases, attribute bases, etc, as depicted in Table 2. In this article, to address the limitations of traditional access control systems, we propose to develop a PBAC system that focuses on resolving these issues in medical data sharing.

Research questions

To guide our research, we have formulated the following questions:

• What are the issues in existing access control mechanisms when applied to make robust electronic health record systems, and how can these issues be solved using policy-based access control?

• How can policy-based access control meet some regulatory requirements within the healthcare industry?

• What policies are implemented by the subject, controller, and requester during their interaction, and what are the resulting outputs for each entity?

• How can the latest tools and techniques be effectively applied to PBAC systems to enhance privacy in healthcare?

Our contribution and article organization

In implementing a PBAC system, we contribute to developing a comprehensive framework that ensures enhanced data security and privacy within healthcare systems.

• We propose a model to formally define resilient properties for assessing the security and privacy of PBAC systems. This model encompasses establishing and enforcing the subject policy, controller policy, and requester policy to regulate data access and usage within the system.

• We explore how various components within a PBAC system interact. This model emphasizes the collaborative efforts of policy entities.

• We emphasize the PBAC system’s functionality in accurately enforcing policies and controlling access based on predefined conditions and policies.

This article is organized as follows: The ‘Introduction’ covers the introduction, problem statement, research questions, contributions, and article organization. ‘Related Work’ presents related work, including issues with EHR, access control challenges, and issues in access control. ‘Theoretical foundations of PBAC’ outlines the theoretical foundation of PBAC, its previous shortcomings, system entities, and the importance of General Data Protection Regulation (GDPR). ‘Methodology’ details the methodology, proposed model, system architecture, algorithms, and setup. ‘System Implementation and Evaluation’ presents the implementation and results. ‘Discussion and Limitations’ discusses limitations. Finally, ‘Conclusion and Future Work’ concludes and suggests future work.

Issues in electronic health record

Issues in EHR encompass various vulnerabilities, including single points of failure and centralized server concerns reported by Merlec & In (2024), which may increase the possibility of data leaks, system interruptions, and system outages (Paul et al., 2023). Patients frequently have limited control over their health data, resulting in privacy concerns and trust issues (Sookhak et al., 2021). Additionally, challenges with traceability and timestamps can compromise the accuracy and integrity of EHR data, potentially raising legal and regulatory compliance issues. Addressing these challenges necessitates implementing decentralized and resilient infrastructure, empowering stakeholders like patients with more control over their health information records, and ensuring robust time-stamping mechanisms and audit trails to uphold the reliability of EHR data. Given patients’ health data sensitivity and the need to prevent privacy breaches, this research focuses on healthcare. It aims to mitigate threats related to unauthorized access by efficiently managing patients’ data and access rights, thereby limiting unauthorized data access (Khan et al., 2021; Salonikias et al., 2022).

Several deficiencies have been identified in the current landscape of healthcare data management (Khalid et al., 2024). Security and privacy policy plans are often inadequate or non-existent (Abutaleb, Alqahtany & Syed, 2023), and there is a lack of continuous security, privacy, and compliance reviews (Biswas et al., 2020). Personal health information is sometimes disclosed, highlighted by Paul et al. (2023), and there are shortcomings in accountability and duty.

Access control

Access controls are a critical element of any information system, ensuring the reliability, integrity, and availability of data. An effective access control system can address scalability challenges, safeguard data, and provide fine-grained access control. Access control systems assist in providing users requesting services and data with only the pertinent information available mentioned by Malik & Shah (2022) and Paul et al. (2023). Access control systems are tools and protocols designed to regulate access to healthcare data and use services based on user identities and permissions. They ensure that only authorized users can access specific information or functionalities. Access control systems have historically been static, granting unrestricted access to entire datasets once permission was given, observed by Abutaleb, Alqahtany & Syed (2023) and Churi & Pawar (2024). However, recent access control systems and models must be dynamically tuned with complex systems and increased data sensitivity. They provide selective access to data and services, allowing for greater automation and customization in various sectors, including consumer, commercial, and industrial applications (Li et al., 2024).

Issues in access control while managing EHR

Access control systems have often been static, granting unrestricted access to entire datasets once permission was given. This poses several challenges as malicious doctors may exploit a Subject’s authorization to access unrelated EMRs, risking the patient’s privacy. Furthermore, a comatose patient is incapable of granting authorization for a doctor to access their previous EMRs (Peng, Zhang & Lin, 2023). In existing independent e-health systems, the application-hosted server, database server, access control mechanism, and certification authority are all located in a single centralized architecture, creating a single point of failure (Biswas et al., 2020; Merlec & In, 2024; Liu et al., 2024). Even though these components are physically distinct machines, they typically belong to the same subnet, making them vulnerable to attack, and leading to a single point of information leakage. Information sharing is crucial because patients may see several service providers over time. Due to the lack of direct links between various EHS, old medical records are frequently unavailable. The system determines Information access and is consistent for all users, not the patient. While this is not inherently disadvantageous, the patient, as the data owner, should have total control over their information (Biswas et al., 2020). Most access control models used in the past have been static, reported by Churi & Pawar (2024); however, we require a dynamic model where the data owner can create policies and prioritize the dynamically changing privacy and utility values.

Why did previous access control have issues?

Several access control mechanisms are designed to address access issues within systems, as mentioned in Table 2. PBAC combines organizational policies, user behavior, and compliance with regulatory requirements. As noted in Churi & Pawar (2024), policies must be flexible and dynamic to accommodate changing user behavior. Despite developing various privacy approaches, implementing access control models still presents challenges. The proposed access control model ensures data is hidden selectively according to adjustable privacy settings. Researchers have made several observations regarding the significance of roles, data access scenarios, risk and utility variables, and the implementation of access control policies. Furthermore, it is critical to provide patients with the resources and tools they need as well as instruction on the significance of protecting their personal information (Paul et al., 2023).

Researchers have investigated diverse approaches to create a more accurate, efficient, and controlled system. A major area of interest has been combining various approaches to improve the features of access control systems based on blockchain technology. The authors Malik & Shah (2022) highlighted the possibility of more studies merging different methodologies and categorizing each technique based on how it affects blockchain access control. The objective is to develop a general-purpose model that takes care of the necessary conditions for reliable access control. According to Zhang et al. (2020), adding more subject, object, and contextual characteristics can make policies more dynamic and detailed. This viewpoint was reinforced by Psarra et al. (2021), which emphasized the necessity of richer context-based data in the creation of policies. Moreover, Arbabi et al. (2022) emphasized the significance of creating a zero-knowledge proof-based anonymous access control system that can function in a trustless blockchain setting without sacrificing computational or financial viability. Although role-based access control (RBAC) works well for managing policies, there are several drawbacks when applied to a large-scale, dynamic system such as IoT. In contexts that change quickly, traditional RBAC systems are inflexible due to their excessive centralization, requirement for explicit user role assignments, and reliance on static policies. Mechanisms like capability-based access control (CapBAC) and attribute-based access control (ABAC) have been proposed as alternatives, though they too face difficulties and challenges when implemented at scale (Pan, Wang & Wu, 2021; Chendeb, Khaled & Agoulmine, 2020; Pal et al., 2018).

Traditional access control approaches, such as role-based access control (RBAC), discretionary access control (DAC), and mandatory access control (MAC), are difficult to deploy in modern computing settings immediately. These models’ adaptability a nd scalability are constrained by their heavy reliance on the identities of subjects and objects. In particular, RBAC is highly centralized and requires explicit user-role assignments, making it rigid and unsuitable for dynamic environments like IoT. This rigidity arises because RBAC primarily supports preset, static policies, which fail to adapt to the rapidly changing and heterogeneous nature of modern computing environments, especially in IoT where flexibility and dynamic policy updates are essential, explained by Pal et al. (2018) and Yutaka et al. (2019). As users and roles grow, RBAC can suffer from role explosion. Attribute-based access control (ABAC) (De Oliveira et al., 2022) offers flexibility by using attributes, but managing and evaluating policies can be complex. Policies may need frequent updates as attributes evolve, which is resource-intensive. The distributed nature of IoT raises questions about where to store and evaluate attribute policies efficiently (Xia et al., 2022). Capability-based access control (CapBAC) mentioned by Nakamura et al. (2020) simplifies permission distribution but often overlooks fine-grained policy management. Capability propagation and revocation issues are significant in large-scale systems (Arbabi et al., 2022). Some of the issues we explored in various studies, as highlighted in Table 4, justify the need for our research by demonstrating the critical gaps and challenges in current access control systems, particularly in maintaining security and privacy in dynamic and distributed environments.

Entities involve in adhering policies

Within a PBAC healthcare ecosystem, various entities play crucial roles in ensuring adherence to access control policies. These entities include the Subject, Controller, and Requester (Khalid et al., 2023a), each with specific policy requirements governing their actions and interactions with healthcare data, as illustrated in Fig. 1.

Subject policy (SP): that governs data subjects’ rights, responsibilities, and actions. In a healthcare context, this primarily refers to patients. Consent management and access rights can come in managing subject policy (Khalid, Ahmed & Kim, 2023).

Controller policy (CP): that governs data controllers’ actions and responsibilities. Data controllers are entities, such as healthcare providers or hospitals, that define the purposes and objectives of processing personal data. Data processing rules, policy enforcement, data retention, decision-making, and deletion policies can be part of controller policy.

Requester policies (RP): that govern the actions and responsibilities of data requesters. Data requesters are entities or individuals, such as researchers or insurers, who request access to personal data for specific purposes. Access requests and usage restrictions can be part of request policies.

Figure 1 highlights the interaction among entities involved in a PBAC system within a healthcare ecosystem. The subject, represented by the patient, is the individual whose medical records are being accessed. As the controller, the hospital is in charge of enforcing access control policies and maintaining and limiting access to patient medical records. Sensitive data can only be viewed by those who are authorized. The person making the request, usually a researcher, does so in order to obtain patient data for research. Figure 2 illustrates the process of handling access requests between various entities. In this model, the hospital, as the controller, evaluates the researcher’s access requests based on predefined access control policies. If the request aligns with these policies, the hospital grants access to patient data. This process ensures patient privacy while supporting important research activities, with access credentials securely managed. The PBAC system enhances security and privacy by dynamically enforcing access policies when managing EHRs.

The importance of GDPR in ensuring data privacy and compliance in healthcare

The GDPR stated a rigorous and comprehensive legal framework aimed at protecting personal data and ensuring privacy. Khalid & Ahmed (2023) and Outchakoucht, Hamza & Leroy (2017) mentioned that GDPR summarised five important lawful grounds for protecting and processing the personal data of individuals, as articulated in recital 40. These rules include (i) processing necessary for the performance of a contract; (ii) processing needed to protect and harmless vital interests and save lives; (iii) processing mandated to fulfill duties related to public interest or public welfare; (iv) obtaining explicit consent from data subjects; and (v) processing required to comply with legal obligations. Among these, “consent” serves as a particularly crucial and clear foundation for processing personal data, especially in sensitive sectors like healthcare, where privacy is paramount (Peng, Zhang & Lin, 2023; Khan et al., 2021).

Our proposed system is primarily designed with GDPR compliance at its core, ensuring that it adheres to the strict data protection standards set forth by this regulation. However, while GDPR provides a robust and globally recognized standard, we acknowledge that there are other regulatory frameworks, such as Health Insurance Portability and Accountability Act (HIPAA) (in the U.S.) or Personal Information Protection Law(PIPL) (in China), that impose additional or differing requirements, which are not fully addressed in our current implementation.

The significance of GDPR in the context of healthcare cannot be overstated. Beyond simply safeguarding individual privacy, GDPR fosters greater transparency and trust between patients (data subjects) and the organizations that manage their sensitive data. By ensuring compliance with GDPR, organizations meet legal requirements and reinforce a culture of accountability, thereby enhancing patient confidence in how their personal data is handled and shared.

Proposed model

EHR systems require PBAC because it provides a systematic and comprehensive approach to implementing and managing access controls in the complex realm of healthcare data storage. To address our proposed problem statement, we develop well-organized and structured policies.

In Fig. 3, the patient whose medical records are being accessed is shown as the Subject. The hospital, acting as the Controller, oversees and controls access to patient data. The Controller has three key parts: the Policy Enforcer, which ensures rules are followed; the Authenticator, which verifies the identities of those requesting access; and the Decision Manager, which decides whether to allow access based on the rules. The researcher, shown as the Requester, asks for access to the patient’s medical records to conduct research. The Requester interacts with the Controller and follows the policies to ensure their access requests comply with the rules. The Subject and the Requester must abide by the rules and specifications specified in the policies in order for access to be authorized.

Blockchain provides a decentralized and secure architecture to manage access control and data transfers within the system. This architecture contains numerous key components, such as the consensus manager, the transaction manager, the blockchain manager, and the smart contract. The consensus manager ensured agreement among all of the blockchain nodes about the transactions and state of data. The transaction manager is responsible for recording and validating the transactions. The blockchain manager is responsible for overseeing the general upkeep and operation of the blockchain network. Smart contracts are used to encode and enforce access control policies defined by the system. Blockchain ensures that every transaction is transparent, improving the system’s security and reliability. Though access control policies are encoded and enforced through Smart Contracts, the blockchain manager manages the overall maintenance and functioning of the blockchain network. This structure limits authorized institutions’ access to sensitive data and guarantees adherence to established criteria while protecting patient privacy. Additionally, it supports vital research endeavors by upholding stringent access control, permitting authorized institutions to share data while safeguarding privacy, and guaranteeing secure data management.

System architecture

Our decentralized proposed system is based on Ethereum, operated by client applications, representing different stakeholders such as the Subject, Controller, and Requester as depicted in Fig. 4. These entities initiate transactions while interacting with the Ethereum network through smart contracts. The main component of the system lies in the smart contracts, which define policies, ensure compliance with PBAC, and implement rules defined by the stated stakeholders. The Controller deploys a smart contract containing Subject-specific information like SubjectID, patientCheckUp, Consent, and ConsentType to start the procedure. This contract establishes the policy of the Subject and serves as the basis for any future decisions on access control. These smart contracts dynamically enforce the access rules, guaranteeing that access requests are processed in compliance with established guidelines.

Dynamic policy management embedded in the system by multiple Subjects to be added. Each patient can check the minutiae of the Controller activities, medical CheckUp details, and consent policy as needed. The requester entity can access specific data after submitting a formal request to the Controller, outlining the purpose for data use. If the Subject’s consent is already set to “true” (i.e., access is granted), the Controller automatically approves the Requester’s access based on the existing consent policy. If the consent is “false,” the Controller forwards the request to the Subject for further review. At this point, the Subject can either grant or deny access by updating their consent status.

This Ethereum-based system ensures that policy changes, such as consent modifications or access revocations, are immediately reflected across the network through the smart contract. This allows for dynamic, real-time enforcement of access control rules. All actions, whether they involve granting access, revoking consent, or denying a request, are securely stored on the blockchain layer, creating an immutable and transparent audit trail. By leveraging Ethereum’s decentralized nature and integrating PBAC into smart contracts, the system ensures secure, flexible, and transparent management of healthcare data access.

Generalized policy equation

The policy can be defined as:

$$P_i=\{\mathrm{m}\mathrm{e}\mathrm{t}\mathrm{a},\mathrm{r}\mathrm{u}\mathrm{l}\mathrm{e}\mathrm{s},\mathrm{v}\mathrm{a}\mathrm{l}\mathrm{i}\mathrm{d}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\}$$

In simplified form:

(1) $$P_i=\{m,R,V\}$$

Metadata:

$$\mathrm{m}\mathrm{e}\mathrm{t}\mathrm{a}=\{\mathrm{d}\mathrm{e}\mathrm{s}\mathrm{c}\mathrm{r}\mathrm{i}\mathrm{p}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n},\mathrm{v}\mathrm{e}\mathrm{r}\mathrm{s}\mathrm{i}\mathrm{o}\mathrm{n}\}$$

(2) $$m=\{d,v\}$$

Rules:

$$\mathrm{R}\mathrm{u}\mathrm{l}\mathrm{e}=(\mathrm{e}\mathrm{f}\mathrm{f}\mathrm{e}\mathrm{c}\mathrm{t},\mathrm{u}\mathrm{s}\mathrm{e}\mathrm{r}\mathrm{s},\mathrm{c}\mathrm{o}\mathrm{n}\mathrm{d}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{s},\mathrm{a}\mathrm{c}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{s},\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{m}\mathrm{i}\mathrm{s}\mathrm{s}\mathrm{i}\mathrm{o}\mathrm{n})$$

(3) $$R=(E,U,C,A,p)$$

• Effect: Enable or disable the rule.

• Users: Subject, Controller, Requester.

• Conditions: Conditions for data usage consent (whole, partial, specific).

• Actions: Store data, check logs, revoke consent.

• Permission: Allow or deny actions.

Validation:

$$\mathrm{v}\mathrm{a}\mathrm{l}\mathrm{i}\mathrm{d}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}=\{\mathrm{p}\mathrm{r}\mathrm{o}\mathrm{o}\mathrm{f},\mathrm{v}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{f}\mathrm{i}\mathrm{c}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\}$$

(4) $$V=\{P,v\}$$

System setup

Our proposed implementation is grounded on PBAC architecture equipped with an Intel processor dual-core 2.4 GHz and 4 GB capacity of DDR3 RAM. Our approach proved to be efficient and workable as we created smart contract features on the Ethereum network using Solidity. This enabled us to create and alter intricate access control procedures specifically suited to the healthcare industry’s strict security and privacy regulations.

The Ethereum framework’s robust monitoring and management capabilities helped in the successful implementation of our healthcare privacy-enabled PBAC system. Adding flexibility to our development process, we used Remix IDE, a browser-based Integrated Development Environment (IDE), to write, manage, and compile the smart contracts. This helped and ensured that the PBAC framework could dynamically and securely manage healthcare data.

Smart contract installation

Ethereum’s Solidity language was used to develop our PBAC project. The Remix Integrated development environment assigns a unique account key to each of the entities, such as Subject, Controller, and Requester. Each stakeholder is assigned an Ethereum account, funded with sufficient Ethers to support network transactions.

For our system testing and deployment, we assigned an account ID to Subject as 0x5B38Da6a701c5-68545dCfcB03FcB875f56beddC4, which has the personal private data and is pivotal in the system. The Controller entity is also associated with account ID 0x617F2E2fD72FD9D5503197092aC168c91465E7f2, which is responsible for maintaining access control policies and maintaining security for sensitive data. The researchers seeking access to patient data for valid purposes are identified by ID 0x78731D3Ca6b7E34a-C0F824c42a7cC18A495cabaB, which also represents an external entity.

Every entity in the system performs specific functions written in smart contracts according to their functionality to establish access control policies within this structured and transparent environment. The patient keeps control over his medical records and has the right to deny or grant access to the Requester at any time. The responsibility of the Controller is to establish policies by auditing all transactions and controlling and maintaining action logs for transparency.

Consent is very important in all processes; the Requester can get access to data after receiving intimation from the Subject in the form of consent, which should comply with the predefined written policies. The secure, structured process ensures Ethereum’s smart contract’s privacy, consent, and audibility functionality, making the healthcare data-sharing process secure for patients.

Results

We have explained in detail the structure, entities, development environment, consent, and smart contract. We presented a patient-oriented system for handling and managing patient data. The code repository is available at PBAC: https://github.com/nadeemyb/PBAC (accessed on 19 November 2024). The code repository contains three key distinct contracts: Subject, Controller, and Requester, each performing diverse functionality in the patient data management system as shown in Fig. 5. The Subject contract is responsible for storing a patient’s personal data, including their name, date of birth, national ID, home address, and consent status, which is represented as an enumerated type with three levels: None, Partial, and Full. The patient’s consent type dictates the level of access that other parties may have to their data, as shown in Fig. 6. Only the patient has the authority to modify their consent type using the ‘UpdateConsentType’ function, ensuring that data access is strictly controlled.

A hospital deploys the Controller contract and manages the relationships between patients and their respective data stored in the Subject contracts. The hospital creates a new Subject contract for each patient, and the Controller contract maintains a mapping between the patient’s address and the corresponding Subject contract. The Controller serves as the gatekeeper, ensuring that the patient’s consent is checked before granting access to their medical data. Whenever a new patient is registered, the Controller contract links their Subject contract and stores their medical records while updating their consent type using the ‘RegisterPatientCheckup’ function. If the hospital or an authorized entity needs access to patient data, the Controller uses the ‘GetPatientInfoByPatientID’ function, which retrieves personal data and consent status from the patient’s Subject contract. The Requester contract allows researchers or third-party entities to request access to patient data. A researcher submits a request by invoking the ‘RequestData’ function, which interacts with the Controller to retrieve the patient’s personal information and medical records. Several events are emitted during this process to provide transparency and feedback regarding the request. The system first triggers an event indicating that the request has been initiated. The Controller then checks the patient’s consent status by fetching the data from the corresponding Subject contract. Based on the patient’s consent type, the Requester contract either grants or denies access, as shown in Fig. 7. If the consent level is set to Partial or Full, the request is successful, and the retrieved data is displayed through an event. Otherwise, the request is denied, and an appropriate event is emitted to signal that access was not granted due to insufficient consent. This system’s core strength lies in its event-driven architecture, having security and transparency by informing all relevant entities at every single stage of the data access process, as access is assigned in Fig. 8. The Controller is responsible for ensuring that no subject data is being accessed, altered, or used without the patient’s proper consent. Offering a robust solution should completely align with privacy rules and regulations for managing sensitive health data. The major advantages of this solution are that it reduces the dependency on a centralized system, guarantees that patient data is safely and impenetrably maintained, and enhances data integrity by utilizing decentralized smart contracts. The solution is well-suited for research settings, with a balance between strict privacy controls and the necessity for data access, where access control and permission management are crucial. It is an example of how blockchain technology may be integrated into healthcare by addressing patient autonomy and data protection.

Comparison with related works

In this research findings, we established a patient-centric decentralized solution for medical data sharing with the help of the Ethereum blockchain to address privacy issues while ensuring patient autonomy and consent. Many of the earlier research, as publicized in Table 5, used a decentralized scheme but badly lacked robust mechanisms for managing and obtaining patient consent. Our current solution gives patients control over their data. It also integrates compliance and privacy features that earlier studies needed to address. Our approach offers a more secure, patient-centric approach for sharing medical data than previous work by leveraging blockchain’s transparency and embedding consent protocols.