This section describes the effectual design view and methods of the proposed blockchain-enabled decentralized, trustworthy healthcare systems and their constructive functions. This work presents a blockchain-based privacy–integrity–availability–security-supported healthcare management industry standard, named the healthcare-chain model, that meets the goal of implementing a new versatile, high-performance framework for securely collecting, handling, and storing human health records. In this section, we discuss the functions and activities used in the trustworthy healthcare-chain system, which is shown in
Figure 2. In this framework, the blockchain-enabled healthcare system can be synchronized with Industry 4.0 by addressing the potentially unique features of emerging blockchain technology. The proposed work offers a radical development in healthcare resources for secured health data transactions. Here are the most-important benefits of the blockchain-based module that prove useful for the management of data sharing, data transmission, and data storage in the healthcare industry. The proposed system provides secured, immutable, and scalable data transactions, as well as indicates the strategies for the quality of e-health services. It potentially processes real-time health data, ensuring remote access to low-cost healthcare industry services.
However, blockchain technology supports establishing trust and reliability in various potential use cases or scenarios for digital health records in the healthcare sector. The use case of blockchain-based secure data storage and transactions or sharing is fully encouraging the improvement of the healthcare system in our proposed decentralized distributed system. In this virtual era, blockchain protects the storage and transfer of sensitive healthcare data with strong security, and healthcare consumers feel secure. The immutability, integrity, and scalability features of this technology make the secure storage and accessibility of life’s most-sensitive data more reliable for healthcare customers and doctors. Based on this sensitive data for secure data sharing or transactions, consultants can provide more specific and authentic treatment to healthcare customers.
4.1. Overview of Blockchain-Based Healthcare Architecture
The design and development of this work fulfill the originality and innovativeness of competitive research according to similar supported studies for secure block data transactions in the heterogeneous network. This module incorporates trustworthy and scalable features according to the transactions of health services. Health data providers participate in this system to process data access and privacy preservation through consensus mechanisms and digital transaction signatures to generate new information ledger policies. In several cases of this architecture, the key design approach and views are presented as follows.
4.1.1. Healthcare Provider Responses and Activities
In the scope of this work, the registered users of the healthcare system may participate in the blockchain consensus protocols for their confidential and immutable data transactions and accomplish health record management. The proposed model uses smart hash contracts for compliance in each block of the blockchain platform to maintain the integrity of health organization data. This model will play a new role in making healthcare accessible to the healthcare recipient and the healthcare consultant using a modern web application by completing the necessary procedures. Healthcare data collected by healthcare consultants are reserved on the blockchain and used as storage on this platform. Only authorized healthcare consultants are able to connect health data transactions to the blockchain in this application, but there is no permission for unauthorized consultants or third parties.
Healthcare providers such as doctors (DTR), physiotherapists (PT), health nutritionists (HNT), and health examination and screening specialists (SHTS) are governed by the healthcare center (HCC) or another HCC (AHCC) through registration. The actions of healthcare providers with the platform are shown in
Table 2. All the HCC’s authorized consultants are the original data providers and generators of healthcare services within the blockchain of this system. As a core functionality without sharing any information with strangers, the consultants of the HCC produce or update human health records through their transaction signatures with their own secret keys generated by the system. Health consultants access digital healthcare information using public keys from blockchain-based health ledgers of their own HCC when they need to know about a person’s health. The AHCC’s health consultants are important data recipients of healthcare information secured on the blockchain. The AHCC’s health consultants can only view and verify healthcare records from the blockchain ledger with the permission of the HCC’s registered healthcare consultant or provider if they need to know a person’s past health history. They are not able to add or modify any data in existing healthcare records.
4.1.2. Registration Control Process of Consultants
In this platform, accredited healthcare providers or consultants are allowed to generate their personal unique user identities through the registration controller using their own public keys to provide the prescribed health data. Human care providers collect, share, and access health information through a registration process in this healthcare web application. Precisely, when a provider or consultant in the healthcare system applies to register by this design, he/she checks the validity of those applicants’ skills and competency records, then he/she securely generates his/her individual unique/user identification (UID) with the password key (PWK). For secure registration, PWK generation is designed based on a password-hashing function called bcrypt to create the user’s best crypto-secret key. All human healthcare records are generated based on SHA-256 for faster processing at a lower cost in the blockchain.
4.1.3. Controlling Access to Health Information
The access control module to health information of the trustworthy healthcare-chain model is designed to allow accredited healthcare providers or consultants to access human health data on the blockchain. The access control module of this platform is governed through the HCC or the AHCC from the healthcare sector side and the blockchain from the technology side to access the health data. Various hubs of the healthcare industry, through healthcare providers or consultants, are able to connect to this blockchain-based platform and have the benefit of accessing secure information. All interaction methods, such as adding, storing, viewing, and sharing the collected human health records, are implemented in accordance with the principles of ensuring the availability, confidentiality, usability, integrity, and security of information by participants in the public healthcare-chain model.
4.1.4. Digital Human Healthcare Ledger
One of the key components of this blockchain-based healthcare system is the digital human healthcare ledger, where health consultants on the platform participate in a peer-to-peer blockchain ledger and manage all transactions. It is particularly designed to securely store health data transaction records in the blockchain under perfect integrity, usability, and confidentiality. In addition, this module is built on the blockchain RSA encryption technique, where health data transactions are cross-referenced by the SHA-256 hash of a block, and the transaction signature method is used to ensure the authenticity. The entire process of adding new and previous block data is performed based on the PoW consensus mechanism to ensure security through health block mining for transactions. Each block contains health data related to valid transactions, previous block hashes, and timestamps, which are capable of being stored in the blockchain-enabled healthcare ledger. Using this platform, each accredited health provider stores, shares, or accesses relevant records from the blockchain ledger when required.
4.2. Health Data Retention Mechanism with Analysis
The data retention evaluator is incorporated into the healthcare-chain system to analyze healthcare processes with reliability and scalability. The blockchain-based healthcare industry exploiting validation techniques stimulates automatic data retention analysis to process human healthcare services, such as prescriptions, cellular and chemical analysis (CCA), genetic and diagnostic image tests (GDITs), physical and visual checkups (PVC), etc. The activities of the proposed approach involving designated healthcare providers or consultants occur consecutively through the approach of collecting, transmitting, storing, and receiving health data in the healthcare-chain. Three types of users, such as the HCC, the AHCC, and healthcare workers or consultants, work in the proposed system to allow access to health data on the healthcare blockchain. An authorized consultant uses a client node to encrypt healthcare data with a designated user public key in this system using key encryption techniques. Encrypted healthcare data are hashed using SHA-256 on blockchain nodes via the DAC module, and the value is implanted inside a block for the mining process. Private blockchain miners successfully start mining over this block to add it to the healthcare-chain. Authorized consultants must decrypt the health data to view their transactions using signature key techniques. Permitted consultants can view or share the health data from the blockchain if the health data block’s hash matches the sender’s encrypted hash. As depicted in the prototype of
Figure 2, the technique of healthcare data transaction activities is briefly introduced as follows.
F1, F7, and F12: Accredited healthcare providers need to assign the UID and PWK through the registration controller (RC) to use the healthcare-chain system. Once the registration process is authenticated, they can send requests directly to the Healthcare-Chain to reserve and access healthcare through client nodes. Otherwise, they will not be allowed in this system.
F2 and F14: Once the registration authentication process of the HCC or AHCC’s healthcare provider is accomplished, they can individually request to send human healthcare data to the DAC. The healthcare data sent will be encrypted for security purposes. In another case, the HCC or AHCC can request to forward the healthcare data to each other’s through the DAC, and they can view the corresponding data after decryption.
F5 and F17: The healthcare providers of the HCC or AHCC will receive their respective UB from the DAC and reserve it in the healthcare ledger for acknowledgment. In another case, the HCC or AHCC can request to view each other’s healthcare data on the DAC using their respective UB.
F3 and F16: Encrypted health records with the signature key will be shipped to the healthcare-chain ledger by the DAC for storing purposes, which are immutable. In another case, when the healthcare data are to be viewed or shared by the HCC or AHCC, the stored data will be sent to the DAC in encrypted form.
F4 and F15: The healthcare user identification and password key data are stored in healthcare-chain ledger blocks. A unique block identity UB will be generated for the request of the HCC or AHCC’s healthcare provider, and the DAC will receive this UB. In another case, if healthcare users want to view or share healthcare data, they can directly request the healthcare-chain ledger to match their respective identities with the stored unique block identity UB.
F6 and F13: Accredited healthcare consultants such as the DTR, PT, HNT, and SHTS can request the HCC or AHCC to make their respective identity UB. They can collect or access healthcare block data using their respective identity. In another case, consultants can gain permission from the HCC or AHCC to view or share the healthcare data for a particular time through the unique healthcare identity of the desired healthcare recipient people (HRP).
F8: Once the respective identity process is authenticated, an accredited healthcare consultant can send a request to the DAC to obtain his/her identity UB from the healthcare-chain ledger.
F9: The DAC will interact with the blockchain to assign the generated corresponding consultant identity UB. A consultant can also send an instruction to the healthcare-chain ledger to match the respective identity with the stored identity UB through the DAC.
F10: When the concerned consultant wants to view or update the data of the desired HRP, the healthcare-chain system will securely explore and authenticate the HRP’s data on the blockchain with the UB as the respective reference and put it back into the DAC.
F11: The DAC will send the encrypted healthcare data of the desired HRP to the corresponding consultant after authentication, and they can view or update that data as needed.
F18, F19, F20, and F21: The corresponding consultant will only collect the healthcare data, UB, including the respective identity of the HRP, for storage purposes on the blockchain. Regardless, due to the possibility of the misuse of health data, the HRP will not obtain any permission for the prescribed data view.
F22: Healthcare providers and consultants as users can submit their requests for health service access to the trustworthy and scalable data retention evaluator for authentic data verification.
F23: The authentic data evaluator of this system will interact with the DAC for the health service access verification to accomplish the user requests.
F24: The DAC will allow a data retention evaluator once data verification techniques ensure secure data access.
F25: The data retention evaluator will send feedback to the healthcare providers and consultants regarding their requests for the healthcare receipt.
4.3. Trustworthy and Secure Healthcare Policy
If health information is processed, stored, or transmitted entirely through blockchain technology in a secure healthcare system, the system can be trusted and scalable while ensuring the high performance of data privacy, integrity, and availability. In this system, the main strategy of decentralized entities is to gain legitimacy to store health data resources by controlling decision-making activities or transferring health data to the blockchain without the risk of an intermediary. A detailed description of the secure data transaction policy in the proposed healthcare system is adequately represented in
Figure 3 through the health data block generating process.
Healthcare providers or consultants as users can participate and confirm transactions on this platform without the need for a central clearing authority. Through all transactions within the blockchain across a peer-to-peer network, prescribed health data are packaged into blocks, which connect to construct a chain accompanied by other blocks of identical information.
Healthcare transaction records are guided as blocks in the blockchain, and healthcare providers or consultants represent data access transactions as network participants. Participants in this system establish a signed transaction when exchanging health information of healthcare recipients using their private keys at a timestamp. The hash value of the block links to the nonce, which is used to identify the data in the particular block. In accordance with the blockchain engineer, is the initial or first block in the blockchain system that should be NULL in value for all periods as genesis block. A nonce is a 32-bit whole number rendered by the proof-of-work process to miner nodes when a block is created. A digitized timestamp is used to store the system time for each digital healthcare data transaction when each block is completed.
The defined notation (DN) and description of related primitives for Algorithms 1–3 are exhibited in
Table 3. A public key,
, and secret key,
, pair is generated and kept in the healthcare ledger, which is used for health data transmitting, shown in Algorithm 1. In this case, the cryptography RSA process is employed to encrypt or decrypt the health record, and a transaction signature is generated using the private key to maintain authentication. The processing block’s hash for healthcare transactions is presented in Algorithm 2. The hash function is used for cryptographic block transactions in the blockchain. Here, the given health data are digested to the hash-256 value. In this case, the data block transaction is assembled with a combination of the timestamp, hash value, and nonce, which are important for data immutability and security. Algorithm 3 presents the procedure of publishing health block data in the healthcare blockchain. A new node is allowed to be added to this system for data transactions on the blockchain. Here, the transactional signature method is used to verify the digital signature of the transactions. Health transaction blocks are hashed using the SHA-256 process as a valid proof technique to validate the data, and and PoW function is used to check the validity of mining necessities. The transactional chain function performs validation checks for successful blockchain operation. The system then broadcasts the health block data through the transaction function on the healthcare blockchain. The following aspects are discussed to maintain the continuity of reliable and safe healthcare policy in the mentioned algorithms.
Algorithm 1 Key management and data transmitting to HC-chain system by health provider. |
- 1:
Procedure setup(Initialization, dictionary, signature) - 2:
Initialization of variables: , , , - 3:
- 4:
function orderedDictionary() - 5:
ifthen - 6:
Collects except sender’s - 7:
return - 8:
else - 9:
Denied to preserve - 10:
end if - 11:
end function - 12:
function signatureOfTrnsaction(D) - 13:
if wishes over then - 14:
← Performs except healthcare sender’s - 15:
← Generate hexadecimal imported key(sender’s ) with RSA - 16:
← Generate crypto-sign of sender’s - 17:
H← Compute hash of encoded () - 18:
Decode using H and - 19:
return for - 20:
else - 21:
Denied to generate - 22:
end if - 23:
end function - 24:
function keyGeneration - 25:
← Generate random(crypto key value) - 26:
← Perform random(RSA(1024, RNG)) - 27:
←· - 28:
Decode hexadecimal , by PEM, ASCII - 29:
Get generated , - 30:
end function - 31:
function performHealthRecord Transaction - 32:
if == of health record then - 33:
access with except sender’s - 34:
else - 35:
No access - 36:
end if - 37:
end function
|
Algorithm 2 Processing block’s hash for transactions. |
- 1:
Procedure setup of block’s hash strategy - 2:
function generateBlock - 3:
Assign in :: , , , , ; - 4:
ifthen - 5:
Add a new in ; - 6:
Reset list for current ; - 7:
Append to ; - 8:
else - 9:
do nothing; - 10:
end if - 11:
end function - 12:
function hash(block) - 13:
if encoded as a json file then - 14:
SHA-256 H of a ; - 15:
update with ; - 16:
return hex ; - 17:
else - 18:
get inconsistent hash; - 19:
end if - 20:
end function - 21:
processing blocks move forward to the blockchain
|
Algorithm 3 Publishing health block data in HC blockchain. |
- 1:
Procedure setup of blockchain strategy - 2:
Initialize parameters:: , , , - 3:
function registerNode - 4:
if holds with containing then - 5:
urlparse(node-url). and urlparse().; - 6:
Allow to add a new node to ; - 7:
else - 8:
Not allow to add for invalid node; - 9:
end if - 10:
end function - 11:
function verifySignature - 12:
hex imported sender’s with RSA; - 13:
if verifier = PKCS1.new() then - 14:
h = Hash encoded ; - 15:
verify(h, hex ) by verifier; - 16:
else - 17:
verify nothing; - 18:
end if - 19:
end function - 20:
function validProof - 21:
= Encoded string(); - 22:
get SHA-256 H of a ; - 23:
Update value with hex and ; - 24:
TRXs satisfy the mining conditions; - 25:
end function - 26:
function PoW - 27:
get last value of chain list; - 28:
and ; - 29:
while validProof(TRXs, , nonce) is false do - 30:
; - 31:
return ; - 32:
end while - 33:
end function - 34:
function validChain - 35:
while length(chain) > current index of list do - 36:
; - 37:
if [] matches then - 38:
Elements of is successful; - 39:
else - 40:
validProof(Elements of ) is not correct - 41:
return unsuccessful operation; - 42:
current index ; - 43:
end if - 44:
end while - 45:
end function - 46:
function newTransaction - 47:
collect , signature, - 48:
if sender’s == mining sender’s value then - 49:
append to TRXs(pending list); - 50:
return ; signature verification is performed - 51:
append to TRXs(pending list); - 52:
return ; - 53:
else - 54:
return inconsistent TRX; - 55:
end if - 56:
end function - 57:
get block , chain and mining by connected nodes
|
4.3.1. Privacy
In the proposed healthcare-chain framework, blockchain guarantees health data storage and protects data privacy by providing access to fair participants in a trustless environment. In this case, confidentiality appraisals defend published data from unrecognized credentials and wrongdoing. This process uses RSA and SHA-256 to ensure data privacy while protecting health data storage access on the network by overcoming digital risks. With this cryptosystem, healthcare data can be encrypted with public keys, and encrypted health data are decrypted by matching participants’ private keys. This approach uses such cryptosystems with raw health data and incorporates trust and anonymity to ensure the ultimate right to privacy.
4.3.2. Integrity
Healthcare providers or consultants who participate in the blockchain platform and add healthcare data to the blockchain once cannot completely delete or modify the data later on. The ethical behavior of integrity prevents unauthorized parties from altering health information and accomplishing unrecognized transactions. In this scheme, the hash function is used to ensure that no one can change the health data of the transaction. Here, SHA-256 and PEM are two methods used to maintain data security. Typically, a key component of blockchain technology for data integrity is the Markel tree, which is verified through a cryptographic hash function. In the block-to-block hashing approach, the hash of the previous block must be found in all data blocks within the blockchain to conserve chain integrity. Integrity guarantees healthcare data transactions without any content tampering or alteration by holding hash values, genesis blocks, nonces, and timestamps in the blockchain. A consensus protocol named proof-of-work is used to ensure the integrity of new blocks of health data added to verify transactions on the proposed healthcare blockchain in a more decentralized way.
4.3.3. Availability
The availability arrangement provides timely data in blockchain storage without allowing interrupted access to the proposed distributed healthcare process. The process uses blockchain technology to provide secure authentication and access to healthcare data in a decentralized manner to achieve high maximum availability. Healthcare providers or consultants connect to the healthcare-chain through the DAC process to send, store, and receive data. In this case, all transactional healthcare data demand generated within a given period can be witnessed by all access levels of the blockchain network. In addition, the blockchain network ensures security and compliance by creating independent streamlined access to HCC and AHCC users using public and private keys, including forming a data transaction signature. Data availability does not include such data on transactions that have been accomplished in the system but not published in the blockchain. User nodes can observe new block generation in this module to ensure that all healthcare records in the block have been published to the blockchain. Thus, data availability guarantees readily available information to healthcare users while maintaining system security.
4.3.4. Scalability
Scalability generally refers to the ability of a network to process many data transactions or how quickly they can be processed. Scalability is the performance of blockchain networks that can sustain significant transactions based on consensus and decentralized principles in healthcare management. In this case, the consensus PoW function of the blockchain system will automatically adjust the number of nodes taking into account new participants in the network and make the data transactions scalable. Blockchain is capable of maintaining the scalable performance of secure data access with increased transaction load across the platform’s networks.
4.3.5. Interoperability
Interoperability, as one of the features of blockchain, enables distinctive and promising data transactions or records in this healthcare system. The proposed distributed healthcare system enables secure data exchange between two or more interoperable blockchains using the PoW consensus protocol. In this case, this application can ensure data security without the necessary cooperation of third parties for digital healthcare transactions. Healthcare providers or consultants connect to the healthcare-chain ledger through the DAC process to share, view, and receive data from other healthcare blockchains.
4.3.6. Accountability and Efficiency
Accountability for data transactions can be an important assessment to ensure secure health services in decentralized delivery systems through consultants. The presented platform for storing and sharing prescribed health information executes accountability through blockchain, digital signature, and key pair techniques. In this case, accountability is acknowledged by calculating the transaction, timestamp, hash value, and nonce within the health blockchain record. Moreover, these processes support achieving the efficiency of secure data transactions in completing transactions on the blockchain.