Skip to main content An official website of the United States government Here's how you know Here's how you know Official websites use .gov A .gov website belongs to an official government organization in the United States. Secure .gov websites use HTTPS A lock ( Lock Locked padlock icon ) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites. Search Log in Dashboard Publications Account settings Log out Search… Search NCBI Primary site navigation Search Logged in as: Dashboard Publications Account settings Log in Search PMC Full-Text Archive Search in PMC Journal List User Guide PERMALINK Copy As a library, NLM provides access to scientific literature. Inclusion in an NLM database does not imply endorsement of, or agreement with, the contents by NLM or the National Institutes of Health. Learn more: PMC Disclaimer | PMC Copyright Notice Sci Rep . 2026 Feb 17;16:8673. doi: 10.1038/s41598-026-39690-2 Search in PMC Search in PubMed View in NLM Catalog Add to search Secure electronic health record access control via blockchain, dual-attribute encryption, and large language model-based attribute extraction Atefeh Nekouie Atefeh Nekouie 1 Department of Computer Engineering, Ma.C., Islamic Azad University, Mashhad, Iran Find articles by Atefeh Nekouie 1 , Majid Vafaei Jahan Majid Vafaei Jahan 1 Department of Computer Engineering, Ma.C., Islamic Azad University, Mashhad, Iran Find articles by Majid Vafaei Jahan 1, ✉ , Mohammad Hossein Moattar Mohammad Hossein Moattar 1 Department of Computer Engineering, Ma.C., Islamic Azad University, Mashhad, Iran Find articles by Mohammad Hossein Moattar 1, ✉ , Reza Sheibani Reza Sheibani 1 Department of Computer Engineering, Ma.C., Islamic Azad University, Mashhad, Iran Find articles by Reza Sheibani 1 Author information Article notes Copyright and License information 1 Department of Computer Engineering, Ma.C., Islamic Azad University, Mashhad, Iran ✉ Corresponding author. Received 2025 Jun 3; Accepted 2026 Feb 6; Collection date 2026. © The Author(s) 2026 Open Access This article is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License, which permits any non-commercial use, sharing, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if you modified the licensed material. You do not have permission under this licence to share adapted material derived from this article or parts of it. The images or other third party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by-nc-nd/4.0/ . PMC Copyright notice PMCID: PMC12979818 PMID: 41703161 Abstract Access control and data privacy are two of the main necessities in managing electronic health records (EHRs) across distributed domain. There are privacy gaps that expose EHRs to risks like unauthorized access by unaffiliated medical personnel. Traditional attribute-based encryption (ABE) allows encryption based on user attributes but is unable to incorporate data-specific attributes, such as the type of medical information included in the record or the potential physician. This paper introduces a novel approach that integrates ABE with large language models (LLMs) and blockchain technology to enhance security and contextual access control in EHR systems. Specifically, a domain-specific LLM, such as ClinicalBERT, is leveraged to automatically extract semantic data attributes from unstructured medical records, enabling a more granular and context-aware encryption process. By embedding both user and data attributes into the ABE framework, access policies are dynamically refined, ensuring that only authorized users can view specific types of medical information. Furthermore, blockchain’s immutable ledger enhances trust, streamlines attribute revocation, and fortifies the system against unauthorized modifications and security threats. The proposed framework significantly strengthens EHR privacy by integrating machine learning-driven attribute extraction with cryptographic access control, outperforming existing schemes in both security and flexibility. Evaluations validate the effectiveness of the proposed framework in preventing unauthorized access while maintaining efficient and transparent data management. Keywords: Electronic health records (EHR), Attribute-based encryption (ABE), Large language models (LLMs), Blockchain, Security, Privacy Subject terms: Health services, Public health, Engineering Introduction Managing electronic health records and ensuring the protection of healthcare data, which are stored in various locations and formats, presents a significant challenge regarding data privacy and security concerns. Healthcare information may be at risk of unauthorized entry, alteration, or loss during transmission, particularly with the rise of unstructured data like clinical notes, medical images, and diagnostic reports 1 . Moreover, it is challenging to implement consistent security measures due to the intricate and varied data formats. Conventional encryption techniques frequently struggle to effectively handle these complications, leaving EHRs vulnerable to dangers like monitoring, data leaks, theft, and manipulation 2 . In order to protect patient privacy and maintain data integrity, obstacles in managing and sharing healthcare data through EHRs need to be addressed despite notable progress. The growing dependence on cloud storage and data sharing raises the risk of unauthorized access, due to the distribution of sensitive healthcare data across various platforms and devices. Given these difficulties, more sophisticated and adaptable security measures are essential. An existing solution for these security issues is attribute-based encryption (ABE). In ABE, data is encrypted based on the attributes of the users, ensuring that only authorized personnel with the required attribute set can access sensitive information. However, to further strengthen security, especially in fields like healthcare, data attributes can also play a critical role. To improve protection, data attributes, like the kind of medical record or sensitivity level, can be used in conjunction with user attributes to make sure that only authorized users can access particular categories of data 3 . In order to identify and use the attributes of unstructured data, it must first be transformed into a structured format. Key information is extracted from unstructured texts, including diagnostic reports, medications, and clinical notes, to enable this transformation. Large language models like BERT and multimodal approaches are two efficient ways to retrieve these data properties. In the healthcare domain, ClinicalBERT, a variation of BERT fine-tuned on clinical notes from EHRs, is particularly useful. ClinicalBERT enables the extraction of relevant keywords and medical entities from complex unstructured text, converting it into structured, interpretable data 4 . In this paper, ClinicalBERT is used to extract data attributes from unstructured medical records. These attributes (or tags) can be integrated into the ABE framework. This allows encryption based not only on user characteristics, but also on specific characteristics of medical data. This is particularly crucial in the healthcare industry, as various data types (such as MRI scans, test results, and prescription drugs) call for varying degrees of access control. This study presents a unique method for safe cloud-based medical data sharing that blends ClinicalBERT with a blockchain-based attribute-based encryption (ABE) scheme. The proposed method improves the security and precision of medical data analysis by tagging, extracting, and classifying unstructured medical data using ClinicalBERT. This integration ensures that sensitive healthcare data is encrypted using both user and data attributes, improving the security, privacy, and efficiency of EHR management. The combination of blockchain‘s immutable structure, ABE‘s robust encryption, and the analytical power of ClinicalBERT provides a comprehensive solution for secure data transfer in modern healthcare systems. Related works The amount of data in electronic health records has been growing exponentially, and therefore efficient and effective computational analytical methods are needed. Aden et al. 4 propose a predictive model for assigning ICD diagnosis codes to patient records using the MIMIC-III dataset. They also use natural language processing (NLP) and deep learning models such as RNN, LSTMs, BiLSTM and BERT to predict diagnosis codes from unstructured clinical text. Turchin et al. 5 used three models based on BERT, BioBERT, and ClinicalBERT to identify complex medical linguistic concepts from electronic health records. Rasmy et al. 6 introduced the Med-BERT model for EHR structured data. By pre-training on a large dataset, the model improves prediction accuracy, especially when tuned to smaller datasets, and shows significant performance in disease prediction tasks. Mantey et al. 7 used the combination of Blockchain and Artificial Intelligence (AI) technologies to increase the security, privacy and efficiency of healthcare data sharing and diagnostics. Their goal is to develop a system in which healthcare professionals can securely share medical records, using the Ethereum blockchain to control access. To increase security, Alabdulatif and et al. 8 integrated machine learning with blockchain technology. In their method, MLP and SVM are used for pre-processing and a more comprehensive decision-making process. Saveetha et al. 9 propose federated machine learning (FML) method in blockchain framework to prevent distributed denial of service (DDoS) attacks. In addition, the proposed framework is tested with random forest machine learning algorithms, multilayer perceptron and logistic regression. Mohammed et al. 10 proposed an architecture to detect transactions and attacks before data enters the blockchain. In this method, machine learning (ML) algorithms are used to analyze and block medical data. Myrzashova et al. 11 used a combination of blockchain and federated learning for diagnosis. This framework enables shared data training across multiple hospitals without exposing sensitive patient data and uses blockchain to secure and manage federated models. Sowjanya et al. 12 designed a method to address data security and privacy challenges in IoT-based healthcare systems, particularly focusing on key management and decryption overhead. Encryption (CP-ABE) using elliptic curve encryption (ECC) is key to improve security and efficiency in IoT healthcare data management while eliminating the key storage problem. Hu et al. 13 present a communication architecture designed for wireless body area networks (WBANs) to secure data communication between implanted or wearable sensors and data consumers, such as doctors or nurses. This method uses encryption policy attribute-based encryption (CP-ABE) and digital signature to ensure that the data stored in the data sink is encrypted and secure. Chandrasekaran et al. 14 introduce a data communication protocol using File Hierarchical Cipher-Text Feature-Based Encryption (FH-CP-ABE). This method aims to overcome the limitations of existing protocols, especially when dealing with multiple files. Tan et al. 15 describe a specially designed lightweight policy key attribute-based encryption (KP-ABE) scheme. Additionally, it makes it more suitable for IoT applications, especially in healthcare systems. Sowjanya and Dasgupta 16 present a secure framework for healthcare systems. This framework uses elliptic curve cryptography (ECC) combined with cryptographic policy attribute-based encryption (CP-ABE) without binary pairing operations. The goal is to provide a lightweight and secure solution that supports user and attribute revocation. Cheng et al. 17 designed a ciphertext policy-based attribute-based encryption scheme (CP-ABE), which aims to enhance data security and privacy by implementing strict access control. And they also allow data users to access only within the time limits and locations specified by the data owners to achieve more precise access control functionality. F. Sammy and S. Maria 18 Celestin Vigila present an encryption scheme based on blockchain-based cryptographic properties (DBC-CP-ABE). It is also a method to secure patient health record (PHR) exchanges through cloud computing. Li et al. 19 introduce a security framework that combines blockchain with feature-based cryptography to protect electronic health records (EHRs). It uses feature-based text policy (CP-ABSE) to enable fine-grained access control and efficient data recovery. Revathi and Manikandan 20 used a combination of IoT, blockchain and machine learning technologies to secure health data. In addition, in their method, Elliptic Curve Encryption (ECC) and Attribute Based Encryption (ABE) are used for data encryption and decryption. Merabet et al. 21 used a combination of CP-ABE cryptography and blockchain to secure sensitive medical data in cloud services. This paper aims to improve trust and security in data sharing by implementing a multi-authorization scheme. Guo et al. 22 used a combination of blockchain and an attribute-based chameleon hash function. The goal of this approach is to reconcile blockchain immutability with the need for secure and privacy-compliant updates for EHRs. To facilitate the sharing of large volumes of sensitive medical data, especially among hospitals and patients, Chen and Li 23 used a combination of blockchain technology and CP-ABE. Wang et al. 24 describe a consortium blockchain-based scheme for managing and sharing personal health records (PHR) collected by Internet of Medical Things (IoMT) devices. The project aims to increase security and privacy in the data sharing process by using the Interplanetary File System (IPFS) to store encrypted PHRs and implementing zero-knowledge proofs for keyword index authentication on the blockchain. Additionally, the scheme uses modified attribute-based cryptographic methods and custom smart contracts to enable secure browsing, privacy protection, and personalized access control. Liu et al. 25 present a secure electronic care system that uses a combination of inner product searchable encryption (IPE) and multi-keyword search (MK-IPSE) to efficiently protect and retrieve encrypted electronic medical records (EMR). The plan aims to provide fine-grained access control, policy obfuscation, and privacy protection in electronic health care systems, specifically addressing issues of unauthorized access to sensitive patient information. Table 1 summarizes the key findings, strengths and weaknesses of the previous works. Table 1. Summary and discussion on the related works. Refs. Method Advantage Disadvantage Deep learning in EHR 4 RNN, LSTMs, BiLSTM and BERT Accuracy and efficiency Complexity of deep learning models 5 BERT, BioBERT, and ClinicalBERT Use of dedicated models Model performance variability 6 MedBERT Enhances the precision of predictions Increased risk of data breaches Blockchain and Machin learning in EHR 7 Blockchain + AI Enhanced security and privacy, transparency and traceability Scalability issues 8 Machine learning + Blockchain Comprehensive integration, resistant to manipulation Latency 9 FML + Blockchain Enhanced security Potential performance overhead 10 Machine learning + Blockchain Versatility of machine learning, high accuracy and performance Complexity in implementation, latency 11 Blockchain + Federated learning Privacy and security, resilience to cyberattacks Latency and throughput ABE in EHR 12 CP-ABE + ECC Reduced decryption overhead, efficient key management Limited applicability 13 CP-ABE Role-based access control, collusion resistance Energy consumption, communication/computation overhead 14 FH-CP-ABE Scalability, improved efficiency Potential for higher initial costs 15 KP-ABE Support for role delegation, efficient performance Increased complexity, scalability concerns 16 CP-ABE + ECC Revocation capability Complexity in implementation, security assumption dependency 17 CP-ABE + ECC Decentralized authority management, efficiency Complexity of implementation Blockchain and Machin learning and ABE in EHR 18 DBC-CP-ABE Enhanced security, dynamic attributes and a user-centric access policy Complex implementation, latency 19 Blockchain + CP-ABSE Efficient data retrieval Scalability issues, resource intensive 20 Blockchain + Machine learning + ECC + ABE Optimized performance, integrated monitoring Performance overheads, scalability 21 CP-ABE + Blockchain Fault tolerance, enhanced security Scalability concerns 22 Blockchain + Attribute-based chameleon Decentralization, practical efficiency Complexity of implementation 23 CP-ABE + Blockchain Scalability and efficiency, privacy protection Performance overhead, cost 24 Consortium Blockchain + ABE Tailored access control, enhanced privacy and security Performance concerns 25 MK-IPSE + Blockchain + ABE Efficient data retrieval Scalability concerns Open in a new tab Basic concept ClinicalBERT ClinicalBERT A specialized language model specifically designed for unstructured clinical notes from the original BERT (Bidirectional Encoder Representation of Transformers) architecture. This model helps healthcare professionals to access meaningful information and large volumes of data. ClinicalBERT is also very effective in identifying specific entities in medical text such as diseases, symptoms, treatments, and drugs 4 . Several methods can be applied for extracting keywords from EHR data, including those enhanced by models like ClinicalBERT. TF-IDF (Term Frequency-Inverse Document Frequency) is one such technique. It combines the term frequency within a document (TF) with how rare the term is across the corpus (IDF), calculated as: Here, measures how often term t appears in document d , while accounts for how common t is across the collection of documents D . Another technique is ClinicalBERT‘s attention mechanism, where attention scores highlight key medical terms. This is given by: This formula calculates the importance of a word about other words in the text, where Q is the query vector and K is the key vector, with being the dimensionality of these vectors. These methods, combined with algorithms like TextRank and RAKE, provide robust solutions for extracting keywords and important medical entities from EHRs 26 . Blockchain Blockchain is a digital platform that builds an uninterrupted, linked chain of data blocks to facilitate safe and transparent transactions. A consensus process among network users verifies and adds a set of transactions to each block, which makes up the chain. A block joins the chain permanently the moment it is added, and each new block builds upon the integrity of the ones that came before it. Because blockchain is distributed and no single entity controls the entire system, data is reliable and resistant to tampering 27 . Because of its creative architecture, the technology is a fundamental tool for applications like smart contracts, cryptocurrencies, and decentralized finance (DeFi) that demand strong security and accountability 28 . Attribute-based encryption Attribute-based encryption (ABE) is a form of encryption that ties access to data directly to the attributes or characteristics of the users rather than relying on traditional key-based access. In this system, the encryption process embeds a set of conditions or attributes within the ciphertext, and only users whose attributes meet these predefined conditions can decrypt the information 19 . This enables highly granular and dynamic control over who can access specific data, making ABE ideal for environments where access needs to be precisely regulated based on user roles, contexts, or other defined criteria, without requiring explicit key exchanges or centralized management. It essentially blends data security with access management, ensuring that only those with the right attributes can unlock the encrypted data 29 . Proposed approach As depicted in Fig. 1 , the proposed scheme has four phases: initialization, registration, data encryption and uploading, and data access and decryption. In the initialization phase, a private blockchain is set up between key generation centers (KGCs). User and data attributes are defined, partial public/private keys are generated for each attribute, and main public keys are computed via smart contracts for data (Algorithm 1) and user attributes (Algorithm 2) and stored on the blockchain. During the registration phase, each data user (DU) submits their attributes and public key to a KGC. After validation, the public key is stored on the blockchain (Algorithm 3), and the KGC forwards the request to other KGCs. Each KGC sends partial private keys to the DU, who then computes their main private keys. In the data encryption and uploading phase, the data owner (DO) gathers medical data, including unstructured information such as clinical notes. ClinicalBERT is then used to label the unstructured data, extracting relevant keywords and entities to transform it into a structured format suitable for encryption. This structured data, enriched with key medical terms, is then encrypted using attribute-based encryption (ABE), which is implemented through smart contracts on the blockchain platform. The DO reads public keys and attribute information from the blockchain, applies ABE via smart contracts, computes the data hash, and uploads the encrypted data to the cloud. In the data access and decryption phase, a DU requests access from the DO, retrieves the encrypted data from the cloud, decrypts it using their private keys, and verifies its integrity by matching the computed hash with the original hash. This process, facilitated by the blockchain and smart contract-based ABE, ensures that only authorized users with the correct attributes can access the medical data, maintaining data privacy and security. Fig. 1. Open in a new tab The proposed system model. System model Figure 1 depicts the system model and communication flow of the suggested approach. Key Generation Centers (KGCs), Cloud Servers (CSs), Data Owners (DOs), and Data Users (DUs) are some of the system entities and models. According to this scheme, Key Generation Centers are trusted entities in charge of registering DUs and collaboratively producing partial private keys for user attributes and data. They have also introduced a private blockchain network to hold the public keys of user attributes and data, utilizing the Hyperledger Fabric platform. CSs are parties that are semi-trusted and offer storage services to DOs. DOs encrypt all of their medical data before storing it in the CS to prevent unauthorized DUs from accessing it later. Our suggested plan‘s primary objective is to provide a reliable and effective cloud-based platform for the exchange of medical data. After receiving the data address from the DOs, DUs, such as medical staff, can access and decode the encrypted medical data that the DOs have stored. It is crucial to remember that CSs are unable to decrypt the data they can only store it. This design consists of 23 phases, which are described in “ Initialization ” section through “ Data access and decryption ” section. This plan’s step 11 demonstrates how to use ClinicalBERT in Fig. 2 to extract medical keywords from unstructured electronic health record (EHR) clinical notes. A clinical note, which contains unstructured medical data on a patient, including symptoms, diagnoses, and prescriptions, is the first step in the process. Tokenizing, cleaning, and formatting the text for model input are all part of the data preprocessing procedure used to this unstructured data before it is kept in a database. After preprocessing, the data is loaded into ClinicalBERT, a language model that has been adjusted for use in a clinical setting. To find relevant medical terms or keywords, such as symptoms (such as chest discomfort), diagnoses (such as diabetes and blood pressure), and medications (such as metoprolol and insulin), ClinicalBERT further tags the input and applies Named Entity Recognition (NER). Slowly these keywords are crucial for clinical decision-making, and the model efficiently extracts them by evaluating the medical significance of the links between symptoms in the text. Fig. 2. Open in a new tab Tagging and data attribute extraction by ClinicalBERT. Clinical note (input) It is an unstructured text document that contains detailed information about the patient‘s medical condition, symptoms, history, prescribed medications, and follow-up instructions. This document is intended as raw input. Direct analysis of clinical notes is challenging because they lack a standardized format. This unstructured format requires advanced processing techniques to systematically extract useful information. Data preprocessing The data undergoes a preprocessing stage prior to being fed into ClinicalBERT as unstructured text. In order to fit the data to the model’s requirements, this procedure entails cleaning the text by eliminating redundant or unnecessary information (such as overused terms like “the” and “is” that typically have no significant meaning), fixing mistakes, and standardizing formats. Tokenization Tokenization in ClinicalBERT divides the text into more understandable chunks known as tokens, which stand in for individual words or sentences. In order to enable the model to analyze the text at a fine level and facilitate the identification and classification of certain phrases pertaining to symptoms, medical conditions, and therapies, tokenization is necessary. For instance, “diabetes”, “chest pain”, and “shortness of breath” would all be distinct tokens. ClinicalBERT may concentrate on each term separately while still taking into account the context that surrounding tokens provide thanks to this deconstruction into tokens, which makes it possible to recognize medical things more accurately. Named entity recognition (NER) ClinicalBERT‘s Named Entity Recognition (NER) classifies each token by determining its function in the medical environment, such as whether it‘s a diagnosis, symptom, or drug. By giving relevant terms particular names, NER transforms plain text into structured information, making it an essential step. For example, ClinicalBERT would identify “diabetes” as a disease, “chest pain” as a symptom, and “insulin” as a prescription drug. By assigning a meaningful label to each item of information in the clinical note, this categorization turns unstructured language into data that can be securely stored or analyzed. Output A collection of structured data with the extracted keywords and medical entities is the end result of ClinicalBERT processing. Relevant medical terms from the original unstructured text are included in this structured output, which has been arranged to facilitate analysis and integration into a database or blockchain-based system. To create structured data that may be encrypted, safely kept, or utilized for additional healthcare analytics, phrases such as “chest pain”, “hypertension”, “diabetes”, “metoprolol”, and “insulin” are retrieved and categorized. Effective data processing, improved security, and easier accessibility for medical experts are all made possible by this structured output. It is important to note that ClinicalBERT is executed locally within the hospital’s secure infrastructure, as part of the data owner’s preprocessing pipeline. Raw clinical notes never leave the institutional boundary; only structured attributes are retained for subsequent encryption. Unlike traditional hospital systems that rely on static metadata, ClinicalBERT generates dynamic, context-aware attributes such as comorbidities, medication relations, and temporal conditions. This feature provides more fine-grained access policies and constitutes a distinctive contribution compared with prior ABE–blockchain approaches. Initialization In this phase, multiple Key Generation Centers (KGCs) collaborate to form a private blockchain network using Hyperledger Fabric (HLF) (as seen in Fig. 3 ), a permissioned blockchain framework where only authorized organizations can participate. In this network, three KGCs act as endorsing organizations, each with endorsing peers (EPs) responsible for signing and validating transactions, and an ordering node (ON) that helps build the blockchain blocks using the RAFT consensus algorithm. The KGCs are connected through a shared channel in HLF, and three smart contracts manage public keys related to data and user attributes (see Algorithm 1–Algorithm 3). Smart contracts are used to insert, update, read or even delete a user‘s public key, user attribute, data attribute in the ledger. Fig. 3. Open in a new tab The proposed blockchain network. Algorithm 1. Open in a new tab Data attribute smart contract Algorithm 2. Open in a new tab User attribute smart contract Each KGC generates partial private keys for both data and user attributes, which are then combined to create the main private key. This approach ensures that no single KGC has full access to the keys, making the system key-escrow-less. The KGCs also compute partial public keys for each attribute and send them to the blockchain, where the smart contracts calculate the main public keys. These main public keys are stored in the ledger and are used later by Data Owners (DOs) for attribute-based encryption (ABE) of medical data. Registration To access a Data Owner‘s (DO‘s) medical data, a Data User (DU) must undergo a one-time registration process conducted by a Key Generation Center (KGC). DUs, who are typically clinical staff needing patient information, physically visit the KGC to present their credentials securely, minimizing the risk of attacks. During registration, the DU submits their public key and their user attribute The KGC validates the credentials and, if approved, uploads to the blockchain, recording it in the ledger via smart contract 3. Algorithm 3. Open in a new tab Data user smart contract The KGC also forwards the registration request to other KGCs, which generate and send partial private keys related to the DU’s data attributes and user attributes. The DU then uses these partial private keys to compute their main private keys for the assigned data attributes and their user attribute. An access policy defined through an access tree or matrix determines the specific keys provided. For example, a nephrologist would receive private keys related only to kidney data, ensuring access control is maintained based on the DU’s role (as seem in Fig. 4 ). Non-medical or administrative sensitivity levels (such as VIP patient status or higher confidentiality flags) are defined directly by the Data Owner during access-policy construction, as described in the registration and policy-definition phases. These contextual attributes are not generated by ClinicalBERT and are instead incorporated manually or through institutional rules. Fig. 4. Open in a new tab Access matrix (1 = access, 0 = no access). We also know from pseudocodes 1 and 2 that for each data attribute Datt n , mPK Dattn = mpk Dattn · G and for each user attribute Uatt m , mPK Uattm = mpkU attm · G . Data encryption and uploading In this phase, the data owner (DO) begins the process by collecting comprehensive medical data, denoted as , which includes structured data (such as patient demographics, laboratory results) and unstructured data (such as medical images, MRI scans, or clinical notes). Unstructured data is more complex and lacks predefined organization, requiring special handling before being encryption and integrated into a blockchain-based system. To deal with this issue and manage unstructured data is to use large language models like BERT. In the healthcare domain, ClinicalBERT, a variant of BERT set on clinical notes from EHRs, is used to extract keywords and related entities from unstructured medical data and transform it into a structured form suitable for encoding. This transformation not only helps to organize the data, but also increases its security by using data properties during encryption, in addition to traditional user properties. Detailed explanation of ClinicalBERT for keyword extraction: Input and output representation ClinicalBERT processes the unstructured data to generate structured information, such as keywords or entities. This is done by applying ClinicalBERT‘s transformer-based architecture to analyze and classify medical text. The model transforms the input text into keywords or medical entities, effectively turning the unstructured data into structured insights. ClinicalBERT architecture ClinicalBERT is based on the BERT (Bidirectional Encoder Representations from Transformers) architecture, which consists of multiple transformer layers designed to understand the context of words in a sentence. The architecture is particularly suited for processing clinical text, as it has been fine-tuned on clinical notes from EHRs. Each layer applies self-attention mechanisms that capture complex relationships between words in the unstructured medical data, allowing ClinicalBERT to extract medical entities such as diagnoses, medications, or procedures. Keyword and entity recognition The output layer of ClinicalBERT identifies and classifies medical entities and keywords. Each word or token in the unstructured data is labeled, indicating its relevance to the medical domain. For example, ClinicalBERT might classify certain words as diagnoses or medications, providing a structured output from previously unstructured text. Structured data formation The structured data resulting from ClinicalBERT can be mathematically represented as: This structured data, , now contains clear, organized labels that correspond to different aspects of the unstructured medical data. Once the unstructured data has been converted, it is combined with any other available structured data: where refers to any additional structured data that did not originate from unstructured sources. After converting unstructured data into structured form, the DO defines an access policy based on either an access tree or matrix. This policy determines which users or groups can access the encrypted data. The DO retrieves the necessary public keys associated with the relevant attributes from the blockchain ledger. Next, assuming that the DO and cloud storage (CS) have already established a shared session key using a known key-sharing protocol, the DO begins the encryption process. The DO generates a random integer and computes a random point , where G is a base point on an elliptic curve. Using this random point and the retrieved public keys, the DO creates an attribute-based key as: Also, in the proposed scheme, the elliptic curve group is defined on a prime number q with the order of 160 bits. All elliptic curve operations, including scalar multiplications and key derivatives, are performed modulo q. For example, the calculation of the original public key for an attribute can be expressed as follows: where G is the base point on the elliptic curve and is the master public key corresponding to the attribute. This ensures that our scheme is resistant to invalid-curve and small-subgroup attacks. Using this random point and the retrieved public keys, the DO creates an attribute-based key. Finally, the encrypted data is uploaded to the Cloud Storage (CS), with additional checks and verifications to ensure secure storage and retrieval. Data access and decryption: In the data access and decryption phase, secure communication between the Data User (DU), Data Owner (DO), and Cloud Storage (CS) is achieved despite using insecure public channels. To facilitate this, each pair (DU-DO and DU-CS) has pre-negotiated symmetric session keys using a key-sharing protocol. These session keys and ensure that the data transmitted between the parties remains confidential and secure. Step 1: Access request from DU to DO: The DU initiates the process by sending an access request to the DO. This request includes encrypted data and a timestamp . Upon receiving the request, the DO first checks the validity of the timestamp to ensure that the request hasn‘t expired. The condition must be satisfied. The DO then decrypts the received message using the session key verifying the hash to ensure the integrity of the request. If the verification is successful, the DO computes a new hash for the medical data address and encrypts this address along with the hash using the session key The DO sends a response containing this encrypted information back to the DU. Step 2: Data request from DU to CS After receiving and verifying the response from the DO, the DU sends a data request to the CS. This request contains the encrypted medical data address and a timestamp . The CS verifies the request by checking the timestamp , ensuring that the request is still valid. The CS decrypts the received message using the session key verifies the hash and retrieves the corresponding medical data record from its storage. The CS then computes a hash and sends the encrypted medical data back to the DU as where is the encrypted message containing , and Step 3: Decrypting the data When the DU receives the response from the CS, they first check the validity of the timestamp . The DU decrypts the message using the session key extracting and The DU verifies the integrity of the message by checking whether the hash matches . And also, from the pseudocode (3), we know that DU obtains the same key ak DU as the key calculated by DO , i.e. ak DO . Step 4: Attribute-based decryption (1) Now that the DU has the encrypted medical data and the random point they proceed with attribute-based decryption. Using their private keys and the DU computes an attribute-based decryption key as follows: General Case If the encryption was for a group of users with certain attributes, the DU calculates: This key will match the previously computed by the DO during encryption. Specific group encryption If the data was encrypted for a specific user group, the DU computes the decryption key as: Specific user encryption If the encryption was targeted at a specific user, the DU computes: (2) Once the DU has the correct decryption key they decrypt the medical data to retrieve the complete medical data and its hash. The DU then verifies the integrity of the data by comparing the received hash with the calculated hash. If the hashes match, the DU accepts the data. From pseudocodes (4) and (5), we know that DU achieves ak DU identical to the key calculated by DO , i.e. ak DO . It should be noted that ClinicalBERT is only responsible for transforming unstructured clinical text into structured metadata. The enforcement of access rights is cryptographically guaranteed by the ABE scheme and the multi-authority private keys; therefore, occasional mis-tagging by the model cannot cause unauthorized disclosure, as decryption strictly requires the correct user keys. Security analyses Before presenting the security analysis of the proposed framework, it is necessary to clearly outline all the system parameters involved in the ClinicalBERT processing pipeline, the ABE construction, the encryption phase, and the blockchain storage layer. Table 2 summarizes all parameters used throughout the system, including cryptographic elements, user and data attributes, metadata fields, and performance-related variables. This table provides a unified reference that facilitates understanding of the security evaluation in the following subsections. Table 2. Summary of All parameters used in the proposed framework. Group Parameter Description ClinicalBERT processing Unstructured data Raw clinical text extracted from EHR records Tokens Tokenized units processed by ClinicalBERT Extracted keywords Medical keywords identified by the model Extracted entities Recognized diseases, medications, procedures, or clinical terms Data attributes (Datt) Structured metadata derived from ClinicalBERT for encryption ABE setup parameters G Base point on the elliptic curve used for key generation PK Public key generated during the ABE setup phase MSK Master secret key generated during the ABE setup phase mpk_att_i Public key associated with each attribute msk_att_i Secret key component associated with each attribute, held by KGCs User attribute parameters Uatt_m User attributes such as role, department, or authorization level Partial private key Partially generated private key issued by each KGC Registration record Metadata related to user registration stored on the blockchain Data attribute parameters Datt_k Data-level attributes extracted from unstructured text mPK_Datt Public key component for each data attribute mSK_Datt Secret key component for each data attribute Encryption parameters C0 Main ciphertext component derived during encryption Ci Attribute-specific ciphertext components Access tree (T) Tree-based representation of the access policy Access matrix (M) Matrix representation of the access structure Blockchain metadata Public keys Public keys stored on-chain for verification Data hash Hash of the encrypted EHR file stored on the blockchain Attribute identifiers Non-semantic IDs representing each attribute on-chain Smart contract ID Identifier of the smart contract maintaining metadata Performance parameters Number of attributes Number of user/data attributes involved in encryption Encryption time Time required to encrypt data under the ABE scheme Decryption time Time required to decrypt data based on user attributes Computation overhead Total computation cost for encryption and decryption Security parameters Collusion resistance Ability to resist collusion among users or KGCs Key escrow prevention Mechanism that prevents any single KGC from controlling keys Blockchain immutability Ensures records cannot be altered once stored Attribute revocation Ability to revoke user or data attributes securely Open in a new tab Formal analysis The formal analysis of the proposed attribute-based encryption (ABE) scheme was conducted using ProVerif, a widely used tool for validating security protocols. The proposed scheme was modeled in ProVerif, which tested its robustness against various security challenges, including unauthorized access to medical data. The analysis involved defining communication channels, parameters, and processes for each entity within the scheme. The results showed that the proposed scheme successfully preserved data secrecy and protected communications from replay and modification attacks. Our source code, provided in 30 , can be tested online using the provided web site in 31 or by the provided binary package in Windows 32 , 33 . Security analysis The security analysis, both formal and informal, assessed the scheme’s resistance to various types of attacks and its capability to manage attributes and access policies: DoS/DDoS attack resistance The scheme mitigates these attacks by hashing messages before transmission, which helps recipients filter out fake messages and ensures data integrity. Replay attack resistance The scheme incorporates time stamps in messages, preventing attackers from resending valid messages since the time cannot be altered without access to the corresponding hashed token. Collusion attack resistance The scheme prevents registered users from sharing secret information to gain unauthorized access, as each piece of data is protected by unique private keys. Internal cloud server (CS) attack resistance The encrypted storage of medical data ensures confidentiality, even from internal cloud server attackers. Any data tampering is detected during decryption due to integrated hash values. Key escrow problem The scheme eliminates the key escrow issue by using partial private keys, ensuring that even trusted entities do not have full access to users‘ private keys. Simple attribute revocation/updating The scheme simplifies attribute revocation by utilizing blockchain, where public keys are stored in a distributed ledger. Revocation or updating of attributes is managed by removing or updating public keys in the blockchain. Access policy updating The scheme allows for flexible updates to access policies, although removing access requires generating and distributing new private keys, which is manageable given the infrequency of such updates. It is also important to emphasize that only non-semantic attribute identifiers and public-key components are stored on the blockchain, and the access structure is represented internally through elliptic-curve parameters inside the ciphertext. Therefore, no clinical meaning or sensitive information can be inferred from observing the fine-grained policy or on-chain metadata. Formal security proof The proposed scheme is a dual-attribute ABE system built on ECC, where both user attributes ( U att ) and data attributes (D att ) are incorporated into the access policy. Keys are generated in a multi-authority manner by several KGC s , attribute public keys are maintained on a private blockchain (Hyperledger), and encryption/decryption operations follow the phases described in “ Proposed approach ” section. Model and notations Elliptic curve cyclic group of large prime order q, with scalar-point multiplication. Hardness assumptions: EC-DDH (Decisional Diffie–Hellman on G ) and ECDLP . Attribute sets: U for users and D for data. Policies are represented as an access tree or LSSS matrix Pol. Cryptographic functions: (hash), KDF: (key derivation). Algorithms: Setup, KeyGen, Enc, Dec as defined in “ Proposed approach ” section. Security definition (IND-CPA, selective policy). The standard game is as follows: Init. The adversary A commits to a challenge policy Pol* or target attribute set in advance. Setup. The challenger C generates system parameters PP and simulates multi-authority key setup. Phase-1 Queries. A may request secret keys for attribute sets that do not satisfy Pol* . Challenge. A submits two equal-length messages . The challenger flips b in {0,1}, encrypts M b , and sends CT* . 5. Phase-2 Queries. Same as Phase-1, under the same restriction. Guess. A outputs b‘. Its advantage is |. High-level idea The session key is derived as: where r is random and {α_a} are parameters linked to valid attribute public keys (stored on blockchain). The ciphertext includes R = rG and policy-dependent components. Unless the adversary can recover r or reconstruct a valid attribute combination, distinguishing K from random reduces to breaking EC-DDH . Main theorems Theorem 1 (IND-CPA, selective policy). If EC-DDH holds in G, then our dual-attribute ABE scheme is IND-CPA secure in the selective-policy model. Proof Sketch (Reduction to EC-DDH). Given a challenge tuple the simulator embeds it in ciphertexts: Game G 0: Real IND-CPA game. Game G 1: Replace blockchain queries with an ideal oracle. No effect on confidentiality. Game G 2: Embed EC-DDH instance by setting R = X and deriving session key from Z . If Z = xyG, ciphertext is real. Game G 3: If Z is random, the derived key is indistinguishable from random. Theorem 2 (Collusion resistance). Any coalition of users whose combined attributes do not satisfy Pol cannot decrypt successfully. Reasoning. Secret keys contain independently randomized shares generated by multiple KGCs. Only a satisfying attribute set can reconstruct the correct secret. Theorem 3 (Escrow-freeness). Since private keys are constructed from independent partial keys issued by multiple KGCs, no single KGC can recover a full user key. Thus, the scheme is key-escrow-free. Extension to IND-CCA By applying a hybrid CCA-secure encryption method using Encrypt-then-MAC with and attaching a tag ) we obtain IND-CCA security. Invalid ciphertexts are rejected before decryption, and the hardness reduction to EC-DDH still applies. Channel and replay considerations The use of timestamps and hashes in access-phase messages ensures replayed or tampered messages are rejected. While this does not alter core ABE confidentiality, it enhances channel integrity and availability. Explicit simulation under the EC-DDH assumption We explicitly describe the simulation underlying Theorem 1 . The simulator is given an EC-DDH challenge tuple: where is either or a uniformly random element of the group . During the Setup phase, generates all public parameters and attribute public keys honestly, while implicitly embedding the unknown exponent into the challenge component. Owing to the selective-policy security model, the adversary commits to the challenge access policy in advance. Consequently, all secret-key queries correspond to attribute sets that do not satisfy this policy, allowing to answer all key-generation queries without knowledge of the master secret. where denotes the set of data attributes associated with the challenge policy. If , then the resulting ciphertext is distributed identically to a real encryption produced by the proposed scheme. Otherwise, if is uniformly random in , the derived session key is computationally indistinguishable from random under the EC-DDH assumption. Therefore, any adversary that distinguishes the challenge ciphertext with non-negligible advantage can be directly transformed into an efficient distinguisher for the EC-DDH problem, contradicting its assumed hardness. This completes the reduction and formally establishes the IND-CPA security of the proposed scheme. Security proof sketch We provide a security proof sketch of the proposed scheme under the Decisional Bilinear Diffie–Hellman (DBDH) assumption. Suppose there exists a probabilistic polynomial-time adversary A that can break the indistinguishability of ciphertexts under a chosen-plaintext attack (IND-CPA) with non-negligible advantage. Then, we can construct a simulator B that uses A as a subroutine to solve the DBDH problem with non-negligible probability. This reduction implies that if our scheme were not IND-CPA secure, then the DBDH assumption would also be invalid. Since the DBDH problem is widely believed to be computationally intractable, we conclude that the proposed scheme achieves IND-CPA security. Performance comparison The timings of crypto operations on the HPE server and Raspberry Pi board are listed in Table 3 . There are different types of Raspberry Pi in the market. We chose the “Raspberry Pi 3 B+” model, which has a 1.4GHz 64-bit quad-core ARMv8 Cortex-A53 CPU (called “BCM2837B0”) and 1 GB of RAM. We have run our tests on a 64-bit Raspbian 12 operating system (OS) using this board. The HPE server also includes 32GB RAM and a six-core ‘{E5-2620 V3‘” CPU with a 2.40 GHz base frequency and 15M cache. An Ubuntu 20.04 operating system has been used for our tests on this server. We have used the OpenSSL crypto library for both systems. Table 3. Implementation results on HPE server and Raspberry Pi by means of OpenSSL crypto library. Operation (time symbol) Time on raspberry Pi (µs) Time on HPE server (µs) Random number generation ( t rn ) 11.1 2.2 One-way cryptographic hashing ( t ch ) 2.3 0.11 Symmetric encryption/decryption ( t se ) 0.5 0.11 Elliptic curve point multiplication ( t pm ) 557 67 Elliptic curve point addition ( t pa ) 2.3 0.3 Exponentiation ( t ex ) 1187 137 Bilinear pairing ( t bp ) 1520 175 Modular multiplication ( t mm ) 0.5 0.06 Modular addition ( t ma ) 0.2 0.02 Open in a new tab This section compares the suggested ABE scheme’s performance to that of top-related schemes. The computational cost of several techniques for data encryption and decryption is shown in Table 4 and Fig. 4 . According to 12 , we have taken into account the amount of encryption characteristics, leaf nodes, and access matrix rows in Table 3 and Fig. 5 , which are x = 5, l = 10, and r = 30, respectively. We have taken into account our obtained execution times on the Raspberry Pi (as seen in Table 3 ) in our calculations without sacrificing generality. As can be shown, when compared to all relevant schemes, our proposed ABE system has the best decryption and total timings. It is important to note that the decryption time is far more important than the encryption time. This is due to the fact that medical data is often encrypted once and then decoded several times. We also examined the performance of our suggested ABE method for varying numbers of attributes (number of attributes used for encryption), leaf nodes, and matrix rows in order to show how effective it is. Figure 6 shows the outcomes. As suggested, even on devices with limited resources, the suggested strategy offers the necessary efficiency. Table 4. Comparing performance of top-related schemes (according to 11 , we have considered x = 5; l = 10; r = 30). Scheme Operations and time of data encryption Operations and time of data decryption Total time 12 t bp + (2 x + 1) t ex = 2374 x + 2707 µs 2 x ( t ex + t bp ) = 5414 x µs 7788 x + 2707 = 41,647 µs 13 x ( t ex + t bp ) = 2707 x µs 2 x ( t ex + t bp ) = 5414 x µs 8121 x = 40,605 µs 14 ( x + 1) t pm = 557 x + 557 µs 2 x ( t ex + t bp ) = 5414 x µs 1671 x + 557 = 8912 µs 15 ( x + 1) t pm = 557 x + 557 µs 2 xt pm = 1114 x µs 1671 x + 557 = 8912 µs 11 ( l + 4) t pm = 557 l + 2228 µs ( x + 2) t pm = 557 x + 1114 µs 557 l + 557 x + 3342 = 11,697 µs 16 (4 r + 1) t pm = 2228 r + 557 µs (x + 2) t pm = 557 x + 1114 µs 2228 r + 557 x + 1671 = 71,296 µs 17 ( r + 1) t pm = 557 r + 557 µs ( x + 2) t pm = 557 x + 1114 µs 557 r + 557 x + 1671 = 21,166 µs 18 t br + t bi + ( x + 2) t bp + (6 x + 8) t ex = 8642 x + 26,926 µs 1187 µs 8642 x + 28,113 = 71,323 µs 29 (l + 4) t pm = 547 l + 2228 µs ( x + 2) t pm = 547 x + 1112 µs 557 l + 547 x + 3242 = 11,577 µs 30 ( x + 1) t pm = 457 x + 557 µs 2 x ( t ex + t bp ) = 1014 x µs 1571 x + 557 = 8812 µs Proposed method t rn + t ch + x( t br + t pa ) + 2 t pm ≈ 1362.3 x + 1131 µs xt ma + t ch + t pm ≈ 0.2 x + 563 µs 1362.5 x + 1694 ≈ 8506 µs Open in a new tab Fig. 5. Open in a new tab Comparative computational overhead for a usual use case, i.e., x = 5; l = 10; r = 30 12 . Fig. 6. Open in a new tab Total computational overhead (encryption plus decryption) of top-related ABE schemes compared to our ABE scheme for different number of attributes. Note that the ledger stores only lightweight metadata (public keys and access policies), with storage overhead on the order of kilobytes per attribute. Encrypted medical files, such as images and reports, remain off-chain. Ledger growth is therefore linear in the number of attributes and negligible compared with medical data size. Moreover, Hyperledger Fabric supports pruning and external storage integration, ensuring scalability of the ledger for long-term EHR deployments. Table 6 shows that ECC-based ABE with both user and data attributes is superior for secure data environments due to its flexibility, enhanced access control, and robust privacy protection. By maintaining a fixed 160-bit ECC key length, this approach achieves efficient encryption while supporting fine-grained access policies that consider both user roles and data sensitivity. This dual-attribute ABE provides complex access conditions and manages sensitive data more effectively, ensuring only authorized users can access specific data types. While this method introduces slightly higher key management overhead, the added security, scalability, and tailored privacy make it ideal for sensitive fields like healthcare, where strict data access control is critical. Table 6. Encryption schemes based on specific characteristics. Characteristic Traditional ECC encryption ECC-based ABE with user attributes only Proposed ECC-based dual-attribute ABE Why ECC-based dual-attribute ABE is better Key length Fixed at 160 bits Fixed at 160 bits Fixed at 160 bits With ECC, all schemes maintain a 160-bit key length, balancing security and efficiency, while the inclusion of data attributes enhances security without increasing key length Access control flexibility Limited Moderate High Adding data attributes allows for fine-grained, flexible access policies based on both user roles and data types Security level Moderate High Very high Adding data attributes makes decryption permissions more complex and precise, enhancing overall security while maintaining ECC’s strength Privacy protection Basic Strong (user attributes) Very Strong (user + data attributes) By integrating data attributes, privacy is strengthened, ensuring only authorized users can access specific data types Complexity of access policies Simple Moderate (based on user roles) Complex (user roles + data types) Dual-attribute ABE supports complex policies like "only licensed cardiologists can access cardiology data," ideal for healthcare applications Overhead in key management Low Moderate Moderate to High While dual-attribute ABE adds some complexity, the use of fixed-length ECC keys keeps the overhead manageable Data sensitivity handling Limited (same for all data) Moderate High Dual-attribute ABE can enforce access controls for sensitive data types, improving data protection in environments like healthcare Scalability Limited Scales with number of users Scales with both users and data types Ideal for large systems, like EHRs, where both user diversity and data variety are present Open in a new tab Table 5 compares our proposed scheme with eight recent approaches 12 – 19 across multiple security and privacy metrics. Schemes like 12 , 14 , 16 primarily focus on CP-ABE with ECC to achieve lightweight encryption and basic access control, but they lack advanced policy flexibility and auditability. In contrast, Chandrasekaran et al. 13 and Sowjanya and Dasgupta 15 introduce hierarchical and patched ABE structures to enhance delegation and resist attacks; however, they do not address metadata privacy or semantic-level control. Our approach, in contrast, utilizes ClinicalBERT for meaningful attribute extraction, offering more context-aware and precise access enforcement. In 17 , 18 , and especially 19 , improvements are made in terms of dynamic access, multi-authority structures, and hidden policies. Particularly, Revathi and Manikandan 19 supports encrypted keyword search and policy hiding through blockchain and smart contracts, aligning closely with modern privacy demands. However, none of the existing works integrates AI, blockchain, and cryptography as comprehensively as our scheme. By combining fine-grained access control, decentralized key management, metadata protection, and machine learning privacy safety, our method provides a more complete and future-ready solution for secure electronic health data sharing. Table 5. Comparison of the proposed scheme with some other recently proposed approaches from different aspects. Measure Proposed scheme 12 13 14 15 16 17 18 19 Access control granularity ABE + ClinicalBERT attributes CP-ABE + ECC Attribute Trees (CP-ABE) FH-CP-ABE with hierarchical files KP-ABE CP-ABE (ECC) CP-ABE (time/location + ECC) Modified Hierarchical CP-ABE + ECC + LSSS Hidden-policy CP-ABE enabling flexible and private access control Unauthorized access resistance Multi-key + ABE ECC-based CP-ABE Role-based CP-ABE Hierarchical policy restricts unauthorized decryption Patched KP-ABE Attribute-based ECC Dynamic Attributes Blockchain + LSSS + ECC prevents unauthorized access Access only permitted if hidden policies are satisfied, blocking leaks Collusion resistance Multi-KGC ECC-based CP-ABE Secret sharing Integrated access structures with randomness PRF patch ECDDH Multi-authority CP-ABE Unique address + RSA keys per attribute prevent collision Key splitting and policy obfuscation resist collusion Key escrow elimination Distributed KGCs ECC + multiparty Attribute-linked key issue Secure key issuance by Key Authority Initially vulnerable ECC key distribution Multi-authority resolves it Blockchain with RSA-based distributed keys Blockchain-driven key management avoids escrow risks Policy flexibility Smart Contracts Low flexibility Role-based, sensor-managed Multi-level access hierarchy Partial (hierarchy) Partial via revocation Real-time, dynamic Supports dynamic LSSS policies Supports dynamic hidden policies via blockchain and LSSS matrices User attribute confidentiality Hashed on-chain Not protected No anonymization Partial: access enforced via policy, not identity PRF reduces risk No anonymization Indirect via time/location RSA-based selective disclosure + blockchain Hidden attributes and one-way key exchange ensure confidentiality Data minimization ClinicalBERT filtering Full data encrypted Selective by sensor Encrypts hierarchical levels selectively Full data Full data Filtered encryption Encrypts only relevant attributes and blocks Online/offline encryption reduces exposure; keyword indexing for targeted access Secure auditability Hyperledger blockchain None No blockchain Not explicitly discussed Not discussed No audit Edge-based logs Blockchain ensures complete traceability Secure logging via smart contracts and permissioned blockchain Privacy of on-chain metadata Hashed/Encrypted Off-chain only Encrypted sink Minimal metadata exposure Not managed Not secured ECC encrypted at edge Metadata encrypted, stored on blockchain Indexes and parameters stored encrypted; only accessible via smart contract logic Inference attack resistance Randomized keys ECC reduces risk Session key based Resists via hierarchical encryption randomness Index randomization ECDDH Time/location help ECC + blockchain + LSSS policies block inference Encrypted queries + hidden structure protect against inference attacks LLM privacy safety ClinicalBERT inference-only N/A N/A N/A N/A N/A N/A N/A No LLM used; privacy ensured through encryption-based mechanisms Open in a new tab On the other hand, Table 6 compares three encryption schemes built on Elliptic Curve Cryptography (ECC). Traditional ECC encryption offers limited access control and moderate security, as it lacks attribute-based mechanisms. The user-only ABE scheme improves flexibility by tying access policies to user roles (e.g., job titles) but still lacks granularity. The proposed dual-attribute ABE system, which integrates both user roles and data attributes, achieves the highest security and privacy standards. It enforces precise, context-aware policies, such as restricting access to sensitive data types based on both user credentials and data classifications. While key management becomes moderately complex with dual attributes, ECC’s fixed key length ensures overhead remains manageable. Scalability also improves, as the dual-attribute model accommodates growing user bases and diverse data types, making it ideal for systems like EHRs where security and flexibility are critical. The proposed dual-attribute ECC-based ABE scheme emerges as the most robust solution for modern data security needs, particularly in environments requiring nuanced access controls. Its primary strength lies in its ability to enforce fine-grained policies that traditional ECC or single-attribute ABE cannot match. ECC’s inherent efficiency ensures that enhanced security does not come at the cost of performance. Even with added complexity from dual attributes, key management remains feasible, avoiding the exponential overhead seen in non-ECC systems. Furthermore, the scheme’s scalability addresses a key limitation of traditional ECC, which struggles with large, diverse systems. By scaling with both users and data types, dual-attribute ABE suits dynamic environments like cloud storage or EHRs, where data variety and user roles evolve constantly. However, the model’s complexity presents challenges. Designing and managing policies that integrate user and data attributes demands advanced infrastructure and expertise, which may deter smaller organizations. Additionally, while overhead is manageable, organizations must still invest in robust key distribution systems to avoid bottlenecks. Also, as explained in “ Initialization ” section, only lightweight metadata (public keys and access policies) are stored on-chain, while encrypted medical files remain off-chain. Storage overhead is therefore negligible. Fabric’s pruning and external storage integration prevent ledger growth from becoming a bottleneck. Conclusions This research introduces an innovative method of attribute-based encryption (ABE) in cryptography for sharing medical data in the cloud. The recommended plan provides better security measures and is more effective than similar projects. By utilizing detailed access control measures, patients can provide specific users, user groups, or a combination of both with access to medical information stored in the cloud. Additionally, the scheme integrates ClinicalBERT for improved handling of unstructured clinical data, ensuring more accurate keyword extraction and contextual understanding during data processing. It also lacks the issue of key escrow and can withstand common threats such as distributed denial-of-service and collusion. The recommended ABE method enhances security and trust, while also simplifying attribute revocation through storing public keys in the distributed ledger of the blockchain. The proposed scheme is evaluated against similar schemes and its security has been verified through formal and informal means. The results show that the suggested ABE plan is better than similar ones. As the directions for future works, we suggest investigating multimodal LLMs to process diverse medical data formats for richer attribute extraction, enhancing context-aware encryption in EHR environments. Also, exploring blockchain-based consensus mechanisms for dynamic, cross-institutional policy management, can address scalability and interoperability challenges in multi-stakeholder healthcare networks. Author contributions AN performed formal analysis, investigations, software development, conceptualization, visualization, and writing original draft. MVJ performed conceptualization, formal analysis, methodology preparation, supervision, and writing reviewing and editing. MHM performed conceptualization, supervision, validation, and writing- reviewing and editing. RS provided resources and performed supervision, investigation, reviewing, and editing. Funding The authors declare that no funds, grants, or other forms of support were received during the preparation of this manuscript. Data availability Data and code will be made available from the corresponding author upon request. Declarations Competing interests The authors declare no competing interests. Ethics approval and consent to participate This study did not involve human participants, animal subjects, or any data requiring ethical approval. Consent for publication This manuscript does not contain any individual person’s data in any form (including individual details, images, or videos); therefore, consent for publication was not required. Declaration of using Generative AI and AI-assisted technologies During the preparation of this study, the authors used freely available tools to improve the language. After using these tools, the authors reviewed and edited the content and take full responsibility for the publication‘s content. Footnotes Publisher’s note Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations. Contributor Information Majid Vafaei Jahan, Email: [email protected]. Mohammad Hossein Moattar, Email: [email protected]. References 1. Ginavanee, A. & Prasanna, S. Leveraging deep learning models and ethereum smart contracts to secure EHR in HL7 environment. In 2023 12th International Conference on System Modeling and Advancement in Research Trends (SMART) , 335–341 (2023). 2. Han, Y., Zhang, Y. & Vermund, S. H. Blockchain technology for electronic health records. Int. J. Environ. Res. Public Health 19 , 15577 (2022). [ DOI ] [ PMC free article ] [ PubMed ] [ Google Scholar ] 3. Aden, I., Child, C. H. & Reyes-Aldasoro, C. C. International classification of diseases prediction from MIMIIC-III clinical text using pre-trained ClinicalBERT and NLP deep learning models achieving state of the art. Big Data Cogn. Comput. 8 , 47 (2024). [ Google Scholar ] 4. Turchin, A., Masharsky, S. & Zitnik, M. Comparison of BERT implementations for natural language processing of narrative medical documents. Inf. Med. Unlocked 36 , 101139 (2023). [ Google Scholar ] 5. Rasmy, L., Xiang, Y., Xie, Z., Tao, C. & Zhi, D. Med-BERT: Pretrained contextualized embeddings on large-scale structured electronic health records for disease prediction. NPJ Digit. Med. 4 , 86 (2021). [ DOI ] [ PMC free article ] [ PubMed ] [ Google Scholar ] 6. Mantey, E. A., Zhou, C., Mani, V., Arthur, J. K. & Ibeke, E. Maintaining privacy for a recommender system diagnosis using blockchain and deep learning. Hum. Cent. Comput. Inform. Sci. 13 , 510 (2023). [ Google Scholar ] 7. Alabdulatif, A., Al Asqah, M., Moulahi, T. & Zidi, S. Leveraging artificial intelligence in blockchain-based e-health for safer decision making framework. Appl. Sci. 13 , 1035 (2023). [ Google Scholar ] 8. Saveetha, D., Maragatham, G., Ponnusamy, V. & Zdravković, N. An integrated federated machine learning and blockchain framework with optimal miner selection for reliable DDOS attack detection. IEEE Access 10.1109/ACCESS.2024.3413076 (2024). [ Google Scholar ] 9. Mohammed, M. A., Boujelben, M. & Abid, M. A novel approach for fraud detection in blockchain-based healthcare networks using machine learning. Future Internet 15 , 250 (2023). [ Google Scholar ] 10. Myrzashova, R. et al. Safeguarding patient data-sharing: Blockchain-enabled federated learning in medical diagnostics. IEEE Trans. Sustain. Comput. 10 , 176–189 (2024). [ Google Scholar ] 11. Sowjanya, K., Dasgupta, M. & Ray, S. A lightweight key management scheme for key-escrow-free ECC-based CP-ABE for IoT healthcare systems. J. Syst. Archit. 117 , 102108 (2021). [ Google Scholar ] 12. Hu, C., Li, H., Huo, Y., Xiang, T. & Liao, X. Secure and efficient data communication protocol for wireless body area networks. IEEE Trans. Multi-Scale Comput. Syst. 2 , 94–107 (2016). [ Google Scholar ] 13. Chandrasekaran, B., Balakrishnan, R. & Nogami, Y. Secure data communication using file hierarchy attribute based encryption in wireless body area networks. J. Commun. Softw. Syst. 14 , 75–81 (2018). [ Google Scholar ] 14. Tan, S.-Y., Yeow, K.-W. & Hwang, S. O. Enhancement of a lightweight attribute-based encryption scheme for the Internet of Things. IEEE Internet Things J. 6 , 6384–6395 (2019). [ Google Scholar ] 15. Sowjanya, K. & Dasgupta, M. A ciphertext-policy attribute based encryption scheme for wireless body area networks based on ECC. J. Inf. Secur. Appl. 54 , 102559 (2020). [ Google Scholar ] 16. Cheng, R. et al. An efficient ECC-based CP-ABE scheme for power IoT. Processes 9 , 1176 (2021). [ Google Scholar ] 17. Sammy, F. & Vigila, S. M. C. An efficient blockchain based data access with modified hierarchical attribute access structure with CP‐ABE using ECC scheme for patient health record. Secur. Commun. Netw. 2022 , 8685273 (2022). [ Google Scholar ] 18. Li, P., Zhou, D., Ma, H. & Lai, J. Flexible and secure access control for EHR sharing based on blockchain. J. Syst. Archit. 146 , 103033 (2024). [ Google Scholar ] 19. Revathi, K. & Manikandan, T. A smart and secured blockchain for children’s health monitoring using hybrid encryption and adaptive machine learning techniques. Expert Syst. Appl. 255 , 124689 (2024). [ Google Scholar ] 20. Merabet, A., Lahoulou, A. & Alioua, A. A multi-authorisation blockchain-based access control for cloud healthcare system. Int. J. Intell. Eng. Inform. 11 , 191–213 (2023). [ Google Scholar ] 21. Guo, H., Li, W., Meese, C. & Nejad, M. Decentralized electronic health records management via redactable blockchain and revocable IPFS. In 2024 IEEE/ACM Conference on Connected Health: Applications, Systems and Engineering Technologies (CHASE) , 167–171 (2024). 22. Chen, R. & Li, Z. Blockchain-based mechanism for electronic healthy records sharing using fine-grained authorization. In 2021 7th International Conference on Computer and Communications (ICCC) , 1557–1564 (2021). 23. Wang, Y., Zhang, A., Zhang, P., Qu, Y. & Yu, S. Security-aware and privacy-preserving personal health record sharing using consortium blockchain. IEEE Internet Things J. 9 , 12014–12028 (2021). [ Google Scholar ] 24. Liu, J. et al. Blockchain-aided privacy-preserving medical data sharing scheme for e-healthcare system. IEEE Internet Things J. 10 , 21377–21388 (2023). [ Google Scholar ] 25. Harnoune, A. et al. BERT based clinical knowledge extraction for biomedical knowledge graph construction and analysis. Comput. Methods Programs Biomed. Update 1 , 100042 (2021). [ Google Scholar ] 26. Brewer, J., Patel, D., Kim, D. & Murray, A. Navigating the challenges of generative technologies: Proposing the integration of artificial intelligence and blockchain. Bus. Horiz. 10.1016/j.bushor.2024.04.011 (2024). [ Google Scholar ] 27. Al Sibahee, M. A. et al. Blockchain-based authentication schemes in smart environments: A systematic literature review. IEEE Internet Things J. 10.1109/JIOT.2024.3422678 (2024). [ Google Scholar ] 28. Luo, F., Wang, H., Yan, X. & Wu, J. Key-policy attribute-based encryption with switchable attributes for fine-grained access control of encrypted data. IEEE Trans. Inf. Forensics Secur. 10.1109/TIFS.2024.3432279 (2024). [ Google Scholar ] 29. Alabdulatif, A. Blockchain-based privacy-preserving authentication and access control model for E-health users. Information 16 , 219 (2025). [ Google Scholar ] 30. Qiao, J. et al. A lightweight CP‐ABE scheme for EHR over cloud based on blockchain and secure multi‐party computation. Trans. Emerg. Telecommun. Technol. 36 , e70053 (2025). [ Google Scholar ] 31. ProVerif’s Source (2024). [Online]. Available: https://github.com/atefehne/Atefeh . 32. ProVerif web interface (2024). [Online]. Available: http://proverif20.paris.inria.fr/ . 33. ProVerif webpage (2024). [Online]. Available: https://bblanche.gitlabpages.inria.fr/proverif/ . Associated Data This section collects any data citations, data availability statements, or supplementary materials included in this article. Data Availability Statement Data and code will be made available from the corresponding author upon request. Articles from Scientific Reports are provided here courtesy of Nature Publishing Group ACTIONS View on publisher site PDF (5.1 MB) Cite Collections Permalink PERMALINK Copy RESOURCES Similar articles Cited by other articles Links to NCBI Databases Cite Copy Download .nbib .nbib Format: AMA APA MLA NLM Add to Collections Create a new collection Add to an existing collection Name your collection * Choose a collection Unable to load your collection due to an error Please try again Add Cancel Follow NCBI NCBI on X (formerly known as Twitter) NCBI on Facebook NCBI on LinkedIn NCBI on GitHub NCBI RSS feed Connect with NLM NLM on X (formerly known as Twitter) NLM on Facebook NLM on YouTube National Library of Medicine 8600 Rockville Pike Bethesda, MD 20894 Web Policies FOIA HHS Vulnerability Disclosure Help Accessibility Careers NLM NIH HHS USA.gov Back to Top