Blockchain technology vs. traditional DBMS.

Blockchain technology and traditional DBMS differ significantly in terms of data management, security, and operational paradigms [34]. Below, we outline the key differences and highlight the necessity of blockchain in our proposed system.

1. (a) Data Management
   1. (1) Traditional DBMS:
      • Centralized architecture with a single point of control.
      • Relational data models with structured query language (SQL) for data manipulation.
      • User can create, read, update, and delete the data.
      • Vulnerable to single points of failure and data breaches.
   2. (2) Blockchain Technology:
      • Decentralized and distributed architecture with no single point of control.
      • Immutable ledger ensuring data integrity and transparency.
      • The user can read and append-only new data blocks, which helps record the history of all data without being able to temper it.
      • Enhanced security through cryptographic techniques and consensus mechanisms.
   
   So, traditional DBMS systems, while efficient for structured data management, are prone to single points of failure and data manipulation. In contrast, blockchain provides a tamper-proof and decentralized approach, ensuring data integrity and resilience against attacks.
2. (b) Security and Privacy
   1. (1) Traditional DBMS:
      • Relies on access control mechanisms and encryption to protect data.
      • Centralized control increases vulnerability to cyberattacks.
   2. (2) Blockchain Technology:
      • Utilizes public and private keys for secure data access.
      • Decentralization reduces the risk of single points of failure and enhances data security.

Therefore, in a blockchain-based healthcare system, patient data is encrypted and distributed across multiple nodes, making it significantly harder for unauthorized parties to compromise the data, as opposed to a centralized DBMS where breaching the central server could expose all data. For example, in [20], the authors discussed the application of blockchain technology in ensuring data integrity and transparency in a distributed system. They highlighted the use of consensus mechanisms to achieve agreement among distributed nodes. Similar to [20], our B-UMCS system exploits blockchain’s consensus mechanisms to ensure that all healthcare providers in the network have a consistent and tamper-proof view of the data. This is crucial for maintaining the integrity of EHRs across different hospitals. In addition, in [21], the authors explored how blockchain can be used to handle massive data dissemination in an Industrial Internet of Things (IIoT) environment, focusing on scalability and data security. In line with [21], our B-UMCS system addresses scalability by utilizing the IPFS for efficient data storage and retrieval. Additionally, our use of public key infrastructure (PKI) and role-based access control (RBAC) ensures that only authorized personnel can access sensitive patient data, thus maintaining data security and privacy.

For further clarification, the integration of blockchain technology in B-UMCS involves several key components and processes:

1. 1. Blockchain Network: The Ethereum blockchain is the backbone of the B-UMCS, providing a secure and immutable ledger for recording transactions. Each transaction, such as a consultation request or the sharing of an EHR, is recorded on the blockchain, ensuring transparency and traceability.
2. 2. Smart Contracts: Smart contracts are deployed on the Ethereum blockchain to manage interactions between healthcare providers. These contracts define the rules and conditions for various operations, such as initiating consultations, sharing EHRs, and updating patient records. Smart contracts ensure that these operations are executed automatically and transparently.
3. 3. Decentralized Storage with IPFS: EHRs and other large datasets are stored off-chain using the IPFS. This decentralized storage solution ensures that data is distributed across multiple nodes, enhancing accessibility and resilience. The blockchain stores cryptographic hashes of the records to ensure data integrity and verify authenticity.
4. 4. Secure Data Access: Data security is maintained through advanced encryption techniques. PKI is used to control access to sensitive information, ensuring that only authorized healthcare providers can access patient records. RBAC is implemented to further restrict access based on user roles.

Scope and selection criteria.

The scope of this literature review includes studies and articles published in peer-reviewed journals, conferences, and reputable sources in the last recent years from 2018 to 2024. The selection criteria for including studies in this review are:

1. The relevance to blockchain technology applications and consultancy services in healthcare.
2. The focus on EHRs, telehealth services, and data security.
3. The studies that provide empirical data, case studies, or theoretical frameworks.

Search strategy.

A systematic search was conducted in several academic databases, including PubMed, IEEE Explore, ACM Digital Library, ScienceDirect, and Google Scholar. Keywords used in the search included “blockchain in healthcare,” “medical consultancy service,” “electronic health records,” “telehealth,” “healthcare consultation services,” “data security in healthcare,” and “blockchain applications in medicine.” The search was refined using Boolean operators and filters to identify the most relevant studies.

Summary of findings.

The following paragraphs summarize the key findings from the current studies, categorized into different themes in terms of (a) Blockchain for EHRs, (b) Blockchain for Telehealth Services, and (c) Security and Privacy in Blockchain Healthcare Systems.

The study by Xiao et al. discussed a blockchain system specifically for EHRs using consortium blockchain technology, where each node holds a ledger copy with EHRs and governed permissions [35]. Sheela et al. also explored a blockchain approach for EHR management, which while innovative, faced challenges like increased storage costs and slower network distribution [36]. Furthermore, while these frameworks facilitated communication among multiple hospitals, they notably lack the provision for direct communication and knowledge transfer between doctors from different hospitals. This limitation underscores a critical gap in the existing telehealth infrastructure, highlighting the need for a more integrated system that not only secures and facilitates the sharing of EHRs but also enables healthcare professionals to collaborate and exchange expertise seamlessly across institutional boundaries.

In their research, Praveen et al. proposed a novel blockchain-based system for managing EHRs, which incorporated off-chain storage solutions to maintain system efficiency and address the challenges of on-chain data storage. This system aimed to enhance communication among healthcare stakeholders including patients, doctors, and insurance providers [37]. Additionally, Hassija et al. introduced a patient-centered blockchain framework using the Ethereum blockchain, designed to recommend specialists for minor medical consultations. This system allowed patients to log in, describe their medical conditions, and interact directly with doctors, thus improving patient engagement and aiming to protect privacy, although the specific privacy protection methods are not detailed in their study [38].

In their study, ANOOHYA et al. [39] introduced a blockchain-based system utilizing the InterPlanetary File System (IPFS) for storing digital content, which enhances privacy, non-repudiation, and immutability of actions within the system. This system facilitated various medical interactions but lacked direct doctor-to-doctor interactions. Kordestani et al. [40] developed HapiChain, a blockchain-based monitoring system with a three-layer architecture designed to enhance functionality and security. Puneeth et al. [41] proposed a blockchain framework that improves the privacy and security of EHRs by using IPFS and hybrid encryption techniques, optimizing the search mechanism and reducing time and space complexity. This system allows patients to control their EHRs’ visibility to doctors, but limits doctors to viewing EHRs without enabling them to diagnose or create treatment plans. Each of these systems contributed uniquely to the blockchain and healthcare domain, showcasing the potential of blockchain technology in enhancing the security, privacy, and efficiency of healthcare services. However, they also highlighted the need for further development, particularly in enabling more interactive and collaborative functionalities for healthcare professionals, and in providing comprehensive details on security measures and system operations.

In the works of Cerchione et al. [42] and Uddin et al. [43], the authors explored blockchain-based networks designed to enhance the quality of healthcare services by generating valuable data sources for science and research. These studies presented effective implementations of telehealth services with a strong focus on health data protection. However, they did not address the primary goal of our research, which is to mitigate resource shortages within hospitals by facilitating more efficient resource allocation and utilization. Hassan et al. [44] introduced a private blockchain solution to address healthcare challenges by enforcing restrictions and assigning access based on participant roles, utilizing Ethereum for activity tracking and IPFS for data storage. This system enhanced telehealth security and efficiency but had limitations in simulating real-world operational dynamics due to its local Ethereum blockchain implementation and lacked a decentralized application for end-user interaction. Bawany et al. [3] developed BlockHeal, a comprehensive telehealth framework that integrates all essential healthcare services onto a single platform. This framework, which utilizes blockchain technology and Hyperledger fabric, aims to include all stakeholders (patients, doctors, health ministries, pharmacists, and insurers) within a secure, reliable, and timely healthcare system, facilitated by a suite of decentralized applications. Despite its complexity and ambition to streamline healthcare service delivery, the framework did not facilitate doctor-to-doctor communication for case management, and details on the consensus mechanisms and algorithms used in the system’s implementation are not provided. These varied approaches to utilizing blockchain technology in healthcare illustrate the potential for enhancing the security, efficiency, and accessibility of healthcare services. However, they also highlight the need for further development to address specific challenges such as facilitating professional collaboration and providing detailed technical specifications for system implementation.

Lee et al. [45] developed a blockchain-based infrastructure designed to establish a global health record exchange platform that ensures the confidentiality, integrity, and availability of health records for efficient health management. This platform used Health Level 7 Fast Healthcare Interoperability Resource (HL7 FHIR) standards to format data, enabling the international exchange of Personal Health Records (PHRs) across healthcare institutions and between patients and doctors. The system architecture included a PHR management interface for user engagement and a blockchain exchange system constructed on Ethereum, which utilized a private blockchain network with a proof of authority consensus model for transaction validation. However, the specific database used for storing EHRs was not detailed, including whether it was cloud-based or not, and the security measures applied during the sharing of EHRs were limited to blockchain constraints, without additional controls. Christodoulou et al. [46] introduced a decentralized, blockchain-based framework aimed at enhancing privacy in health information exchanges and empowering patients to manage their medical data and control access permissions, thus maintaining their autonomy. Additionally, research by Patil et al. [47] developed a framework for distributing EHRs that combines blockchain technology with the decentralized IPFS within a cloud environment. This framework proved effective in securely transferring data and protecting sensitive patient information, offering significant improvements over traditional data sharing models, such as enhanced access control, reduced network latency, and heightened security and privacy. However, this system primarily facilitated patient actions in uploading and sharing EHRs, without detailing the involvement or functionalities available to healthcare professionals, particularly doctors.

Critical analysis of literature studies and their gaps.

The review of existing literature, summarized in Table 1, highlights key challenges in ensuring privacy and security of EHRs and in facilitating secure information exchange within peer networks. It is observed that the introduction of blockchain technology into healthcare has brought significant advancements, particularly in enhancing data security, transparency, and interoperability. Furthermore, Scholarly work shows a strong preference for patient-centric models, which significantly improve patient autonomy and security in managing health data. However, these models typically overlook the critical need to address real-time challenges in healthcare, such as the scarcity of healthcare providers in various settings. However, several gaps remain in the current literature, which our study aims to address through the proposed B-UMCS.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 1. Summary of the comparison between our work and the related studies.

https://doi.org/10.1371/journal.pone.0310603.t001

Therefore, despite the promising applications of blockchain in healthcare and medical consultancy services, the following shortcomings have been identified in the existing literature:

1. 1. Limited Inter-Hospital Collaboration: Current blockchain-based healthcare systems primarily focus on intra-hospital applications and lack mechanisms for effective inter-hospital collaboration. They also do not adequately support seamless communication and knowledge transfer among healthcare providers and practitioners across different institutions. Improving patient outcomes and sharing professional expertise requires an integrated system for seamless doctor-to-doctor contact.
2. 2. Scalability and Data Management: Many studies highlight the scalability issues associated with blockchain technology, particularly in managing large volumes of healthcare data. Traditional blockchain implementations often struggle with data storage and retrieval efficiency, which is critical for healthcare applications involving extensive EHRs.
3. 3. Security During Data Transfer: Many systems rely on blockchain’s inherent features, like immutability and decentralization, to secure EHRs. However, these systems often lack additional security measures during data transfer; they ensure data security at rest. Consequentially, they overlook the vulnerabilities associated with data transmission, making the data susceptible to breaches during transit.
4. 4. Real-Time Applicability: There is a lack of real-time applicability in existing blockchain-based healthcare solutions. Most studies focus on theoretical frameworks and simulations without demonstrating practical implementations that can operate efficiently in real-world healthcare settings.
5. 5. Integration with Emerging Technologies: Limited research has been conducted on integrating blockchain with other emerging technologies such as artificial intelligence (AI) and the Internet of Things (IoT) to enhance healthcare services. This integration could potentially improve diagnostic accuracy, patient monitoring, and overall healthcare delivery.

How B-UMCS addresses the gaps in the literature.

The proposed B-UMCS aims to address several critical gaps in the current literature on blockchain applications in healthcare through the following features and improvements:

1. 1. Enhanced Inter-Hospital Collaboration: B-UMCS facilitates seamless communication and knowledge transfer among healthcare providers and practitioners from different hospitals and regions. By leveraging smart contracts and a decentralized architecture, B-UMCS enables real-time consultations and collaborative decision-making, thereby addressing the limitations of current systems.
2. 2. Efficient Data Management with IPFS: B-UMCS integrates the IPFS for off-chain and decentralized data storage to tackle scalability and data management challenges. This approach ensures efficient storage and quick retrieval of large volumes of healthcare data, enhancing the system’s scalability.
3. 3. Secure Data Transfer Mechanisms: B-UMCS employs advanced encryption techniques and PKI to secure data during transfer. By implementing RBAC and end-to-end encryption, the system ensures that data remains protected throughout the transmission process.
4. 4. Real-Time Implementation: Our study demonstrates the real-time applicability of B-UMCS through practical implementation and evaluation in healthcare settings, showcasing its capability to operate efficiently and effectively in practice.

Consequently, in response to these findings, our paper introduces a secure B-UMCS system designed for medical consultancy services. This system aims to enhance the security and privacy of EHRs and facilitate robust information exchange among healthcare providers, potentially easing provider shortages and enhancing the quality of healthcare services offered. The next section details the proposed system’s architecture, functionalities, and approach to addressing the limitations identified in existing research.

Hospital registration process.

This section covers the three steps interaction process detailed in Figs 3–5, which illustrate the sequential steps involved in hospital applications, administrative entity’s assessments, and the subsequent approval process. These figures provide only an example representations of the workflows, delineating the various stages of interaction from application to active participation in the B-UMCS. By integrating these components, the proposed platform aims to streamline the process of healthcare consultancy, foster a collaborative environment among medical professionals, and significantly enhance the security and privacy of patient data within the healthcare system.

The process illustrated in Fig 3 depicts a streamlined approach for hospitals to register and participate in a specialized blockchain network for B-UMCS. The procedural steps are as follows:

• Accessing a dedicated registration portal: Hospital (A) start the registration process by accessing the registration portal.
• Providing registration information: Upon accessing the portal, Hospital (A) is presented with a registration interface where it is required to input critical identifiers such as its name and email address.
• Prompting the areas of interest: The registration form also prompts Hospital (A) to select its areas of medical specialty, for example, hospital (A) is identifying Cancer treatment as its area of interest for the B-UMCS.

As depicted in Fig 3, the registration establishes a framework for a mutual exchange of medical knowledge and services, creating a network of collaborative support that enriches the capabilities of each participating institution.

By completing this registration, Hospital (A) takes the first step toward joining a community of medical professionals dedicated to improving patient outcomes through collective expertise. The system is designed to facilitate a secure, reciprocal sharing of knowledge, wherein each hospital contributes to and benefits from the shared pool of medical specialization, thereby enhancing the quality and breadth of healthcare services available.

The process depicted in Fig 4 showcases the review phase undertaken by the MOH. It illustrates a user-friendly interface for the MOH to manage applications efficiently, highlighting the importance of a robust and transparent review system in the healthcare consultancy blockchain network. This system interaction phase is essential for maintaining the quality and reliability of the healthcare services provided through the B-UMCS.

In the review phase, the MOH evaluates applications from various hospitals seeking to join the B-UMCS. This step is crucial as it ensures that only qualified and credible institutions are allowed access to the system, thereby maintaining high standards of healthcare consultancy services. Therefore, upon receiving applications through the registration portal, the MOH conducts a thorough assessment of each hospital. This assessment is based on established criteria, likely encompassing factors such as medical expertise, years of experience, and the hospital’s technological readiness to integrate with the blockchain system. Hospitals are listed with their respective areas of specialization, such as ENT, surgeries, and cancer, alongside their years of experience in these fields. The MOH uses this information to make informed decisions on which hospitals will be granted access to the network. Each application is accompanied by two actionable options represented by check (approve) and cross (reject) icons, allowing MOH officials to easily approve or reject applications with a simple click. This streamlined process aids in expediting the review phase while ensuring accuracy and fairness in the approval process.

The transparency of the approval process is critical, and the blockchain network facilitates this by providing an immutable ledger of all actions taken by the administrative entity, ensuring that transactions are recorded in cryptographically linked blocks and broadcast over a network, guaranteeing that each entry is permanent and tamper-proof. This builds trust among participating hospitals and stakeholders. By employing such a detailed review system, the MOH acts as a administrative entity, upholding the integrity of the medical consultancy services provided through the blockchain.

The approval process as shown in Fig 5 involves the MOH reviewing and assessing the applications of various hospitals, including Hospital (A), that have applied to be part of a specialized blockchain network. The MOH’s role is critical in vetting the hospitals based on their expertise, areas of specialization, and experience to ensure the highest quality of collaborative healthcare consultation services within the blockchain network.

Upon a successful review, Hospital (A)’s application to join the blockchain network specializing in cancer treatment is accepted. The MOH grants Hospital (A) access to the network, enabling it to become a contributing member to this exclusive pool of healthcare expertise. As a result, Hospital (A) gains the capability to request and provide specialized consultations, share EHRs securely, and engage in private messaging with other network hospitals to collaborate on patient cases. This process is essential to form a secure, decentralized network of healthcare providers that leverages the strengths of blockchain technology to enhance the quality of care provided to patients. The approval and access granted by the MOH allow for a secure and private exchange of medical knowledge, fostering a community of medical practice aimed at leveraging collective expertise for improved patient outcomes.

Fig 6 delineates the essential functionality of the system’s Request Consultancy page. This interface empowers hospitals to draft and disseminate consultancy requests to peers within the network and to respond to existing inquiries. The process goes as follows

• Drafting the Consultation request: Hospital (A) start by navigating through the “request consultancy” page where the request can be drafted
• Broadcasting the request: After drafting the request, hospital (A) is ready to share the request with all peers within the blockchain. this is done through sharing the request message that sent from the DApp front-end to the IPFS.
• Hashing the request and calling Smart Contract: The request data is saved on IPFS, is hashed, creating a cryptographic representation of the content. This hash is then returned to the DApp front-end, and smart contract function ‘CreateMessage’ is then called.
• Completing the Blockchain Transaction: The response text is digitally signed to guarantee its authenticity and prevent denial of its origin. This signing uses the the Elliptic Curve Digital Signature Algorithm (ECDSA), an effective method for generating verifiable digital signatures.using the private key of the sender. This signature guarantees that the message’s origin is legitimate and that the content has not been altered, as it can be verified by anyone with access to the corresponding public key
• Incorporating into the Blockchain and Distributing: The signed response is incorporated into a new block on the blockchain, where it is timestamped and linked to the existing sequence, ensuring the data remains continuous and unalterable. After this block is formed, it is transmitted to all peers in the blockchain network, thereby informing all members about the current consultation and the latest information from Hospital (A).

Fig 7 illustrates the components of the block specifically the ‘Data’ section in the Fig 1. it shows the transaction’s data that has been stored on the block. The data includes (8) elements which are:

• messageId variable: A variable that store the value of the message identifier. This variable is automatically generated every time the ‘CreateMessage’ function 2 is invoked. This variable’s value is unique that can identify the request on the blockchain.
• parentId variable: this variable hold the value of the original request of the thread, indicating that this is an initial, standalone request. this variable is automatically filled every time the button ‘reply’ is clicked to reply an original request.
• Sender Variable: This variable holds the value of the sender’s address or public key. In Fig 21, the public key can be seen at the very end of the request message which is under the hospital name.
• Receiver Variable: This variable holds the value of the reciver, this variable’s value is ‘0’ whenever the request is sent to all peers on the blockchain, but hols an actual public address value when it is privately sent to one peer. Also, this variable is mainly used when the function 6 since this function checks all requests that hold the current hospital address as value in the receiver variable.
• isPublic variable: is boolean variable that hold either true or false value to check the request/reply status if it is public or Private. This is done through the function 2. the receiver value is checked, if it is equal to ‘0’ then the variable is assigned with true value, if not, then assigned with false. meaning this request/reply is not going to be publicly shown to all peers on the blockchain.
• encrypt variable: this variable holds the value of the key of the receiver that is authorized to access the EHR or the CR. This variable is used through the function 4 to restrict the access of the file hash. To ensure it is only accessible to that specific user.
• attachementURI variable: this variable holds the attachment’s hash that is returned from the IPFS.
• messageURI variable: This variable holds the value of the request/reply message’s hash that is returned from the IPFS.

Hospital (B), along with other network participants, is notified of this new case via updates on their respective home pages within the platform. This process ensures a transparent, secure, and efficient method for requesting and offering medical consultancy services (See Fig 8). This process include the following:

• Access Home Page: Hospital (B) access the B-UMCS DApp, and access the default home page, it refreshes to capture all public requests/replies.
• Fetch function invoking: ones the home pages is accessed, it invoke the function ‘FetchMessageItem’ 3, to return all messages that are (isPublic==true).
• return array of MessageURI: after calling the function ‘FetchMessageItem’ 3, it return an array of public MessageURI, that is then sent to the IPFS to return the actual request/replies.

Fig 9 encapsulates the process wherein Hospital (B) demonstrates an intent to engage with a case posted by Hospital (A), seeking additional information and the EHR of the patient. So, after perusing the available cases on the platform, Hospital (B) signals its willingness to delve deeper into a specific case presented by Hospital (A). To facilitate this, Hospital (B) initiates a request to access the patient’s EHR. The procedural steps are as follows:

• Initiating a Response to Consultation Request: Hospital (B) navigates to the ‘Reply’ section of the Request Consultancy page on the Unified BC Portal for Medical Consultancy and prepares a response to Hospital (A)’s consultation request.
• Storing the Response: The composed response is securely stored on the IPFS, leveraging its decentralized nature for enhanced security and integrity of data.
• Hashing and Smart Contract Invocation: The response data, now on IPFS, is hashed, creating a cryptographic representation of the content. This hash is then utilized in the invocation of the smart contract function, ‘CreateMessage’. The function call includes the Parent ID, which corresponds to the original request ID from Hospital (A)’s case, thereby linking the response to the initial request.
• Finalizing the Blockchain Transaction: The text of the response is digitally signed to ensure authenticity, integrity, and non-repudiation of the message. The signature process employs the ECDSA, a robust technique for creating verifiable digital signatures.
• Adding to the Blockchain and Broadcasting: The signed response is added to a new block within the blockchain. This block is timestamped and appended to the existing chain, maintaining the continuity and immutability of the data. Once this block is created, it is broadcast to all peers within the blockchain network, thus updating all participants about the ongoing consultation and the newly available information from Hospital (B).

This sequence of actions demonstrates the platform’s commitment to maintaining a secure and efficient communication channel for medical consultations. By utilizing blockchain technology, smart contracts, and decentralized storage solutions, the platform ensures that sensitive patient information is handled with the utmost care, allowing for transparent and secure professional collaboration.

Fig 10 illustrates the secure exchange of EHRs between hospitals within the blockchain-based medical consultancy platform. The figure depicts the sequence of steps taken by Hospital (A) to respond to a consultation offer from Hospital (B) and to securely transmit relevant patient EHRs. Thus, upon receiving a consultation offer, Hospital (A) accesses the Unified BC Portal for Medical Consultancy and retrieves the offer from the home page. Recognizing the intent to consult from Hospital (B), Hospital (A) proceeds to select the pertinent EHR associated with the case.

• EHR Selection and Preparation: Hospital (A) carefully selects the EHR pertinent to the case, ensuring that any personal patient information is anonymized to maintain privacy before uploading the document to the platform.
• EHR Uploading and Hashing: Hospital (A) then uploads the EHR to the IPFS, which returns a hash of the uploaded file. This hash serves as a unique identifier for the EHR.
• Smart Contract Interaction: Utilizing the smart contract function ‘CreateMessage’, Hospital (A) includes the hash of the EHR along with the Parent ID—the Consultancy Request and the public address for Hospital (B). This smart contract encapsulates the details necessary for the transaction and links it to the initial request for consultancy. To ensure secure access to the EHR, the hash or reference of the EHR is only shown to hospital (B),this is done through assigning the Public address of the hospital (B) to the encrypt variable.
• Blockchain Storage and Sharing: The transaction, containing the EHR’s hash, is stored on the blockchain. This action ensures the immutability and traceability of the EHR within the secure blockchain network.
• Broadcasting to Network Peers: Once the transaction is added to a new block and signed, it is broadcast to all peers within the Cancer Blockchain network. This process notifies all participants of the new data addition, though only Hospital (B) can access and read the EHR, ensuring confidentiality and secure access to patient information.

This process exemplifies the system’s capability to facilitate secure communication and data exchange between participating hospitals, leveraging blockchain technology to ensure the confidentiality and integrity of patient data while fostering collaborative medical consultation.

Fig 11 illustrates the workflow where Hospital (B), upon receiving the EHR from Hospital (A), commences the evaluation of the patient’s case. The steps are outlined as follows:

• Case Review and Analysis: Hospital (B) meticulously reviews the EHR provided by Hospital (A). This involves a detailed analysis of the case and the patient’s symptoms, leading to the development of a comprehensive medical report and plan.
• Consultation Report Preparation: After a thorough diagnosis and planning, Hospital (B) compiles the Consultation Report (CR), which includes their expert recommendations and proposed treatment plan for the patient’s case.
• Secure Report sharing: Prior to sharing, the CR is access restricted using the public key of Hospital (A), denoted as PU(A). This ensures that the report can only read by Hospital (A), maintaining patient confidentiality and secure communication.
• Uploading and Hashing the Report: The CR is uploaded to the IPFS, which generates a hash of the document, serving as a unique identifier for this specific communication.
• Blockchain Transaction Creation: Hospital (B) then invokes the smart contract function ‘CreateMessage’, incorporating the hash of the CR and specifying the Parent ID as the original Consultancy Request along with Hospital (A)’s public address in the encrypt variable. This creates a new transaction on the blockchain that securely records the exchange.
• Storing Data on the Blockchain: The transaction, now containing the encrypted CR, is added to a new block on the blockchain. This block is timestamped and securely linked to the existing chain.
• Broadcasting the CR: Finally, the new block with the CR is broadcast to all participants within the Cancer Blockchain network. Due to the access restriction, only Hospital (A) has the capability to access the content of the CR.

This process, as depicted in Fig 11, showcases the robust use of blockchain technology for secure and private communication between healthcare institutions. Smart contracts, and the IPFS for secure data management, the platform ensures that sensitive medical information is exchanged with integrity and confidentiality, facilitating a collaborative approach to patient care.

Fig 12 outlines the process for Hospital (C) to engage privately with Hospital (A) via the B-UMCS following the completion of a consultation that involved Hospital (B). So, Hospital (C) accesses the B-UMCS and navigates to the home page. Their objective review the CR shared on the case ‘1’, since it is only accessible to Hospital (A), Hospital (C) has to request it from the data owner, which is hospitak (A). This is done though the following:

• Loading the Home page: In the context of a recently completed consultation case, Hospital (C) expresses its intent to obtain detailed case information that was initially shared by Hospital (A) and subsequently consulted upon by Hospital (B)
• Drafting a private request Messages: To accomplish this, Hospital (C) composes a private message directed at Hospital (A), indicating the public key of Hospital (A) (PU(A)) as the message’s destination. This ensures that the message, upon being sent, remains confidential and accessible solely to Hospital (A).
• Saving the private message on IPFS: once The message is drafted, undergoes the standard procedure of uploading to IPFS, and hashing. The smart contract ‘CreateMessage’ function is called with the appropriate parameters, including the hash and the public address of Hospital (A) as the value assigned to the receiver attribute.
• Storing the Data on Blockchain: This message is then added to the blockchain as a new transaction, signed to maintain integrity and authenticity, and finally broadcast to the network. However, due to the rule (Receiver == PU(A)), only hospital (A) will be able to review the communication.

This process facilitates a secure and private channel for hospitals to request and share sensitive case details, further enhancing collaborative efforts in patient care within the network.

The process by which Hospital (A) receives and responds to private messages from Hospital (C) is delineated in Figs 13 and 14. It is demonstrated that Hospital (A), upon receipt of a communication from Hospital (C), initiates the retrieval of private messages through the execution of the smart contract function ‘FetchReceivedMessages’. Through this method, Hospital (A) identifies the specific message dispatched from Hospital (C). In response, Hospital (A) proceeds to restrict the access the CR using Hospital (C)’s public key, denoted as PU(C), ensuring the message’s confidentiality. Subsequently, the CR is uploaded to the blockchain, where it becomes a part of the immutable ledger, accessible only by Hospital (C). Thus, Figs 13 and 14 illustrate the steps for receiving and sending messages within the blockchain infrastructure. Furthermore, Hospital (A) has the capability to audit all sent messages, both private and public, by invoking the ‘FetchSentMessages’ function. This function allows Hospital (A) to oversee their communication history, contributing to a transparent and secure exchange of information within the medical consultancy blockchain network. This robust mechanism ensures that all exchanges between hospitals A and C remain secure, private, and verifiable at any given time (See Fig 15).

In the concluding phase of the communication protocol within the blockchain-based medical consultancy system, Hospital (C) employs a procedure analogous to the one depicted in Fig 13 to retrieve their incoming messages. By invoking the ‘FetchReceivedMessages’ function of the smart contract, Hospital (C) is able to access the list of messages directed to it. This function provides Hospital (C) with the ability to identify and securely download the CR that Hospital (A) has transmitted.

The security protocols established within the system ensure that when Hospital (C) initiates the download of the CR, it does so through a secure channel, maintaining the confidentiality and integrity of the patient’s data. The CR, encrypted and stored on the blockchain, can only be read by Hospital (C), as it is the intended recipient with the corresponding private key.

This final step exemplifies the secure and efficient exchange of medical consultation data facilitated by the system, demonstrating the practical application of blockchain technology in enhancing communication and collaboration among healthcare institutions.

Accessing the home page.

Upon successful authorization, Hospital (A) gains entry to the B-UMCS. The Home page, which is the default landing interface upon login, presents a comprehensive view of all active and historical consultation requests. This feature is triggers the Algorithm 1, which delineates the smart contract function responsible for aggregating all consultations and publicly accessible responses (See Fig 18). The figure illustrates the user interface, clearly identifying the active user in the top-left corner; in this instance, it denotes Hospital (A) as the currently active user, thus personalizing the user experience and ensuring that the relevant user’s activities and messages are conveniently accessible.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 18. Hospital (A) accesses the B-UMCS.

https://doi.org/10.1371/journal.pone.0310603.g018

Algorithm 1 FetchMessageItems

Output: Returns an array of public consultations and replies that are visible to the querying hospital.

1: procedure FetchMessageItems

2:  itemCount ← Current(_messageIds)

3:  publicItemCount ← 0

4:  currentIndex ← 0

5:  for i = 0 to itemCount − 1 do

6:   if IsPublic(idToMessageItem[i + 1] then

7:    publicItemCount ← publicItemCount + 1

8:   end if

9:  end for

10:  DECLARE items as array of MessageItem with size publicItemCount

11:  for i ← 0 to itemCount—1 do

12:   if idToMsgItem[i + 1].isPublic = true then

13:    currentId ← i + 1

14:    currentItem ← idToMsgItem[currentId]

15:    items[currentIndex] ← currentItem

16:    if items[currentIndex].attachementURI ≠ “” AND NOT(msg.sender = idToMsgItem[i + 1].encrypt OR idToMsgItem[i + 1].encrypt = address(0)) then

17:     items[currentIndex].attachementURI ← “Restricted”

18:    end if

19:    currentIndex ← currentIndex + 1

20:   end if

21:  end for

22:  return items

23: end procedure

The FetchMessageItems 1 Algorithm is responsible for retrieving an array of all the public messages. First it initiates a variable to count the Number of Public Message items. The function creates a loop function and retrieve message items, the items either can be the consultation request or their replies from the blockchain. Then, it checks the (isPublic)variable included within the data stored on the blockchain if (isPublic == True), then this message item will be included within an array of public messages that is later returned as an output to be displayed on the home page. Then, the function also checks the “AttachementsURI” of each message item if it is not null And The sender’s public address is the same public Address in the encryption variable, or the public address of the encryption variable is not “0”, then Attachment IPFS hash will be restricted.

Requesting consultancy.

Faced with a shortage of oncology specialists and an increasing number of cases, Hospital (A) turns to the B-UMCS to solicit external expertise. To initiate a request for assistance, the hospital navigates to the “Request Consultancy” tab, employing the procedures outlined in Algorithms 2 and 3.

The CreateMessge 2 Algorithm creates a new message and associate it with a unique ID NewMsgID and sets its metadata which is the IPFS hash returned from storing the message request on the IPFS. The Function calls the function mint which is used to create a new request message (Digital Asset) and assign it to a given public address, which in this case is the Sender variable. The SetTokenURI is used to set a new URI or reference to the new request message, to allow retrieving the request message when needed. Then, a sendMessageItem private function is called, including the updated variables as an input to the functions (the Message unique ID, the receiver Address, the Parent ID of the message, the address used to encrypt the CR’s referense, and the Attachment IPFS hash). Finally, the Message ID is returned.

The Algorithm SendMessage 3 is used to Handles the creation and storage of message items, the Functions take a variable as an input, The Message ID, The Public Address of the receiver, The Case ID (ParrentId), The Public Address needed for an referense encryption, The IPFS hash of Attachment (If there is an attachment). The Function checks the Receiver variables, if it’s “0” meaning it is not sent to a particular Public Address. It will be flagged as a public Message (isPublic = True), if the Variable hold a specific Address, it is then flagged as a private Message (isPublic = False). Finally, the “MessageItemSent” Event is emitted including the 7 variables to create the Message transaction, Events are components of contracts Which When triggered, they record their arguments in the transaction log, a specific data structure on the blockchain.

Algorithm 2 Create Message Function

Input: messageURI, address of the receiver, parentId

Output: providing the message IPFS Hash, receiver’s address, parent ID (if any), and encryption address (if applicable). The function returns the new message ID.

 1: procedure CreateMessage(messageURI, receiver, parentId, encrypt, attachmentURI)

 2:  MsgID ← MsgID + 1

 3:  newMsgID ← MsgID

 4:  _mint(msg.sender, newMsgID)

 5:  _setTokenURI(newMsgID, messageURI)

 6:  sendMessageItem(newMsgID, receiver, parentId, encrypt, attachmentURI)

 7:  return newMessageId

 8: end procedure

Algorithm 3 Send Message Function

Input: MsgID, receiver, parrentId, encrypt, attachementURI.

Output: None.

 1: procedure SendMessageItem(MsgID, receiver, parentId, encrypt, attachmentURI)

 2:  if receiver = address(0) then

 3:   publicItems ← publicItems + 1

 4:   idToMsgItem[msgID] ← MsgItem(MsgID, parentId, msg.sender,

 5:   receiver, true, encrypt, attachmentURI)

 6:  else

 7:   idToMsgItem[MsgID] ← MsgItem(MsgID, parentId, msg.sender, receiver, false, encrypt, attachmentURI)

 8:  end if

 9:  emit MessageItemSent(MsgID, parentId, msg.sender, receiver, receiver = address(0), encrypt, attachmentURI)

 10: end procedure

This dual-algorithm process facilitates both broad and targeted communications, underpinning the platform’s capacity to adapt to the diverse needs of its users. The system’s architectural design, coupled with the blockchain’s immutable ledger, ensures that every consultancy request is traceable, secure, and handled with the utmost efficacy.

Fig 19 shows the user interface for consultancy requests, enabling the hospital to determine the audience of the message. The system offers the option to disseminate the message either publicly or privately, or as a reply to an ongoing consultation thread. In the presented scenario, Hospital (A) opts for the “Public” setting, seeking wide engagement for their request.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 19. Hospital (A) requests a medical consultation.

https://doi.org/10.1371/journal.pone.0310603.g019

Upon selecting the message content for broadcast, as depicted in Fig 19, Hospital (A) engages the “Send Message” feature. This action triggers the MetaMask wallet interface, which serves as the gateway to the Ethereum blockchain’s backend processes. The MetaMask prompt delineates the transaction’s particulars, including the Ethereum account address, the stipulated gas limit which is the fee required for successfully complete a transaction, the actual gas consumption, which is the fee, and the corresponding cost associated with this specific transaction. It then presents the user with the option to either authenticate or negate the contract interaction, ensuring that the user retains control over the transaction confirmation process. Fig 20 provides an insightful view into the MetaMask transactional interface, illustrating the critical steps of user verification required for successful transaction execution on the blockchain.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 20. Contract transaction details.

https://doi.org/10.1371/journal.pone.0310603.g020

This step is vital in preserving the security and integrity of the system, as it requires explicit user consent for any blockchain transaction, thereby reinforcing the trustworthiness of the B-UMCS. It exemplifies the seamless integration of user interface actions with the underlying blockchain operations, enhancing the platform’s user experience while upholding the stringent security measures inherent to blockchain technology.

In the B-UMCS platform, each consultation request or reply is systematized into a cohesive format, comprising five essential components for straightforward navigation and comprehension. Fig 21 exemplifies this format:

• Case Number: Prominently displayed at the commencement of the entry, this numerical identifier correlates to each new public consultation. It is designed to facilitate easy tracking and referencing within the platform’s case management system.
• Message: Positioned as the foremost element within the entry, the message succinctly encapsulates the consultation’s core appeal or response, intended for dissemination to peers on the blockchain.
• Sender Name: This element serves to attribute the communication to its originator, displaying the name of the hospital responsible for the consultation request or reply.
• Public Address: It reveals the blockchain public address of the sender, a unique digital identifier within the blockchain network, ensuring transparency and traceability. The public address is a shortened and hashed form of the public key.
• Attachment: This component becomes visible only when there is an inclusion of additional documentation, such as EHR or Medical CR, tied to the message.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 21. Display format for consultation requests and replies on the proposed platform.

https://doi.org/10.1371/journal.pone.0310603.g021

These components are intricately woven into the platform’s interface to ensure a high degree of clarity and accessibility for all participants, thereby enhancing the overall efficacy of the consultation process. Therefore, this standardized representation of cases not only streamlines the consultative exchange but also fortifies the process with a level of detail necessary for comprehensive peer review and collaborative decision-making.

Fig 23 illustrates the dialog where Hospital (B) is formulating a response to the initial request, clearly indicating their reply pertains to case number 1. This sequence is underpinned by the smart contract functions enumerated in Algorithms 2 and 3, which operationalize the communication. The parameters for the recipient’s address and the parent message identification are established as follows, with ParentID equating to the original case number, thus interlinking the subsequent communication with the initial request:

Offering consultancy.

Upon the dissemination of a consultation request by Hospital (A), Hospital (B) recognizes the request and decides to offer their expertise to the case. To initiate this process, Hospital (B) engages with the consultation announcement as exhibited in Fig 22, by selecting the “Reply” option provided therein. This action transports Hospital (B) to the dedicated reply interface, which is depicted in Fig 23. Here, Hospital (B) articulates their willingness to consult on the case by requesting additional specifics concerning the patient’s condition and associated EHR.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 22. Visibility of consultation request to Hospital (B) within the network.

https://doi.org/10.1371/journal.pone.0310603.g022

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 23. Hospital (B) formulates a Reply to the consultation request.

https://doi.org/10.1371/journal.pone.0310603.g023

Sharing the EHR.

Following the reception of Hospital (B)’s solicitation for additional details, Hospital (A) responds by securely transmitting the EHR through the platform. This is achieved by limiting the access the EHR by only restricting the access of the IPFS hash to only Hospital (B) by using it’s public key (PU(B)). Fig 24 depicts Hospital (A) in the process of uploading the EHR. This step involves selecting the pertinent file from their local device and restricting the access, to ensure for confidentiality and integrity of the patient’s file. Hospital (A) proceeds to send the message, confident in the secure delivery of the sensitive health record exclusively to Hospital (B).

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 24. Hospital (A) uploads the EHR to the platform to be then saved on IPFS.

https://doi.org/10.1371/journal.pone.0310603.g024

Upon Hospital (A) initiating the transfer of the EHR, the secure exchange between the hospitals is displayed across the B-UMCS interface. Hospital (B), possessing the private key, is thereby granted exclusive access to review the pertinent EHR. Figs 25–27 collectively narrate the interface’s updates, presenting a coherent sequence of interactions between Hospitals A and B. Particularly, Fig 25 validates that Hospital (B), upon interaction with the encrypted EHR referense, is provided the option to review and retrieve the document. In stark contrast, Hospitals A and C are presented with a clear notification stating “You don’t have access,” underscoring the rigorous enforcement of data confidentiality facilitated by the platform’s cryptographic protocols.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 25. Exclusive access granted to Hospital (B) for reviewing the EHR, demonstrating the efficacy of the restriction protocol.

https://doi.org/10.1371/journal.pone.0310603.g025

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 26. Restricted access notification for Hospital (A), highlighting the platform role in preserving data privacy.

https://doi.org/10.1371/journal.pone.0310603.g026

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 27. Hospital (C) encounters access restrictions, reinforcing the secure and targeted dissemination of medical data.

https://doi.org/10.1371/journal.pone.0310603.g027

Algorithm 4 elucidates the mechanism underlying the insurance of authorization to provide the IPFS hash of EHRs within the smart contract’s framework. The algorithm is methodically designed to authenticate the presence of an attachment within the current message. Should an attachment be confirmed, and provided the encrypting public address diverges from the sender’s or remains unspecified, the attachment URI is accordingly adjusted to a “Restricted” status. This safeguarding measure ensures that only the intended recipient, armed with the appropriate public key, is authorized to access the sensitive EHR information, thereby preserving patient confidentiality and maintaining the integrity of the medical data exchanged across the blockchain network.

Algorithm 4 Checking the Authorization of the attachment’s IPFS hash

1: Assign currentItem to items[currentIndex]

2: if the hash of items[currentIndex].attachmentURI is not empty and

3:  (the sender is not equal to idToMessageItem[i + 1].encrypt or

4:  idToMessageItem[i + 1].encrypt is the null address) then

5:  Set items[currentIndex].attachmentURI to “Restricted”

6: end if

Fig 28 presents a visual representation of the IPFS storage mechanism for a medical record. The structure illustrated denotes the distributed nature of IPFS, a content-addressable, peer-to-peer hypermedia distribution protocol. In this depiction, we observe a file characterized by a unique Content Identifier (CID), which encapsulates the file’s hash, providing an immutable reference within the IPFS network. The multihash details reveal the security and integrity of the file storage, with the SHA-256 cryptographic hash function serving as a cornerstone of this robust system. IPFS saves files on various nodes throughout its network. It utilizes a data structure known as a DAG to arrange and handle connections to nodes of data, where each node is a segment of a document, and each node contains (a hash of the node itself and links to other nodes), ensuring that the document remains intact and verifiable across the decentralized network. Such a system guarantees that the document’s authenticity and integrity are maintained without reliance on a single point of failure, embodying the principles of redundancy and resilience inherent to blockchain technologies.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 28. Illustration of an EHR’s secure storage and reference within the IPFS, highlighting the data’s decentralization and immutability.

https://doi.org/10.1371/journal.pone.0310603.g028

The architecture of the IPFS presents a multi-tiered linkage system where each node represents a block of data. Within this framework, the data is not stored in a singular location but rather distributed across a network, enhancing resilience and preventing single points of failure. The versatility of this system allows healthcare providers to interact with a robust data exchange platform, where the security of sensitive information is not a matter of concern but a given assurance. So, in the broader context of blockchain technology and its applications in healthcare, the utilization of IPFS represents a paradigm shift towards a more open, interoperable, and secure framework for health information exchange. The implications for patient care, research, and medical collaboration are substantial, as such systems enable the seamless, secure, and swift sharing of critical health data across institutional and geographic boundaries.

Sharing the medical CR.

Subsequent to the reception of the EHR by Hospital (B), a diagnostic process is initiated, culminating in the creation of a medical CR. Post-diagnosis, Hospital (B) is tasked with disseminating the CR via the platform. In alignment with preserving consultation secrecy and ensuring the confidentiality of the report, it is safeguarded through restricting the access using the public address of Hospital (A). Depicted in Fig 29 is the procedure of Hospital (B) uploading the CR and using the PU(A) to restrict the acquiring of the IPFS Hash only to hospital (A) Address. Conversely, Fig 30 delineates the exclusive accessibility of Hospital (A) to the CR bequeathed by Hospital (B), precluding any potential access by tertiary hospitals. This exclusive exchange is operationalized through the invocation of Algorithm 4, as delineated in the smart contract, which stipulates the mechanisms for both uploading and restricting the access to the the CR’s IPFS hash on the designated platform. Upon receipt of the CR, Hospital (A), through the automated recognition of PU(A), is facilitated to retrieve the document.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 29. Hospital (B) engaging in the upload the CR to the platform to be then saved on IPFS.

https://doi.org/10.1371/journal.pone.0310603.g029

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 30. Hospital (A) authorized to access the CR.

https://doi.org/10.1371/journal.pone.0310603.g030

Sending of private messages.

Hospital (C) expresses a particular interest in Case 1 and desires to examine the CR pertinent to the case. In pursuit of this information, Hospital (C) commences a private communication channel with Hospital (A) to request the CR. Fig 31 depicts the user interface through which Hospital (C) initiates the private message to Hospital (A). In the interface, the communication type “Private” is explicitly selected, as indicated by the activated radio button. The interface necessitates the entry of the recipient’s Public (PU) address; in this instance, the Public address of Hospital (A). The interaction triggers the execution of the smart contract functions: “CreateMEssgae()” as referenced in Algorithm 2, and “SendMessgae” as indicated in Algorithm 3. The Address Receiver parameter is consequently set to the Public address of Hospital (A) (PU(A)) to facilitate the secure and private transmission of the message.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 31. The process of Hospital (C) sending a private message to Hospital (A) for the CR.

https://doi.org/10.1371/journal.pone.0310603.g031

View sent messages.

Hospital (C) possesses the capability to review messages previously transmitted by navigating to the “All Sent Communications” tab. This specific interface element consolidates and displays all forms of communications—both private and public—originating from the user. Fig 32 provides a visual representation of the user interface displaying Hospital (C)’s sent communications. The functionality underpinning this feature is encapsulated in Algorithm 5, which delineates the procedure “FetchSentMessages()” for retrieving the sent messages.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 32. Interface for Hospital (C) to view all communications dispatched from their end.

https://doi.org/10.1371/journal.pone.0310603.g032

The FetchSentMessages Retrieves an array of all messages sent by the current hospital. The function checks all message items within the blockchain. First a counter is incremented to count how many message items have the same public address in the “Sender” variable that is equal to the current hospital. Then a new temp array is created named “items”, then a new loop with the length of the counter is set to go through the blockchain data. Retrieve each message item’s data, checks the sender variable if it is equal to the current hospital, then the message item is then appended to the new array “items”. Finally it also checks the restriction over the IPFS hash, if it not empty and the current hospital is not the user, or the encryption variable holds the address zero, then it is restricted.

Algorithm 5 Fetch Sent Messages

Input: None.

Output: Array Of all sent messages.

 1: function FetchSentMessages

 2:  totalItemCount ← CurrentMessageCount

 3:  itemCount ← 0

 4:  currentIndex ← 0

 5:  for i ← 0 to totalItemCount − 1 do

 6:   if Sender(idToMsgItem[i + 1] == CurrentSender then

 7:    itemCount ← itemCount + 1

 8:   end if

 9:  end for

 10:  items ← NewMessageItemArray(itemCount)

 11:  for i ← 0 to totalItemCount − 1 do

 12:   if Sender(idToMsgItem[i + 1] == CurrentSender then

 13:    currentId ← i + 1

 14:    currentItem ← GetMessageItem(currentId)

 15:    items[currentIndex] ← currentItem

 16:    if NotEmpty(items[currentIndex].attachmentURI) and

 17:  not (CurrentSender == Encryptor(idToMsgItem[i + 1] or

 18:  IsEncryptorNull(idToMsgItem[i + 1]) then

 19:     items[currentIndex].attachmentURI ← “Restricted”

 20:    end if

 21:    currentIndex ← currentIndex + 1

 22:   end if

 23:  end for

 24:  return items

 25: end function

View received messages.

Upon sending a private message to Hospital (A), Hospital (C) awaits a response. Hospital (A), in due course, accesses the “Received Messages” tab within the platform to review any direct communications. Fig 33 displays the interface where only Hospital (A) can view messages intended for them, ensuring privacy. Subsequent to viewing the private message from Hospital (C), Hospital (A) is to reply with the CR, encrypted using Hospital (C)’s public key (PU(C)), and transmitted privately to the specified address (see Fig 34). This sequence of secure message exchange is underpinned by Algorithm 6, as outlined in the smart contract, which delineates the process of retrieving private messages.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 33. Hospital (A) views the received messages.

https://doi.org/10.1371/journal.pone.0310603.g033

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 34. Hospital (A) sends the CR to Hospital (B) privately.

https://doi.org/10.1371/journal.pone.0310603.g034

Algorithm 6 Fetch Received Messages

Output: Array of messages that the hospital has received privately.

 1: function FetchReceivedMessages

 2:  totalItemCount ← Current(_messageIds)

 3:  itemCount ← 0

 4:  currentIndex ← 0

     ▹ Count received messages

 5:  for i = 0 to totalItemCount − 1 do

 6:   if idToMsgItem[i + 1].receiver == msg.sender then

 7:    itemCount ← itemCount + 1

 8:   end if

 9:  end for

 10:  items ← new MessageItem array of size itemCount

    ▹ Populate array with received messages

 11:  for i = 0 to totalItemCount − 1 do

 12:   if idToMsgItem[i + 1].receiver == msg.sender then

 13:    currentId ← i + 1

 14:    currentItem ← idToMessageItem[currentId]

 15:    items[currentIndex] ← currentItem

    ▹ Restrict attachment URI under certain conditions

 16:     if hash of items[currentIndex].attachmentURI ≠ empty and

   (msg.sender ≠ idToMessageItem[currentId].encrypt and

   idToMessageItem[currentId].encrypt ≠ null address) then

 17:     items[currentIndex].attachmentURI ← “Restricted”

 18:    end if

 19:    currentIndex ← currentIndex + 1

 20:   end if

 21:  end for

 22:  return items

 23: end function

The FetchReceivedMessages function works similar to the fetch Sent Messages, retrieves an array including all received messages to the current hospital, it first go through all message items within the blockchain, and checks if the receiver variable value is equal to the current hospital’s public address, if yes, it includes it to a newly declared array called Items that is then retrieved. It also checks the attachment restrictions if the IPFS hash is not null and the current sender’s PU is not equal to one of the messages encrypt variable’s value. Or if the encrypt variable’s value is equal to zero, then the attachment IPFS hash is then restricted.