This section introduces the main components. In addition, it illustrates the goals of the system design, the workflow of each function, and the implementation details.
System architecture
This subsection presents the SVBE system architecture. Figure 1 illustrates the structure of the proposed system, in which the essential components are shown. The main components are as follows.
The system architecture of the file storing process conducted by the medical user and the verifying file process conducted by the external user. Several components are used to perform these two functions: SVBE DApp, IPFS, cloud, and blockchain. The stored data are kept in the cloud and blockchain databases.
User application (decentralized application)
This system provides a user application that can be used by medical agents, patients, and external beneficiaries. The application offers two functions related to the patients (add patients and verify patients) in addition to three functions related to the patient records. In this work, three functions related to the patient records are introduced. The first function adds the patient medical files. The second function is a validation service for the stored files that any external beneficiaries can use without worrying about tampering with original data based on the blockchain characteristics. The third function searches for any medical file stored in the system. One of the most important application tasks is to encrypt the uploaded files using the asymmetric cryptography algorithm ECC.
Interplanetary file system (IPFS)
Medical systems usually deal with files that can be rather large, which causes difficulty in storing them directly on the blockchain. Hence, the SVBE system needs to deal with a reliable storage environment. The system adopted the IPFS decentralized environment to store the patients medical files. IPFS is considered a suitable solution for dealing with medical files due to several advantages, such as being free from a single point of failure and having high throughput in storage. An IPFS generates a unique hash for each stored file, giving users the ability to find that file by the hash address.
Cloud computing storage
The proposed SVBE system relies on storing all data in the cloud. The system stores all encrypted patient data such as personal data, file type, and the keywords of the stored files, in addition to the IPFS hash of the encrypted file. In addition, the system stores the actual content of the medical files after encrypting them to maintain data privacy.
Blockchain network
As mentioned earlier, since it is difficult to store large files in a blockchain environment, the system restricts the storage to the IPFS address of the medical files and all the encrypted patient personal information in the blockchain environment. The whole encrypted file is stored in the cloud.
Design goals
To be effective, the proposed system must achieve the following design goals:
-
The system should ensure the security and privacy of the patient records. Therefore, the system has to apply strict rules to guarantee data integrity and confidentiality, and the system needs to prevent access to the records by any unauthorized entities.
-
The system should have the ability to search for any file or patient despite the encryption.
-
The system should provide the ability to verify the files by any outside related entity.
-
The system must achieve high performance and low costs regarding latency, storage, and price to be suitable for adoption in the medical sector.
Workflow
The system provides three essential functions. The first function is storing a file in the patient record. The second function is verifying from any stored file. Finally, the third function is searching. The three functions are available only for the authorized health agents, except the verification function is available to any external entity. Each functional workflow is described in detail in the following subsections.
Files addition function
To add a new file, it is required that the patient who owns the file has a previous record in the system. Blockchain databases are not suitable for storing extensive data. To decrease the blockchain overhead, fewer data are stored in the blockchain database compared to the data stored in the cloud database. Thus, blockchain and cloud require different inputs sent by the Dapp based on the user inputs. The inputs of each party are explained as follows.
The following tuple shows the data that our system’s decentralized application requires for adding a new file:
$$begin{aligned} AddingFile_{DAPP}=(P_{id}, T_{f}, K_{w}, f) end{aligned}$$
(1)
where:
(P_{id}) = means the patient’s identification number.
(T_{f}) = the type of file, whether it is a report, medical test, medical history, etc.
(K_{w}) = keywords that relate to the file content that can use it in the search process.
(f) = a new file of a patient that will store in a medical records system.
The following tuple describes the data that are sent to the blockchain upon adding a new file:
$$begin{aligned} AddingFile_{BC}=(P_{id},f_{hash}) end{aligned}$$
(2)
where:
(f_{hash}) = hash of the file generated from IPFS.
The following data are sent to the cloud:
$$begin{aligned} AddingFile_{C}=(P_{id},f_{hash},T_{f}, K_{w},f_{ec}) end{aligned}$$
(3)
where:
(f_{ec}) = encrypted file content.
As evident, the system excludes the entire content of the encrypted file stored in the blockchain due to the difficulty of storing large files or data in the blockchain database. Hence, it compensates by storing the encrypted file in the cloud. Storing the encrypted file in the cloud helps the medical user access and retrieve files directly from the cloud by entering the file IPFS hash. Figure 2 shows the workflow of the file adding process.
A sequence diagram of the process of adding files process to the system. The process starts by uploading a file, encrypting it, sending it to the IPFS to generate a hash, and then storing it in the cloud and blockchain.
File verification function
The system provides a service to verify files circulating between users to prevent fraud and forgery. An IPFS hash is stored for each file exported from the medical system. Therefore, during the verification process, the user must enter the patient’s ID in addition to uploading the file to be verified. The following tuple shows this step:
$$begin{aligned} VerifyFile_{C}=(P_{id},f_{ec}) end{aligned}$$
(4)
When the file is uploaded, all the steps applied when uploading a new file are performed, which means that if this file is trusted, it will get the same IPFS hash of the original file stored in the system. When the Dapp sends the IPFS hash to the blockchain, the blockchain informs the system that this file is identical to one of the files stored in the patient’s record. Hence, a message will appear to the user stating that this file is trusted. In case of the file is forged or modified, its IPFS hash will not match any of the files stored in the patient record in the blockchain, and a message will appear to the user stating that the file is not trusted. The verification process relies upon the blockchain rather than the cloud because the blockchain environment is more reliable.
Search function
Search is a required feature to make the system more functional. The medical user can search for any patients file they need by entering two mandatory inputs: the type of file and the keyword who wants to search for. The time range of the patient birth year is an optional input to narrow the search. If the medical user wants to narrow the search, they need to enter the time range they want to search through. The following tuple explains the search process.
$$begin{aligned} Searching File_{DAPP}=(T_{f}, K_{w}, B_{starty}, B_{endy}) end{aligned}$$
(5)
where:
(B_{starty}) = demotes the start of the search time range.
(B_{endy}) = demotes the end of the search time range.
A sequence diagram of a search process in the system through which file type and the keywords are entered (additionally, it is possible to enter the time range), encrypted, and searched in the cloud, which together generate the results.
Figure 3 shows the search function. The search is performed directly by searching in the cloud database to reduce the costs involved in the blockchain environment. Moreover, an inverted index technique is used to index the keywords in the cloud to reduce the search cost. An inverted index form is a pair (key, value), where the key is a keyword and the value is a list of IPFS hash of files related to the keyword. Table. 1 shows the architecture of the files linked with the keywords in the cloud. The search results can be customized either by returning the file hash or the patient’s ID.
Implementation
The detailed implementation and tools used in the proposed system are presented. Additionally, the system design and description of the data stored in the cloud and blockchain databases are illustrated in the following subsections.
System settings
The proposed system consists of several parts: the user application, smart contract blockchain, IPFS, and the cloud database. For the blockchain, a simulated public Ethereum network is used. The model uses a local Ganache to run a local blockchain. Ganache provides 10 accounts, each with 100 ethers that are used to conduct the transactions. These accounts can be used by using MetaMask, a web browser extension that links the application with the smart contract. The smart contract was written in the Solidity language using the Remix code editor. The user application was written in Javascript. The system uses a React library to build the user frontend. The node package manager (NPM) of ECC was used to encrypt the data. To link the application with the blockchain network, the WebJs3 library was used, which is a library that interacts with MetaMask in the application. Furthermore, the system uses IPFS to generate a hash for each medical file. For cloud storage, the system uses two Firebase products: Cloud Firestore and Cloud Storage, to store both separate data and medical record files.
System design
A smart contract was built for the system, which the system administrator monitors. The smart contract conducts several functions, including add_file and verify_file. The pseudocode of these two functions is explained in Algorithm 1. The search function is conducted on the cloud database. The pseudocode of the search function is described in Algorithm 2.
Cloud-based data storage
The proposed system uses two Firebase products: Cloud Firestore and Cloud Storage. Cloud Firestore is a NoSQL database that accepts several data types. The Cloud Firestore database is organized as a hierarchical structure. The root of Cloud Firestore is a collection; each collection has many documents depending on the stored data. Then, each document has several attributes. There are three collections in Cloud Firestore: patients, files, and keywords. Storing any patient on the patient collection requires five fields: ID, first and last name, and birthdate. The system stores the birth year as a separate attribute to allow an encrypted search for patients of a specified age. File collection contains two fields: patient ID, which links the file with its owner, and the IPFS hash of the file. The keyword collection includes two values: the keywords and the list of the IPFS hashes. The keyword is stored in a document, and each keyword document contains a list of IPFS hashes of files associated with the keyword. Cloud storage is a storage service suitable for storing files, voices, or images. Cloud storage stores the files and provides information about them, namely, the filename, size, type, and last modification. Cloud storage is used to store patient medical documents and images. Each file name with its IPFS hash to link each file with its owner’s medical record.
Blockchain-based data storage
There are fewer data stored in the blockchain than data stored in the cloud. Generally, the data stored in the blockchain are divided into two parts: one for the patients and the second for the files. The patient part stores four attributes, which are the same as those stored in the cloud: ID, first and second name, and birthdate. Then, the file part stores two attributes: a patient’s ID connected with the list of all IPFS hashes of its files.
